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

Às vezes eu ouço pessoas reclamando de seus clientes, dizendo que insistem em usar Rails, que já tomaram muito Kool Aid. Se eles são recrutadores, eles quase se sentem mal por terem que encontrar outro desenvolvedor Ruby on Rails 'primadona'. Então eles tiram algo semelhante a essa comparação incrivelmente ignorante entre Git e PHP para provar seu ponto. “Eles nem sabem o que estão pedindo”, dizem.

Para nós, programadores, às vezes parece que nossos clientes não têm a menor ideia. Adoramos exagerar casos como este. Quando você pensa um pouco sobre isso, não parece certo pensar que uma pessoa que está me dando dinheiro para construir coisas é de alguma forma limitada e 'simplesmente não entende'. Na verdade, eu acredito que a maioria dos clientes conhece bem suas opções e ainda assim eles decidem ir com Rails.

Vou tentar explicar o que, na minha opinião, torna o Rails benéfico o suficiente para ser considerado seriamente para uma infinidade de projetos e necessidades.

Benefícios do rubi

É possível que ninguém saiba dos benefícios do Ruby se não fosse pelo próprio Rails. Algumas pessoas gostam de menosprezar Ruby dizendo que é “tão fácil para Ruby” com seu “cavaleiro de armadura brilhante chamado Rails” e que sem Rails, “Ruby seria irrelevante”. Não posso dizer com certeza se isso é verdade ou não, mas sei que seria uma grande pena se o mundo perdesse uma linguagem tão soberba. O fato é: o autor de Rails escolheu Ruby deliberadamente, e sua aposta 'selvagem' valeu a pena com enorme interesse. O que ele viu naquela época, muitos outros podem ver hoje. Ruby de alguma forma habilita os programadores de uma forma especial que é tão difícil de explicar para as 'massas não lavadas'. Então, por que usar Ruby on Rails? Ruby deixa os programadores felizes, como anunciado.

Enquanto a maioria dos desenvolvedores concorda que Ruby é útil, alguns o consideram muito . Eles se preocupam com o que pode acontecer com todas as liberdades que Ruby permite, todo o potencial de uso indevido. Deixe-me ilustrar com alguns patches de macaco:

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

É muito fácil: com apenas cinco linhas de código, pegamos uma classe existente e substituímos seu comportamento. Nada é sagrado – nem mesmo um String. Esse erro específico seria fácil de detectar, mas as coisas podem ficar muito mais sinistras:

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

Assim, introduzimos um erro na classe String que pode ser encapsulado e obscurecido por camada após camada de complexidade.

Então, você pode estar pensando: todo mundo e sua mãe podem estragar meu precioso aplicativo? Embora esse comportamento realmente pareça assustador, na verdade não é. Em cinco anos usando Ruby, tive exatamente zero problemas com esse comportamento. Pode parecer contra-intuitivo, mas, novamente, dirigir carros a 60 MPH em direções opostas, separados apenas por uma fina linha branca no meio da estrada. Na prática, ambos funcionam notavelmente bem.

Outro benefício é que Ruby é uma ferramenta versátil. Como tal, tem bordas afiadas e semelhantes a facas. Eu gosto de pensar que os adultos podem lidar com facas muito bem – à prova de crianças é para, bem, crianças (Tweet). E ser tratado como uma criança em TI deixa você vítima do paradoxo Blub de Paul Graham: você acha que está melhor sem certas características que você não entende ou que alguém disse que você é muito perigoso. Claro, hoje estamos perguntando “por que usar Ruby on Rails”; assim, este é um debate para outro momento. Reconhecidamente, Ruby perde alguns recursos que outras linguagens possuem (Lisp hmm, hmm). Em suma, Ruby está perto do topo do 'continuum de poder da linguagem'.

Meus primeiros anos com Ruby foram humilhantes. Eu aprendi muito apenas lendo o código dos outros. Às vezes, eu ficava maravilhado; às vezes, eu ficava louco; mas, eventualmente, esse conhecimento permitiu que eu me comunicasse com meu computador de forma muito mais eficaz do que antes. Eu quase sinto pena de algumas outras linguagens de 'burocracia' que fazem você pular por obstáculos apenas por pular por eles, ao mesmo tempo em que lhe digo: "Estou apenas fazendo o que é melhor para você, é para o seu próprio bem!"

Pragmatismo

Há um profundo respeito pelo pragmatismo no DNA de Rails no 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. Pragmatismo é frequentemente anunciado como uma tenda de Rails, então essa afirmação não é nova, mas eu fui lembrado de sua veracidade recentemente quando um amigo meu tentou me mostrar o quão “legal” o Hibernate realmente é. Ele estava lutando. Eu podia sentir sua dor, pois ele não conseguia definir uma infinidade de opções e parâmetros de configuração que deveriam ter sido os padrões da estrutura em primeiro lugar.

