No começo do ano um amigo foi para os States e me trouxe (obviamente após eu muito implorar) um Kindle. Devo dizer que o dispositivo é sensacional (mesmo ainda não sendo a versão touch ou com andróid que saiu recentemente) e que eu nunca li tantos livros como tenho lido ultimamente.

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 ?

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

Ok, sempre vi por aí que o pessoal recomenda fortemente a utilização de factories de objetos ao invés de fixtures, porém as fixtures sempre serviram pra mim. Pelo menos até hoje.

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…

Quem nunca se confundiu com isso, que atire a primeira pedra =p. Realmente, e pra quem está começando com Ruby, isso gera ainda mais confusão. Por isso, estou postando um artigo bem interessante que acabei de ler. Segue o link:

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

[]‘s

Rafael

Quando escrevi o meu primeiro código executável (Visual Basic 3.0 em 1997) me perguntei se o havia feito do jeito “certo”, se era legível, se outras pessoas entenderiam, enfim, questionei-me se havia escrito o código da melhor maneira possível.

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á.