Ruby on Rails

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Question book.svg
Esta página ou secção não cita nenhuma fonte ou referência, o que compromete sua credibilidade (desde novembro de 2010).
Por favor, melhore este artigo providenciando fontes fiáveis e independentes, inserindo-as no corpo do texto por meio de notas de rodapé. Encontre fontes: Googlenotícias, livros, acadêmicoScirusBing. Veja como referenciar e citar as fontes.
Ruby on Rails
Ruby on Rails logo.jpg
Rails default index.png
Boas vindas do Rails
Desenvolvedor Rails Core Team
Lançamento julho de 2004
Versão estável 3.2.11 (8 de janeiro de 2013; há 81 semanas e 2 dias)
Idioma(s) inglês
Escrito em Ruby
Sistema operacional Multiplataforma
Gênero(s) Framework Web
Licença Licença MIT
Estado do desenvolvimento Ativo
Página oficial rubyonrails.org

Ruby on Rails é um framework livre 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 arquitetura MVC (Model-View-Controller).

História[editar | editar código-fonte]

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 2003.

Componentes[editar | editar código-fonte]

O Rails é um "meta-framework" (ou seja, um framework de frameworks), composto pelos seguintes frameworks:

Active Record[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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 "leitor" (getter) e um "modificador" (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[editar | editar código-fonte]

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. Se o desenvolvedor quiser, 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[editar | editar código-fonte]

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 suficiente para 90% das aplicações atuais[carece de fontes?]. 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.

Ver também[editar | editar código-fonte]

Ligações externas[editar | editar código-fonte]

Ícone de esboço Este artigo sobre software livre é um esboço. Você pode ajudar a Wikipédia expandindo-o.