Quem já está há mais de 10 nos no mercado de trabalho, provavelmente viu a máxima “convention over configuration” assassinar muitos XMLs e configurações desnecessárias; a época do “deve ser tudo customizável”, foi substituída por: “me dê um padrão que eu altero o que precisar”, e consequentemente aquele Dinossauro chamado Enterprise JavaBeans 2.X foi extinto (ok, ok, ainda deve existir algum exemplar em algum oceano beeeem profundo).

Depois veio o Rails com sua facilidade e simplicidade comovente e todos da comunidade Java começaram a se perguntar: “Será que precisa ser tudo tão complexo e burucrático ? “, e mais uma revolução veio e mudou inclusive a forma de pensarmos. Entretanto algumas coisas que fazemos ainda são jurássicas, exemplo: Deploy em produção!

Duas coisas na nossa vida que deveriam ser extremamente fáceis, e dificilmente o são (pelo menos em todos os lugares que eu trabalhei): Buildar o projeto na sua máquina e fazer o deploy em produção.

Quando um funcionário novo começa a trabalhar, tudo o que ele deveria fazer é baixar o código do SCM (subversion, git, etc.), dar um comando, ou um clique e estar pronto para contribuir escrevendo código. Traduzindo para o mundo Git + Java:

git clone projeto_que_vou_contribuir
cd projeto_que_vou_contribuir
mvn clean install (ou ainda melhor: mvn clean tomcat:run)

e voilá!

Idealmente, o processo de deploy também deve ser simples, rápido, indolor e de fácil rollback, porque todos nós sabemos: “shit happens”. Sou adepto da filosofia “one click to rule them all”, ou seja, apenas um passo para ter tudo pronto. Claro, o processo de deploy depende muito de empresa para empresa, da tecnologia utilizada, se o dev tem acesso ao ambiente de produção ou não e mais uma porrada de outras variáveis, porém o importante é seguir a máxima: “1 clique para fazer o deploy”.

Nessa linha, recentemente li um livro que me ajudou muito: Jenkins the definitive guide. Ok, sempre imaginei que o jenkins é completamente intuitivo de se usar e que não precisa de um livro, mas este livro conseguiu me supreender. Após a leitura comecei a ter várias idéias de como automatizar ainda mais o processo de deployment no meu trabalho, e acredito que cheguei em um panorama bem interessante, um passo importantíssimo rumo ao “continuous deployment” e que eu vou descrever os pontos mais importantes:

• Ter 1 job para fazer checkout do codigo no scm e gerar o artefato do maven (.war, .ear, etc.)
• Ter 1 job separado para copiar o artefato do job anterior e fazer o deploy no artifactory
• Ter X jobs (onde X é o número de servidores em prod) para copiar o artefato deployado no artifactory e fazer o deploy no servidor (tomcat no meu caso)
• Ter 1 Jobs para fazer rollback (que chama os outros X jobs do passo anterior especificando uma versão).

E para startar toda essa pilha de jobs, tudo o que preciso é fazer um git-push no meu branch production.

Prós desta abordagem:

• “1-click build”. Com apneas um push no branch production qualquer dev é capaz de fazer um deploy em prod, sem mesmo ter acesso ao ambiente de produção.
• Temos no branch production o código exatamente como ele está em produção, para eventual bugtracking ou analise.
• Fácil rollback. Com um clique, pela interface do jenkins é possível disparar um rollback
• Rastreabilidade: pelo jenkins consigo saber exatamente o que está em produção.
• Simplicidade

Obviamente ainda há o que melhorar, como por exemplo uma forma de externalizar as configurações de ambiente, para que o mesmo WAR que vai para o ambiente de teste também vá para a produção, mas acredito que esse foi um importante passo. Inclusive, gostaria de deixar uma dica:

O dia que você se acomodar com a sua forma de trabalhar e parar de pensar em como poderia otimizar ainda mais o seu trabalho, duas coisas podem ter acontecido: Você perdeu a paixão pelo que faz e se tornou algum comum, ou você atingiu o nirvana.

Portanto, nada mais justo do que uma recomendação dos últimos livros que li e que julgo serem fundamentais para qualquer programador que queira melhorar a qualidade do seu trabalho, ou melhor, da sua arte.

