Quando usávamos o método assert_difference com múltiplas expressões e um erro ocorria era difícil de saber qual das expressões não teve seu valor alterado, já que a mensagem de erro não informava isto.

No Rails 2.2 a mensagem devolvida pelo método informará exatamente qual expressão não passou no teste. Por exemplo:

assert_difference ['Post.count', 'current_user.posts.count'] do
  Post.create(params)
end

O código acima retornará a seguinte mensagem, caso a segunda expressão não tenha passado:

<current_user.posts.count> was expression that failed. <1> expected but was <0>.

Já faz um tempo que existe uma dicussão sobre o nome do arquivo application.rb. O motivo é que como ele corresponde à classe ApplicationController, deveria chamar-se application_controller.rb.

Bom, depois de muita discussão isto foi alterado. Particularmente eu gostei, mas muitos não gostaram do fato de isto sair já para o Rails 2.2 sem um aviso prévio. Veja a discussão sobre isto aqui.

O fato é que se você estiver usando o Edge Rails ou pretende migrar seu projeto para o Rails 2.2, deve alterar o nome deste arquivo manualmente.

Normalmente no Rails funciona assim: Programadores do mundo todo desenvolvem novas funcionalidades e corrigem bugs, criam patchs e o core team aceita ou não estes patches. Mas quando DHH resolve colocar a mão no código ele muda tudo. O bom é que na maioria das vezes é para melhor!

No último Rails Podcast Brasil eu disse que deveríamos ficar atentos a algumas mudanças dele na parte de internacionalização. Ele mudou mais do que isto internamente, mas uma alteração importante foi a criação de um diretório config/locales para colocarmos nossos arquivos de internacionalização.

Também foi adicionado ao arquivo environment.rb o seguinte comentário:

# The internationalization framework can be changed
# to have another default locale (standard is :en) or more load paths.
# All files from config/locales/*.rb,yml are added automatically.
# config.i18n.load_path << Dir[File.join(RAILS_ROOT, 'my', 'locales', '*.{rb,yml}')]
# config.i18n.default_locale = :de

O que já era fácil, ficou mais fácil! Na teoria é só colocar o seu arquivo br.yml ou br.rb nesta pasta e alterar a última linha comentada e pronto!

Foi adicionado ao método field_set_tag um parâmetro opcional para facilitar a formatação do HTML. Este parâmetro aceita todas as opções que o método tag já aceita. Exemplo:

<% field_set_tag nil, :class => 'format' do %>
  <p>Some text</p>
<% end %>

O código acima retornará o seguinte:

<fieldset class="format">
  <p>Some text</p>
</fieldset>

Um episódio inteiro comentando as principais alterações no Rails 2.2, explicando alguns conceitos e tirando algumas dúvidas.

Entenda se você poderá se beneficiar do novo sistema de Thread-Safe do Rails, o que são eTags, quais métodos saíram e quais entraram e muito mais.

Obviamente não deu para cobrir todas as alterações, principalmente porque não dá para explicar muito sobre código em um podcast. Mas se você deseja entender melhor cada uma das novidades desta versão há três formas: Leia a tradução do Akita do release notes, acompanhe a séria Edge Rails deste blog, ou compre o PDF (em português e inglês) + screencast do Rails 2.2 no site do Envycasts.

Download: Episódio #38
iTunes: http://podcast.rubyonrails.pro.br/rss
Episódios anteriores: http://podcast.rubyonrails.pro.br/

Nota: Este episódio foi gravado na semana passada, antes do anúncio do Rails 2.2 RC2.

 

 Rails Podcast Brasil - Episódio 38: Especial Rails 2.2 [25:09m]: Play Now | Play in Popup | Download

David Heinemeier Hansson iniciou uma série de artigos em seu blog pessoal desmistificando algumas crenças sobre o Ruby on Rails. Este texto não é uma tradução literal e sim uma explanação do primeiro artigo de David.

Quando David lançou o Basecamp sob mod_ruby, há alguns anos atrás, ele não estava preocupado com o fato de que precisaria executar várias instâncias de um projeto Rails, tanto é que na época isto era um pouco complicado de se fazer, sem uma bela de uma gambiarra.

Naquela época só era possível executar o Rails sob CGI. Depois veio o FCGI, que ainda hoje é uma plataforma viável. Os softwares da 37signals foram executados sob esta plataforma durante alguns anos, mas esta parecia ser uma plataforma moribunda.

