Ruby on Rails é um meta-framework gratuito que promete aumentar velocidade e facilidade no desenvolvimento de sites orientados a banco de dados (database-driven web sites), uma vez que é possível criar aplicações com base em estruturas pré-definidas. Frequentemente referenciado como Rails ou RoR, o Ruby on Rails é um projeto de código aberto escrito na linguagem de programação Ruby. As aplicações criadas utilizando o framework Rails são desenvolvidas com base no padrão de projeto MVC (Model-View-Controller).
História
Ruby on Rails foi uma extração de David Heinemeier Hansson de um projeto seu, o gerenciador de projetos Basecamp. Foi lançado a público pela primeira vez em julho de 2004.
Componentes
O Rails é um "meta-framework", uma vez que é uma junção de cinco frameworks:
Active Record
O Active Record é uma camada de mapeamento objeto-relacional (object-relational mapping layer), responsável pela interoperabilidade entre a aplicação e o banco de dados e pela abstração dos dados.
Action Pack
Compreende o Action View (geração de visualização de usuário, como HTML, XML, JavaScript, entre outros) e o Action Controller (controle de fluxo de negócio).
Action Mailer
O Action Mailer é um framework responsável pelo serviço de entrega e até mesmo de recebimento de e-mails. É relativamente pequeno e simples, porém poderoso e capaz de realizar diversas operações apenas com chamadas de entrega de correspondência.
Active Support
Active Support é uma coleção de várias classes úteis e extensões de bibliotecas padrões, que foram considerados úteis para aplicações em Ruby on Rails.
Action WebServices
Provê uma maneira de publicar APIs interoperaveis com o Rails, sem a necessidade de perder tempo dentro de especificações de protocolo. Implementa WSDL e SOAP.
O Action Web Service não estará mais presente na versão 2.0 no Rails, visto que o mesmo está voltando-se para a utilização do modelo REST. Mesmo assim, aos ainda interessados em utilizá-lo, será possível fazê-lo através da instalação de um plugin.
Tempo de desenvolvimento
Ruby on 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 "mudador" (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 é atualizado 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
A maioria dos sites não necessita de esquemas sofisticados de escalabilidade, bastando alguns aceleradores. 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 FastCGI, LightTPD ou Mongrel, que são necessários para obter uma velocidade aceitável de abertura da página. Comparando uma aplicação com FastCGI e sem FastCGI (rodando Ruby direto como CGI), a diferença é perceptível em qualquer aplicação. O processamento do código (sem contar o tempo de download) em CGI ocorre em no mínimo 10 segundos mesmo em servidores Quad Core, enquanto que em FastCGI o desempenho é notável: em no máximo 1 segundo a página é processada, tal qual linguagens web como PHP.
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. Nestes sites, 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.
Ruby on Rails foi uma extração de David Heinemeier Hansson de um projeto seu, o gerenciador de projetos Basecamp. Foi lançado a público pela primeira vez em julho de 2004.
Componentes
O Rails é um "meta-framework", uma vez que é uma junção de cinco frameworks:
Active Record
O Active Record é uma camada de mapeamento objeto-relacional (object-relational mapping layer), responsável pela interoperabilidade entre a aplicação e o banco de dados e pela abstração dos dados.
Action Pack
Compreende o Action View (geração de visualização de usuário, como HTML, XML, JavaScript, entre outros) e o Action Controller (controle de fluxo de negócio).
Action Mailer
O Action Mailer é um framework responsável pelo serviço de entrega e até mesmo de recebimento de e-mails. É relativamente pequeno e simples, porém poderoso e capaz de realizar diversas operações apenas com chamadas de entrega de correspondência.
Active Support
Active Support é uma coleção de várias classes úteis e extensões de bibliotecas padrões, que foram considerados úteis para aplicações em Ruby on Rails.
Action WebServices
Provê uma maneira de publicar APIs interoperaveis com o Rails, sem a necessidade de perder tempo dentro de especificações de protocolo. Implementa WSDL e SOAP.
O Action Web Service não estará mais presente na versão 2.0 no Rails, visto que o mesmo está voltando-se para a utilização do modelo REST. Mesmo assim, aos ainda interessados em utilizá-lo, será possível fazê-lo através da instalação de um plugin.
Tempo de desenvolvimento
Ruby on 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 "mudador" (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 é atualizado 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
A maioria dos sites não necessita de esquemas sofisticados de escalabilidade, bastando alguns aceleradores. 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 FastCGI, LightTPD ou Mongrel, que são necessários para obter uma velocidade aceitável de abertura da página. Comparando uma aplicação com FastCGI e sem FastCGI (rodando Ruby direto como CGI), a diferença é perceptível em qualquer aplicação. O processamento do código (sem contar o tempo de download) em CGI ocorre em no mínimo 10 segundos mesmo em servidores Quad Core, enquanto que em FastCGI o desempenho é notável: em no máximo 1 segundo a página é processada, tal qual linguagens web como PHP.
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. Nestes sites, 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.
