Ruby On Rails

10:21 am Desenvolvimento, Internet, Web 2.0

Quem trabalha com “Desenvolvimento Web” quase certamente já ouviu falar de Ruby On Rails. Assim como muitas tecnologias, RoR (pra encurtar) gerou muito hype nos últimos meses e, consequentemente, uma legião de fanboys que pregam fervorosamente que RoR é a melhor coisa que já inventaram desde o pão-fatiado. :-)

O quê

Mas em que consiste exatamente o tal “Ruby On Rails”? Traduzindo diretamente do site oficial:

Ruby On Rails é um framework web de código aberto que é otimizado para a satisfação do programador e produtividade sustentável. Ele permite que você escreva código elegante ao favorecer convenção ao invés de configuração.

E ainda:

Ruby On Rails é um framework completo para desenvolvimento de aplicações web de acordo com o padrão Model-View-Controller (ou MVC).

Até aí, nenhuma novidade. Antes da popularização de RoR, já existiam diversos outros excelentes frameworks como ASP.NET, a pilha Servlets+JSP+Struts+Hybernate e PHP/Zend, só pra citar alguns. O diferencial de RoR está justamente na adoção da metodologia de desenvolvimento de software “Ágil”, ao focar as funcionalidades do framework nas necessidades diretas dos desenvolvedores e diminuir tanto quanto possível o tempo gasto com instalação e configuração do ambiente.

Por esse motivo, RoR se tornou especialmente popular entre desenvolvedores e empresas que adotam processos semelhantes ao “Extreme Programming”, onde a elaboração rápida de um protótipo e a constante refatoração do código são essenciais. RoR realmente prima nestes casos. Chega a ser assustador a facilidade com que se gera o esqueleto e o protótipo de uma aplicação MVC, ou o número ínfimo de linhas de código que são necessárias para implementar funcionalidades relativamente sofisticadas.

Porquê

Descontando um pouco do exagero típico dos fanboys, é fácil notar com pouco tempo de uso porque Ruby On Rails se popularizou tão depressa.

  • Convenção ao invés de Configuração: Levante a mão quem nunca perdeu pelo menos umas 2 horas de trabalho tentando instalar ou configurar uma aplicação/sistema/etc e descobriu no fim do dia que o problema era um “;”, ou um path errado. Pois é, RoR procura acabar com essa dor-de-cabeça ao eliminar tanto quanto possível os malfadados arquivos de configuração através da adoção de uma série de convenções que permite integrar as diferenças partes do framework sem praticamente nenhuma intervenção direta do desenvolvedor.As convenções englobam todo tipo de aspecto de uma aplicação web: o nome dos modelos e tabelas relacionais associadas; o nome da colunas das tabelas que constituem chaves primárias e estrangeiras; o nome dos arquivos e das classes que implementam cada camada da estrutura MVC; o nome e identificador dos campos HTML e diversas outras.
  • ActiveRecord: Active record é um design pattern utilizado para acessar bancos de dados e fazer o mapeamento Objeto-Relacional. O padrão em si é bem mais antigo do que RoR, mas a implementação utilizada em RoR em específico prima pela qualidade e é um dos pontos fortes e mais badalados do framework. A extensa utilização de instrospeção, tanto do lado da estrutura relacional, quanto da parte das classes e objetos torna praticamente desnecessário escrever mais do que meia dúzia de linhas de código para se fazer o mapeamento de uma classe/tabela.
  • ActionView: Da mesma forma que o módulo ActiveRecord é responsável pela implementação dos modelos, ActionView é o módulo responsável pela implementação das visões. O diferencial está no fato de este módulo ser fortemente influenciado pela metodologia ágil: quase todas as funcionalidades tipicamente utilizadas para construção de uma interface web podem ser adicionadas através de uma API concisa e intuitiva. Mesmo as tendências mais recentes das aplicações Web modernas — como Javascript, DHTML e AJAX — estão fortementes integradas ao framework. Em RoR, usa-se apenas uma linha de código para adicionar funcionalidades relativamente complexas como “atualizar uma tabela/list assincronamente” ou “adicionar um campo de texto com auto-sugestão” (no estilo Google Suggest))
  • Plugins: Outra grande vantagem de Ruby On Rails é sua extensibilidade. Devido à sua crescente popularidade, existem hoje literalmente centenas de plugins (normalmente gratuitos) disponíveis para os desenvolvedores incrementarem suas aplicações conforme as necessidades individuais de cada projeto — permitindo assim que uma gama enorme de problemas sejam rapidamente resolvidos sem necessariamente tornar o core do framework demasiadamente inchado. Mas cuidado: em alguns casos, é preciso ficar atento para não se perder mais tempo escolhendo o melhor plugin que implementa uma deterinada funcionalidade do que efetivamente instalando e utilizando o plugin. :-)
  • Ruby: Flamewars discutindo qual a melhor linguagem são quase tão antigas quanto a própria computação — portanto não vou me alongar demasiadamente nesse tópico — mas é inegável que parte da atratividade de RoR advém da linguagem Ruby. Pra quem ainda não conhece, sugiro o tutorial rápido do site oficial, ou ainda o divertidíssimo“Guia Pungente”, por “Why The Lucky Stiff”.

