Após terminar a minha suite de testes unitários, rodei o famoso “rake stats” para ver como estava a relação linhas de código x linhas de teste. Para a minha surpresa deu aproximadamente 1 para 1 (surpresa, pois achei que tivesse escrito muuuuuuuuuito mais teste do que código, rs…). Mas ainda queria ter mais informações. Gostaria de saber se os meus testes estavam indo na direção certa…

Bom, dei uma pesquisada e achei duas coisas interessantes: RCov e Heckle.

O RCov se parece com o Emma que temos no mundo Java. Ele roda os testes e verifica a cobertura, ou seja, analisa quais linhas do seu código, realmente estão sendo chamadas. Com ele é menos provável que você acabe testanto o seu teste, ao invés do seu código.

Para usá-lo é muito simples, basta instalá-lo via ruby gems:

gem install rcov

E depois chamá-lo dentro do seu diretório raiz da aplicação:

rcov test/*.rb

Isto irá criar um diretório chamado “coverage”. Entre nele e abra o index.html. Recomendo fortemente.

Já o Heckle, parece ser muito massa, pelo que entendi, ele serve para validar a eficácia do seu testes. Como ele faz isso ? Bom, isso é assunto para um próximo post.

Paralelamente ao meu trampo Java EE, estou desenvolvendo um sisteminha para controle financeiro em Rails. E tudo o que vejo de errado, ou que poderia ser melhor aqui na empresa, estou tentando levar no meu projeto. E uma das coisas é o TDD. Evidentemente testes unitários deveriam ser prioridade em qualquer sistema de informação, mas sabemos que na realidade, as vezes a diretoria pressiona, e você tem que correr com o codigo e deve deixar algo de lado, para encaixar no prazo. Geralmente esse “algo” que fica de lado, é o teste. Com rails/ruby, é possível explorar mais ainda o TDD. Pelo fato de ser uma linguagem dinâmica, é possivel você criar o teste antes do código. Parece estranho né ? Mas isso te força a sempre codificar pensando no teste e sempre testar pensando no código. E acredite, isto faz uma enorme diferença.

Temos alguns sistemas legados aqui na empresa, que não tiveram esta preocupação com o teste. Devido, provavelmente ao que relatei no parágrafo anterior. E agora estamos com muito receio de refatorar o código, pois não temos a segurança que uma boa suite de teste nos daria. Ai você me diz: “Simples! Faça a tal suite de testes, e depois refatora!”. Entretanto, o sistema não foi feito pensando em testes, não foi concebido para ser unitariamente testado. Com isso temos o codigo de negocio completamente vinculado ao acesso ao banco, o que torna praticamente impossível a utilização de uma camada de mocks. Ou seja, estamos em maus lençóis.

Existem vários tutoriais sobre isso na net, mas aqui vou fazer uma compilação e falar o que funcionou para mim.

Para começar, estou utilizando ubuntu 8.04 (Hardy Heron) com gnome 2.22. Portanto, não sei se este tutorial vale para todos os linux disponíveis por ai.

Um bom lugar de partida é este tutorial do site grigro.org. O tutorial é bem completo.

A única ressalva para este tutorial, é que os plugins devem ser colocados no dir /usr/lib/gedit-2/plugins. Se colocar no local indicado pelo autor, não irá funcionar.

Passo 2. Instalando a fonte.

A fonte utilizada no TextMate é a Liberation Mono, que pode ser encontra para download aqui. Após baixá-la e descompactá-la, rode:

sudo mkdir /usr/share/fonts/truetype/liberation

e depois copie todos os arquivos .ttf para o diretório criado e rode o comando:

sudo fc-cache

Desta forma a nova fonte estará disponível para todos que utilizarem o sistema. Agora basta abrir o gedit e selecioná-la. Sugiro que deixe com tamanho 11.

Qualquer dúvida, é só me escrever.

Estava eu seguindo o tutorial “Rolling with Rails 2.0″ do Akita, quando me deparei com um pequeno problema envolvendo autenticação com o plugin restful_authentication. No tutorial, o Akita “migra” o famoso “Webblog in 15 minutes” para rails 2.0, inclusive usando as características restful desta versão.

Porém, na hora de falar sobre autenticação, o Akita apenas cita o plugin restful_authentication e parte para a autenticação básica via http, me deixando sem rumo…

Confesso que foi super simples utilizar o plugin. Há muita documentação sobre isso na net, porém, eu não conseguia criar rotas aninhadas em 2 níveis, do tipo:

localhost:3000/users/1/posts/3/comments

Porém, tava deificil encontrar como fazer isso, mas finalmente achei. Basta fazer isso no routes.rb:

  map.resources :users do |user|
    user.resources :posts do |post|
      post.resources :comments
    end
  end

Com isso, teremos as seguintes rotas:

• user_posts_path
• new_user_post_path
• user_posts_comments_path
• …

E assim resolvi o meu problema! Bom, por ter dado tanto trabalho, talvez alguém também precise disso. Fica ai a dica

Tá, eu sei que cheguei tarde na onda do Rails 2.0, e só vi que mudou muita coisa, quando tentei atualizar um sisteminha antigo que fiz em Rails 1.X para a nova versão e não consegui. Tá certo que usei muita coisa Deprecated, bem como alguns plugins que não evoluíram e tal, mas nem “compilar” o código foi foda… Mas isso me levou a estudar um pouco mais sobre o Rails 2.0 e ver o que tinha mudado. Fiquei impressionado com o tamanho do change log. Por isso surgiu a idéia de criar uma série de artigos explicando o que mudou e o ganho disso.

Para começar, vamos falar de “Sexy Migrations” e outras atualizações no ActiveRecord.
Em poucas palavras, “Sexy Migrations” é apenas um formato mais elegante e enxuto de se declarar os seus arquivos de migrations. Antes, você faria assim:

create_table :people do t
t.column, “account_id”, :integer
t.column, “first_name”, :string, :null => false
t.column, “last_name”, :string, :null => false
t.column, “description”, :text
t.column, “created_at”, :datetime
t.column, “updated_at”, :datetime
end

E agora, pode fazer assim:

create_table :people do t
t.integer :account_id t.string :first_name, :last_name, :null => false
t.text :description
t.timestamps
end

Atente para “t.timestamps”. Ele é um “atalho” para você criar os campos created_at e updated_at. Ficou bem mais enxuto e intuitivo, não ?

Desempenho:
No rails 2.0, o ActiveRecord sofreu algumas alterações para um maior ganho de desempenho. Foi adicionado um simples cache de consultas ao banco. Com isso, consultas (queries) similares serão reconhecidas e retornarão os objetos que estão no cache, ao invés de ir até o banco. Algo que lembra o que o Hibernate faz com grande sucesso. O desempenho dos “fixtures” foi drasticamente melhorando, o que implica em um ganho de 50% ou mais em relação a versão anterior, ao rodar suites de testes que utilizam “fixtures”.

Serialização em JSON:
Exato, agora é possível serializar o seu model para a sintaxe JSON. Mas porque eu iria querer algo assim ? Talvez para trabalhar com Javascript (AJAX) de forma mais prazerosa do que com XML ? Acredito que sim! E veja como é ridiculamente simples:

Person.to_json

E você terá a representação em JSON do seu model.

Bom, por hoje é só. Tentarei, ainda essa semana, escrever um pouco mais sobre as melhorias do Rails 2.0. (Digo tentarei, porque ainda tenho o meu trampo, meus projetos pessoais em rails, e mais meu videogame que ocupam muito do meu tempo, rs…)