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.

What The Fuck Is MVC?

Essa é uma pergunta que eu me fiz pelo menos umas 300x durante o ano de 2006. MVC é a sigla para Model-View-Controller, uma metodologia de design que divide o software em 3 partes.

• Model: parte responsável por manter o estado e a lógica da aplicação.
• View: parte responsável pela formatação das telas que são apresentadas as usuários.
• Controller: parte responsável pela controle do fluxo da aplicação.

Lindo, eu li isso em milhares de lugares diferentes, mas a pergunta persiste, What The Fuck Is That? Que negocio é esse de estado da aplicação? Ok, a parte das telas eu entendi, mas poxa, que raios é a lógica de negócio de uma aplicação? E como eu junto isso tudo?

Ontem todas estas minhas perguntas foram respondidas :)

• Model é a parte responsável pelos dados de uma aplicação. O model, como o nome já diz, é onde vou definir o modelo dos meus dados. Agora que eu sou uma pessoa chique, estou na moda e programo orientado a objeto (ok, entrei na moda atrasado, a moda agora é programação orientada a aspectos, mas logo logo eu chego lá) , então meus modelos são objetos. Cada modelo é uma classe, contendo seus atributos e métodos. Toda a parte que trata do dado é feita aqui. Tanto no que diz respeito a manutenção do estado da aplicação, quanto ao que diz respeito a lógica da aplicação, que são tratadas pelos meus métodos. Deve-se ficar claro que o modelo deve ser capaz de tratar de toda a lógica que o envolve e não apenas ser um guardador de valores. Se ele for capaz de tratar toda a lógica que o envolve, então depois poderá ser reutilizado em outro aplicativo.
• Sobre a view, creio que não preciso falar muito né? É a formatação da tela que será apresentada ao cliente. Aqui entra HTML, Flex, OpenLaszlo, etc. Já ia me esquecendo, tem mais coisa pra falar de view sim. Para gerar a interface que será apresentada para o usuário da aplicação, a view faz acesso direto às classes que foram definidas no model. Agora fica até obvio, se o view tem que apresentar meus dados aos usuários ele tem que ter acesso a estes dados.
• Controller é a parte da aplicação que vai receber as requisições do usuário. É ele quem vai determinar o fluxo da aplicação, ou seja, é ele quem vai dizer que métodos devem ser invocados para tratar determinada requisição. São os organizadores da aplicação, eles recebem uma requisição do usuário, interagem com o modelo adequado para o tratamento desta requisição e retornam, ao usuário, a view correspondente.

Estou aprendendo ainda, então se você já tem experiência com isso e estiver lendo alguma besteira, por favor me avise, assim como fez o Danilo Magrini e eu já corrigi os erros que ele apontou. Valeu Danilo.

A figura abaixo foi retirada do livro Agile Web Development With Rails e ilustra bem o modelo MVC.

Facil não? Só não entendo por que demorei tanto para aprender isso. Enfim, acho que o único texto que encontrei que explica isso direitinho foi o Agile.

O mais curioso de tudo é que eu sempre achei que MVC era uma ideia nova. Nova nada, MVC foi idealizado em 1979!!! E eu achando que MVC era pra web apenas. Trygve Reenskaug foi o cara que pensou no MVC, engraçado que o pessoal do desenvolvimento web só se voltou pro MVC muito tempo depois de quebrar a cabeça e fazer o sistema todo num bolo só (monolítico). O site oficial dele pode ser acessador por aqui.

Tópicos Aprendidos

Alguns pontos do dia de hoje.

1. A uns três dias quando decidi estudar Ruby, Rails e desenvolvimento web, eu montei um combo de livros sobre estes assuntos. O combo é formado por Programming Ruby – The Pragmatic Programmers Guide, Agile Web Development With Ruby on Rails, Rails Recipes e Getting Real. No início esta era a ordem que eu pretendia lê-los, mas as coisas tem mudado e tenho visto que o ideal é ler o Agile Web Devel. e o Getting Real.
   Falando em Getting Real, acredito que seja um desconhecido da maioria das pessoas. É um livro escrito pelos caras da 37signals, empresa que criou o Rails e que possui alguns sistemas muito interessantes rodando em RoR. Esse Getting Real fala da metodologia de desenvolvimento dos caras da 37signals, e por tabela fala da metodologia aplicada para criação do Rails. Sinceramente? Fiquei fã dos caras. Nesse link tem um video deles dizendo por que escolheram trabalhar com a plataforma Apple.