Mongrel

Foi nesta época em que apareceu o Mongrel, e junto com ele a sensação de que não precisávamos de mais nenhum outro protocolo para fazer com que os servidores de aplicação e os servidores web conversassem. Nós simplesmente podíamos usar HTTP! Hoje Mongrel, Thin, Ebb e outros servidores web baseados em Ruby predominam nos ambientes de produção. E existem boas razões para isto, afinal eles são estáveis, versáteis e rápidos.

Muitas opções

Até aqui tudo parece muito bem, mas um problema apareceu: Entre tantas opções, qual é a melhor para colocar meu projeto em produção? Devo ir de Apache, nginx, ou quem sabe de lighttpd? Devo confiar nos proxies dos servidores web ou usar algo como o HAProxy ou Pound? Quantos processos do Mongrel devo usar? Seria bom usar alguma ferramenta para monitorar os processos? God ou Monit?

Todas estas são boas opções, mas isto gera um paradoxo das Boas Opções. Entre elas qual é a melhor? Este grande numero de Boas Opções é exatamente o que cria este primeiro mito sobre o Ruby on Rails. Sem saber exatamente qual ferramenta usar, conclui-se que é difícil implantar um projeto Rails.

Como resolver este tipo de problema?

Phusion Passenger™

Passenger (mod_rails), é uma solução única que torna o deploy de aplicativos Rails tão fácil quanto um mod_php. Após um deploy ridiculamente simples, você tem um Apache se comportando como um web server, load balancer, application server e monitorador de processos. Você simplesmente joga seu aplicativo, altera o arquivo tmp/restart.txt e pronto, você está no ar!

Isto ainda não quer dizer que todos os grandes projetos Rails estão usando Passenger. Atualmente até mesmo os projetos da 37signals ainda não estão usando-o, pelo menos por enquanto.

O fato importante é que se houver alguma razão para isso, você pode montar todo o seu ambiente de produção manualmente com algumas das soluções mencionadas acima. Mas caso queira algo realmente simples e rápido, pode optar pelo Passenger, e confiar que esta é uma excelente opção.

Resumindo, Rails é difícil de implantar? Não! Phusion Passenger tornou o processo de implantação de projetos Rails ridiculamente simples.

Um novo livro está sendo preparado pela Pragmatic Programmers: The RSpec Book: Behaviour Driven Development with Ruby.

O livro será escrito pelo próprio David Chelimsky (principal desenvolvedor e mantenedor do Rspec) e outros participantes de peso. A idéia é ser um livro introdutório sobre RSpec, Cucumber e outras ferramentas necessários para se fazer BDD com Ruby, e promete ser recheado de tutoriais e exemplos práticos.

O último capítulo do livro abordará testes no Rails usando todas as ferramentas e conceitos explorados nos primeiros capítulos.

Infelizmente a previsão para venda é somente para o mês de abril de 2009.

Tópicos

• Foreward
• Introduction
• Tutorial: BDD with RSpec and Cucumber
  • Mastermind
• Behaviour Driven Development
  • Writing Software That Matters
  • It’s Not About Testing
  • Coupling
  • Mock Objects
• RSpec
  • Code Examples
  • Expectations
  • Mocking in RSpec
  • RSpec and Test::Unit
  • Tools and Integration
  • Extending RSpec
• Cucumber
  • Cucumber
• Behaviour Driven Rails
  • BDD in Rails
  • Cucumber with Rails
  • Webrat
  • Rails Views
  • Rails Helpers
  • Rails Controllers
  • Rails Models

Durante um tempo adotei o Shoulda com Test::Unit como meu principal framework de testes, mas depois que comecei a brincar com o Cucumber estou migrando para o RSpec. Mais detalhes aqui.

Coloque um bando de nerds em uma Van, apague a luz e prenda-os no trânsito de São Paulo por algumas horas. Qual seria o resultado?

O vídeo mais maneiro sobre o Rails Summit Latin America, sem dúvida!

Parabéns pelo trabalho, vocês deviam se juntar e fazer isto mais vezes, mas não precisa ser sempre no escurinho…

Conforme previ no último podcast, saiu o segundo release candidate do Rails 2.2. Esta versão ficou classificada como 2.2.1 e deve ser a última antes do lançamento oficial do Rails 2.2, que deve aparecer como 2.2.3.

