Ultima parte da tradução da entrevista que o David Heinemeier deu a O’Reilly Network.
Parte I, Parte II, Parte III.
ED: Apesar dos bancos de dados relacionais cobrirem 90% dos casos de uso, existem momentos em que diferentes métodos de armazenamento são muito úteis. O que você acha de adicionar meios de armazenamento alternativos como um banco de dados orientado a objetos ou um RDF datastore?
DHH: Rails vai servir muito bem com qualquer modelo que você puder imaginar. Como exempo, Instiki, o wiki que eu criei, foi recentemente portado para Rails mas ainda usa Madeleine (uma implementação de Prevayler em Ruby que funciona mais ou menos como um banco de dados orientado a objetos) como backend.
Assim, é até que fácil esquecer Active Record e usar alguma outra coisa como backend. Eu vi recentemente pessoas utilizando SOAP, SAP, LDAP e um monte de outros backends. Até mesmo arquivos de texto puro. Tudo isso é possível.
O que de fato aconteceu é que o Active Record reduziu o sofrimento de lhe dar com as dificuldades do objeto-relacional a um ponto onde é muito menos interessante procurar por alternativas – especialmente com bancos de dados como SQLite que te dão a impressão de trabalhar com arquivos de texto puro, mas num contexto SQL.
Meu entusiasmo pessoal para com projetos como o Madeleine diminuiu muito conforme o Active Record se tornava cada vez melhor. Não significa que as outras possibilidades não sejam boas, simplesmente tem sido muito mais facil pra mim trabalhar com Active Record do que procurar alternativas.
ED: Um grande número de frameworks web tem sofrido por se tornarem grandes demais e pontencialmente impossíveis de se administrar, Zope por exemplo. Qual a sua estratégia para evitar isso?
DHH: Ficar abaixo da camada de infraestrutura. Não deixar a lógica de negócios fazer parte do framework. Não é a responsabilidade do Rails tratar de administração de conteúdo, listas de controle de acesso, forums, chats ou qualquer outra coisa que você fizer. Tratamos da estrutura geral que faz sentido para todo o tipo de aplicação.
Assim nós jamais nos tornaremos um Zope, ou OpenACS, ou qualquer outro framework que tenha se perdido nas águas da lógica do negócio e tenha sido consumido por ela.
Nós nos preocupamos em facilitar cada vez mais o que a maioria das pessoas fazem na maioria das vezes em qualquer tipo de aplicação. Por exemplo, estamos contruindo um novo subprojeto chamado SwitchTower (o nome do projeto mudou para Capistrano e seu manual pode ser encontrado clicando aqui) para as próximas versões do Rails. Ele resolve o problema de deploy da aplicação para o servidor de produção. Este é um problema com o qual a maioria das pessoas tem que lhe dar, mas ele não complica o processo de desenvolvimento deixando as ferramentas básicas mais complicadas. Ele simplesmente está lá, esperando pacientemente até que você precise dele.
ED: Quais as próximas novidades que veremos no Rails?
DHH: Eu já falei sobre o SwitchTower que será uma das novidades principais, por outro lado, estamos perto do lançamento do Rails 1.0 agora. É a corrida e o polimento final.
Depois disso nós temos muitos planos. Estou especialmente excitado com o Conductor. Mas eu vou manter este projeto em segredo por um pouco mais de tempo.