2. Hoje a tarde eu me toquei de uma coisa importante. Eu estou vendo muito código, como fazer isso, como fazer aquilo, em geral eu consigo entender tudo isso para criar uma aplicação desktop, aliás, já criei uma para um cliente!!! É tosca, mas ele ficou feliz e eu também. O problema é que eu não entendo bem como as coisas funcionam quando se está programando pra web, principalmente por Ruby usar a metodologia MVC (Model-View-Controller), fico perdido tentando entender como parte do meu programa interagem com a outra e onde devo por isso e aquilo. Sendo assim, decidi parar de ler sobre Ruby e ler sobre Rails, até porque já li um tanto considerável sobre Ruby. Decidi iniciar com a leitura de Agile Web Development With Ruby on Rails, estou na página 36 e estou gostando muito do livro.
3. Tem mais tópicos que eu queria escrever hoje, mas vão ficar pra amanhã, to morrendo de sono, mas só pra registrar e eu não esquecer, amanha vou postar sobre o esquema de criação de banco de dados usando o rake, falar sobre o modelo de organização do programa centrado no banco de dados e o modelo de desenvolvimento do banco de dados centrado no programa, coisa que eu achava que nem existia em desenvolvimentos sérios e agora vejo que é sério rs. E falar sobre ORM (Object/Relational Mapping), tecnologia que eu adorei saber que existe e que praticamente salvou minha vida, já que o design do banco pra minha agenda envolvendo algumas outras características que quero no futuro, feito pela maneira tradicional estava me deixando maluco. Por fim, vou falar um pouco de MVC. Muita coisa prum dia só :)

Ambiente de Desenvolvimento

Após testar algumas coisas me decidi por utilizar o eclipse como IDE. É impressionante como o eclipse cresce, a gente encontra plugins pra tudo nele. Bom, junto com ele estou utilizando o plugin RadRails. Não fui atrás de saber o motivo, já que tenho pressa de iniciar logo a codificação, mas a instalação do RadRails pela interface de instalação de plugins do eclipse não deu muito certo pra mim, acabei fazendo o download e instalando manualmente, ai ele criou o radrails.exe que eu uso pra abrir o eclipse com o plugin ativado, pela instalação automatica ele até me deixava criar o novo projeto, mas depois que eu iniciava servidor ele não encontrava nenhum dos métodos que eu tinha criado. Enfim, com a instalação manual tudo funcionou belezinha e até resolveu um outro problema meu, eu estava usando o plugin Ruby Development Tools (RDT) e iniciava o servidor e fazia geração de models, controllers e etc via console, agora faço tudo pelo eclipse :)

Após a instalação do RadRails é necessário configurar os caminhos dos scripts que este plugin utiliza. Para isso é só ir em Window->Preferences, selecionar Rails->Configuration e setar os caminhos do rails, rake e mongrel. Detalhe, é necessário ter instalado o ruby antes, nesse link é possível fazer o download. Eu estou rodando o ruby no Windows, e eu instalei o ruby em C:\ruby, sendo assim, os caminhos que eu setei para o rails, rake e mongrel foram: C:\ruby\bin\rails, C:\ruby\bin\rake e C:\ruby\bin\mongrel_rails. Mais um detalhe, após instalar o ruby no windows, eu tive que ir ao command, entrar no diretório C:\ruby\bin e fazer: gem install rake mongrel. Com isso ele instalou tudo que preciso para continuar o desenvolvimento.

Feitas estas configurações, ainda na tela de preferências, ir em Ruby->Installed Interpreters e configurar o interpretador. É só clicar em add, definir um nome (ruby) e dar o caminho, no meu caso C:\ruby\bin\ruby.exe. No meu aqui eu criei dois interpretadores, um eu coloquei como nome ruby e caminho C:\ruby\bin\rubyw.exe (que ficou como interpretador padrão), e o outro eu criei como ruby console e o caminho C:\ruby\bin\ruby.exe. A diferença é a seguinte, quando você interpreta um programa com rubyw.exe, ele não abre um console, já com o ruby.exe o console é aberto. Assim quando eu crio um programa em ruby pra desktop em linha de comando, eu interpreto com ruby.exe, nos outros casos eu uso o rubyw.exe.

