Quais são os Benefícios do Ruby on Rails? Após duas décadas de programação, Eu Uso Rails

Algumas vezes ouço pessoas a queixarem-se dos seus clientes, dizendo que insistem em usar Rails, que tiveram demasiada Kool Aid. Se são recrutadores, quase que se sentem mal do estômago por terem de encontrar outro programador Ruby on Rails ‘primadona’. Depois retiram algo semelhante a esta comparação espantosamente ignorante entre Git e PHP para provar o seu ponto de vista. “Eles nem sabem o que estão a pedir”, dizem eles.

Para nós como programadores, por vezes parece de facto que os nossos clientes não fazem a menor ideia. Gostamos de exagerar casos como este. Quando se pensa um pouco sobre isso, não parece correcto pensar que uma pessoa que me dá dinheiro para construir coisas é de alguma forma limitada e “simplesmente não o recebe”. De facto, acredito que a maioria dos clientes conhece bem as suas opções e mesmo assim decide ir com Rails.

Tentarei explicar o que, na minha opinião, torna Rails suficientemente benéfico para ser seriamente considerado para uma infinidade de projectos e necessidades.

Benefícios do Ruby

É possível que ninguém soubesse sequer dos benefícios do Ruby se não fosse o próprio Rails. Algumas pessoas gostam de depreciar o Ruby dizendo que é “tão fácil para Ruby” com o seu “cavaleiro de armadura brilhante chamado Rails” e que, sem Rails, “Ruby seria irrelevante”. Não posso dizer com certeza se isso é ou não verdade, mas sei que seria uma enorme vergonha se o mundo deixasse escapar uma linguagem tão soberba. O facto é: o autor de Rails escolheu Ruby deliberadamente, e a sua aposta “selvagem” valeu a pena com enormes juros. O que ele viu na altura, muitos outros podem ver hoje. O Ruby de alguma forma permite aos programadores de uma forma especial que é tão difícil de explicar às “massas não lavadas”. Então, porquê utilizar o Ruby on Rails? O Ruby faz os programadores felizes, como anunciado.

Embora a maioria dos programadores concorde que o Ruby é útil, alguns vêem-no como demasiado. Preocupam-se com o que pode acontecer com todas as liberdades que o Ruby permite, todo o potencial de utilização indevida. Deixem-me ilustrar com algumas correcções de macacos:

"1".to_i #=> 1class String def to_i raise 'foobar' endend"1".to_i #=> RuntimeError: foobar

É assim tão fácil: com apenas cinco linhas de código, tomámos uma classe existente e anulámos o seu comportamento. Nohting é sagrado – nem sequer uma String. Este erro particular seria fácil de detectar, mas as coisas podem ficar muito mais sinistras:

class String def to_i self.to_f - 1.13 endend"2".to_i #=> 0.8700000000000001

Apenas assim, introduzimos um erro na classe String que poderia ser envolvido e obscurecido por camada sobre camada de complexidade.

Por isso, pode estar a pensar: Será que toda a gente e a sua mãe podem estragar a minha preciosa aplicação? Embora este comportamento pareça realmente assustador – não é realmente. Em cinco anos de utilização do Ruby, tive exactamente zero problemas com este comportamento. Pode parecer contra-intuitivo, mas também o é conduzir carros a 60 MPH em direcções opostas, separados apenas por uma fina linha branca no meio da estrada. Na prática, ambos funcionam notavelmente bem.

Outro benefício é que a Ruby é uma ferramenta versátil. Como tal, tem arestas afiadas, semelhantes a facas. Gosto de pensar que os adultos podem manejar facas apenas à prova de facas é para, bem, crianças (Tweet). E ser tratado como uma criança em TI deixa-nos uma vítima do paradoxo de Paul Graham’s Blub: pensamos que estamos melhor sem certas características que não compreendemos ou que alguém nos disse que é demasiado perigoso. Claro que hoje nos perguntamos “porquê usar Ruby on Rails”; assim, este é um debate para outra altura. É certo que o Ruby perde algumas características que outras línguas têm (Lisp hmm, hmm). All-in-all, Ruby está perto do topo do ‘continuum do poder da linguagem’.

