IDGNow: Ruby on Rails ganha adeptos entre os desenvolvedores da Web 2.0
Com nome de canção de rock, o Ruby on Rails (conhecido também como RoR) aparece cada vez mais como uma linguagem popular entre webmasters pela alta produtividade derivada na simplicidade do desenvolvimento.
Lançado em 2004 pelo programador dinamarquês David Hansson, o framework foi codificado pela linguagem Ruby como uma maneira de simplificar o trabalho de desenvolvedores online, que perdiam muito tempo em processos repetitivos.
A preocupação do Ruby on Rails em trazer processos mais simples para o desenvolvimento online se reflete em dois motes que o projeto carrega.
O primeiro que o usuário não se repita (do inglês, Don´t Repeat Yourself), em que partes do código não precisam ser duplicadas para atender a partes semelhantes do projeto; e o Convenção sobre configuração (do inglês, Convention over configuration), que prega a padronização de processos orquestrados pelo Ruby on Rails.
Leia o texto completo no IDGNow. Leia também 22 Successful Ruby On Rails Web Applications
Lançado em 2004 pelo programador dinamarquês David Hansson, o framework foi codificado pela linguagem Ruby como uma maneira de simplificar o trabalho de desenvolvedores online, que perdiam muito tempo em processos repetitivos.
A preocupação do Ruby on Rails em trazer processos mais simples para o desenvolvimento online se reflete em dois motes que o projeto carrega.
O primeiro que o usuário não se repita (do inglês, Don´t Repeat Yourself), em que partes do código não precisam ser duplicadas para atender a partes semelhantes do projeto; e o Convenção sobre configuração (do inglês, Convention over configuration), que prega a padronização de processos orquestrados pelo Ruby on Rails.
Leia o texto completo no IDGNow. Leia também 22 Successful Ruby On Rails Web Applications
(postado por Augusto Campos)
Mas eu acho que o RoR hoje faz uma aplicação um pouco exagerada e ingênua desses princípios, sobretudo em relação aos ActiveRecords (o recurso que mais "economiza tempo" no framework).
Imagine que seu DBA resolve renomear um campo em uma tabela relacionada, esquece de avisar e seu sistema, ao invés de parar de funcionar, começa a gravar dados nos lugares errados ou deixar de gravá-los nos lugares certos... Muito chato. Não é algo fácil de ocorrer, mas é uma possibilidade.
Particularmente, eu gosto de ler um código onde não seja preciso "adivinhar" as coisas em cada pedaço de código que leio. Eu tenho que ler muitos scripts de uma aplicação RoR para ter uma idéia de como a base de dados se parece.
Claro, evitar isso é fácil, basta vc. declarar explicitamente o mapeamento entre propriedades e campos do ActiveRecord. Mas daí não há muitas vantagens em relação ao JPA do Java ou o (argh!) DLink do plagiador .NET (que, ao que parece, ainda não está disponível).
Outras coisas que me incomodam são a pouca escolha no que se refere a ambientes de execução para deploy da aplicação RoR em produção, a performance que um código excessivamente dinâmico terá em cenários de alta demanda, a escalabilidade, etc.