Foi criado um novo branch para esta versão no GitHub, o que significa um congelamento do que temos até agora, nenhuma outra novidade será incluída de agora em diante para esta versão. Também podemos definir que a partir de agora tudo de novo quer for acrescentado ao Rails será para uma futura versão 2.3 ou 3.0.

Para os que já desejam ir testando esta nova versão, primeiro devem atualizar o RubyGems para a versão 1.3.1:

gem update --system

Só então instalar o novo gem:

gem install rails -s http://gems.rubyonrails.org

Enjoy!

No Rails 2.2 você poderá definir atributos do ActiveRecord como private. Como estes atributos são criados via metaprogramação, até agora isto era impossível.

Para entender como isto funcionará, vamos tornar o atributo name da classe User privado:

class User < ActiveRecord::Base

  private
  def name
    "I'm private"
  end

end

Agora ao tentar recuperar o valor do atributo name:

user = User.first
# => #<User id: 1, name: "teste", created_at: "2008-09-26 21:55:23", updated_at: "2008-09-26 21:55:23">

user.name
# => NoMethodError: undefined method `NoMethodError' for #<User:0x234df08>
#    from /Users/carlosbrando/Projects/sandbox/edge/vendor/rails/activerecord/lib/active_record/attribute_methods.rb:260:in `method_missing'
#    from /Users/carlosbrando/Projects/sandbox/edge/vendor/rails/activerecord/lib/active_record/attribute_methods.rb:236:in `method_missing'
#    from (irb):3

Veja que uma exceção NoMethodError foi disparada ao executar o método que agora é privado. Por outro lado eu posso alterar o nome do usuário, já que o método name= ainda é público.

user.name = "Carlos"
# => "Carlos"

Durante um bom tempo andei evangelizando o uso do Shoulda na Surgeworks e fiz muito uso dele em meus projetos pessoais. O fato é que não obtive muito sucesso em evangelizar meus colegas de trabalho a adotarem o Shoulda, por outro lado eles conseguiram me convencer a aprender e usar RSpec.

E realmente RSpec é um framework de testes muito interessante. Mas tudo ficou ainda mais interessante quando comecei a brincar com o Cucumber (pretendo escrever sobre isto no futuro).

Mas o segredo do sucesso do Shoulda é a maneira em que ele transforma testes comuns como verificar se as associações estão funcionando, se todas as validações necessárias foram adicionadas ou se uma simples informação foi adicionada corretamente a sessão, em algo extremamente trivial.

Passei a gostar cada dia mais do RSpec e decidi adotá-lo como meu framework oficial de testes de agora em diante. Mas não posso mais viver sem as facilidades que o Shoulda me oferecia. Então resolvi coçar a minha própria coceira.

Remarkable

Inicialmente, a função do Remarkable é portar para RSpec todas as macros do Shoulda, mas obviamente o plano é muito mais ambicioso do que isto. Tenho muita coisa em mente que tornará este projeto especialmente útil para os usuários de RSpec.

Neste momento você talvez se pergunte: “Mas já não existem plugins que fazem a mesma coisa, como o skinny e o rspec-on-rails-matchers, por exemplo?”. Sou obrigado a responder: “Sim”. Então, por que mais um projeto?

Por que mais um projeto?

Em primeiro lugar este não é simplesmente “mais um” plugin com matchers para RSpec. Vou usar um clichê agora, mas é mais pura verdade: “Este é um projeto feito do jeito certo!”.

Vejamos então uma lista com o que torna o Remarkable único:

1. Não é um plugin, e sim um gem.
2. Porta todas as macros atuais do Shoulda para RSpec.
3. Possui duas sintaxes de escrita, uma para quem gosta do estilo RSpec e outra para os que estão migrando seus projetos Shoulda para RSpec.
4. Testes.
5. Mais testes.
6. E mais um pouco de testes.

Sim, diferente de todos os outros projetos com o mesmo objetivo, o Remarkable é o único que possui testes, e este é um grande diferencial, acredite! Como se pode confiar em um projeto que não tem testes? Como evoluir um projeto open-source que não possui testes? O que garante que o último commit não quebrou alguma coisa que estava funcionando?

Instalação

Instalar o Remarkable é muito fácil. Ele está armazenado no GitHub, então se você nunca instalou um gem via GitHub execute primeiro:

