Documentário sobre Ruby on Rails [Vídeo]
(youtube.com)- Durante o desenvolvimento do Basecamp na 37signals, David Heinemeier Hansson criou em Ruby as ferramentas de que precisava, dando origem ao ponto de partida do Rails
- A colaboração entre Jason Fried e David começou em 2001 com uma pergunta sobre PHP no blog da 37signals, e levou ao desenvolvimento do backend do Basecamp e à extração do Rails
- O Rails tentou combinar, dentro do Ruby, a rapidez do desenvolvimento web do PHP com o rigor do design orientado a objetos ao estilo Java, e sua forma central foi construída do verão de 2003 até o lançamento do Basecamp em fevereiro de 2004
- A difusão inicial foi impulsionada por um produto real chamado Basecamp, pela demo de 15 minutos, pelas comparações com Java e pela reputação da 37signals, formando também os primeiros contribuidores como Jamis Buck, Jeremy Kemper e Tobias Lütke, além do Rails core team
- Depois de ser lançado como open source sob licença MIT, o Rails manteve ao longo de 20 anos, com casos de grande escala como Shopify e GitHub e com sua comunidade, a direção de permitir que equipes pequenas construam grandes aplicações web
O encontro entre 37signals e David Heinemeier Hansson
- Em 1999 ou 2000, Jason Fried administrava uma empresa de web design chamada 37signals e estava criando em PHP um projeto paralelo de banco de dados online de livros chamado Single File
- Ele aprendeu PHP por um livro e avançou bastante, mas encontrou limitações; como ainda não existiam espaços de respostas como o StackOverflow, pediu ajuda online
- Em Copenhague, na Dinamarca, David Heinemeier Hansson, que trabalhava no setor web, lia regularmente o blog Signal vs. Noise da 37signals e respondeu, em 2001, à pergunta de programação feita por Jason
- A resposta de David foi muito detalhada, e Jason sentiu que não era apenas um comentário, mas uma atitude de quem realmente queria ajudar
- Depois disso, David olhou o código inteiro de Jason e disse algo como “isso não está bom, vamos recomeçar”, e a colaboração entre os dois começou nesse ponto
- Os dois trabalharam remotamente por um tempo e depois se encontraram pela primeira vez pessoalmente perto do Hancock Building, em Chicago; Jason relembra que a roupa toda branca de David chamava muita atenção
O Rails nasce durante a criação do Basecamp
- A 37signals sentia que, ao gerenciar projetos de clientes por e-mail, era difícil acompanhar versões de arquivos, tarefas pendentes e o estado de preparação para lançamento, então em 2003 decidiu criar uma ferramenta de gestão de projetos para uso interno
- Na época, David era estudante de administração em Copenhague e só podia trabalhar cerca de 10 horas por semana; como compensação pelo desenvolvimento do backend do Basecamp, queria mais um notebook da Apple e equipamentos do que dinheiro
- David conheceu Ruby por textos de Martin Fowler e Dave Thomas e se sentiu atraído pelo fato de que o código dessa linguagem vinda do Japão parecia pseudocódigo ao ser lido
- Antes do Basecamp, a 37signals usava PHP em seus trabalhos, mas David decidiu construir o backend do Basecamp em Ruby, e Jason confiou nessa escolha
- A combinação que David encontrou no Rails tinha dois elementos
- A imediatidade de colocar algo na web rapidamente, como no PHP
- O rigor intelectual do design orientado a objetos e dos padrões vistos em Java
- Na época, Ruby ainda não tinha muitas bibliotecas ou frameworks para desenvolvimento web e acesso a banco de dados, então David criou ele mesmo as ferramentas necessárias para construir o Basecamp
- Do verão de 2003 até o lançamento do Basecamp em fevereiro de 2004, o núcleo do Rails foi tomando forma; depois do lançamento do Basecamp, ele passou cerca de 6 meses refinando o código e a documentação, e então lançou o Rails em 2004
Lançamento inicial, marketing controverso e formação do core team
- Ao preparar o lançamento do Rails, David considerava importante não só o código, mas também a qualidade da documentação, e julgava que a primeira versão precisava estar boa o suficiente
- Quando o Rails começou a chamar atenção, David tentou preservar com firmeza a direção do framework e dizia “não” a demandas que não queria atender
- Em uma conferência inicial sobre Rails, David usou um slide com “F()c% You” como reação a exigências injustas e ameaças de fracasso, deixando clara a posição de que open source não é uma relação comercial e de que usuários não podem ditar a direção
- Ao mesmo tempo, o Rails cresceu aceitando o bom trabalho enviado por milhares de contribuidores; David não rejeitava feedback nem contribuições em si
- Na International Ruby Conference de 2004, David apresentou o Rails e focou menos em demos de código do que em explicar por que o Rails foi criado e no objetivo de oferecer uma experiência melhor aos programadores
- Durante aproximadamente o primeiro ano, só David fazia commits diretamente no código, enquanto os patches eram recebidos por e-mail e Wiki
- Depois, pessoas que haviam contribuído bastante receberam acesso ao codebase, formando o Rails core team, com nomes como Jamis Buck, Jeremy Kemper, Marcel Molina, Scott Barron, Sam Stephenson e Michael Koziarski entre os primeiros committers
- A 37signals contratou parte do Rails core team e de outros contribuidores do Rails, e Jamis Buck se tornou o primeiro programador contratado pela 37signals no período em que o Basecamp estava crescendo
A expansão impulsionada por produto real e ecossistema
- A atenção inicial ao Rails foi fortemente influenciada pela reputação da 37signals e pelo fato de o Basecamp ser um produto real e bem-sucedido
- David acreditava que, para divulgar uma ferramenta baseada em uma linguagem menos conhecida como Ruby, era preciso um grito forte em vez de uma apresentação discreta, e por isso produziu materiais controversos comparando implementações em Java e em Rails
- A expansão do Rails contou com a demo de 15 minutos, com os clientes pagantes e o crescimento do Basecamp, além de código real em produção
- Tobias Lütke, quando estava começando uma empresa no Canadá, usou Rails muito cedo ao criar uma loja online de snowboard, e esse projeto, Snowdevil, mais tarde levaria ao Shopify
- Tobias relembra que, graças ao Rails, conseguiu construir o sistema sozinho e era mais produtivo do que outras equipes que montavam lojas online na época
- O Shopify é uma empresa influenciada pelo Rails; até hoje usa a versão mais recente do Rails, mantém a maior parte de seu codebase em Ruby e sua estrutura básica de pastas continua igual à de um app Rails comum
- As críticas de que o Rails “não escala” existem desde o começo, mas o Basecamp já atendia usuários reais, e mesmo antes de surgirem casos como Shopify e GitHub, houve respostas dizendo que o Rails era escalável desde o início
- O Shopify é tratado como um serviço de grande escala que responde por cerca de 10% do comércio eletrônico mundial, e há relatos de que nem se sabe qual seria um tamanho grande demais para o Rails suportar
Releases, fusão com Merb e uma direção mantida por 20 anos
- Desde o início, lançar o Rails como open source era uma escolha natural; David via que a base que tornava possível o trabalho na web era feita de ferramentas open source, então também deveria compartilhar sua própria caixa de ferramentas
- Houve discussões sobre cobrar pelo Rails ou mantê-lo como vantagem competitiva exclusiva, mas David decidiu que o open source sob licença MIT era importante e que faria do Rails um grande sucesso
- A ferramenta criada por Jamis Buck para implantar o Basecamp mais tarde se consolidou com o nome Capistrano
- O fluxo principal de releases do Rails foi o seguinte
- O Rails 1.0 foi um ponto de partida importante
- O Rails 1.2 é avaliado como um release inicial estável e como o momento em que passou a mostrar a forma de um framework web maduro
- Em dezembro de 2007, o Rails 2.0 trouxe sessões baseadas em cookies e named scopes
- Em março de 2009, o Rails 2.3 foi tratado como um release com as ferramentas de que um desenvolvedor web moderno precisava, de apps pequenos a grandes
- Na época do Rails 2.3, o jQuery estava surgindo, e o Rails tentou criar espaço para absorver a energia do mundo JavaScript
- Depois, o framework web em Ruby Merb surgiu como um concorrente mais rápido, mais leve e que fazia menos coisas, e os desenvolvedores do Rails viram valor em aprender com essa direção
- O Rails 3.0 levou à fusão com o Merb, o que exigiu um grande trabalho de redesenho interno para tornar o Rails configurável, recombinável e modular
- A comunidade Rails se concentrou em permitir que pessoas sem formação formal em ciência da computação ou programação também pudessem criar aplicações web e construir carreira
- O Rails buscou reduzir a barreira de entrada e depois oferecer um caminho para que essas pessoas se tornassem programadores de alto nível em empresas ou na indústria
- Como diz o texto atual do site do Rails, o Rails é um framework que permite ir “de Hello World ao IPO” com uma equipe pequena, e a avaliação é que a qualidade da comunidade e do codebase está melhor do que nunca
1 comentários
Comentários do Hacker News
Gostei muito deste documentário, e a perspectiva de framework de uma pessoa só apareceu bem por meio da história pessoal de Toby, da Shopify
“From Hello World to IPO” também foi bom, e achei especialmente marcante a menção de que, ao abrir qualquer app Rails, seja o maior app Rails ou um app novo, a estrutura é praticamente a mesma
No ambiente atual, em que APIs e stacks de front-end ficam entrelaçados, essa consistência nem sempre é garantida
As mudanças recentes do Rails estão tornando uma base sólida ainda mais forte, e há trabalhos em andamento não só com o Kamal, mas também com Solid Cache e Solid Queue, para facilitar a infraestrutura
No front-end, Turbo Morphing também está ativo; em apps móveis, Turbo Native e Strada também
Já fiz upgrade para a 7.1 e estou operando um app móvel feito com Turbo Native; também estou animado para trocar o cache Redis por Solid Cache, simplificar mais as coisas e manter o cache por mais tempo
É bom ver que a comunidade Rails continua ativa e que ex e atuais membros do core team seguem profundamente ligados ao framework
Nunca usei Rails, mas uma coisa que eu realmente detesto no ecossistema Node.js é a falta de convenções claras
Mesmo usando o mesmo framework, a estrutura sempre muda e vira uma bagunça; a exceção talvez seja o Next.js, mas ele também fica mais próximo do lado de front-end
Muitas ferramentas de desenvolvimento ao redor de Ruby e Rails também estão surgindo, então espero que Rails 8.0 e Ruby 3.4 tragam ainda mais boas mudanças
Foi engraçado descobrir que ele é o fundador da Shopify e tem patrimônio de US$ 5,5 bilhões
Desenvolvedores tendem a subestimar muito esse aspecto do RoR
Além de facilitar o onboarding, isso também reduz bastante o bikeshedding
MVC talvez não seja o melhor para tudo, mas na maioria dos casos é bom o suficiente
Vou assistir a isso mais tarde hoje
Já mexi em vários frameworks, como Laravel, ExpressJS, MeteorJS, Django e Flask, e cada um tinha seus prós e contras, mas eu sempre acabava desistindo ao seguir tutoriais ou tentar fazer do meu jeito
Comecei com Rails três dias atrás e, no fim de semana, consegui criar rapidamente um MVP para mostrar a um colega
Rails me fez focar no que o app deveria fazer, não em como implementar o app, e só agora entendo por que as pessoas gostam tanto dele
No Rails, a produtividade é realmente alta
Há muito tempo, minha maior reclamação era que, quando você saía das convenções, a documentação era insuficiente ou havia muitas informações conflitantes
Encontrar e entender o “jeito abençoado” pode ser muito difícil; felizmente, o ChatGPT é razoavelmente bom para ajudar a encontrar um ponto de partida nesses casos
Foi um documentário realmente excelente
Usei Rails nos últimos anos, e ele é muito produtivo para equipes pequenas criarem produtos e implementarem lógica de negócio seguindo padrões bem estabelecidos
Se você tem curiosidade sobre a estrutura de um app Rails real, recomendo olhar a base de código do Jumpstart. É um bom material para aprender como estruturar as coisas
https://jumpstartrails.com/
Como alternativa, o Bullet Train também é bem bom, mas adiciona muitas bibliotecas customizadas que são difíceis de ver como o “jeito Rails”
https://bullettrain.co/
Acho que este documentário sobre Rails e o documentário sobre Elixir deixaram muita coisa de fora
Por serem curtos, mal começam a contar a história de origem e já acabam, encerrando antes de chegar aos pontos que empolgariam
Em vez de mostrar à comunidade e a pessoas de fora dela o quanto essas tecnologias são incríveis, pareceu mais algo voltado a massagear o ego dos participantes
Eu gostaria que fizessem documentários de 1 hora e 30 minutos para Elixir e Rails, indo além das partes em que todos se elogiam e mostrando anos de dificuldades, as diferentes formas de uso em várias empresas etc.
Por assim dizer, se adotassem o formato de Indie Game: The Movie, acho que seria muito mais envolvente; espero ver mais bons documentários sobre software
Houve muitos pequenos fragmentos de história difíceis de encontrar em outro lugar, como o quanto a abordagem de David era incomum, como o time do Rails se formou por meio de Toby e outras pessoas, e como ele se fundiu com outros frameworks
Poderia ter sido mais longo, mas é excelente que tenham conseguido produzir isso mesmo assim
Assisti, mas acho que não mostrou o suficiente do que o Rails realizou
Ruby on Rails mudou o paradigma de criação de aplicações web, saindo de abordagens centradas em arquivos, como PHP, JSP e WebForms, para rotas e o padrão MVC; hoje, praticamente todo framework web decente tem esse modelo
O documentário não falou dessa parte, mas ainda assim foi agradável de assistir
Dito isso, chega a dar um pouco de pena colocar Struts e Rails na mesma frase, porque Rails realizou muito mais
As figuras lendárias dos primeiros dias do Rails abriram caminho para a forma moderna de desenvolver apps web
Dá até para dizer que existe um antes e depois do Rails no desenvolvimento web
Pelos comentários, parece que Rails está voltando a ganhar um pouco mais de popularidade, deixando de ser visto apenas como um framework entediante, porém sólido
Rails é uma lembrança de outra época: de quando eu criava coisas de um jeito mais divertido e bruto, e que fazia sentido para meu caminho naquele momento
O que eu realmente valorizo no Rails é a visão forte, e o fato de ele não ter se tornado apenas mais um framework inchado para criar aplicações “enterprise”
Mesmo sendo um framework de 20 anos, ele não tem medo de mudar de forma ousada para acompanhar os tempos e ainda parece punk em comparação com outras coisas
Fiquei com o coração aquecido ao lembrar da minha própria história, de quando comecei a usar Rails há 20 anos
https://twitter.com/buger/status/1723040883325460818
Trabalhei de 2015 a 2019 em um app Rails em produção muito grande e, como resultado, passei a amar Rails, mas a odiar Ruby
Se existisse um Rails em TypeScript ou Go, não consigo pensar em motivo para usar outra coisa no backend de apps web
O Rails Console é uma das melhores ferramentas de aumento de produtividade que já encontrei
Com TypeScript talvez seja possível usando o REPL existente do Node, mas o grande motivo pelo qual o console do Rails é tão útil está, no fim das contas, no próprio Ruby
Os documentários da Honeypot são realmente bons; recomendo muito