Com a idade, meus padrões de complexidade artificial aumentaram cada vez mais. Considerando que comecei a escrever código de produção em 1989 aos 11 anos (começando com um projeto para meu vizinho no Clipper Summer '87), tenho tolerância quase zero para complicações desnecessárias. E Rails pontua muito alto nesse departamento. É mais do que apenas 'convenção sobre configuração'; Estou falando de toda a mentalidade pragmática que é altamente valorizada e permeia a comunidade Rails.

Expressividade

Rails é o mais próximo possível do inglês (a menos que você esteja usando COBOL). Ele usa o que é conhecido como DSL interno, estendendo Ruby com sua própria semântica. Construir uma DSL é sempre perigoso, pois você está efetivamente desenvolvendo uma nova linguagem. Por ser interno, você não precisa usar um analisador externo, mas, de certa forma, parece uma nova linguagem. A equipe Rails conseguiu um bom equilíbrio com seu DSL, usando-o onde faz sentido e raramente exagerando, demonstrando excelente autocontrole. Acho que qualquer programador, independente da experiência em Rails, (e até mesmo alguns não programadores) poderia entender isso:

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

Na verdade, se você não estiver familiarizado com Ruby, isso pode parecer estranho – é quase como se não fosse uma linguagem de programação. Uma vez que você perceba que são apenas chamadas de método sem parênteses, você está pronto para ir. Ainda assim, o Rails DSL parece ser essa linguagem especial para descrever requisitos quando na verdade é apenas uma nomenclatura inteligente e uso inerente da excelente sintaxe do Ruby.

Comunidade

Rails tem um exército de committers que garantem que ele permaneça em ótimas condições. Muitos projetos esmorecem com a idade, mas com Rails, faíscas ainda voam quando as decisões precisam ser tomadas. Parece que os mantenedores (ainda) realmente se importam e querem que as pessoas usem Ruby on Rails e entendam seus benefícios.

Debaixo do próprio Rails, como cereja no topo, está o Ruby com seu formidável gerenciador de pacotes, RubyGems, comparável ao CPAN em termos de número de pacotes – e considerando a idade do CPAN, essa afirmação é (para dizer o mínimo) muito impressionante. Rails teve um breve descarrilamento quando tentou fazer seus próprios “plugins Rails”. Felizmente, isso não pegou, então RubyGems continua sendo a fonte unificada e excelente para código programado por indivíduos muito brilhantes.

A sinergia entre uma linguagem legal, um framework pragmático da web e uma comunidade soberba dão ao Rails um resultado muito melhor do que a soma de suas partes.

Maturidade

Rails tem dado a volta ao quarteirão. De um jeito meio hipster, não é mais tão legal assim. Isso é bom quando se trata de escolher uma pilha de tecnologia: você quer algo comprovado. E Rails é exatamente isso. Recentemente escrevemos um artigo falando sobre a grande variedade de interpretadores e runtimes Ruby 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 encarar:

1. Comparado com a concorrência, o site Rails parece bom .
2. O primeiro elenco de Rails, naquela época, foi simplesmente de tirar o fôlego. Pode não parecer tão impressionante hoje, mas lembre-se de que a única razão pela qual todos sabemos sobre Java é que todo mundo estava tão entusiasmado com a possibilidade de executar um Java Applet no navegador. Isso acabou não sendo tão importante, mas ainda assim, isso colocou o Java no radar. Da mesma forma, este screencast do mecanismo de blog de 15 minutos foi um grande sucesso que empolgou muitas pessoas.

Não se trata nem de vaidade; trata-se de envolver o maior número possível de pessoas inteligentes para colocar água no moinho. Quando os frameworks são considerados, o melhor lugar para estar é no meio da multidão. Escolher uma estrutura na qual essas pessoas inteligentes estão se concentrando simplesmente significa que muito mais terreno já está coberto para você. E isso me leva ao meu próximo ponto.

(Não) Reinventando a Roda

Eu tenho um fraquinho por estruturas minúsculas. Gosto quando consigo entender o que uma estrutura específica está fazendo e por quê. Nesse sentido, Rails é um pouco inchado, e até mesmo esmagador às vezes.

O dilema aqui: quantas vezes você quer escrever as mesmas coisas repetidamente? Algumas coisas podem ser reescritas melhor, tenho certeza, mas leva tempo – muito tempo. Quanto mais você permitir que o Rails faça por você, menos você terá que se preocupar em reescrever ou reimplementar sua funcionalidade.

Rails é (como dizem) 'baterias incluídas'. Isso não é bom se você gosta de esparsidade ou se sente a necessidade de ter amplo conhecimento de como tudo funciona. Na prática, se você deixar de lado seus medos, parece funcionar. Rails tem padrões razoáveis ​​para quase tudo que você precisa e é modular o suficiente para evitar encurralá-lo em um local apertado.

Conclusão

Pergunte a si mesmo novamente, por que usar Ruby on Rails? O Rails é adequado tanto para sites públicos de última geração que competem com aplicativos JavaScript de página única quanto para aplicativos complexos de sistema central corporativo que geralmente parecem um pouco mais "feios" (com uma interface de usuário mais genérica e de baixa fidelidade), mas compensam isso mancha com uma tonelada de regras e lógica de negócios complicadas. Seu benefício é que ele é versátil e capaz de competir com o elegante e o poderoso.

Para a maioria dos problemas comuns, o Rails tem um componente à sua disposição quase pronto para uso com documentação consistentemente acima da média (de alguma forma, a equipe principal do Rails convenceu os contribuidores que escrever documentação é legal (mesmo que todos nós saibamos que é não), levando a documentos bem escritos, concisos e que economizam tempo).

Quando você deixa de lado os unicórnios e os abraços de sexta-feira, você acaba com uma estrutura poderosa que pode ser usada tanto para o seu futuro divisor de águas quanto para o seu próximo site de negócios no meio do caminho. E com seu conjunto de joias de primeira linha, você tem na ponta dos dedos um arsenal que implementa algumas das ideias mais brilhantes da programação de computadores. Sem alarido.