Já havia ouvido e lido alguma coisa sobre o Ruby on Rails, mas comecei a ter algum contato com o framework, quando descobri o Redmine.

O Redmine é um gerenciador de projetos bastante eficiente, desenvolvido nessa plataforma. Adorei o produto e comecei a ficar curioso sobre o que na verdade seria o Ruby on Rails. Comecei a pesquisar, ler e a assistir aos vídeos espalhados pela web e pelo YouTube.

Juntei aqui alguns textos que achei interessantes como introdução e alguns comerciais que comparam o Ruby on Rails com outras linguagens de programação. Os comerciais são vídeos divertidos nos moldes das propagandas Mac x PC.

Saiba mais sobre o novo framework Ruby On Rails

Por: José de Menezes

Ruby On Rails é um framework de código aberto para desenvolvimento de aplicações Web, escrito em Ruby.

Rails foi projetado para:

• Ser uma solução de desenvolvimento completa;
• Que as suas camadas se comuniquem da forma mais transparente possível;
• Ser uniforme, escrito totalmente apenas numa linguagem;
• Seguir a arquitectura MVC (Model-View-Controller)

Essas características tornam o Rails extremamente produtivo e mantem baixa a curva de aprendizagem. A versão atual do Rails é 1.8.4-19 Final.

Componentes

O Rails é um “meta-framework”, contendo 5 outros frameworks:

• Active Record;
• Action Pack;
• Action Mailer;
• Active Support;
• Active WebServices.

Cada um destes “mini-frameworks” está disponível via gem (sistema de gerenciamento de pacotes para Ruby), mas todos eles são baixados e instalados automáticamente quando se instala o gem do Rails.

Tempo de desenvolvimento

Rails segue dois conceitos que visam aumentar a produtividade do desenvolvedor: DRY e Convention over Configuration. Estes métodos estão implementados por todo o Rails, mas podem ser mais notados nos “pacotes” do Active Record (ORM, Object Relational Mapper) e Action Pack (MVC)

DRY

DRY (Don’t Repeat Yourself, Não se repita) é o conceito por trás da técnica de definir nomes, propriedades e códigos em somente um lugar e reaproveitar essas informações em outros.

Por exemplo, ao invés de ter uma tabela Pessoas e uma classe Pessoa, com uma propriedade, um método “acessador” (getter) e um “mutador” (setter) para cada campo na tabela, tem-se apenas no banco de dados. As propriedades e métodos necessários são “injetados” na classe através de funcionalidades da linguagem Ruby.

Com isso, economiza-se tempo, já que não é necessário alterar a tabela, o “bean”, o “form bean”, o “local home”, o “home”, o “session”, … Alterando apenas no banco de dados, tudo o que se baseia nessas informações são atualizadas automaticamente.

Convention over configuration

Na maioria dos casos, usamos convenções no dia-a-dia da programação, em geral para facilitar o entendimento e manutenção por parte de outros desenvolvedores. Sabendo disso, e sabendo que o tempo gasto para configurar XML em alguns frameworks de outras linguagens é extremamente alto, decidiu-se adotar esse conceito.

Ele diz basicamente que deve-se assumir valores padrão onde existe uma convenção. Caso o desenvolvedor deseje, pode-se sobrescrever essa convenção com o valor necessário. Por exemplo, uma classe User pode ter seus dados armazenados na tabela Customer. Seguindo a convenção, seria na tabela Users. Com isso, o tempo de desenvolvimento cai ainda mais.

Escalabilidade

Uma questão frequente é sobre a escalabilidade de aplicações escritas em Rails. Ao contrário de outras tecnologias, você não precisa fazer um código específico para que o sistema esteja preparado para “escalar”. Quando necessário, pode-se adotar uma das táticas disponíveis para escalabilidade em Rails. Vale notar que o único problema da escalabilidade é a manutenção de sessões entre servidores. Portanto, a saída mais óbvia é guardar estas sessões em volumes NFS, acessíveis por todos os servidores de aplicação. Outra tática é usar o armazenamento de sessões diretamente no banco de dados. Uma terceira, seria salvar a sessão em um cookie na máquina do usuário. Como pode-se ver, uma aplicação Rails já nasce com todo o suporte necessário para crescer sem traumas.

Porém, a maioria dos sites não necessita de esquemas sofisticados de escalabilidade. Em sites menores ou normais, uma configuração padrão do servidor web consegue suportar uma boa quantidade de carga, principalmente se forem usados o lighttpd e FastCGI. Existem casos de sites feitos em Rails que suportaram 5 milhões de visitas em um mês, ou seja, aproximadamente 115 por minuto, uma performance considerada bastante suficiente para 90% das aplicações atuais.

Fonte: PlugMasters

Ruby on Rails vs Java

Ruby on Rails vs .NET

Ruby on Rails vs .NET

Ruby on Rails vs PHP

Ruby on Rails vs PHP

Ruby on Rails vs PHP

Ruby on Rails VS ColdFusion

Ruby on Rails VS Django