gem sources -a http://gems.github.com

Agora instale o gem:

sudo gem install carlosbrando-remarkable

Por último adicione a seguinte linha no seu arquivo RAILS_ROOT/config/environment.rb:

config.gem "carlosbrando-remarkable", :lib => "remarkable", :source => "http://gems.github.com"

Usando

Todas as macros do Remarkable podem ser acessadas de duas maneira diferentes. Para aqueles que preferem o estilo Shoulda, vejamos como ficaria o teste de um modelo:

describe Post do
  fixtures :all

  should_belong_to :user
  should_belong_to :owner
  should_belong_to :user, :owner

  should_have_many :tags, :through => :taggings
  should_have_many :through_tags, :through => :taggings
  should_have_many :tags, :through_tags, :through => :taggings

  should_require_unique_attributes :title
  should_require_attributes :body, :message => /wtf/
  should_require_attributes :title
  should_only_allow_numeric_values_for :user_id
end

Igualzinho ao Shoulda? É esta a idéia! Esta sintaxe é ideal para aqueles que desejarem migrar seus testes do Shoulda para o RSpec (tendo apenas de alterar de context para describe e de should para it) ou mesmo para os que adoram a jeitão do Shoulda, assim como eu.

Mas se você não gosta desta sintaxe, também pode criar os mesmos testes da seguinte forma:

describe Post do
  fixtures :all

  it { should belong_to(:user) }
  it { should belong_to(:owner) }
  it { should belong_to(:user, :owner) }

  it { should have_many(:tags, :through => :taggings) }
  it { should have_many(:through_tags, :through => :taggings) }
  it { should have_many(:tags, :through_tags, :through => :taggings) }

  it { should require_unique_attributes(:title) }
  it { should require_attributes(:body, :message => /wtf/) }
  it { should require_attributes(:title) }
  it { should only_allow_numeric_values_for(:user_id) }
end

Agora muito mais no estilo RSpec!

Macros

Veja uma relação com todas as macros disponíveis na documentação do projeto.

Para o estilo Shoulda, clique aqui.
Para o estilo RSpec, clique aqui.

Finalizando

Este projeto já atingiu o primeiro objetivo, que era portar todas as macros do Shoulda para o RSpec. Tudo feito da maneira correta, com todos os cuidados e muitos testes. Mas nada melhor do que o uso na prática para encontrarmos pontos que devem ser melhorados.

Enfim, usem o Remarkable, e ajudem a torná-lo ainda melhor!

No último podcast mencionei minha escolha pelo Paperclip como meu plugin preferido para upload de arquivos. Depois disso algumas pessoas tem me perguntado porque usá-lo, já que o attachment_fu seria a opção mais conhecida.

Durante muito tempo usei o attachment_fu para esta função, mas em um projeto recente da Surgeworks optei por testar o Paperclip e depois disso acabei adotando-o como meu plugin padrão para uploads. Confesso que de inicio o grande motivo para experimentar o novo plugin foi por ele ter sido criado pela thoughtbot, o mesmo time que criou o Shoulda (que não estou usando mais, mas é uma outra história que vou explicar em um outro post), e como os caras são bons e tem criado inúmeros projetos interessantes, resolvi dar uma chance.

Mas foram alguns detalhes que me chamaram a atenção, como o fato de você não precisar de uma tabela extra no banco de dados para armazenar o caminho dos arquivos, a forma simplificada que ele oferece para se acessar e configurar o tamanho das fotos enviadas para o servidor, a macro de teste preparada para o Shoulda, a facilidade para configurar o acesso ao Amazon S3, entre outros detalhes que valorizam o plugin.

Enfim, não existe um grande motivo que chegue a desvalorizar o famoso attachment_fu ou torná-lo obsoleto. São apenas alguns pequenos detalhes que me conquistaram, só isso. É puramente uma questão de preferência  pessoal.

Não importa qual plugin de upload você use, só não esqueça do :multipart => true na construção do formulário!

Usando o Paperclip em 3 passos

1. Instale o plugin em seu projeto Rails:

./script/plugin install git://github.com/thoughtbot/paperclip.git

2. Adicione três colunas na tabela que armazenará os dados dos arquivos:

class AddAvatarColumnsToUser < ActiveRecord::Migration
  def self.up
    add_column :users, :avatar_file_name,    :string
    add_column :users, :avatar_content_type, :string
    add_column :users, :avatar_file_size,    :integer
    add_column :users, :avatar_updated_at,   :datetime
  end

  def self.down
    remove_column :users, :avatar_file_name
    remove_column :users, :avatar_content_type
    remove_column :users, :avatar_file_size
    remove_column :users, :avatar_updated_at
  end
end

3. Adicione uma linha no modelo com as configurações desejadas (tive de dividir em mais linhas para caber no blog):

class User < ActiveRecord::Base
  has_attached_file :avatar,
                    :styles => { :medium => "300x300>",
                                 :thumb => "100x100>" }
end

Leve ao forno e sirva à vontade!

No exemplo acima acabamos de adicionar um avatar (a famosa fotinha) para os usuários. Para recuperar a foto enviada pelo usuário, use:

<%= image_tag @user.avatar.url %>
<%= image_tag @user.avatar.url(:medium) %>
<%= image_tag @user.avatar.url(:thumb) %>

O attachment_fu também não é tão diferente disso, mas gosto mais do Papeclip. Apenas para fechar o artigo, um bônus! Para testar se o Paperclip está funcionando você pode pegar a macro para Shoulda, e depois adicionar uma linha ao teste do modelo:

class UserTest < Test::Unit::TestCase
  should_have_attached_file :avatar
end

Excelsior!

Mais uma semana cheia de novidades! Tivemos o lançamento da versão 1.0 (finalmente) do Merb e também do JRuby 1.1.5. Além disso o RubyMine, uma nova IDE para desenvolvimento Rails foi liberada. Veja nossa opinião sobre estes lançamentos.

Também comentamos sobre alguns projetos importantes como Redshift, Shoes, Rails Guides e Roxy. Saiba porque você deve dar sua atenção para cada um deles.

Neste episódio

• Redshift: What Ruby and a nice API can do in the browser
• Merb 1.0 released
• A major milestone for DB2 on Rails
• session_lifetime plugin
• Micro-Tutorial de Ruby
• Ruby and Shoes Programming: A New Course
• RubyMine: A New “Intelligent” Ruby IDE Built on IntellJ
• cached_externals
• RailsTree 0.8
• Rails Guides Wants You
• 3 Tools for DRYing Your Ruby Code
• ANN: braid 0.5 – vendor your git and svn repositories
• Lightweight Webservices with Sinatra and RestClient
• Scaling Ruby
• Roxy: A Ruby Proxy-Object Library
• Liberado o JRuby 1.1.5
• A more in-depth analysis of Ruby HTTP client performance
• Ruby 1.9.1 preview1 is out
• How to save 100m of RAM per mongrel
• A Short Puppet History, pt. 2: Cfengine

Download: Episódio #37
iTunes: http://podcast.rubyonrails.pro.br/rss
Episódios anteriores: http://podcast.rubyonrails.pro.br/

 

 Rails Podcast Brasil - Episódio 37 [32:43m]: Play Now | Play in Popup | Download

Depois do Rails, o framework mais famoso para Ruby com certeza é o Merb. O problema com o Merb até agora era a falta de uma versão 1.0 finalizada, garantindo que não haveria mais mudanças drásticas na API. Muitos desenvolvedores ainda não queriam se arriscar neste framework com medo das mudanças que poderiam vir até o lançamento de uma versão 1.0 estável.

Depois de dois anos de desenvolvimento, Ezra Zygmuntowicz e o core team do Merb anunciam o lançamento da versão 1.0.

No site RubyInside, Peter Cooper publicou um artigo com 44 links de tutoriais, noticias, livros, eventos e aplicativos de exemplo para os que desejam se aventurar no Merb.

O famoso site RubyLearning administrado por Satish Talim vem ensinando Ruby gratuitamente para programadores do mundo todo já faz algum tempo. Satish tem feito um trabalho excepcional com estes cursos e merece todo o reconhecimento da comunidade Ruby mundial.

A grande novidade é o novo curso de Ruby e Shoes que começará no próximo dia 15 de novembro, ministrado pelo Shoes Ninja Satoshi Asakawa, do Japão.

O curso tem um custo simbólico de 5 dólares, que serve apenas para ajudar Satish a manter o site e continuar oferecendo cursos.

