Tudo que quero saber!

Estou começando a me aventurar na versão 2.0 do Rails, com a vontade de já ficar por dentro do que irá surgir nos próximos meses. Minha coragem está nos meus testes.

Foi adicionado os comandos:

rake notes                     # Enumerate all annotations
rake notes:fixme               # Enumerate all FIXME annotations
rake notes:optimize            # Enumerate all OPTIMIZE annotations
rake notes:todo                # Enumerate all TODO annotations

class Game < ActiveRecord::Base
  belongs_to :event
  has_many :results
 
  #TODO Fazer alguma coisa aqui
  #FIXME Um probleminha bla bla ;)
 
end

Quando você colocar algum comentário com essas 3 opções(FIXME, OPTIMIZE ou TODO), executando rake notes você receberá uma saída assim no seu console:

eduardo-ubuntu:~/AmbienteRails/Projetos/basketball$ rake notes
(in /home/eduardo/AmbienteRails/Projetos/basketball)
app/models/game.rb:
  * [  5] [TODO] Fazer alguma coisa aqui
  * [  6] [FIXME] Um probleminha bla bla ;)
 
app/models/player.rb:
  * [  5] [OPTIMIZE] Associação feia pra caramba..

O valor entre colchetes é o numero da linha que está a anotação.

Mais dicas em breve. ;)

Primeiramente acho que todo gerente de ti ou a pessoa que paga seu salário “DEVERIA” participar de uma competição como essa, para saber das dificuldades de ter tempo escasso e valorizar o salário dos seus desenvolvedores.

No rails rumble nós temos que fazer o papel de desenvolvedor, analista, admin linux, psicólogo, designer e ainda ter vida além das 48h de desenvolvimento.

A experiência é impagável. Assumir todas essas resposabilidades foi um aprendizado muito interessante. A colaboração entre os outros competidores brasucas atravéz do twitter(eu também tenho :) ) foi muito boa. Enfatizo os problemas descritos pelo urubatan e pelo nando.

Esta é minha aplicação rails: http://refactoringgame.railsrumble.com/

A idéia é compartilhar códigos e soluções de problemas com ruby, não preciso nem dizer que falta muita coisa da idéia que sonhei antes da competição. Já apareceram alguns doidos ajudando a limpar os códigos. :)

Procurei manter a cobertura de testes alta para não ter problemas futuros e continuar a desenvolver essa aplicação.

Durante o desenvolvimento encontrei alguns problemas e recebi dicas do Arthur, Nando Vieira e do George Guimarães. Fique sabendo também que na equipe do George tinha também o Hugo Barauna e o Jose Valim. Tinha mais algum brasileiro participando?

Vocês tem mais alguma dúvida? Quem sabe um podcast com os participantes? O que acham? Dependo do feedback de vocês.

Se você ainda não usa capistrano, já passou da hora de colocar em prática esta excelente ferramenta. Minha motivação para usá-lo se traduz no logo do site capify.org, pois é assim que me sinto ao utilizar o capistrano.

Imagine que você utilize uma base sqlite3 que está no caminho db/meubanco.sqlite . Há um pequeno problema quando você vai utilizar o capistrano para este tipo de situação.

[deploy_to]
  +- releases
  |    +- 20050725121411
  |    +- 20050801090107
  |    +- 20050802231414
  |    ...
  |    +- 20050824141402
  |    |   +- Rakefile
  |    |   |  app
  |    |   |  config
  |    |   |  db
  |    |   |   +- meubanco.sqlite
  |    |   |  lib
  |    |   |  log –> [deploy_to]/shared/log
  |    |   |  public
  |    |   |    +- …
  |    |   |       system –> [deploy_to]/shared/system
  |    |   |       …
  |    |   |  script
  |    |   |  test
  |    |   |  vendor
  |
  +- shared
  |    +- log
  |    +- system
  |
  + current –> [deploy_to]/releases/20050824141402

Quando executar o “cap deploy” ele irá criar uma nova pasta com o formato -ANOMESDIAHORAMINUTOSEGUNDO- dentro da pasta release e copiar todo conteúdo do repositório para esta nova pasta. O capistrano não irá guardar sua base e mover a base para seu novo deploy.

Há várias maneiras de se fazer essa persistência. Você pode copiar a base do release antigo para o novo release e etc. A solução que cheguei é utilizar a pasta shared/system presente na estrutura do capistrano.

Primeiro você deve copiar o banco para a pasta shared/system, e criar uma nova regra na sua receita de deploy para que o caminho db/meubanco.sqlite aponte para shared/system/meubanco.sqlite

task :after_update_code, :roles => [:app] do
  run "ln -nfs #{shared_path}/system/meubanco.sqlite  #{release_path}db/meubanco.sqlite”
end

Detalhe:
shared_path = é a pasta shared da estrutura criada pelo capistrano.
release_path = é a pasta criada no seu deploy corrente.

Ficando assim:

[deploy_to]
  +- releases
  |    +- 20050725121411
  |    +- 20050801090107
  |    +- 20050802231414
  |    ...
  |    +- 20050824141402
  |    |   +- Rakefile
  |    |   |  app
  |    |   |  config
  |    |   |  db
  |    |   |   +- @meubanco.sqlite
  |    |   |  lib
  |    |   |  log –> [deploy_to]/shared/log
  |    |   |  public
  |    |   |    +- …
  |    |   |       system –> [deploy_to]/shared/system
  |    |   |       …
  |    |   |  script
  |    |   |  test
  |    |   |  vendor
  |
  +- shared
  |    +- log
  |    +- system
  |    |   +- meubanco.sqlite
  |
  + current –> [deploy_to]/releases/20050824141402

Esta dica pode ser utilizada para qualquer conteúdo que você precise guardar entre seus deploys. Utilizo este passo no RailsPlayground.

Nas minhas aplicações Rails eu costumo utilizar o plugin “Restful Authentication” que disponibiliza um código inicial para criar usuários e o esqueleto de autenticação. (Veja como utilizar)

O ponto principal na escolha deste plugin é a alta cobertura de testes de unidade e funcionais, assim posso inserir novas funcionalidades com segurança e mantendo a cobertura de testes.

Os testes gerados pelo plugin utilizam o helper assert_difference e o assert_no_difference presente somente no “edge rails”. Felizmente o plugin sofreu algumas alterações e já possui no seu helper de testes esses dois métodos. Então se você utilizou o plugin antes dessa modificação, ou já quer usar este helper antes do Rails 2.0 ser lançado, basta adicionar o seguinte código no test_helper:

  def assert_difference(expressions, difference = 1, message = nil, &block)
    expression_evaluations = [expressions].flatten.collect{|expression| lambda { eval(expression, block.binding) } } 
 
    original_values = expression_evaluations.inject([]) { |memo, expression| memo << expression.call }
    yield
    expression_evaluations.each_with_index do |expression, i|
      assert_equal original_values[i] + difference, expression.call, message
    end
  end
 
  def assert_no_difference(expressions, message = nil, &block)
    assert_difference expressions, 0, message, &block
  end

Sua utilização é simples, se antes você tinha esse código:

  def test_create_player
    old_count = Player.count
    post :create, :player => {:name => "Eduardo", :game => "Starcraft 2"}
    assert_response :redirect    
    assert_equal old_count + 1, Player.count
  end

Você agora pode utilizar este que é muito mais bonito:

  def test_create_player
    assert_difference 'Player.count' do
      post :create, :player => {:name => "Eduardo", :game => "Starcraft 2"}
      assert_response :redirect
    end
  end

O Artur publicou um artigo com mais alguns helpers que ele utiliza.

Fica ai a dica.