Ruby on Rails

Nestas férias resolvi estudar o Ruby on Rails, um framework de desenvolvimento Web que gradualmente está se popularizando no mercado – principalmente após o boom do Twitter, que foi desenvolvido nele.

À primeira vista, o Rails (para os íntimos) parece ser apenas mais uma linguagem de script (no servidor) à la PHP, ASP e afins. Ledo engano. O Rails, fundamentado na arquitetura Model View Controller (MVC), faz muito mais que rearranjar construções léxicas e oferecer uma sintaxe intuitiva e funcional. Construído em Ruby – linguagem de programação interpretada, e não vinculada explicitamente ao desenvolvimento web – o framework apresenta conceitos ousados, como por exemplo o de ser uma “ferramenta de opinião” (tradução livre, e adaptada ao contexto de: opinated software)! Por exemplo, em Rails, a recomendação é de se preferir as construções mais legíveis ( stock.send(basket.products) unless payment.refused? ) sobre as complicadas ( if payment.refused = false then stock.send(basket.products) ).

Diferentemente do que então é considerado politicamente correto, o Rails (à primeira vista) não vangloria-se por oferecer liberdade. Muito pelo contrário! A filosofia do framework é que se há uma maneira mais eficiente de se fazer algo, então que ela seja a padrão.

Outro conceito que deriva do primeiro é o da “convenção sobre a customização”, significando caminhos mais simples e intuitivos para o desenvolvedor – que domina minimamente o inglês técnico. O Rails preza por um minimalismo sintático incrível, onde o framework “deduz” a intenção do desenvolvedor baseado em algumas invariantes, tais como um esquema de nomenclatura de classes próprio e o contexto de símbolos em escopos específicos.

Validações, correções de código, consistências e mais consistências… Esta é uma tarefa (chata?) que normalmente fica relegada à fase final de uma aplicação, quando “aparam-se” as arestas para entregar o produto ao cliente. Em Rails é diferente, pois adota-se a filosofia do Desenvolvimento Dirigido a Testes (ou TDD, do inglês Test-Driven Development). Em TDD a idéia é elaborar testes que assegurem a consistência de sua aplicação desde o início, aliás, desde antes do início! Sim, a idéia é criar primeiro os testes, e depois implementar o código que os satisfaça, o chamado caminho Red > Green. Em Red, você elabora os testes, que inicialmente não serão satisfeitos, e acusarão erro. Em Green, você implementa as classes responsáveis em fazer o teste passar. O processo é gradual, e feito a partir de cada funcionalidade, de fora para dentro. Ou seja, a implementação do MVC que, usualmente, parte do modelo (M) para depois seguir para Interface (V) e controladores (C); segue o caminho V-C-M.

Ainda estou no início da minha curva de aprendizado. Apanhando um pouco com conceitos já cristalizados que eu estou tendo que me desfazer. Mas a empolgação da comunidade e a promessa de agilidade no desenvolvimento estão me impulsionando.

Para finalizar, algumas referências on-line (na ordem sugerida):

1. Try Ruby! : tutorial interativo, com um console on-line,  da linguagem de programação Ruby.
2. Rails for Zombies: faça um Twitter para zumbis! Tutorial básico super divertido.
3. Ruby on Rails Tutorial: Tutorial similar ao de cima, mais detalhado (e menos cômico). Nota: a parte de testes é meio problemática. Resolvi meus problemas do Capítulo 3 aqui.
4. Ruby on Rails Guides: Guia oficial do framework
5. Git Community Book: Sistema de Controle de Versão mais difundido na comunidade Rails (quase mandatório)
6. RSpec: Ferramenta para gerenciamento de Testes alternativa às classes nativas do Ruby.
7. Rubular: editor regexp on-line