• Effective Java 2nd. Edition - Fundamental para qualquer programador java. (ponto !)

• Clean Code - Gostei muito deste livro. O Autor, Uncle Bob, escreve muito bem e é super didático em seus textos. Há algumas polêmicas, como por exemplo o capítulo de comentário, e o de TDD, mas em suma é um excelente livro. Altamente recomendado se você também acredita que programar é uma arte e que, como toda arte, pode ser melhorada continuamente.

• The Clean Coder - Estou quase terminando de ler, e também estou gostando muito. É do mesmo autor do livro acima, porém eu indicaria esse livro mais para líderes técnicos, pois fala muito sobre profissionalismo e a postura que um programador deve ter em relação ao trabalho, ao time de negócio / produto, etc.

Se você acredita que já é bom o bastante, ou que aprende tudo o que quiser através do google, saiba que eu também tinha um pensamento parecido, e me surpreendi com os livros acima. Hoje posso dizer que a minha forma de programar, de pensar, minha política de sempre tentar melhorar um código que estou lendo e que não necessariamente escrevi (“boyscout rule” – Clean Code), e a minha postura profissional, evoluiu muito.

Com certeza o Rafael versão 2011 é bem melhor que o Rafael 2010, e também muito mais humilde =p.

Algum outro livro interessante para o meu Kindle ?

Talvez amanhã…

Bom dia! Estou participando do RailsSummit, o maior evento de RoR da America Latina. A Infra estrutura está ótima e a palestra do Chad Fowler foi bem inspiradora. Acompanhe tudo o que está acontecendo através do meu twitter: @rafaelmanoel

[]‘s
Rafael

O Problema comecou quando eu tive que sair da convenção do Rails. Tenho uma classe, digamos Customer, por exemplo, que possui dois Addresses:

class Customer < ActiveRecord::Base

has_one :business_address, :class_name => 'Address'
has_one :home_address, :class_name => 'Address'

end

Para os meus testes, criei os arquivos de fixtures

# addresses.yml

endereco_1:
street: Endereco 1

endereco_2:
street: Segundo Endereco

# customers.yml
rafael:
name: Rafael
business_address: endereco_1
home_address: endereco_2

Com as novas sexy fixtures, acreditei que isso seria possível. Porém, as fixtures, por natureza, refletem o que está no banco de dados, e nao nos objetos. Não importa que a minha classe Customer tenha atributos business_address e home_address mapeando para a classe Address, o sistema de fixtures não irá conseguir vincular o meu endereco_1 e endereco_2 com o customer rafael. Eu teria que criar uma fixture da seguinte forma:

# customers.yml
rafael:
name: Rafael
business_address_id: 1
home_address_id: 2

E com isso, perder toda a legibilidade. Imagina a bagunça que ficaria se todas as associações do meu modelo fossem com os ids. Quem conseguiria entender além do computador ?

Foi por isso que decidi utilizar o factory_girls. Com ele é possível fazer este tipo de associação sem ter que ficar fazendo macumba gambiarra workarounds. Após a instalação da gem, e configuração (que pode ser vista aqui), basta criar um factories.rb da seguinte forma:

Factory.define :endereco_1, :class => Address do |a|
a.street "Endereco 1"
end

Factory.define :endereco_2, :class => Address do |a|
a.street "Endereco 2"
end

Factory.define :rafael, :class => Customer do |c|
c.association :business_address, :factory => endereco_1
c.association :home_address, :factory => endereco_2
end

E no seu teste:

rafael = Factory(:rafael)

Simples, não ? E bem melhor…

http://www.neeraj.name/blog/articles/589-block-vs-lambda-vs-proc

[]‘s

Rafael

Já se passaram 12 anos desde então e eu ainda tenho essa dúvida! Incrível, não ? Mas acho que isso é algo que levarei comigo para o túmulo. Evidentemente há várias técnicas para melhorar a qualidade (caramba, não queria utilizar esta palavra) do seu código. Ultimamente tenho estudando bastante isso e me forçado a não me corromper com códigos ruins, por conta de prazos apertadíssimos. Eis que cheguei em algumas conclusões:

1. Tente não violar a Lei de Demeter. Se você ainda não compreender a beleza por trás da sua simplicidade, não tem problema você pode segui-la mesmo assim, ou dar algumas cabeçadas e ver que o problema todo é que suas classes falam com muitas outras que não deveriam.
2. TDD! Ok, isso é polêmico, mas pense assim: Quando você se utiliza de TDD, você se torna o primeiro cliente do seu código, e acredite, você vai querer mudar bastante suas interfaces para agradar a você cliente.
3. Já que falei de interfaces, lembre-se: “Programe para interfaces!!!!” (ok, 4 exclamações acho que basta =p ).
4. Codifique pensando no teste (unitário) e teste pensando no código. Se a criação dos testes estiver se tornando uma tarefa árdua, há algo de errado no seu design
5. Nunca se acomode com o design de suas classes. Acredite, sempre pode ser melhorado.

Acho que consegui resumir o que ando fazendo para tentar melhorar o meu jeito de codificar, de forma que a manutenção do código que eu escrevo não seja tao árdua. E agora, para finalizar, uma frase do Martin Fowler que eu adoro:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

E é isso o que estou perseguindo. Um dia eu chego lá.

A cada dia que passa, evoluímos mais, aqui na empresa, para um cenário estável de integração contínua. O que isso quer dizer ? Bom, integração contínua, é você ter o status do seus sistema (testes, cobertura, javadoc, build, release, etc.) em um único ponto, e de fácil acesso. Com isso, fica simples ver quando alguém faz uma macacada e detona o software que você está fazendo.

Para atingir esse estado da arte de integração contínua, há vários métodos. Desde agendar tudo no crontab, criar scripts, ou utilizar softwares específicos para isso. Qua aliás, não faltam opções.

Aqui no trabalho, começamos a utilizar o continuum, porém, há apenas uma máquina para gerar uma grande quantidade de builds, sem contar com os testes automáticos. Dado isso, resolvi, colocar na minha máquina mesmo, uma tarefinha no crontab para gerar a build e rodar os testes automatizados, o que leva mais ou menos 8 horas (por isso optei em rodar na minha máquina e não no continuum server da empresa =p).

Até então estava tudo indo bem, com relatórios diários do status dos testes. Mas isso me abriu um horizonte. De repente me peguei fazendo uns scripts (em Ruby, lógico) para gravar no banco o resultado dos testes, para conseguir fazer um tracking da evolução desta tarefa. Apesar de ser divertido, estava meio complicado fazer este script. E eis, que numa conversa no café, um amigo me sugere a utilização do Hudson, que assim como o continuum é um software para integração contínua.

Ainda está cedo para disponibilizar qualquer análise, mas estou gostando muito, principalmente da facilidade que o software proporciona. Em poucos cliques consegui fazer o hudson baixar o codigo do subversion, fazer a build, gerar relatorio dos testes unitários, e ainda rodar a suite de testes automatizados. Ah, e de graça consegui um gráfico que mostra a variaca na quantidade de testes (e de falhas e erros nos testes também), ou seja, tudo o que eu queria!

Bom, fica ai a dica de pelo menos experimentarem o Hudson

Há um projeto no github, chamado whenever, que encapsula chamadas ao cron, utilizando a sitaxe e o jeitão do Ruby.  É possível fazer agendar tarefas no cron desta forma:

  every 3.hours do
    runner "MyModel.some_process"
    rake "my:rake:task"
    command "/usr/bin/my_great_command"
  end

  every 1.day, :at => '4:30 am' do
    runner "MyModel.task_to_run_at_four_thirty_in_the_morning"
  end

  every :hour do # Many shortcuts available: :hour, :day, :month, :year, :reboot
    runner "SomeModel.ladeeda"
  end

  every :sunday, :at => '12pm' do # Use any day of the week or :weekend, :weekday
    runner "Task.do_something_great"
  end

Para saber mais, visite o site do projeto, ou assista a este video.

Fonte: http://www.rubyinside.com.br/whenever-uma-dsl-ruby-para-programar-tarefas-no-cron-1514

…Porque nem só de programação vive um geek =p.Reebok 10k no sábado (20/06), na USP. Alguém mais vai ?

Boa prova a todos!

(e que eu consiga terminar os 10km…)