Finalizando, falta ir em Ruby->RI/rdoc e configurar o caminho para os mesmos. Aqui ficou C:\ruby\bin\rdoc e C:\ruby\bin\ri.

Banco de Dados v0.1

Criei um banco bem tosquinho em mySQL para guardar os dados especificados em requerimentos versão 0.1.

Segue o código sql:

CREATE TABLE `people` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(300) NOT NULL,
`company` varchar(300) default NULL,
`department` varchar(300) default NULL,
`note` text,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `phones` (
`id` int(11) NOT NULL auto_increment,
`id_owner` int(11) NOT NULL,
`number` varchar(20) NOT NULL,
`description` varchar(300) default NULL,
PRIMARY KEY (`id`),
KEY `id_owner` (`id_owner`),
CONSTRAINT `phones_id_owner_fk` FOREIGN KEY (`id_owner`) REFERENCES `people` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Optei por usar o nome das tabelas todas em inglês e no plural, depois quando for para o rails os objetos que criarei pra representar pessoas e telefones terão os nomes em inglês e no singular, assim o rails vai cuidar de fazer automaticamente a associação de objeto com a tabela e criar os templates pra mim. O nome dos atributos também ficou em inglês por uma questão de seguir o padrão.

Requerimentos v0.1

Vou começar com requerimentos bem básicos para minha agenda.

• Cadastrar, editar e remover pessoas.
• Cada pessoa deve ter:
  • 1 nome (obrigatório)
  • 1 empresa (opcional)
  • 1 departamento (opcional)
  • 1 bloco de notas sobre a pessoa (opcional)
  • N números de telefones (opcional)

• Cada telefone deve ter:
  • 1 pessoa associada (obrigatório)
  • 1 número (obrigatório) obs.: pessoas diferentes podem possuir o mesmo número
  • 1 descrição (obrigatório) ex.: ramal, celular, comercial, residência

Motivação

Olá, meu nome é Alexandre, tenho 24 anos e sou de Ribeirão Preto – SP.

Trabalho com soluções para telefonia e redes, mais voltado para a parte de PABX, Call Centers, administração e segurança de servidores MS Windows e GNU/Linux. Gosto muito de programação, mas sempre fui meio que anti programação para web, sempre gostei mais de desenvolvimento desktop e pior, mesmo em desktop nunca gostei da parte gráfica dos programas, detesto pensar em janelinhas, botões, etc. Minha experiência com programação se limita a alguns programinhas feitos em C, apesar de que já dei uma lidinha em php, python, java e outros. Acontece que com a web 2.0 a coisa tem ficado interessante e eu agora quero aprender esse negócio. :)

Comecei a ler sobre java, mas acabei achando tudo muito complicado pra quem está começando e achei que demora muito até ter um protótipo que eu possa brincar e ver que uma parte do que eu fiz já esta funcionando. Pesquisando um pouco mais eu encontrei o Ruby e o framework Rails e após ver alguns webcasts eu acredito que esta seja a linguagem adequada para que eu inicie o aprendizado de uma linguagem para programação web e que também permite desenvolvimento de programas desktop.

Criei este blog para que eu tenha um lugar onde possa documentar os passos desse aprendizado, compartilhar isso com outras pessoas e receber contribuição de outras pessoas. Não tenho muita paciência para ficar muito tempo só na teoria, sendo assim já defini um toyproject para praticar. Pretendo desenvolver uma agenda de contatos, inicialmente algo bem básico e depois irei implementando mais funcionalidades. Vou postar aqui tudo que eu fizer sobre definição de requisitos, testes, programação em ruby, o design, banco de dados, ou seja, esse blog vai falar um pouco de tudo, Ruby, Rails, CSS, mySQL, Ajax, etc, tudo que for necessário a minha agenda.