Para quem não conhece, o Shoes é uma biblioteca criada por Why The Lucky Stiff para a criação de aplicativos desktop multiplataforma em Ruby. Para fazer o curso, basta se cadastrar no site e pagar a taxa de inscrição. Mas é importante ter um conhecimento mínimo de Ruby para ter um bom compreendimento do curso, caso contrário recomendo se inscrever em uma das turmas gratuitas de Ruby antes.

Este texto é uma tradução do artigo “Average environments beget average work“.

Grady Booch soltou o seguinte axioma no BrainstormTECH: “Na média, um trabalhador mediano realiza um trabalho mediano”. Inicialmente, pareceu-me perfeitamente racional. Mas, pensando melhor, isto começou a me incomodar. Isto se baseia na hipótese de que mau, médio e bom são atributos estáticos de uma pessoa, o que eu considero totalmente ofensivo e de mau gosto.

Eu acredito que somos capazes de fazer trabalhos ruins, medianos e bons. Eu certamente já fiz trabalhos ruins algumas vezes e constantemente faço trabalhos medianos. O que tenho percebido é que os trabalhos bons e excepcionais dependem mais do ambiente em que trabalho do que de mim. Ambientes medianos produzem trabalhos medianos.

Bons profissionais produzem trabalhos ruins o tempo todo

Simplesmente pense em todas as grandes pessoas e empresas que desapareceram em algum momento, só para aparecerem novamente depois de alguns anos, com quase nada de novo para mostrar. Até pessoas conhecidas como excepcionais podem fazer trabalhos imprestáveis quando são colocadas em ambientes ruins.

Ou pense em como boas pessoas podem facilmente fazer coisas ruins quando colocadas em circunstâncias ruins. O Stanford Prison Experiment é um bom exemplo da banalidade do mal.

Isso não quer dizer que somos todos iguais e que a estrela do rock dentro de você pode ser destravada com música hippie e sandálias. Só que há muito potencial inexplorado dentro de nós preso sob políticas de merda, má direção e burocracias sufocantes. Existem muitas pessoas esperando para fazer um grande trabalho se lhes dermos oportunidade.

Ninguém pode ser uma estrela do rock sem um grande cenário

Se você quer um time vencedor, então pare de tentar encher uma sala com estrelas do rock e ninjas. Em vez disso, comece a pensar na sala!

Aqui estão três perguntas para você começar a pensar sobre como auto-diagnosticar o seu meio ambiente:

• Você valoriza o esforço antes do efeito?
  Alguém que fica a noite toda trabalhando é um herói, mas aquele que termina todo o trabalho e vai mais cedo para casa é visto como alguém que não trabalha em equipe.

• Você confia que as pessoas farão a coisa certa?
  Nós não contamos dias de férias e damos a qualquer um o cartão de crédito corporativo, mas exigimos relatórios do que não são despesas.

• Você incentiva questionamentos?
  As discussões sempre acabam com a frase “porque eu quero isto assim” ou explicando políticas como ” porque deve ser desse jeito e pronto”.

Mas o mais importante, pare de utilizar a qualidade percebida do seu time como desculpa para justificar porque você não pode experimentar ou seguir novas idéias. É uma grande realização dizer que isto nunca vai decepcioná-lo. Os seres humanos são extremamente propensos a desanimar sob baixas expectativas.

Para tornar o ActiveRecord mais consistente foi adicionado o método de instância Model#delete. Ele é similar ao método de classe com o mesmo nome. O método delete, diferente do método destroy, apaga o registro do banco de dados sem disparar callbacks, como o before_destroy e o after_destroy.

Este método também não aplicará nenhuma das regras impostas na associação através de cláusulas como :dependent.

client = Client.find(1)
client.delete

A e-Genial está inovando mais uma vez, desta vez está lançando um curso on-line e intensivo de BDD (Behaviour-Driven Development) com Rails e RSpec, com nada mais nada menos que Danilo Sato.

Diferente dos demais cursos, este curso será aos sábados, com uma carga horária de 12 horas. Tive o prazer de conhece o Danilo Sato (ThoughtWorks) durante o RejectConf’07, onde ele palestrou sobre o mesmo tema.

Recomendo o curso!

De volta a nossa programação normal, um podcast com as últimas noticias desta e da última semana. Neste episódio falamos sobre o Rails Rumble, a polêmica do Nokogiri, Paperclip, o novo gem de autenticação Authlogic e CouchDB.

Estamos preparando um episódio especial sobre o Rails 2.2, em breve!