Por que não

Nenhuma boa análise técnica estaria completa sem uma seção de “Contras”, e esse post não poderia ser diferente.

  • Performance: Um dos compromissos que precisam ser feitos para se tirar proveito da elegância e agilidade de se utilizar uma linguagem como Ruby é o desempenho. Por ser uma linguagem dinamicamente tipada que executa sobre uma interpretador (pra lá de ineficiente, diga-se de passagem), Ruby On Rails é inegavelmente um framework com overhead alto. Muita gente vai argumentar que baixa performance não é tão crítico se sua arquitetura tem boa escalabilidade, e outros ainda irão citar diversas técnicas para minimizar esse overhead, mas ainda assim, em alguns casos a recomendação é deixar de usar justamente as funcionalidades que tornam o framework interessante.Por outro lado, as comunidades por trás de Ruby e RoR estão cientes desse problema e tem trabalhado para atenuá-lo. A versão 2.0 de RoR, por exemplo, já apresenta significantes melhorias, e a próxima grande revisão da linguagem Ruby que deve ser lançada ainda nessa década também promete ganhos substanciais de performance, graças à utilização de um nova máquina virtual.
  • Código legado: Uma das máximas de RoR — “Convenção ao invés de configuração” — perde seu appeal quando consideramos sistemas legados. Nesses casos, é provável que sua base de dados ou suas classes existentes não tenham adotado as mesmas convenções utilizadas por RoR. Com isso, é necessário adicionar diversas diretrizes no código para sobrescrever os valores e padrões utilizados pelas tais convenções. Não chega a ser a mesma dor-de-cabeça de se editar um “hibernate.cfg.xml” ou um “web.xml”, mas é possível que você acabe sendo forçado a escrever alguns trechos de [gasp!] SQL. :-)
  • Documentação: Algumas tecnologias promissoras perdem momento devido à carência de documentação. Ruby On Rails sofre do problema inverso: excesso de documentação. Hoje em dia é natural utilizar a Internet para buscar por trechos de código, recomendações, receitas ou (no caso de RoR) plugins para se solucionar um problema específico ou implementar corretamente uma funcionalidade. O problema é que, frequentemente, a documentação ou plugin encontrados estão defasados por terem sido escritos/implementados com foco em uma versão do framework que já está deprecada. Como o desenvolvimento de RoR é muito dinâmico — a versão 1.0 foi lançada em Dez/05; a versão 1.1 em Mar/06; a 1.2 em Jan/07; e a 2.0 em Dez/07 — e não existem garantias de compatibilidade, muitas vezes torna-se difícil encontrar a solução correta para a versão específica do framework que você está utilizando.

Pra finalizar

Se você se é desenvolvedor Web, mora em Belo Horizonte, se interessou por Ruby On Rails e gostaria de saber mais a respeito, o Instituto Turing está oferencendo um curso intensivo à partir do dia 14 de abril. Para maiores informações, mande e-mail para cursos@institutoturing.org.

3 Respostas
  1. kenji :

    Date: abril 7, 2008 @ 10:24 am

    gostaria de acrescentar que uma grande diferença entre RoR e os demais frameworks é que RoR talvez tenha sido o único feito a partir de uma solução de um problema real.

    Talvez por isso, RoR não tenha os “vícios” de muitas aplicações com muitas características que parecem boas idéias na teoria, mas que viram verdadeiras quimeras na prática ;-)

  2. Paulo Ferreira de Moura Junior :

    Date: abril 7, 2008 @ 11:41 am

    Acho o RoR muito bacana, mas outro projeto que tem chamado a minha atenção é o Grails (Groovy on Rails). Parece bastante com o RoR, mas usa o Groovy como linguagem e, mesmo utilizando como base frameworks bem conhecidos como Spring e Hibernate, abstrai tudo isso. Para a comunidade Java, acho que é uma alternativa mais adequada, pois pode-se usar “código legado” desenvolvido nesta plataforma.

  3. Repolês :

    Date: abril 7, 2008 @ 3:58 pm

    Gostei muito desse overview sobre o Ruby On Rails. E valeu pela dica do curso. Vou procurar me informar!