Keynotes do Rails Underground 2009 – Fred George e Yehuda Katz

Ric Roberts, que escreve para o Ruby Inside inglês, foi à conferência Rails Underground em Londres, que aconteceu nos dias 24 e 25 de Julho. Segue a tradução de suas impressões:

Como parece ser a regra nesse tipo de eventos, as apresentações mais proveitosas foram aquelas com mais conteúdo teórico e opiniões pessoais do que das apresentações técnicas. Isso posto, Pat Allan e George Palmer fizeram grandes apresentações mostrando seus plugins: thinking_sphinx e couch_foo, respectivamente.

Irei me concentrar nos keynotes dos dois dias, que tiveram perspectivas bastante distintas.

Fred George - Rails é um martelo. Nem tudo é um prego.

No keynote do primeiro dia (link do vídeo), Fred George, ex-Thoughtworker, nos alertou sobre o uso do Rails em projetos para os quais ele não é a melhor escolha. Ele começou discutindo como frameworks como o Rails permitem que comecemos rapidamente mas se tornam difíceis de gerenciar conforme a complexidade do problema aumenta.

Durante o resto da apresentação ele explicou a arquitetura de um projeto para o qual ele decidiu criar seu próprio framework, apenas com as partes que precisava. Ele explicou que não era fã de bancos de dados relacionais tradicionais baseados em SQL, porque eles podem forçar a modelagem de seus objetos a ter uma forma "não-natural" que pode não se adequar ao domínio em questão. Seu projeto consistiu de uma interface HAML/SASS com Sinatra e objetos puros em Ruby que persistiam dados usando arquivos YAML. Sob meu ponto de vista, o problema dessa abordagem é que, por depender de um conjunto tão dispare de tecnologias, você corre o risto de um ou mais componentes ficarem obsoletos com o passar do tempo.

Como mencionado por algumas pessoas na platéia após a apresentação, Fred não fez uma comparação muito detalhada entre o Rails e outras alternativas, uma vez que estava simplesmente descrevendo uma aplicação específica que ele desenvolveu. Acredito que a principal mensagem de sua apresentação foi que se o domínio da sua aplicação se adapta bem à estrutura de bancos de dados relacionais, então usar MVC com Rails da maneira tradicional é uma boa pedida (um bom exemplo seria a administração de usuários de um sistema). Porém, um serviço que apenas expõe uma estrutura de banco de dados e seus conteúdos não adicionam muito valor (por exemplo, REST/CRUD em um conjunto de tabelas). Para adicionar valor é preciso desenvolver models que contenham inteligência.

Yehuda Katz - o futuro é granular

Yehuda Katz fez seu keynote no segundo dia (link do vídeo), falando sobre como o Rails está evoluindo. Yehuda explicou como os core teams do Merb e do Rails se juntaram para trabalhar no Rails 3.0 - a fusão das melhores partes de cada framework, mas com a estrutura interna repensada. O Rails 3.0 não irá remover nada que faz dele um excelente framework, mas se tudo correr bem irá ser melhor para os "usuários avançados", por exemplo, desenvolvedores que se preocupam com o funcionamento interno e querem se aproveitar desse conhecimento.

Durante boa parte da apresentação ele falou sobre porque interfaces são uma boa abstração (Não interfaces como no Java, o construto, mas o conceito geral, ou seja, contratos entre componentes). Interfaces criam convenções sobre como os métodos são chamados, nos permitindo alterar sua implementação interna sem afetar o código que os chamam. Classes e módulos nos dão ainda mais: usar mixin de módulos é mais poderoso do que herança, uma vez que nos permite adicionar novos comportamentos as classes existentes. Como explicou Yehuda, "Seus pais não definiram tudo que vocês podem fazer quando nasceram. Vocês podem aprender coisas novas." Com os módulos do Ruby você pode trocar pequenos pedaços da implementação em tempo de execução quando você precisar.

Esse conceito é utilizado para permitir que diferentes componentes do Rails 3.0 sejam separados. Por exemplo, você não será forçado a utilizar ActionView - você só precisa de algo que é "compatível com ActionView". O mesmo se aplica ao ActiveRecord - seus models só precisarão respeitar o contrato do ActionModel.

E não se preocupe, os contratos necessários para tornar um objeto compatível com de ActionView e ActionModel são muito simples, exigindo poucos métodos. Se você quiser o comportamento padrão, tudo que você precisa fazer é incluir um módulo já existente. Ao implementar essas interfaces você poderá criar componentes que funcionam sem problemas com o ActionPack, mantendo as funcionalidades comuns para forms e helpers para tratamento de erros. Além disso, ActionController::Base será em essência um ActionController::Metal com a inclusão de alguns módulos, mas você ainda poderá usar a versão simplificada com Metal se você não precisar das funcionalidades incluídas.

Assim, todas essas medidas tornarão o Rails muito mais granular, permitindo que você escolha cada parte que será usada ou não na sua aplicação, de acordo com suas necessidades. Ao adicionar apenas as partes necessárias, você ira reduzir o uso de memória e a complexidade de seus aplicativos. De certa forma, essas mudanças respondem à parte das críticas feitas por Fred George, no que diz respeito de não podermos escolher apenas as partes necessárias para cada projeto. Além disso, essas mudanças também poderão unir a comunidade Ruby criando apenas uma implementação "oficial" de cada componente.

Links para os slides e vídeos das apresentações feitas na conferência podem ser encontradas na página com a programação do site do Rails Underground.

Este artigo foi publicado originalmente em inglês em 14 de August de 2009 às 10:00 na categoria Eventos, Interessante, Rails. Você pode deixar um comentário ou um trackback do seu próprio site.