Este ano a itexto decidiu investir em Ruby on Rails, o que me fez iniciar uma imersão pessoal de aprendizado na tecnologia e cujas primeiras (segundas?) impressões conto para vocês neste post.
Aviso: esta é a visão de alguém que trabalha com Java há muito tempo e que é iniciante em Ruby on Rails. Por favor entendam e me corrijam caso diga bobagens aqui, ok? Você estará ajudando no meu aprendizado.
Minha história pessoal com Ruby on Rails e Grails (o antigo Groovy on Rails)
Minha história com Ruby on Rails (RoR) completa em 2020 15 anos. Começou quando vi o vídeo abaixo em 2005, quando o David Heinemeier Hansson (DHH) nos mostrou como escrever um blog em 15 minutos com RoR. Se você leu meu livro sobre Grails deve ter visto minha menção ao framework e parte desta história no capítulo 4: "Precisamos falar sobre Grails".
https://www.youtube.com/watch?v=Gzj723LkRJY
Apesar de ter mudado radicalmente o modo como via o desenvolvimento web na época (não só a minha visão, mas a do mundo, dado que a esmagadora maioria dos frameworks que vieram depois são profundamente influenciados pelo RoR (Grails se chamava Groovy on Rails - cópia bruta - link para e-mail com ameaça de processinho vindo do DHH)), não embarquei neste trem naquela época pelas seguintes razões:
- Na empresa em que trabalhava já tinha sido um parto convencer o pessoal a usar Java (a linguagem adotada era VB6).
- Apesar de incrível o framework mostrava na época alguns limites no que dizia respeito ao desempenho e estabilidade (talvez por minha própria falta de experiência com ele na época).
Na mesma época surgia um framework chamado "Groovy on Rails" (Grails) que me oferecia a produtividade do RoR somado à possibilidade de poder aproveitar todo meu código legado Java e, ainda por cima, ser baseado em um stack que já havia sido fortemente testado pelo mercado (Spring e Hibernate essencialmente). Grails me ganhou ali e foi um dos maiores acertos da minha carreira sem dúvidas.
Mas Grails apesar da popularidade na época nunca se tornou um framework mainstream. E por todos estes anos observava a popularidade do Rails e me perguntava por que Grails também não havia obtido tanta popularidade.
Grails ainda é um dos meus frameworks favoritos (empata com Spring). Tenho diversos cases em que atuei e conheci nos quais pude ver quão bem escala, é fácil de manter a base de código ao longo dos anos (ANOS!) mantendo o framework atualizado e, ainda mais importante: é uma plataforma que continua muito viva e ativa, basta ver que sempre saem grandes releases do framework (como o 4.0, lançado no final do ano passado).
Por que Rails agora?
Então por que resolvemos investir também em Ruby on Rails agora?
- Rails passou pelo teste do tempo, tal como Grails.
- Rails tem a popularidade que falta ao Grails (há clientes que levam a popularidade do stack de desenvolvimento como um fator determinante (discordo da postura, mas entendo)).
- Usamos internamente muitas ferramentas feitas em Ruby on Rails que gostaríamos de entender a fundo e, quem sabe, até mesmo contribuir para seu desenvolvimento (Gitlab, Discourse, Redmine...).
- É importante do ponto de vista estratégico abraçar plataformas que vão além da JVM (e aqui entram sub-razões):
- Pra termos uma visão melhor a respeito do próprio Java.
- Aumentar nosso horizonte de atuação enquanto consultoria.
- Pra que possamos ter cada vez mais uma visão menos enviesada do que é desenvolver software.
E o mesmo tipo de projeto no qual atuamos com Grails, podemos atuar no Rails: aplicações web baseadas em um banco de dados relacional que podem ser tanto full stack (fornecendo a base para o desenvolvimento tanto da API quanto do front-end) quanto apenas a API, o que o torna compatível com os tempos atuais, nos quais o desenvolvimento do back-end desacoplado do front-end se tornou quase que a norma. Mas mais do que isto: projetos para os quais precisemos de altíssima produtividade: a mesma ou ao menos bem próxima daquela que temos com Grails.
Não estamos abandonando o Grails (muito pelo contrário!), mas é interessante podermos dar mais esta opção para nossos clientes e, de quebra, ainda ampliarmos enormemente nossos horizontes.
Meu processo de aprendizado (ou reaprendizado)
Para alguém que está a tanto tempo no Java (1996) e Groovy (2007/8) como eu pegar para aprender Ruby on Rails pode ser um processo bastante complicado. Sendo assim fiz o que recomendo a nossos alunos de Grails. Começar pela linguagem.
Comecei pelo aprendizado do Ruby: do mais básico ao mais avançado, o que se mostrou um desafio e tanto. Apesar da comunidade Ruby on Rails ser extremamente ativa, o mesmo não posso dizer a respeito da disponibilidade de bom material sobre a linguagem Ruby. Foi bastante difícil selecionar este material.
Comecei por dois livros que li na época em que tive meu primeiro contato com Rails em 2005/2006. Os livros do Fábio Akita (Repensando a Web com Rails) e do Eustáquio Rangel (Ruby: conhecendo a linguagem). Não vou mentir, por serrem livros bem antigos apenas dei uma repassada rápida de olho neles. Mas os menciono aqui por que na época, apesar de não terem sido meu caminho, exerceram forte influência sobre mim: especialmente o primeiro, do Fábio Akita.
Encontrar material novo sobre Ruby se mostrou uma tarefa muito árdua. Isto por que no site oficial os links que existem apontam muitas vezes para versões muito antigas ou material muito raso como, por exemplo, o site "Try Ruby", que promete em 15 minutos te dar uma visão geral da linguagem. Ele até consegue, mas não era o que buscava.
Na prática acabei ficando com uma dobradinha entre três sites:
- Ruby Learning - que são essencialmente notas sobre a linguagem, mas que me ajudaram bastante a pegar o vocabulário a respeito da linguagem.
- Ruby Essentials - vai um pouco além das notas do Ruby Learning: essencialmente o mesmo conteúdo.
- Programming Ruby - do mesmo pessoald o Pragmatic Programmer. Infelizmente trata da versão 1.6 da linguagem ainda.
Segui o estilo de leitura mais chato que vocês podem imaginar: linear, do início ao fim, experimentando todos os exemplos que podia no meu computador e fazendo meus próprios experimentos. Saber Groovy (que é inspirado também em Ruby) me ajudou bastante a entender a linguagem.
Se com Ruby tive dificuldade em encontrar material, o mesmo não posso falar sobre Ruby on Rails, que peguei logo na sequência. E me sinto muito aliviado por ter começado pela linguagem, por que foi graças a este esforço que consegui ficar minimamente produtivo com o framework.
(Volto à ênfase na linguagem. Se você não entender a sintaxe do Ruby, Rails vai parecer mágica e isto além de perigoso é péssimo pra sua compreensão)
O site oficial do framework contém os guias essenciais que são o material que tenho seguido em meus estudos. São guias muito bons! Até bem pouco tempo atrás achava a documentação do Grails a melhor que conhecia: agora prefiro a do Ruby on Rails.
Comecei pelo guia introdutório no qual criamos um motor de blogs. Foi uma boa escolha por que você consegue pegar o início sobre como é o fluxo de trabalho do framework.
Feito isto fui seguindo os guias um a um. Estou usando a última versão do Rails (6.0.2.1), e alguns dos guias ainda não estão 100% completos. Tenho conseguido me virar bem, mas meu foco não está sendo a construção full stack do framework, mas sim a implementação de APIs.
Minhas segundas impressões
É muito difícil pra mim ver as tecnologias relacionadas ao Rails e não fazer comparações com o que temos no mundo Java (e agora .net). Sendo assim tenha em mente que minhas opiniões ainda são bastante enviesadas (e limitadas pela minha pouca experiência).
Active Record
É o framework de persistência objeto-relacional do Rails. A primeira vez que vi em 2005/6 (especialmente os finders dinâmicos) achei que era mágica. Hoje, tantos anos depois, não me impressiona tanto. Na realidade, comparado ao GORM do Grails, acho que fica pra trás, especialmente quando penso na busca por criterias e no próprio HQL/JPQL.
Apesar de ainda o ver um pouco atrás (talvez por minha pouca experiência com ele), há aspectos que me agradam. Percebi que a busca por SQL é quase uma necessidade com ele. Eu tenho algo interessante que é o fato de ter uma solução de ORM mas, ao mesmo tempo, tenho acesso ao SQL.
Não é tão completo quanto o Hibernate. Ao lidar com MySQL, por exemplo, tive alguma dificuldade ao tratar campos do tipo bit na base legada que usei para testes (a do /dev/All - mais sobre isto a frente). Também tive dificuldade em fazer algo simples como a busca com operador like usando apenas o Active Record e sem precisar escrever SQL.
É muito interessante a abordagem do framework com o banco de dados, especialmente legado. Dado a natureza da linguagem Ruby, o mapeamento das nossas classes de modelo com o banco de dados nascem quase que por mágica. Cada campo presente nas tabelas vira imediatamente um atributo de instância de nossas classes, sem a necessidade de mapeamentos.
(É importante que você saiba que Active Record é o nome de um padrão de projeto, antes que o nome de um framework de persistência. Esta compreensão lhe ajudará DEMAIS a entender o framework.)
Mas note: são minhas segundas/primeiras impressões. Ainda não tenho muita experiência com o framework e tenho certeza de que estou comendo mosca neste ponto.
Action Controller
É como escrevemos nossos controladores com Rails. Não há como não comparar com o Grails. O que posso dizer a respeito... Grails é uma cópia XEROX do Rails aqui. É realmente MUITO parecido, talvez por isto eu tenha pego tão rápido o jeito da coisa.
Fiquei produtivo muito rápido com o Action Controller. Bastou ler o guia Action Controller Overview e, na sequência, o Rails Routing from Outside In, ambos presentes no site oficial do framework.
Interessante que o framework já nasce com tudo o que precisamos para poder aplicar o BDD/TDD de cara na escrita dos controladores. Isto me possibilitou fazer diversos experimentos e já começar a usar o framework com o pé direito, isto é, já tendo tudo baseado em testes.
Resumindo: se você sabe Grails, já sabe 80% do que precisa no Rails.
Dificuldades com o ambiente de desenvolvimento
Nem tudo são flores. Há pedras no caminho, especialmente se você está acostumado com Java. No mundo Java tudo é Java: é muito raro você precisar de código nativo pra fazer qualquer coisa. O mesmo não se dá com Ruby on Rails.
Pra ter acesso à base de dados MySQL, por exemplo, achei em um primeiro momento que bastava instalar a gem mysql2. Quebrei muito a cabeça até notar que faltavam algumas bibliotecas nativas pra que esta funcionasse (native client for MySQL). Este é um ponto interessante a ser levado em consideração.
Comecei a aprender Capistrano também, que no meu primeiro contato era uma ferramenta bastante popular para o deployment de aplicações Ruby on Rails. É muito interessante: mas estou vendo tantas alternativas de deployment que ainda me deixam um pouco confuso. Mas estou aprendendo!
Tal como no caso do Java que temos o SDKMan, no caso do Ruby temos o RVM. É interessante, mas não é tão fácil de usar quanto o SDKMan. Ainda apanho um pouco com ele.
Estas tem sido minhas dificuldades iniciais, mas pouco a pouco estou aprendendo com elas.
Surpresas com o desempenho - o uso oculto do /dev/All
O /dev/All tem uma função adicional na itexto. Além de ser um dos nossos projetos favoritos é também o sandbox que usamos para testar novas tecnologias. Pouca gente sabe (agora todo mundo sabe), mas a API do /dev/All é aberta.
Temos documentados no formato Swagger todos os comportamentos esperados por esta API. Isto nos possibilita testar as mais variadas tecnologias. Já houve implementações desta API em Grails, Spring (é a atual), Node.js, PHP, .net e, agora: Ruby on Rails.
Isto nos possibilita fazer comparações de desempenho, escalabilidade e estabilidade com um caso real, o que evita muita especulação. E o resultado que tivemos com Ruby on Rails no que diz respeito ao desempenho foi muito satisfatório.
Levando em consideração que a base usada hoje em produção, escrita em Spring tem pelo menos um ano de otimizações, e a que escrevi em Ruby on Rails, com pouquíssima experiência, consistiu em uma prova de conceito, eu diria que os resultados, apesar de inferiores, foram excelentes.
Para realizar nossos testes uso um programa chamado Siege, que me permite simular acesso concorrente a uma API. Meu código RoR não é tão ruim assim: ele já faz a busca por eager fetching, evitando consultas do tipo N+1, mas não é lá a coisa mais otimizada do mundo. Quer ver o resultado com 255 clientes concorrentes durante 10 segundos nos dois ambientes? Segue o print:
Ruby on Rails não ficou muito atrás (20% menos transações na média). Tudo bem que não é o melhor benchmark do mundo mas pelo menos é um caso real contra uma base de dados legada. Já dá uma ideia ou pelo menos um norte!
Por muito tempo algo que me fazia ficar alguns pés atrás com Rails era o mito de que se tratava de um framework lento. Bem: "myth busted". Não é o melhor desempenho do mundo (Node.js me causou uma primeira impressão bem melhor), mas também não é um problema.
Além disto, só se pode falar que algo é lento se tivermos um requisito de desempenho bem definido.
Resumindo
Tem sido meses de muito aprendizado. Faz tempo que não aprendo tantas coisas e sinto tanto prazer no processo. Aquele papo de que Ruby é uma linguagem focada na felicidade do programador é real, e como!
Gosto muito do lado pragmático do RoR (e do Grails). Você não fica preso a burocracias (tal como não raro ficamos no Java): é tudo muito direto, muito prático e ao mesmo tempo sem ser tosco. O aspecto lúdico da linguagem vaza pro framework.
E como é um framework baseado em convenções muito bem pensadas (como Grails), dar manutenção neste tipo de sistema fica muito mais barato. Ter comprovado também o fato de que não temos um problema real de desempenho com Rails me fez sentir muito mais seguro para adotá-lo em projetos futuros.
Já iniciamos um projeto interno em Ruby on Rails: sei que vamos aprender muito neste processo. Conforme vou aprendendo, conto pra vocês neste blog, ok? Até lá!
PS: se falei alguma bobagem aqui, por favor, leve em consideração minha pouca experiência e também me conte. Isto irá nos ajudar a, futuramente, dominarmos estas tecnologias. Valeu!
Top comments (0)