Os meus primeiros anos com Ruby foram humildes. Aprendi tanto só de ler através do código dos outros. Por vezes, fiquei espantado; outras vezes, fiquei louco; mas eventualmente, este conhecimento permitiu-me comunicar com o meu computador muito mais eficazmente do que antes. Quase sinto pena de algumas outras linguagens ‘burocráticas’ que nos fazem saltar por entre aros só por saltar por eles, tudo isto enquanto vos digo “Só estou a fazer o que é melhor para vós, é para o vosso próprio bem!”

Pragmatismo

Existe um profundo respeito pelo pragmatismo tricotado no ADN do Rails ao nível mais baixo possível. Em combinação com os benefícios do Ruby, este pragmatismo produz soluções elegantes e encoraja/inspira a comunidade de desenvolvimento Ruby on Rails a fazer o mesmo. O pragmatismo é frequentemente anunciado como uma tenda de Rails, por isso esta afirmação não é nova, mas foi-me recordada a sua veracidade muito recentemente quando um amigo meu tentou mostrar-me o quão “fixe” Hibernate é realmente. Ele estava a debater-se. Pude sentir a sua dor, uma vez que ele não foi capaz de definir uma miríade de opções e parâmetros de configuração que deveriam ter sido, em primeiro lugar, padrões de enquadramento.

Com a idade, os meus padrões de complexidade artificial têm crescido cada vez mais alto. Considerando que comecei a escrever código de produção em 1989 aos 11 anos de idade (começando com um projecto para o meu vizinho do lado em Clipper Summer ’87), tenho uma tolerância próxima de zero para complicações desnecessárias. E Rails pontua realmente alto nesse departamento. É mais do que apenas ‘convenção sobre configuração’; estou a falar de toda a mentalidade pragmática que é altamente valorizada dentro e permeia a comunidade Rails.

Expressividade

Rails é o mais próximo do inglês (a menos que se esteja a usar COBOL). Utiliza o que é conhecido como uma DSL interna, estendendo o Ruby com a sua própria semântica. A construção de uma DSL é sempre perigosa, uma vez que se está efectivamente a desenvolver uma nova linguagem. Por ser interna, não precisa de usar um analisador externo, mas de certa forma parece ser uma nova linguagem. A equipa Rails conseguiu um bom equilíbrio com a sua DSL, utilizando-a onde faz sentido e só raramente a exagera, demonstrando um excelente auto-controlo. Penso que qualquer programador, independentemente da experiência Rails, (e mesmo alguns não programadores) poderia compreender isto:

Na verdade, se não estiver familiarizado com Ruby, isto pode parecer estranho – é quase como se não fosse uma linguagem de programação. Uma vez que se aperceba que é apenas uma chamada de método sem parênteses, está pronto a partir. Ainda assim, a DSL Rails sente-se como se fosse esta linguagem especial para descrever requisitos, quando na realidade é apenas nomeação inteligente e uso inerente da excelente sintaxe do Ruby.

Comunidade

Rails tem um exército de committers que se certificam de que se mantém em estado de ponta. Muitos projectos acalmam com a idade, mas com Rails, as faíscas ainda voam quando as decisões precisam de ser tomadas. Parece que os mantenedores (ainda) se preocupam verdadeiramente e querem que as pessoas usem Ruby on Rails e compreendam os seus benefícios.

Embaixo do próprio Rails, como uma cereja no topo, está Ruby com o seu formidável gestor de pacotes, RubyGems, comparável ao CPAN em termos de número de pacotes – e considerando a idade do CPAN, essa afirmação é (para o dizer de forma suave) muito impressionante. O Rails teve um breve descarrilamento quando tentou fazer os seus próprios “plugins Rails”. Felizmente, isto não colou, por isso RubyGems continua a ser a fonte unificada e soberba para código programado por indivíduos muito brilhantes.

