// 9 Junho 2007
A dot vem acompanhando e se inspirando nos passos da 37signals desde sua fundação e não é para menos que a tecnologia da qual fazemos uso para a codificação de nossos sistemas web é o framework Ruby on Rails, por eles desenvolvido.
Uma vez que o Rails é diretamente derivado dos paradigmas que fazem do Ruby uma linguagem tão produtiva - a Linguagem Centrada no Programador (ou, Programmer-centered Language) - nada destoa ou parece sobrar na sinergia entre ambas as ferramentas.
Se o Ruby é uma linguagem poderosa e que oferece tanta flexibilidade quanto qualquer outro servidor de aplicação orientado a Web, o framework Rails (como todo framework) tem como objetivo a viabilização de um trabalho mais produtivo no que se refere as tarefas mais corriqueiras e que se colocam entre o programador e o término de seu trabalho. O diferencial, contudo, vai ficando evidente quando o programador começa a fazer uso efetivo do Ruby on Rails.
A estrutura sugerida pelo Rails garante que sua filosofia de desenvolvimento venha a reboque e se instale entre as más práticas e os vícios do programador, empurrando-as para o lado até caírem de cima da mesa direto dentro do cesto de lixo.
Boa parte da programação em Rails garante uma experiência de codificação mais agradável e produtiva, cortando caminhos que normalmente levariam a um trabalho sistemático e repetitivo e tirando da frente do programador tudo aquilo que normalmente é obstáculo.
A linguagem, que é totalmente orientada a objetos, foi desenvolvida por Yukihiro Matsumoto - carinhosamente apelidado de Matz pela comunidade de tecnologia - em meados de 1993 e teve seu lançamento público em 1995.
Com a evolução da velocidade dos processadores, o barateamento de memórias e outros componentes, as linguagens de programação vêm - desde a década de 90 - se concentrando menos em capacidade de otimização de código gerado e muito mais em fornecer ferramentas de alto nível que ofereçam para o programador um conjunto de blocos de construção que garantam maior velocidade de desenvolvimento, ainda que o código gerado não seja o mais eficiente.
O fenômeno parece um pouco com o que fez com que a Usabilidade se popularizasse. Passadas as décadas nas quais o usuário tinha pouco acesso a tecnologia, esta tinha mesmo de deixar de ser tão centradas nas necessidades do implementador e passar a se concentrar no usuário. Muito semelhante mesmo ao que vem acontecendo com as linguagens de programação, que vêm deixando de ser tão centradas no que a máquina precisa e passando a se concentrar em oferecer um conjunto mais agradável e produtivo para quem desenvolve o sistema.
Esta “Centralização no Humano” é uma característica muito clara no Ruby on Rails e fica ainda mais clara quando se percebe que Matz também se calcou em outros princípios tão em voga em Usabilidade, como o “Princípio das Poucas Surpresas” e o “Não Repita a si Mesmo” (ou, Principle of Least Surprises POLS e Don’t Repeat Yourself DRY).
A despeito de suas claras diferenças, se comparada com outras linguagens, o Ruby tende a não surpreender ou entrar em conflito com a intuição do programador, o que é um grande avanço sobretudo para quem tem o Ruby como sua primeira linguagem de programação.
Este princípio acaba emprestando ao programador um poder desmedido quando - ainda inexperiência na ferramenta - precisa deduzir ou intuir o que deve fazer sem olhar um manual de referência.
Tanto a linguagem quanto framework de Matz seguem uma linha mestra bastante nítida depois que você começa a fazer uso das ferramentas, a norma da convenção como sendo mais importante que a configuração, o que tenta tirar de uma vez por todas a noção de que quanto mais parametrizável um sistema melhor ele é.
Isso vai desde a regra de formação do nome de uma tabela no banco de dados, a partir de uma classe até as convenções que o próprio usuário pode criar dentro do Ruby on Rails.
No momento em que o Ruby on Rails monitora a criação de uma classe “Cliente” e automaticamente nomeia a tabela correspondente como “Clientes”, o estabelecimento de uma cultura de convenções começa a se fazer presente, liberando o programador de se preocupar em ser criativo com o que menos deveria demandar criatividade.
Model-View-Control
O Ruby on Rails tem ainda a característica de ser implementado usando o padrão arquitetural conhecido como Model-View-Control, que reduz o acoplamento entre o modelo de dados, interface de usuário e lógica de negócios, o que empresta flexibilidade na hora de efetuar manutenções corretivas ou evolutivas, uma vez que cada projeto de sistema acaba sendo um projeto de integração entre camadas autônomas.
Conforme a filosofia da ferramenta, o Ruby on Rails impõe gentilmente suas convenções para o bem do programador, que começa a pensar o MVC como sendo uma forma ágil de desenvolver projetos sem perder de vista onde está o que e sem ter de se descabelar quando o contratante resolve modificar os requisitos de um projeto.
Muito da inclinação do Ruby on Rails para ser uma ferramenta de desenvolvimento de alta produtividade reside nas características de estruturação do código. Mesmo um novo programador, entrando em um projeto, tem mais chances de entender aquele bando de código, graças em parte a princípio da convenção sem configuração. Além disso, como a lógica está toda compartimentada em um esquema MVC tanto o acesso ao que já foi feito quanto uma eventual alteração é bem mais fácil de ser implementada.
Conclusão
Estamos em um ecossistema tecnológico onde fábricas de software fazem de tudo para vender projetos de desenvolvimento em Java, usando bancos de dados cuja escalabilidade necessita de muito dinheiro e muito hardware, onde projetos menores são rotulados de projetos pouco importantes e pouco lucrativos.
Não precisa ser assim… Mesmo sistemas de maior porte podem ser levados a cabo, sem maiores problemas e com baixíssimo custo de propriedade, por ferramentas como Python com Turbo Gears ou Django, CakePhP e Ruby on Rails.
Cada ferramenta tem vantagens intrínsecas, que são ou não afins dos requisitos de projetos identificados para o projeto a ser desenvolvido. Nós da dot temos motivo para preferirmos desenvolver em Ruby on Rails: ele mostra o caminho sem se colocar no seu caminho; é elegante sem que nos faça tropeçar nesta elegância; e usa das boas práticas de forma pragmática e sem academicismos supérfluos.
O custo de processamento e memória dos servidores vêm caindo já há duas décadas além de todas as expectativas. Concentrar-se em linguagens e frameworks que exijam sucessivas otimizações no código e sintonia entre hardware e software, embora possa alcançar alguns micro-segundos a mais de velocidade do sistema, pode vir a se mostrar uma faca de dois gumes, aumentando o acoplamento entre camadas.
No fim, o que é mais importante?
A dot considera como um bom investimento a criação de um sistema que garanta saúde financeira para a contratante e velocidade na implantação dos entregáveis, mantendo baixo custo de propriedade e garantindo escalabilidade.
Nos parece que o homem/hora, de quem produz um sistema, onera mais, hoje, o custo total de um projeto, do que o gasto relativo em hardware para torná-lo mais rápido, caso necessário.
Diante desta realidade, nos escapa o motivo que faça uma corporação escolher um alto custo de desenvolvimento e um maior custo de propriedade, quando o caminho mais curto entre não-Ter e Ter um sistema é usar um framework como o Ruby on Rails no desenvolvimento de seus projetos.
Bruno Accioly