Published on

Ruby on Rails e o desenvolvimento web entre 2004 e 2011

Link curto:https://www.michelpf.dev/go/97547d7e
Authors
Ilustração de capa do post Ruby on Rails e o desenvolvimento web entre 2004 e 2011 Fabio Akita apresenta Ruby on Rails como um caso raro de tecnologia que mudou o fluxo de trabalho do desenvolvimento web, não apenas como framework. Ele contrapõe o ambiente de 2019 — GitHub ou GitLab, pull requests, testes automatizados, CI, staging no Heroku, monitoramento e análise de código — ao cenário de 2004, dominado por Java corporativo, SAP, UML, servidores pesados, Subversion difícil de operar, ClearCase e uma divisão rígida entre programadores, DBAs e infraestrutura. A tese é que boa parte desse padrão atual foi consolidada pela comunidade Rails.

O episódio explica por que Rails funcionou naquele momento. A escolha de Ruby, então uma linguagem quase inexistente fora do Japão, permitiu criar uma cultura nova sem carregar práticas antigas. DHH extraiu o framework do Basecamp, produto real da 37signals, e impôs uma visão forte: convention over configuration, DRY, estrutura previsível, pouco boilerplate, segurança ligada por padrão e testes presentes desde a criação do projeto. Akita ressalta que essa postura opinionated era controversa, mas produziu integridade conceitual e reduziu a fragmentação que ele via em Java, PHP e depois JavaScript.

A narrativa avança por uma cronologia de 2004 a 2011, conectando Rails à Web 2.0, Ajax, Git, GitHub, Heroku, AWS, jQuery, RSpec, Capistrano, Sinatra, Travis-CI e CodeClimate. O argumento não é que tudo nasceu em Rails, mas que a comunidade reuniu práticas ágeis, produto, open source, testes, deployment e serviços em um ecossistema coerente. Akita também revisita tensões internas: a acusação de que Rails não escalava no caso Twitter, que ele atribui mais à arquitetura de broadcast do que à linguagem, e o conflito com Merb, resolvido por pressão política e técnica no Rails 3.

A dimensão brasileira aparece como parte da história: mailing lists, blogs, livros, tutoriais, empresas, eventos e a Rubyconf Brasil ajudaram a criar um mercado local quando quase ninguém prestava atenção em Rails. Akita reconhece que Rails já não é obrigatório em 2019 e que problemas posteriores, como mensageria massiva, mobile moderno, Docker, Kubernetes e DevOps, abriram espaço para Elixir, Go, Swift, Kotlin e outras ferramentas. A pergunta prática que fica é quando vale escolher o pacote coerente e maduro de Rails e quando um componente especializado justifica sair desse caminho.

Assistir ao episódio original

Leia também: Aprender programação exige prática antes do curso ideal, Aprendizado exige ciclos curtos de erro e ajuste, Estrutura de dados define o custo do código.

Referências encontradas

Livros

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.