#tasafoEmbarcAÇÃO no Barco Hacker!

O Ta safo! recebeu o convite e irá embarcar em mais uma expedição de um projeto sensacional, o Barco Hacker! Iniciativa tocada pela galera da Casa da Cultura Digital de Belém.

É juntar a fome com a vontade de comer, queríamos muito realizar um lance desses. A programação está só o creme e será uma excelente oportunidade de conversar com uma galera de diferentes segmentos e falar um pouco de nossa experiência de alguns anos pelo Tá safo!, através de um debate sobre: “Os desafios do empreendedorismo em comunidades”.

O evento será realizado no dia 19 de setembro a partir das 18hs com a saída do barco do Píer do Hotel Good Mar, Rua Professor Nelson Ribeiro, 132, Bairro do Telégrafo.

A programação completa, inscrições e mais informações estão no link https://doity.com.br/barcohacker. Até lá, marujos e marujas!

PS.: Quem não sabe nadar, não precisa levar bóia de braço. Terá colete salva-vidas no barco : P

E obrigado Breno Peck pela foto do barco no veropa.

Tá safo! no Agilidade@Recife 2014

AR2014-ChamadaMail

Tenho a satisfação de participar da organização, e levar junto a bandeira do Tá safo!, do evento que a cada ano leva para Recife palestras e workshops de qualidade sobre a temática da gestão e desenvolvimento ágil de software. Também terei a oportunidade de palestrar mais uma vez, agora para falar um pouco sobre Técnicas e ferramentas para manter a sanidade em uma startup. Que venha mais um Agilidade@Recife! Segue o anúncio do evento:

No próximo dia 02 de outubro, das 8h às 18h, no Auditório do Banco do Brasil (Av. Rio Branco, s/n), vai acontecer o Agilidade@Recife. O evento, que conta com o apoio do Softex Recife e do Porto Digital, é um conjunto de palestras e workshops com o objetivo de criar um ambiente colaborativo para que a comunidade de software da região compartilhe e agregue conhecimento de valor durante todo o dia de encontro, sobre temas relacionados aos métodos ágeis de desenvolvimento de software.

Nesta sétima edição do evento, o Agilidade@Recife pretende reunir novamente desenvolvedores, líderes, gerentes, executivos, pesquisadores, estudantes e outros interessados na adoção de métodos ágeis no desenvolvimento e gestão de produtos de software. Serão 6 palestras, 2 sessões práticas e um momento para open spaces (dinâmica onde os próprios participantes discutem temas de interesse comum).

A programação do evento conta com palestrantes conhecidos nacionalmente quando o assunto é agilidade, como Alisson Vale, Alexandre Magno, Marcos Garrido, Juliano Ribeiro e Dairton Bassi, entre outros. Empresas como Globo.com, Instituto Nokia de Tecnologia, Liferay do Brasil e TV Globo também estarão marcando presença no evento, narrando suas experiências na área.

As inscrições estão abertas e devem ser realizadas através do acesso ao link: http://www.eventick.com.br/agilidaderecife2014. Para mais informações acesse o site do evento: http://agilidaderecife.com.br/ ou envie um e-mail para agilidaderecife@gmail.com.

Mocks e Stubs com Rspec

mock-vs-stubs-clerb-presentation-1-728

Mocks e stubs são conceitos, muitas vezes de difícil compreensão, principalmente para desenvolvedores iniciantes em testes automatizados. Eu mesmo levei um tempinho para compreendê-los e nem sei se entendi muito bem. Por trás disso existe uma nomenclatura um tanto confusa e que não ajuda muito na compreensão dos conceitos. Vamos analisar como o Rspec trabalha com eles utilizando a biblioteca rspec-mocks.

Muitas vezes quando estamos escrevendo nossos testes, precisamos utilizar de objetos falsos. Em determinados cenários, o objeto real pode não estar disponível ou é necessário utilizar algum recurso externo que pode deixar o teste lento. Algumas vezes não precisamos testar o estado do objeto mas sim seu comportamento. Chamamos esses objetos falsos de Test Doubles ou Dublês de teste. Mocks e stubs são dois dos tipos especializados de doubles e são os mais utilizados.