Neste Episódio

• Rails Rumble
• Phusion Passenger, now with Global Queuing
• PeepCode Lançamentos
• Nokogiri: A Faster, Better HTML and XML Parser for Ruby (than Hpricot)
• Hpricot Strikes Back
• Why’s (Poignant) Guide to Ruby em português
• FFI for Ruby Now Available
• Goodbye attachment_fu, hello Paperclip
• Criando gems com GemHub, nunca foi tão simples
• Using Gmail with IMAP to Receive Email in Rails
• A DB admin interface written in Rails
• Tutorial: Authlogic Basic Setup
• Merb 1.0 RC2 Now Available: Merb 1.0 Not Far Behind!
• Rails Application Visualization
• suprails and rg: Two Rails Application Generators
• Suspenders
• jShoulda – Shoulda for JavaScript
• CouchDB

Download: Episódio #36
iTunes: http://podcast.rubyonrails.pro.br/rss
Episódios anteriores: http://podcast.rubyonrails.pro.br/

 

 Rails Podcast Brasil - Episódio 36 [54:23m]: Play Now | Play in Popup | Download

Quando uma exceção é dispara recebemos em nossa view uma mensagem semelhante a esta:

NoMethodError in Administration/groups#show
Showing app/views//_list.erb where line ...

Quando na verdade deveríamos receber uma mensagem com o caminho completo do arquivo que disparou o erro, assim:

NoMethodError in Administration/groups#show
Showing app/views/administration/reports/_list.erb where line ...

Este problema já está corrigido no Rails 2.2, facilitando nosso trabalho.

Ao se criar um cookie existe uma opção esquecida por muita gente. A opção http_only faz com que o cookie somente seja acessível via HTTP, impedindo que um trecho de código em javascript consiga acessá-lo. O valor padrão para esta opção é false.

No Rails 2.2 o cookie que armazena a sessão do usuário terá a opção http_only ligada por padrão. A intenção é aumentar a segurança em nossos projetos. Obviamente esta opção pode ser desligada caso necessário. Se este for o caso, basta incluir a seguinte linha no ApplicationController ou em um controller especifico:

session :session_http_only => false

A tarefa rake db:migrate:redo tem se mostrado muito útil quando precisamos voltar e executar novamente a última migration criada. Agora esta tarefa ficou ainda mais útil, porque podemos utilizar a opção VERSION e informar qual migration queremos que seja reexecutada.

rake db:migrate:redo VERSION=20080725004631

As classes Time, Date, DateTime e TimeWithZone receberam três novos métodos muito convenientes. Os métodos today?, past? e future? foram introduzidos em todas as classes que trabalham com datas e horas para facilitar nossa vida em algumas situações.

Acredito que não seja necessário explicar o funcionamento de cada um. Então vejamos os métodos em ação:

date = Date.current
# => Sat, 04 Oct 2008

date.today?
# => true

date.past?
# => false

date.future?
# => false

time = Time.now
# => Sat Oct 04 18:36:43 -0300 2008

time.today?
# => true

Para entender esta alteração, vamos precisar analisar o mesmo código sendo executado em uma versão anterior do Rails e depois no Rails 2.2. Vamos pegar um modelo como exemplo:

class Comment < ActiveRecord::Base
  alias_attribute :text, :body
end

Note que estou usando o método alias_attribute para criar um alias para o atributo body com o nome de text. Na teoria este método deveria replicar todos os métodos de leitura, escrita, pesquisa e qualquer outro que envolva o atributo body. Mas vejamos um exemplo sendo executado no Rails 2.1 ou anterior:

c = Comment.first
# => #<Comment id: 1, body: "my comment">

c.body
# => "my comment"

c.text
# => "my comment"

c.body = "a new message"
# => "a new message"

c.body_changed?
# => true

c.text_changed?
# => NoMethodError: undefined method `text_changed?' ...

Ao executar o método text_changed? temos um erro, porque o alias_attribute não estava replicando os métodos de rastreamento, mas isto já foi corrigido. Veja o mesmo código executado agora em um projeto Rails 2.2:

c = Comment.first
# => #<Comment id: 1, body: "my comment">

c.body
# => "my comment"

c.text
# => "my comment"

c.body = "a new message"
# => "a new message"

c.body_changed?
# => true

c.text_changed?
# => true

c.text_change
# => ["my comment", "a new message"]