Nome do Jogo

Estava vendo hoje um projeto legal chamado "Refactor :my => ‘code’", é um site onde você posta um trecho de código para que outras pessoas lhe ajudem a melhorá-lo.

Quando vi este projeto, fiquei com uma sensação de déjà vu , já tinha visto isto em algum lugar… Foi quando me lembrei do projeto do Eduardo Fiorezi para o Rails Rumble, o Refactoring Game.

Falando em Rails Rumble, hoje é o grande dia. Finalmente saberemos quem foi o vencedor, e tem brasileiros na parada. Aguardem…

Tenho um relacionamento muitos-para-um, e gostaria que ao excluir o objeto pai todos os seus relacionamentos (filhos) fossem também apagados no banco de dados. Esta exclusão automática existe e se chama exclusão em cascata. No Rails é muito simples implementar:

class Pai < ActiveRecord::Base has_many :filhos, :dependent => true end

Esta declaração informa que o Filho não pode existir sem um Pai. Desta maneira, se eu apagar uma instância de Pai, todos os seus filhos também serão apagados. Mas, atenção, cada filho será apagado individualmente, será executado um DELETE para cada linha no banco de dados.

Mas se seus objetos Filhos forem exclusivos de um objeto Pai - e somente de um - então você pode trocar esta declaração por esta:

class Pai < ActiveRecord::Base has_many :filhos, :exclusively_dependent => true end

Agora o Rails fará o mesmo, mas de uma vez, com apenas um comando SQL.

Fiquem atentos aos recursos do Rails, os maiores problemas de desempenho que encontro é em detalhes como esse.

Um problema comum e uma solução trivial. É assim que posso descrever o uso de heranças em modelos no Rails.

Imagine a seguinte situação: No meu diagrama de classes tenho uma classe Person com duas subclasses, Manager e Employee. De inicio a primeira coisa que faríamos seria criar três modelos no Rails:

class Person < ActiveRecord::Base end class Manager < ActiveRecord::Base end class Employee < ActiveRecord::Base end

Mas como modelar as tabelas neste caso? Podemos usar o recurso de heranças do ActiveRecord e fazer tudo em cima de apenas uma tabela.

create table people ( id INT AUTO_INCREMENT NOT NULL, type VARCHAR(20), /* atributos comuns */ name VARCHAR(100) NOT NULL, email VARCHAR(100) NOT NULL, /* atributos do gerente */ dept INT, /* atributos do funcionario */ reports_to INT, PRIMARY KEY (id) );

Note que criamos uma coluna chamada type na tabela people, é aqui que está o segredo.

Agora alteramos os modelos para que as classes Manager e Employee sejam subclasses de Person:

class Person < ActiveRecord::Base end class Manager < Person end class Employee < Person end

Pronto. Agora todos os modelos acessam a mesma tabela. Se você utilizar a classe Person, o ActiveRecord vai sempre retornar todas as linhas desta tabela, mas se usar Manager ou Employee ele somente tratará os registros com o tipo especificado.

Mas temos um problema aí, você vai verificar que todas as classes possuem os mesmos atributos. Mas na prática isto nem é um problema assim tão sério. Você pode simplesmente ignorar os atributos que não pertencem àquela classe. É um preço baixo a pagar por tamanha facilidade. Sem contar que isto vai lhe poupar a criação de pelo menos três tabelas, e melhorar o desempenho de sua aplicação, já que menos tabelas são menos associações.

Diante de tantas opções, não é fácil para um desenvolvedor RoR escolher o melhor servidor web para o seu software. Resolvi criar este post para tentar explicar de uma forma simples e rápida as diferenças entre os principais servidores web que suportam Rails.

WEBrick

Padrão. Se tivesse de resumir este servidor em apenas uma palavra, a palavra seria: padrão. É o servidor que "vem" com o Rails. Ele é escrito em Ruby e por isto é fácil integra-lo com o Rails, pois ele pode fazer chamadas diretas ás suas aplicações.

Em minha opinião é a opção mais simples e rápida de se usar.

Apache

O Apache é o servidor web mais usado no mundo. É a opção mais escalável e flexível para projetos Rails. Possui plugins que permitem que o servidor funcione com dezenas de linguagens de programação diferentes. Também suporta balanceamento de carga e sprayes de uma forma bem robusta.

Em outras palavras é a opção mais segura.

lighttpd

Velocidade é a palavra que estava na mente dos criadores do lighttpd. Ele foi criado com este objetivo em mente. Não chega perto da flexibilidade oferecida pelo Apache, mas faz o serviço direitinho e muito mais rápido. Pode rodar softwares produzidos em RoR por meio de uma interface FastCGI.

lighttpd é o papa-léguas dos servidores web para Rails.

Mongrel

O Apache é mais escalável e o lighttpd é o mais rápido, mas fazê-los funcionar com o Rails com certeza não uma tarefa das mais triviais. Mas fazer uma aplicação Rails rodar no Mongrel é extremamente simples e trivial.

O Mongrel é tão simples de usar quanto o WEBrick, pois também é escrito em Ruby e foi construído com o mesmo conceito do lighttpd em mente: velocidade. Talvez por este motivo ele seja o queridinho da comunidade RoR.

Outras opções

É claro que existem outros servidores web que podem ser utilizados para suportar uma aplicação em Ruby on Rails, na verdade qualquer servidor que suporte CGI pode fazer isto. Mas esses quatro são os mais usados hoje em dia.

Saiu no Ryan’s Scraps.

Especificando a ordem de carga de plugins

Hoje o máximo que podemos fazer com plugins é informar ao Rails quais devem ser carregados. No environment.rb:

config.plugins = %W( exception_notification ssl_requirement )

A partir da próxima versão do Rails esta este trecho de código também será usado para definir a ordem em que os plugins devem ser carregados.

Para isto, o método passou a aceitar o símbolo :all, facilitando o preenchimento do método e evitando o trabalho de listar todos os plugins. Veja alguns exemplos de uso:

config.plugins = [ :exception_notification, :ssl_requirement, :all ]

Neste caso só importa para mim que os dois primeiros plugins carreguem nesta ordem, os demais não interessam.

config.plugins = [ :exception_notification, :all, :ssl_requirement ]

Agora, fiz diferente. Quero que sempre o Rails carregue primeiro o plugin exception_notification e por último o plugin ssl_requirement.

Para ver a referencia no Rails Trac, clique aqui.

Uma maneira melhor de interceptar erros

A pior coisa que pode acontecer em nosso produto é uma horrível página com uma mensagem de erro. Por isto é sempre bom se preparar para estes casos. Na nova versão do Rails teremos uma nova forma de tratar exceções geradas em uma action:

class ApplicationController < ActionController::Base rescue_from User::NotAuthorized, :with => :deny_access rescue_from ActiveRecord::RecordInvalid, :with => :show_errors protected def deny_access ... end def show_errors(exception) exception.record.new_record? ? ... end end

Muito simples, não é?

Para ver a referencia no Rails Trac, clique aqui.