Stubs

Simulam implementações dos objetos reais através de métodos que retornam valores pré-determinados. São métodos pré-configurados com as informações necessárias para a execução dos testes. Abaixo temos um exemplo de declaração de um test double.

  double = double('user', name: 'Tyrion Lanister')

O primeiro parâmetro é uma descrição do dublê que é usada na documentação e nas mensagens de falha. O segundo é o método stub setado com um valor qualquer. Vamos a um exemplo melhor. Queremos testar o método calculate_total_price da classe Order.


class Order
  attr_reader :total

  def calculate_total_price itens
    @total = 0
    itens.each { |item| @total += item.price }
  end

end

Podemos testar esse método sem instanciar o objeto real Item, através de stubs.


describe Order, "#calculate_total_price" do

  let(:itens) { [double(price: 10.0), double(price: 45.5)] }

  it "calculates the total price" do
    order = Order.new
    order.calculate_total_price(itens)

    expect(order.total).to eq(55.5)
  end

end

Na linha 3 setamos um array de doubles ao invés de uma array de objetos da classe Item. O teste irá passar. Isso é muito útil em testes  de unidade,, pois não precisamos acessar o banco de dados para pegar os dados do objeto Item que poderia ser um modelo do Active Record.

Mocks

São doubles pré-programados que irão criar expectativas que deverão ser satisfeitas pelos testes. Podemos usá-los quando queremos testar a chamada de uma api externa, por exemplo. Vamos dar uma olhada no exemplo abaixo.


class Westeros

  def geolocate(place)
    Geocoder.coordinates(place)
  end

end

O método geolocate da classe Westeros tem uma chamada da bilblioteca geocoder que retorna as coordenadas geográficas de um dado endereço. Precisamos testar se o método coordinates de Geocoder irá mesmo retornar as coordenadas? Acho que não. Os desenvolvedores da gem já fizeram isso. Precisamos mesmo é garantir que o método geolocate de Westeros irá chamar coordinates de Geocoder com o parâmetro correto. Para isso vamos usar um mock.


describe Westeros, "#geolocate" do

  it "retuns coordinates" do
    place = 'Ponta Tempestade, Westeros'
    westeros = Westeros.new

    expect(Geocoder).to receive(:coordinates).with(place)
    westeros.geolocate(place)
  end

end

Na linha 7 definimos as expectativas. Geocoder deve executar o método coordinates com place como argumento. O teste passa. Dessa forma testamos a interface de geocoder e não seu funcionamento interno. Um detalhe a parte é a dsl do rspec que deixa a leitura muito simples e agradável proporcionando um modo bastante elegante de se escrever testes.

conclusão

O rspec possui muitas outras inúmeras funcionalidades no que diz respeito a test doubles e testes regulares. A prática e a experiência irão melhorar ainda mais o entendimento dos conceitos de mocks e stubs, assim como os conceitos de testes automatizados. Existem uma infinidade de artigos sobre o assunto na internet. Vale a pena dar uma pesquisada no assunto.

Referências

https://github.com/rspec/rspec-mocks

http://www.infoq.com/br/articles/mocks-Arent-Stubs

Iniciando com Elasticsearch

elasticsearch

Elasticsearch é um mecanismo de busca open source, desenvolvido ‘em cima’ do Apache Lucene, uma engine de pesquisa full-text. Podemos dizer que o Elasticsearch abstrai a api do Lucene, que apresenta uma certa complexidade e curva de aprendizado alta. Mas o Elasticsearch não é somente uma engine de pesquisa full-text:

  • disponibiliza dados em tempo real
  • pode ser distribuído e configurado para apresentar alta disponibilidade
  • é orientado a documentos
  • disponibiliza uma api restFul

O Elasticsearch armazena dados em forma de documentos. Ele disponibiliza os documentos no formato JSON, que é suportado pela maioria das linguagens de programação modernas e também é o formato usado pelo movimento NoSQL.