A sinergia entre uma linguagem fria, uma estrutura web pragmática e uma comunidade soberba dá ao Rails um resultado muito melhor do que a soma das suas partes.

Maturidade

Rails tem estado à volta do bloco. De uma forma hipster, já nem sequer é assim tão fixe. Isto é bom quando se trata de escolher uma pilha de tecnologia: quer-se algo comprovado. E Rails é exactamente isso. Escrevemos recentemente um artigo falando sobre a grande variedade de intérpretes Ruby e tempos de execução que estão agora disponíveis.

Marketing

Eu sei, eu sei. Como profissional de TI, devo realmente valorizar as coisas ‘sérias’ e ignorar o ‘brilho’. Pode parecer superficial, mas vamos enfrentá-lo:

1. Comparado com a concorrência, o site Rails tem bom aspecto.
2. O primeiro elenco de ecrã do Rails, antigamente, era simplesmente de tirar o fôlego. Pode não parecer assim tão impressionante hoje em dia, mas lembre-se que a única razão que todos conhecemos sobre Java é que todos estavam tão entusiasmados com a possibilidade de executar uma Applet Java no navegador. Afinal, isto acabou por não ser assim tão importante, mas mesmo assim, isto colocou Java no radar. Da mesma forma, este screencast de 15 minutos do motor do blog foi um enorme sucesso que entusiasmou muita gente.

/ol>

Nem sequer se trata de vaidade; trata-se de envolver o maior número possível de pessoas inteligentes para colocar água no moinho. Quando as estruturas são consideradas, o melhor lugar para estar é na multidão. Escolher uma estrutura em que estas pessoas inteligentes estão a concentrar-se significa simplesmente que muito mais terreno já está coberto para si. E isto leva-me ao meu próximo ponto.

(Não) Reinventando a Roda

Tenho um ponto macio para estruturas minúsculas. Gosto quando consigo compreender o que uma determinada estrutura está a fazer e porquê. Neste sentido, o Rails está um pouco inchado, e por vezes até avassalador.

O dilema aqui: quantas vezes queres escrever o mesmo material vezes sem conta? Algumas delas podem ser reescritas melhor, tenho a certeza, mas leva muito tempo. Quanto mais permitir que o Rails faça por si, menos tem de se preocupar em reescrever ou reimplementar a sua funcionalidade.

Rails é (como se costuma dizer) ‘pilhas incluídas’. Isto não é uma coisa boa se estiver interessado na parcimónia ou se sentir necessidade de ter um conhecimento extensivo de como tudo funciona. Na prática, se deixar de lado os seus medos, parece funcionar. O Rails tem padrões razoáveis para quase tudo o que precisa e é suficientemente modular para evitar encurralá-lo num ponto apertado.

Conclusion

Ask yourself novamente, porquê usar Ruby on Rails? Rails é adequado tanto para websites públicos de última geração que competem com aplicações JavaScript de página única, como para aplicações complexas de sistemas centrais empresariais que normalmente parecem um pouco mais ‘feias’ (com uma IU mais genérica e de menor fidelidade), mas compensam esta mancha com uma tonelada de regras e lógica empresarial complicada. A sua vantagem é que é versátil e capaz de competir tanto com o elegante como com o poderoso.

Para a maioria dos problemas comuns, Rails tem à sua disposição um componente quase totalmente à mão com documentação que está consistentemente acima da média (de alguma forma, a equipa central de Rails convenceu os colaboradores de que escrever documentação é fixe (embora todos saibamos que não é), levando a documentos bem escritos, concisos e que poupam tempo).

Quando se põem de lado unicórnios e abraços de sexta-feira, acaba-se com uma estrutura poderosa que pode ser usada tanto para o seu futuro jogo de mudança como para o seu próximo site de negócios no meio da estrada. E com o seu conjunto de pedras preciosas de topo de gama, tem ao seu alcance um arsenal que implementa algumas das ideias mais brilhantes na programação de computadores. Sem alarido.

Relacionado: Truncagem do Timestamp: Um conto de Ruby on Rails ActiveRecord