Ruby on Rails: Entrevista com David Heinemeier Hansson – Parte I

Estive lendo o blog do Akita, que é muito bom, e achei muito interessante a ideia de software de opinião (opinionated software), o Akita tem vários posts sobre o assunto, alguns que eu achei e que gostei muito são Rails Sucesso Pela Arrogancia e David Hansson e Opinionated Software. No segundo post foi que encontrei o link para a entrevista do David que eu traduzi abaixo.

Está é a tradução da entrevista que o David Heinemeier Hansson deu ao Edd Dumbill para a O’Reilly Network. Pra quem não sabe, David, é o criador do Rails.
A entrevista original pode ser encontrada neste link.

Parte II, Parte III, Parte IV.

---

Por Edd Dumbill
30/08/2005

Poucos devem ter perdido o aparecimento da mais recente estrela das plataformas de programação – Ruby on Rails. O criador do Rails, David Heinemeier Hansson, já deixou a multidão estasiada no OSCON deste ano e está escalado para uma palestra na European O’Reilly Open Source Convention, que acontecerá em agosto deste ano, em Amsterdam.

David mora em Copenhagen, Dinamarca, e é sócio da inovadora 37signals, criadora do sistema web para gestão de projetos conhecido como Basecamp. A O’Reilly Network conversou com ele sobre o sucesso e o futuro do Rails.

Sobre o Sucesso do Rails

Edd Dumbill: Rails está se tornando mundialmente popular. Quando o criou em 2004, você tinha ideia de que ele seria tão bem aceito como tem sido?

David Heinemeier Hansson: Sim e não. Não acho que se possa predizer, muito menos planejar o tipo de sucesso que Rails tem atualmente. Mas eu tinha um bom palpite sobre a possibilidade dele ser bem aceito, principalmente por eu me sentir tão bem trabalhando em Rails. E eu achei que se esta ferramenta podia melhorar tanto o meu prazer e a minha produtividade em comparação com a maneira convencional de trabalhar que eu tinha utilizado no passado, porque ele não seria capaz de proporcionar o mesmo para outras pessoas?

Eu acho que consegui representar dois contextos que são pouco comuns na programação. Eu estive trabalhando com PHP por um longo tempo, então eu tinha aquela ânsia por fazer as coisas de maneira rápida, me preocupando em ver o resultado antes de todo o resto. Ao mesmo tempo, eu tive uma educação universitaria e trabalhei com Java em uma loja desenvolvida em J2EE por um tempo. Isso me fez dar valor a pureza e a facilidade de manutenção que bons padrões e práticas podem te dar.

Então eu estava no cruzamento entre duas filosofias muito populares em desenvolvimento de software. Aquela representada pelo PHP era rápida-e-suja, já a do Java era lenta-e-limpa. Combinar essas influências para chegar a última meta – rápido-e-limpo, me deu motivos para andar pelos dois lados.

ED: Qual você acha que é o ponto chave para a popularidade do Rails?

DHH: Não existe uma chave. Isto é, não existe apenas uma grande inovação no Rails para que se possa apontar e dizer: este é o motivo. De alguma forma, isso faz com que Rails seja mais difícil de se explicar pois a ideia não pode ser concreta e ao mesmo tempo seguir apenas uma linha de pensamento.

Mas vamos focar em apenas uma das chaves: Rails é software “de opinião” (opinionated software). Ele se diferencia por ignorar os antigos ideais de desenvolvimento de software. Um destes ideais é a flexibilidade – a noção de que nós devemos tentar integrar o maior número possível de opções, que não devemos julgar formas de desenvolvimento, ignorando uma em favor de outra. Bem, Rails faz isso e é por isso que eu acho que funciona.

Com Rails você troca flexibilidade no nível da infraestrutura para ganhar flexibilidade no nível da aplicação. Se você tem a felicidade de trabalhar no caminho de ouro que eu defini para o Rails, você tem uma recompensa imensa em termos de produtividade que te permite fazer mais, mais rápido e melhor em nível de aplicação.

Ainda assim, não é uma venda fácil. Vejá só as guerras travadas de tempos em tempos sobre padronização de código. Se as pessoas simplesmente pudessem concordar com uma forma de posicionar suas chaves ({ }), eles provavelmente poderiam códigos mais legíveis e uniformes. Para muitas pessoas isso não funciona, pois a troca não lhes parece boa o suficiente. Obter uma base uniforme de codigicação é frequentemente tratada como não mais importante do que “liberdade” individual por muitos programadores.

Em essencia, Rails tenta fazer o mesmo que os padrões de código fizeram, mas a razão para a qual ele está se saindo melhor é que a troca é muito mais doce. Conseguir uma base de codificação uniforme é uma meta abstrata e alguns grupos de programadores. Ver a sua aplicação funcionando em uma fração do tempo que você levaria antes é uma meta muito concreta e individialmente recompensadora.

Uma característica dos softwares de opinião é a noção de “convenção sobre configuração”. Se você seguir convenções básicas, como classes são singulares e tabelas são plural (a classe pessoa se refere a tabela pessoas), você é recompensado por não ter que configurar esta ligação. A classe automaticamente sabe que tabela usar para persistência. Nós temos uma tonelada de exemplos como este, onde a utilização todos acaba por fazer uma enorme diferença no uso diário.

---

Parte II, Parte III, Parte IV.