Em Elasticsearch, um documento pertence a um Tipo e esses tipos estão localizados dentro de um Index. Podemos dizer, fazendo uma analogia com banco de dados relacionais, que os Indices são os banco de dados, os Tipos são as Tabelas, documentos são os registros das tabelas e os campos são as colunas das tabelas.


{

  "email": "john@smith.com",

  "first_name": "John",

  "last_name":  "Smith",

  "info": {

    "bio": "Eco-warrior and defender of the weak",

    "age": 25,

    "interests": [ "dolphins", "whales" ]

  },

  "join_date": "2014/05/01"

}

A palavra index pode ter diferentes significados dependendo do contexto. Indexes, ou Indíces são como banco de dados, como explicado anteriormente. Indexar um documento é armazená-lo em um Index, para que ele possa ser consultado posteriormente. O Elasticsearch utiliza uma técnica chamada índice invertido que permite com que os usuários executem procuras rápidas por palavras-chave e localizem os documentos que correspondem a uma determinada consulta.

Existe também o conceito de node (nó) que é uma instância do Elasticsearch em execução. Um cluster é um grupo de nós com o mesmo cluster.name que trabalham juntos e compartilham dados para prover escalabilidade e alta disponibilidade.

Instalação

Para instalar o Elasticsearch é necessário a última versão do java estar instalada na máquina. Você pode instalar através do site www.java.com. E fazer download do Elasticserch em elasticsearch.org/download. Em produção você pode instalar usando os pacotes Debian ou RPM na página de download ou usar Puppet ou Chef.

Após baixar o pacote zipado e desempacotá-lo, você poderá executá-lo em um terminal:


./bin/elasticsearch

Adicionando o parametro -d você poderá executálo em background.

Já sabemos que o Elasticsearch disponibiliza uma api restFul. Logo podemos fazer um teste executado o seguinte comando:


curl 'http://localhost:9200/?pretty'

Que deverá retornar:


{

  "status": 200,

  "name": "Shrunken Bones",

  "version": {

    "number": "1.4.0",

    "lucene_version": "4.10"

  },

  "tagline": "You Know, for Search"

}

Significa que seu cluster está em execução.

Tentando entender a bagaça

Vamos analisar um exemplo simples utilizando a modelagem do twitter:

  • Indexar um documento por usuário que contem informações de um único usuário do twitter
  • cada documento será do Tipo user
  • esse tipo estará dentro de um Index twitter
  • esse Index estará dentro de um cluster Elasticsearch


Primeiramente, iremos criar um usuário do twitter:


curl -XPUT 'http://localhost:9200/twitter/user/tasafo' -d '{ "name" : "TáSafo" }'

O comando acima deverá retornar:


{"_index":"twitter","_type":"user","_id":"tasafo","_version":1,"created":true}

Para recuperar os dados salvos anteriormente, poderemos executar o seguinte comando:


curl 'http://localhost:9200/twitter/user/tasafo'

Lembrando:

  • twitter é o index
  • user é o tipo
  • tasafo é o id que identifica o documento

Agora iremos criar um tipo tweet que faz referência a uma mensagem que o usuário twitou:


curl -XPUT 'http://localhost:9200/twitter/tweet/1' -d '
{
  "user": "tasafo",
  "postDate": "Sat, 09 Aug 2014 19:50:57 -0300",
  "message": "Testando Elasticsearch. Safo até agora!"
}'

Vamos verificar os dados que foram adicionados:


curl -XGET 'http://localhost:9200/twitter/tweet/1?pretty=true">http://localhost:9200/twitter/tweet/1?pretty=true'

Mais uma twitada:


curl -XPUT 'http://localhost:9200/twitter/tweet/2' -d '
{
  "user": "tasafo",
  "postDate": "Sat, 09 Aug 2014 19:52:57 -0300",
  "message": "Testando Elasticsearch. Essa parada é muito fácil!"
}'

Agora vamos encontrar todos os twitts de tasafo:


curl -XGET 'http://localhost:9200/twitter/tweet/_search?q=user:tasafo&pretty=true">http://localhost:9200/twitter/tweet/_search?q=user:tasafo&pretty=true'

O comando irá retornar o seguinte documento:


{

  "took" : 3,

  "timed_out" : false,

  "_shards" : {

    "total" : 5,

    "successful" : 5,

    "failed" : 0

  },

  "hits" : {

    "total" : 2,

    "max_score" : 0.30685282,

    "hits" : [ {

      "_index" : "twitter",

      "_type" : "tweet",

      "_id" : "2",

      "_score" : 0.30685282,

      "_source":{"user":"tasafo", "postDate":"Sat, 09 Aug 2014 19:51:57 -0300 ",      "message":"Testando Elasticsearch. Essa parada é muito fácil!"}

    }, {

      "_index" : "twitter",

      "_type" : "tweet",

      "_id" : "1",

      "_score" : 0.30685282,

      "_source":{"user":"tasafo", "postDate":"Sat, 09 Aug 2014 19:51:57 -0300 ", "message":"Testando Elasticsearch. Safo até agora!"}

    } ]

  }

}

Para queries mais complexas, podemos usar JSON ao invés de query string, utilizando a Query DSL:


curl -XGET 'http://localhost:9200/twitter/tweet/_search?pretty=true' -d '
{
  "query" : {
    "match" : { "user": "tasafo" }
  }
}'

Agora vamos testar a pesquisa full-text. Para isso usaremos a query dsl com o campo message:


curl -XGET 'http://localhost:9200/twitter/tweet/_search?pretty=true' -d '
{
  "query" : {
    "match" : {
      "message": "testando safo"
    }
  }
}'

Por padrão, o Elasticsearch ordena o resultado por sua relevância. O comando irá retornar todos os resultados que contenham a palavra testando e ou safo no campo message.

Conclusão

Esse foi um tutorial simples para se iniciar os estudos de Elasticsearch. É claro que ele possui inúmeras outras features, como sugestão, geolocalização, analytics e muitas outras. Nenhuma configuração hard é necessária para começar e já existem apis em várias linguagens. Em outros artigos podemos verificar o funcionamento dessas apis.

 

Concrete Solutions estará em Belém para recrutamento de desenvolvedores Android e iOS

Alô, desenvolvedores de Belém!

Dia 08/08, Olavo Castro (Arquiteto de Soluções) da Concrete Solutions estará em Belém para bater um #papoSafo com a Comunidade. Na ocasião, ele irá apresentar a palestra:

 

Times mobile: uma trajetória de aprendizado

Descrição:

Esta palestra tem por objetivo mostrar como a Concrete Solutions conseguiu montar e manter times de alta performance em um cenário de constante mudança como a mobilidade, considerando um aprendizado de 12 anos e o jeito certo de fazer software atualmente: com métodos ágeis, Lean e efetivo gerenciamento de produto.

Ao final, será lançada uma seletiva para recrutamento de desenvolvedores Android e iOS para trabalharem em São Paulo. Mais detalhes em http://goo.gl/Q5q2A8.

E aí, ficou interessado? Então não perca essa oportunidade e garanta sua vaga fazendo sua inscrição neste link.

Código legado. O Horror!!

Cthulhu

Cthulhu

Existem, na comunidade, várias definições para o que seria código legado: todo código que você escreveu é legado; o código que outra pessoa escreveu é legado; o código ruim, de difícil manutenção é legado. Não importando a definição, podemos identificar uma característica primordial, o código legado é aquele difícil de mudar. E isso, geralmente é um terror para os desenvolvedores.

Quem escreveu o código, não necessariamente é um desenvolvedor ruim. Precisamos entender o contexto. Mas gosto da idéia de que a qualidade do código é um espelho do local onde ele foi desenvolvido. Se o código é ruim, a empresa pode apresentar sintomas graves de uma péssima gestão, principalmente em se tratando de comunicação inter-departamentos, já que normalmente as demandas não vem de TI. Nesse cenário, será bem difícil trabalhar em melhorias do código legado, enquanto não houver melhorias nos processos internos da empresa e um alinhamento de negócios com TI. Mas, ainda assim, agente tenta.

Já tive a oportunidade de trabalhar em muitos projetos legados. Sei que você também tem muita história pra contar a respeito de suas aventuras nas matas densas do legado. Você irá achar que, a partir daqui, eu estarei exagerando e querendo causar polêmica, mas não, o que vou contar é a mais pura verdade. Já trabalhei com código que dava vontade de vomitar só de olhar pra ele. hahaha. Não é pra tanto, mas já chegou perto disso.

Trabalhei em projetos legados bem complexos e com uma base de código bem ‘doente’, normalmente monstros monolíticos. Mas apesar disso, os softwares eram, e são até hoje, bastante elogiados. Assim como para seres humanos o que importa é o caráter e não a aparência, para software o que importa é o valor que ele entrega ao cliente. Mas isso é só um lado da moeda. Aqueles sistemas tão elogiados de que falei faziam bem o seu trabalho, mas apresentavam uma base de código extremamente difícil de gerenciar, o que dificultava a criação de novas funcionalidades e melhorias.

Outro fator que considero importante em um cenário como esse é a satisfação com o seu trabalho. É bem ruim ter que trabalhar todo dia fazendo remendos em uma estrutura ‘capenga’. É desmotivante, é cansativo e isso pode aumentar a rotatividade em sua empresa. E a alta rotatividade de desenvolvedores é um fator que contribui a gerar mais código ruim. É extremamente frustrante quando, devido a algum fator, ou vários fatores, não é possível melhorar a base de código.

Você pode achar que isso tudo é muito mimimi. Mas que fique claro que o maior prejudicado nessa história é a empresa que mantém o código. Se não for possível fazer melhorias, a empresa terá que conviver com os custos de se manter um legado ruim. A escolha é sua, ficar no mimimi ou partir pro ataque.

Enfrentando o monstro

Uma outra definição para sistemas legados, e essa foi a que mais gostei, nos diz que sistema legado é todo sistema que não está coberto por uma suíte de testes, ou seja, você estará construindo código legado toda vez que você escreve código sem testes. Interessante. Então fica a dica: sempre que for refatorar, escreva um teste, se bem que refatorar sem testar não faz sentido. Mas quando se tem uma base de código muito grande e complexa, isso não é tão fácil. Além disso, você irá encontrar no legado muitos recursos que nem são utilizados. Puro lixo.

O código legado tem a característica de ser bastante acoplado. Então uma forma de começar a refatoração é isolando as dependências e trabalhar em cima delas. Inicialmente pode ser inviável criar testes de unidade, mas é possível criar testes de aceitação e isso pode ser um bom começo.

Outra forma seria o que Martin Fowler chama de estrangular a aplicação. Você vai criando um novo sistema nas bordas do antigo, muitas vezes de forma transparente ao usuário. Não é uma tarefa tão simples, principalmente se precisar rever a modelagem do banco de dados. É um processo bastante demorado e pode durar anos, mas é eficaz. É importante estar alinhado com a gerência e que ela saiba o que você está fazendo, mas algumas vezes é mais fácil pedir perdão do que permissão, essa é a verdade.

Um outro cenário é reescrever tudo. Isso pode ser possível, mas tem que ser analisado com cautela. Dependendo do contexto pode ser a melhor solução, ou pode ser catastrófico. Tive a experiência de trabalhar num sistema legado que estava até bem escrito. O problema é que ele havia sido desenvolvido com um framework caseiro que possuia geradores de código e o dono não estava mais na empresa. Não havia muito o que fazer. Resolvemos reescrever tudo com um novo framework que estávamos testando na época (um framework bastante conhecido e usado pela comunidade). Um fator que ajudou bastante é que a modelagem de dados do sistema legado estava impecável, então reaproveitamos o banco.

Uma dica final é sempre seguir padrões. Estar atento ao que a comunidade recomenda e participar de eventos é importante. Você pode estar sendo o vilão escrevendo o legado de amanhã. Poupe sua mãe de xingamentos. Lembre-se que o código não é seu, mesmo que você o tenha escrito.

referências:

Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2005.

Martin Fowler, “StranglerApplication”, http://www.martinfowler.com/bliki/StranglerApplication.html.

Mary e Tom Poppendieck, Implementando o Desenvolvimento Lean de Software