Este ano, por total coincidência, tive a oportunidade de participar de 3 canais de podcast. Quero deixar meus agradecimentos ao Paulo Silveira, Charles Max Wood, Lucas Caton, Fellipe Azambuja e Ramon Sanches.

O primeiro na verdade saiu no fim do ano passado, em Novembro, pelo Ruby Rogues com o tema “Ruby Conf Brazil and Building Communities” (em inglês) onde o Charles Wood e eu discutimos um pouco sobre a história da comunidade Ruby no Brasil, como eu tentei começar, o que tentei fazer, blog, palestras, eventos. Além de pontos mais específicos como um pequeno panorama da linguagem Ruby e meu conceito sobre não se limitar a somente uma linguagem ou tecnologia. Se você é novo na comunidade Ruby talvez ajude a ter uma idéia de como chegamos onde estamos hoje.

O segundo saiu em fevereiro, no podcast do Paulo Silveira, o Hipsters Ponto Tech e o assunto foi “Carreira em Tecnologia”. Participaram os grandes Guilherme Silveira e Sérgio Lopes, e nessa conversa demos uma pincelada nos principais aspectos para quem está começando na carreira de programação. Vejam também os comentários, pois vários outros pontos de vista, opiniões e dicas surgiram dos ouvintes. De curiosidade, esse deu um pouquinho de trabalho porque gravamos um anterior mas como o Paulo ainda estava no início do podcast, ele refinou o processo e pediu para regravar este que acabou saindo. O formato e os temas mudaram um pouco para ficar mais focado, o que tornou a conversa melhor. Alguns dos assuntos que eu abordei na primeira tentativa acabei retomando nos podcasts seguintes desta lista.

O terceiro saiu no meio de maio a convite do Lucas Caton, que me apresentou ao Montanha e Ramon do podcast Dev na Estrada e o tema foi “Vale a pena? Ruby on Rails com Lucas Caton e Akita” onde novamente eu retomo um pouco da parte história da comunidade Ruby internacional e porque Ruby on Rails é diferente de todas as outras comunidades e porque ainda vale a pena investir seu tempo nesse ecossistema.

O quarto saiu no fim de maio e o Charles Wood me convidou novamente para o Ruby Rogues com o título de “My Ruby Story” (em inglês), mas desta vez para eu contar um pouco da minha história pessoal. Como comecei minha carreira. Como comecei com Ruby particularmente. O contexto histórico no mundo da tecnologia nos últimos 20 anos.

O quinto e último até agora saiu hoje, começo de junho. Retorno novamente com o Montanha do Dev na Estrada numa “Entrevista” para repetir um pouco do tema do Ruby Rogues sobre meu começo de carreira. Mas enquanto no Ruby Rogues eu passo muito rápido sobre o começo e vou para os últimos 10 anos onde foquei mais em Ruby, neste com o Montanha eu foco muito mais realmente no comecinho da minha carreira, particularmente os anos 90 e uma pincelada de 30 anos atrás até 10 anos atrás. Os anteriores são longos (média de 1h cada) mas esse em particular é MUITO longo (quase 2h!), peço desculpas pelo tamanho. Mas o Montanha começou “conta do começo” … eu tentei resumir e só contar alguns poucos pontos, mas mesmo assim ficou BEM longo!

Quem chegou a escutar um dos podcasts? O que acharam? Deixem seus comentários abaixo.

• Dr. Nic
• Geoffrey Grosenbach
• Chad Fowler
• David Black
• Ola Bini
• Carl Youngblood
• Jamis Buck
• John Lam
• Avi Bryant
• Avi Bryant
• Adrian Holovaty
• Peter Cooper
• Hal Fulton
• Evan Phoenix

Gerenciamento de Configuração é um assunto complicado. Para quem não está familiarizado: quando você é um desenvolvedor com poucos servidores para cuidar, geralmente dá para se virar gerenciando-os manualmente. As pessoas provavelmente estão acostumadas a colocar um CD, dar duplo clique no programa “instalar” e clicar “avançar”, “avançar” até o fim, depois entrar manualmente para fazer backup (quando se lembra), e às vezes até aplicar atualizações de segurança quando se lembra delas.

Mas quando você tem mais de uma dúzia de máquinas, as coisas começam a ficar feias. Você acaba cometendo mais erros, esquecendo etapas importantes, e de repente gerenciar máquinas vira um pesadelo. Você acaba sendo acordado no meio da noite porque esqueceu de instalar algum componente crucial, e por aí vai.

Da mesma forma que você precisa de testes e ferramentas de integração contínua como desenvolvedor, você também precisa de ferramentas automatizadas, confiáveis e flexíveis para o papel de administrador de sistemas. É aí que ferramentas como o Chef entram para ajudar.

Da Opscode Inc., temos Adam Jacob (CTO) e Jesse Robbins (CEO) para falar sobre o novo concorrente no campo de administração de sistemas automatizada, o Chef, já em uso em muitas empresas que se esforçam na vanguarda para manter seus datacenters.

AkitaOnRails: Para começar esta entrevista, seria ótimo ter mais informações de background sobre vocês. Como vocês chegaram ao espaço de gerenciamento de configuração?

Adam: Sou administrador de sistemas há 13 anos e, na maior parte desse tempo, trabalhei em empresas que faziam muitas fusões e aquisições. A cada dois meses adquiríamos uma nova empresa e era minha função ajudar a descobrir como absorver essas empresas no todo. Fiquei muito bom em analisar uma aplicação com a qual não tinha nada a ver com a criação e descobrir o que precisava ser feito para escalá-la (ou pelo menos fazê-la funcionar).

Uma coisa que não podíamos fazer era dizer às pessoas que construíram as aplicações que elas precisavam ser radicalmente alteradas — em muitos casos, elas nem estavam mais lá. O que isso significava na prática era que precisávamos de uma arquitetura subjacente muito flexível e modular — tudo que fazíamos tinha que servir à aplicação, e não o contrário. Por necessidade, isso significou me tornar um desenvolvedor de ferramentas — se não tivéssemos as ferramentas de que precisávamos, nunca conseguiríamos fazer o trabalho diante de nós.

Eventualmente cofundei uma empresa de consultoria chamada HJK Solutions. Construímos infraestrutura totalmente automatizada para startups — desde a instalação do SO até o deployment de aplicações, tudo totalmente automatizado (incluindo Gerenciamento de Identidade, Monitoramento e Tendências, etc.). Ao longo dos dois anos seguintes, construímos infraestrutura para 12 startups diferentes, cujos produtos iam de gerenciamento de frotas de carros elétricos a namoro online.

Então chego ao gerenciamento de configuração pelas trincheiras — como administrador de sistemas de linha tentando facilitar minha vida, como consultor ajudando outros a colher os benefícios, e agora como construtor de ferramentas tentando avançar o estado da arte.

Jesse: Jesse Robbins é CEO da Opscode (criadores do Chef) e um especialista reconhecido em Infraestrutura, Operações Web e Gerenciamento de Emergências. Atua como co-presidente da Velocity Web Performance & Operations Conference e contribui para o O’Reilly Radar. Antes de cofundar a Opscode, trabalhou na Amazon.com com o título de “Master of Disaster” onde era responsável pela disponibilidade do site para todas as propriedades com a marca Amazon. Jesse é bombeiro voluntário/técnico de emergências médicas e gerente de emergências, e liderou uma força-tarefa implantada na Operação Furacão Katrina. Suas experiências no serviço de bombeiros influenciam profundamente seus esforços em tecnologia, e ele se esforça para destilar seu conhecimento desses dois mundos e aplicá-lo em serviço de ambos.

AkitaOnRails: Qual é a história por trás da Opscode, qual é sua missão e qual é a história da criação do Chef?

Opscode: A história por trás da Opscode realmente começa quando conhecemos Jesse. Ele havia escrito um artigo para o O’Reilly Radar sobre Operações sendo o novo molho secreto para startups. Ele e eu tomamos um café, nos tornamos amigos e ficamos em contato. Jesse entende a cultura de operações de forma visceral, e está muito bem conectado a uma enorme comunidade de pessoas com mentalidade semelhante que eu nem sabia que existia.

À medida que nossa empresa de consultoria crescia, chegamos a uma encruzilhada — claramente tínhamos um bom negócio, e não era difícil encontrar mais trabalho. O que era difícil era encontrar pessoas com as habilidades para de fato fazer o deploy de uma nova infraestrutura e adaptar a stack que desenvolvemos para uma nova aplicação. Não podíamos evitar o fato de que havia algumas semanas de trabalho muito intenso necessário para colocar toda a infraestrutura funcionando para um novo cliente.

Tentamos recrutar Jesse durante esse período, já que ele era um daquelas pessoas raras que podiam fazer esse engajamento inicial intenso. Ele recusou — principalmente porque via o que fazíamos: poderíamos construir uma empresa de consultoria enorme, mas ainda seria nas trincheiras todos os dias. A menos que conseguíssemos superar esse obstáculo, provavelmente havia formas menos estressantes de ganhar a vida. :)

Então começamos a analisar o que nos impedia de conseguir essa parte inicial do engajamento o mais rapidamente possível. O que nos impedia de literalmente fazer um cliente preencher um questionário e deixar esses dados orientar 95% das decisões sobre a infraestrutura?

A resposta, em uma palavra, era “tudo”. Toda a stack de ferramentas open source que estávamos usando havia sido construída em uma era diferente e via o mundo por uma lente muito diferente. Precisávamos que tudo tivesse uma API, precisávamos que tudo fosse mais aberto com seus dados e precisávamos que tudo fosse flexível o suficiente para lidar com a próxima evolução das arquiteturas de aplicações (seja lá o que isso fosse ser).

Com essa revelação, o próximo passo foi descobrir como seria uma “nova stack” de verdade. Se pudéssemos começar do zero, o que levaríamos e o que deixaríamos para trás? A Amazon havia feito um trabalho tão bom mostrando como uma API sobre o processo de bootstrapping poderia parecer, e os benefícios que poderiam ser obtidos com essa abordagem. Supondo que algo assim existisse para bootstrapping, e a próxima camada da stack (configuração)?

Começamos a experimentar com o Chef durante esse período de questionamentos. Começamos a trabalhar no Chef com o objetivo de nos colocar fora dos negócios — tornando a barreira de entrada para ter uma infraestrutura totalmente automatizada tão baixa que qualquer desenvolvedor ou administrador de sistemas pudesse simplesmente fazê-lo. Construímos um protótipo, mostramos para Jesse e ele concordou em se juntar ao time.

A Opscode nasceu então, e nossa missão surgiu desses experimentos: estamos levando a Automação de Infraestrutura para as Massas. Queremos derrubar as barreiras de entrada que impedem as pessoas de ter uma infraestrutura realmente ótima, repetível e automatizada. Nosso papel é trazer aos desenvolvedores e administradores de sistemas as melhores ferramentas possíveis para que possam construir os sistemas que sempre quiseram.

Captamos 2,5 milhões da DFJ em janeiro de 2009 com essa visão e desde então temos trabalhado nisso.

AkitaOnRails: Gostaria de dizer que apenas sysadmins amadores fazem tudo manualmente, mas acho que a maioria das corporações pequenas e médias ainda faz tudo manualmente ou com scripts aleatórios espalhados por todo lugar. A noção de “gerenciamento de configuração” ainda é nova para muita gente. Você poderia explicar brevemente o que é e por que é importante?

Opscode: Para mim, “Gerenciamento de Configuração” em sua essência é tudo que você precisa fazer para levar um sistema de “rodando um sistema operacional” para “fazendo seu trabalho”. Quando um administrador de sistemas configura um sistema manualmente e posta suas notas em um Wiki, ele está praticando a forma mais primitiva de Gerenciamento de Configuração.

Ter essas notas é melhor que nada — quando ela precisar fazer aquela tarefa de novo, pode pelo menos voltar e lê-las para se lembrar do que fez da última vez. Mas ainda precisa fazer tudo de novo — e a repetição cansa. Então ela começa a escrever scripts que encapsulam esse conhecimento em código, de modo que agora só precisa executar uma série de comandos menores.

O tempo passa, porém, e a entropia entra em ação. Os sistemas começam a derivar de onde estavam quando o administrador escreveu os scripts. Logo os scripts não rodam mais, ou se rodam, a configuração que constroem está errada. Nossa destemida admin começa então a editar os scripts ou criar novos para lidar com o sistema nesse novo estado. Isso é o estágio que chamamos de “tool sprawl” — você tem uma ferramenta para cada fase diferente do ciclo de vida observável de um sistema.

As ferramentas modernas de gerenciamento de configuração resolvem esse problema fornecendo um framework para descrever o estado final em que um sistema deve estar, em vez dos passos discretos que devemos seguir para chegar lá em qualquer momento. Em vez de escrever um script que lista os comandos para instalar o Apache, escrever o arquivo de configuração e iniciar o serviço, você descreveria que “apache deve estar instalado”, o arquivo de configuração “deve ter esta aparência” e o serviço “deve estar rodando”.

Quando o sistema de gerenciamento de configuração roda, ele analisa cada uma dessas descrições individualmente e garante que estejam no estado adequado. Não nos importa mais qual é o estado inicial do sistema — o sistema de gerenciamento de configuração só tomará ação em cada etapa se o sistema não estiver no estado que você descreveu. Se você rodar novamente e nada tiver mudado, o sistema não toma nenhuma ação. (Os geeks de gerenciamento de configuração chamam essa propriedade de idempotência)

Isso significa que você pode descrever seus sistemas uma vez em código e, à medida que mudam com o tempo, simplesmente atualizar esse código para refletir o estado desejado. O impacto desse modelo no dia a dia de um administrador de sistemas não pode ser subestimado — torna tudo mais fácil.

Também tem impactos enormes fora do mundo dos administradores de sistemas. Você agora tem um documento vivo que descreve como todos os seus servidores estão configurados — pode compartilhá-lo, colocá-lo em controle de versão, imprimi-lo para um auditor. Processos de negócios que antes exigiam intervenção manual frequentemente podem ser reduzidos a mudanças discretas. Quanto mais você trabalha dessa forma, mais os impactos se espalham pela organização.

AkitaOnRails: Embora a comunidade Ruby provavelmente compare Chef com Puppet, acho que um dos sistemas mais amplamente utilizados é o CFEngine2. Como o Chef se compara ao CFEngine2?

Opscode: O Cfengine 2 é onde quase todo mundo no mundo do gerenciamento de configuração aprendeu. Mark Burgess é responsável pelos artigos acadêmicos que delinearam a ideia de que cada parte do sistema deve ser idempotente, e seu trabalho estudando como sistemas do mundo real podem ser gerenciados em escala fez mais para impactar a evolução do gerenciamento de configuração do que qualquer outro indivíduo.

Além da ideia de recursos idempotentes, Burgess introduziu o conceito maior de “convergência”. A ideia básica aqui é que se você tem a descrição de como cada recurso finito deve ser configurado, dado tempo suficiente, esses recursos trarão o sistema para um estado compatível. A ordem em que os recursos rodam fundamentalmente não importa — eventualmente, todos chegarão ao lugar certo.

Embora esse modelo funcione em um nível fundamental, tem algumas ineficiências bastante dramáticas. O Cfengine aplica recursos com base em seu tipo — todos os arquivos são gerenciados de uma vez, depois todos os serviços, depois todos os pacotes. Você pode controlar a ordem em que são executados com o ‘actionsequence’, mas cada sistema tem apenas uma ordem. Então se você precisa copiar um arquivo, instalar um pacote e reiniciar um serviço, é fácil o suficiente de modelar. Quando você começa a entrar em configurações mais complexas, porém, fica cada vez mais difícil montar um actionsequence que permite configurar todo o seu sistema em uma única execução.

Isso não é um bug no Cfengine — é por design. A convergência é a resposta — não tem problema precisar rodar mais de uma vez; eventualmente chegará lá. Se você está pensando demais sobre a ordem em que as coisas devem acontecer, provavelmente não está pensando em descrições idempotentes.

Na minha experiência, porém, isso era frustrante em escala. Significava que o tempo necessário para configurar um sistema aumentava à medida que a configuração ficava mais complicada, e sua capacidade de modelar interações complexas no sistema tornava-se cada vez mais opaca.

Para a era em que foi escrito, esse problema importava muito menos. Se leva de 6 a 8 semanas para pedir um servidor, depois mais uma semana para instalá-lo no rack e instalar o SO, o fato de que o Cfengine precisa rodar 3 vezes para configurá-lo não importa muito. (Você tem problemas muito maiores!) Em um mundo onde muitos de nós podemos ir de bare-metal a um sistema operacional rodando em 5 minutos, seja por nossos próprios sistemas de instalação ou por uma chamada de API à AWS, isso começa a importar muito.

O Chef adota uma abordagem diferente. Começamos com a ideia de um “recurso” idempotente — um pacote, um serviço, etc. Adicionamos a ideia de “ações” — todos os diferentes estados que você pode querer solicitar que um recurso esteja. Depois você coloca esses recursos em “recipes”, que são avaliadas na ordem em que são escritas. Você pode então fazer com que recipes dependam de outras recipes que tenham sido concluídas antes de serem executadas, dando-lhe a capacidade de dizer “certifique-se de que o Apache está instalado antes de configurar minha Aplicação Web”.

O objetivo é que, com Chef, você sempre possa trazer o sistema ao estado adequado com uma única execução do Chef. Ele vê a convergência como uma resposta a um bug — um sistema que está 1/2 configurado está, de fato, quebrado. Se a causa do bug for ambiental — um serviço de rede não está disponível, por exemplo — então rodar o Chef novamente provavelmente corrigirá as coisas. Se o problema é que você não especificou a ordem em que quer que os recursos sejam configurados, então é um bug em suas recipes. Se você não consegue escrever uma recipe para configurar seu sistema em uma única execução do Chef, é um bug no Chef.

Isso também tem efeitos colaterais para raciocinar sobre o sistema em escala. Dada a mesma configuração e atributos, o Chef sempre se comportará da mesma forma, em todos os sistemas. À medida que você adiciona mais e mais coisas ao sistema, ainda é fácil raciocinar sobre quando e como elas serão configuradas.

Curiosamente, o Cfengine 3 implementa um sistema muito similar ao Chef. Em vez de uma actionsequence global única, usa um ‘bundlesequence’, onde bundles são aproximadamente análogos ao conceito de recipe do Chef.

Outra diferença importante é que o Chef permite que você ‘olhe para cima’ em toda a sua infraestrutura ao configurar um sistema. Essa capacidade é útil quando você quer fazer coisas como configurar um sistema de monitoramento ou um load balancer. Você pode fazer perguntas ao Chef como “quais são todos os servidores rodando minha aplicação em produção” e usar a resposta para configurar seu sistema. (Você pode ver um exemplo disso no nosso blog)

Do ponto de vista de arquitetura de sistemas, Chef e Cfengine são na verdade bastante similares. Ambos empurram a maior parte do trabalho difícil de configurar um sistema para os próprios sistemas. Isso é muito vantajoso em escala — os servidores do Chef e do Cfengine são na verdade sistemas glorificados de transferência de arquivos.

Diferimos bastante em nossa abordagem sobre como deve ser uma linguagem para gerenciamento de configuração, mas falarei mais sobre isso numa pergunta posterior.

O Cfengine está em uso em alguns dos maiores datacenters da indústria e alterou fundamentalmente o panorama do gerenciamento de sistemas. Embora não seja mais a ferramenta que quero, não se pode subestimar o impacto que teve no design de todas as ferramentas de gerenciamento de configuração que vieram depois — incluindo o Chef.

AkitaOnRails: O Chef tem muitos componentes. Você pode descrever brevemente todos os principais componentes que trabalham juntos? O lado do cliente, o lado do servidor, os cookbooks?

Opscode: Claro! A parte mais importante do Chef são os cookbooks — é onde você realmente descreve sua configuração. Eles coletam recipes e todos os assets necessários para a recipe rodar (arquivos, templates, etc.). Cookbooks são muito frequentemente compartilháveis e já existem muitos deles.

O Chef pode executar seus cookbooks em dois modos — um modo cliente/servidor (chef-client) ou um modo standalone (chef-solo). Quando você executa chef-solo, passa uma URL para um tarball cheio dos cookbooks que você quer rodar. Não há mais infraestrutura do que isso — coloque seus tarballs em algum lugar onde possa baixá-los e se divirta.

No modo cliente/servidor, cada cliente Chef é configurado para se comunicar com um Chef Server. O servidor armazena informações sobre cada cliente (muitas delas — coisas como endereços IP, módulos de kernel carregados e mais) e distribui os cookbooks de que precisam para se configurar. Ele também fornece uma API REST e uma interface Web interativa, para que você possa alterar facilmente a configuração de seus sistemas de forma centralizada. Por fim, todos os dados que o servidor coleta são indexados e pesquisáveis — você pode usar isso em suas recipes para configurar serviços que requerem configuração complexa e dinâmica. (Alguns exemplos seriam descobrir dinamicamente um servidor MySQL master ou encontrar todos os servidores memcached em um cluster)

AkitaOnRails: O que você diria sobre a maturidade do Chef? O CFEngine tem mais de uma década de uso, o que é difícil de superar. Você diria que é “maduro o suficiente”? Ou seja, já está em produção em empresas de muitos tamanhos, suas APIs não mudam muito e meus cookbooks provavelmente funcionarão se eu atualizar para uma versão mais nova do Chef?

Opscode: O Chef tem pouco mais de um ano — foi lançado ao público em 15 de janeiro de 2009. Desde então, 42 desenvolvedores diferentes contribuíram para o projeto, sendo que cerca de 5 trabalham para a Opscode. Está em uso em produção no Engine Yard Cloud desde o dia do lançamento. Desde então, foi adotado por empresas e universidades de todos os tamanhos, de pequenas startups a grandes empresas com requisitos de compliance muito pesados.

Então definitivamente é “maduro o suficiente” para uso no mundo real — muitas pessoas o usam e dependem dele todos os dias. Equilibrar esse conhecimento com a realidade de que o projeto está em rápida evolução é importante, e tentamos fazer isso de várias formas:

1. A sintaxe de recipe é considerada basicamente “completa”. Se fizermos mudanças, elas são retrocompatíveis com lançamentos anteriores do Chef. Salvo algo verdadeiramente incrível que altere radicalmente a forma do universo, isso permanecerá verdadeiro.
2. Testamos muito. O Chef tem mais de 2000 unit tests e functional tests que cobrem toda a API REST e muitos dos recursos individuais (visamos 100% de cobertura de testes de features). Há mais linhas de código testando o Chef do que linhas de código no próprio Chef.
3. Se de fato quebrarmos compatibilidade retroativa, tentamos fazer isso apenas quando incrementamos a revisão minor. Se você tem uma versão 0.7.x do Chef instalada, ela deve sempre funcionar com outras versões do Chef no mesmo ciclo de lançamento.

A maior parte do trabalho no Chef atualmente é sobre adicionar mais funcionalidades, não em mudar a forma como as funcionalidades existentes funcionam. É seguro usar o Chef hoje — no futuro, você continuará recebendo mais ingredientes para adicionar ao mix, em vez de ter que refatorar profundamente a forma como você faz as coisas.

Por fim, a Comunidade Chef é verdadeiramente épica — temos muitas pessoas que dedicam quantidades significativas do seu tempo ao Chef. Mesmo que não estejam contribuindo código, estão respondendo perguntas, escrevendo documentação, ficando no IRC e oferecendo cupcakes. É um grupo de pessoas focadas em resolver problemas do mundo real e ajudar umas às outras a fazer o mesmo. É de longe o que mais me orgulha e acho que tem um impacto significativo em se o Chef está pronto para o prime time. O banco é realmente muito profundo.

AkitaOnRails: O Chef usa Ruby diretamente, o que alguns diriam ser uma bênção e uma maldição. Provavelmente é perfeito para Rubistas, mas sinto que a maioria dos sysadmins está acostumada com Bash, Python e não é muito flexível a mudanças. Por que você escolheu usar Ruby em vez de uma linguagem mais simples?

Opscode: A resposta para a pergunta de por que usamos Ruby diretamente para a linguagem de configuração tem duas partes: por que estendemos uma linguagem 3GL em vez de construir uma DSL declarativa ou uma linguagem de modelagem completa, e por que escolhemos Ruby como essa 3GL.

Primeiro, por que estendemos uma 3GL. Ferramentas como Cfengine e Puppet constroem uma DSL declarativa para gerenciamento de configuração — uma linguagem customizada que fornece um modelo dentro do qual administradores de sistemas ou desenvolvedores de software podem trabalhar para automatizar seu sistema. Outras ferramentas como o EDML e ECML da Elastra, o DCML da OpsWare ou o Bcfg2 dão a você um schema XML para descrever como o sistema deve se comportar.

O problema com essas abordagens é que, por definição, elas devem construir uma abstração para cada tarefa que o usuário final pode querer realizar: uma façanha impossível. O nível de complexidade inerente à automação, aliado à incapacidade de recorrer a construções de linguagem 3GL quando necessário, resulta em um sistema que só pode lidar com um subconjunto da complexidade total, em vez de permitir que os usuários encontrem soluções inovadoras para seus problemas específicos. Ao aproveitar o Ruby, adicionar suporte para outros casos de uso é uma questão de adicionar novos conjuntos de classes base mantendo consistência e acessibilidade no design de sua interface, porque o escopo completo da linguagem está disponível.

Nosso objetivo com o Chef era manter a simplicidade que vem de ter o foco na declaração de recursos idempotentes, enquanto dá a você a flexibilidade de uma 3GL completa. Em termos práticos, tudo que você pode fazer com Ruby, você pode fazer com Chef — e como Ruby é uma 3GL, isso equivale a essencialmente qualquer coisa.

Larry Wall, o criador do Perl, tem uma citação que adoro:

“Para a maioria das pessoas, a utilidade percebida de uma linguagem de computador é inversamente proporcional ao número de eixos teóricos que a linguagem pretende afiar.”

Como queríamos que o Chef tivesse a máxima utilidade, ativamente tentamos remover o maior número possível de eixos teóricos — a crença de que podemos imaginar a amplitude total do espaço do problema sendo um deles. Há mais de uma forma de fazer isso com Chef, e o único critério válido para avaliar o sucesso do seu projeto de automação é se ele resolve seus problemas de forma confiável.

Na prática, você precisa saber muito pouco de Ruby para usar o Chef. Aqui está um exemplo de instalação do programa “screen”:

package "screen" do
 action :install
end

O mesmo em Puppet:

package { "screen":
 ensure => present
}

E em Cfengine 2:

packages:
 screen action=install

Embora todos esses sistemas exijam aprender a sintaxe, em um nível base não há muita diferença entre eles em termos de aprendizado bruto necessário. A diferença é que quando você atinge uma limitação no Chef, você tem a capacidade de inovar facilmente, e quando atinge as mesmas limitações em outras ferramentas, você não tem.

Escolhemos Ruby por sua capacidade bastante única de criar nova sintaxe facilmente. Ferramentas como Rspec são bons exemplos de formas como você pode manipular Ruby de forma útil e que são muito difíceis de replicar em outras ferramentas. Queríamos garantir que, mesmo estando “em” uma 3GL, você não precisasse passar por obstáculos adicionais para fazer as coisas simples funcionarem. Ruby era a linguagem em que eu me sentia suficientemente confortável e que eu sabia ter a capacidade de tornar isso realidade.

Dito isso, um de nossos objetivos é estender a capacidade de escrever recipes Chef para outras 3GLs. Já temos um exemplo disso com Perl — e não fizemos nenhuma mudança no código fonte do Chef para isso. Você pode ver o demo aqui no CPAN. Funciona usando a API JSON do Chef para enviar os recursos compilados para a biblioteca Ruby para execução, e ao longo do tempo estaremos estendendo essas interfaces. Você poderá ter recipes escritas em Python interoperando com recipes escritas em Ruby e Perl.

AkitaOnRails: O Chef tem (ou precisa de) algo como o Augeas, que o Puppet está tentando suportar?

Opscode: O Augeas é interessante. O Chef não tem suporte ao Augeas hoje, e a razão é que ninguém precisou tanto a ponto de escrever a integração. Uma razão é que, com o Chef, é bastante fácil adicionar dinamicamente a um recurso (como, por exemplo, um template) ou pesquisar sistemas específicos que correspondam a um critério. Isso significa que o caso de uso do Augeas (que edita arquivos in-place) é menos necessário — você muitas vezes pode obter os dados necessários para renderizar um template, em vez de precisar construí-lo ao longo do tempo com edições incrementais.

Achamos que isso é uma prática melhor em geral, pois garante que todos os sistemas que você está gerenciando sempre possam ser restaurados a um estado funcional a partir apenas do repositório de cookbooks. Se você usa o Augeas para permitir mudanças idempotentes de linhas individuais de um arquivo de configuração, ele incentiva o comportamento de administradores individuais editando arquivos in-place, o que é um anti-padrão de gerenciamento de configuração.

AkitaOnRails: Sysadmins acostumados ao CFEngine reclamam das dependências do Ruby e do peso geral. Porque para o Chef rodar você precisa do Ruby instalado. Nem todas as distros têm Ruby na mesma versão (embora a maioria já tenha migrado para 1.8.7). Depois há o problema do peso. Não estou familiarizado com o Chef, mas o Puppet pode chegar a centenas de megabytes. O que não querem é ter clusters de máquinas Chef (que, por si só, também precisam de manutenção, adicionando à complexidade geral). Como vocês lidam com datacenters com milhares de servidores? Sei que é difícil medir com precisão, mas qual seria uma proporção razoável entre servidores Chef x servidores gerenciados?

Opscode: Ao avaliar a escalabilidade de sistemas de gerenciamento de configuração, você quer analisar dois eixos diferentes. O horizontal, que é o número de sistemas que podem ser gerenciados por um único servidor de gerenciamento de configuração a uma taxa específica de mudança, e o vertical, que é quanto da sua infraestrutura pode ser automatizada pela ferramenta.

No eixo vertical, acho que o Chef é o claro vencedor, por razões que acho bem resumidas pela minha resposta à pergunta 7. Colocaria o Puppet em segundo lugar e o Cfengine por último.

No eixo horizontal, o Cfengine é o claro vencedor. É escrito em C e tem o componente de servidor mais fino possível — basicamente não faz nada além de autenticar clientes e servir arquivos. Conheço em primeira mão datacenters que estão rodando enormes quantidades de servidores com um único servidor cfengine.

Uma métrica importante a ter em mente ao discutir a escalabilidade horizontal de uma solução de gerenciamento de configuração é que a métrica mais importante é a taxa de mudança. Todas as ferramentas sobre as quais estamos falando são baseadas em ‘pull’ — os clientes fazem check-in em um ‘intervalo’ com o servidor e aplicam um ‘splay’ para garantir que nem todos os sistemas façam check-in de uma vez. Uma configuração out-of-the-box comum é um intervalo de 30 minutos com um splay de 15 minutos. (Isso significa que um servidor faz check-in a cada 30-45 minutos, dependendo.) Se você se sentir confortável em aumentar esse intervalo, obterá mais escalabilidade com menos recursos (reduzindo a quantidade de concorrência).

Então, quando alguém disser “tenho 10 mil servidores em um único servidor de gerenciamento de configuração”, pergunte “a que intervalo?”.

O Chef escala como uma aplicação web. O próprio servidor é bastante leve e é responsável por autenticar clientes, transferir arquivos, armazenar o estado dos nós e fornecer uma interface de busca. Ele escala horizontalmente adicionando novos Servidores Chef conforme necessário. A API é RESTful e não há estado de sessão entre os clientes e o servidor (pelo menos não no Chef 0.8+). Quando você encontra problemas de escalabilidade com o Chef, as ferramentas que você aplica são as mesmas que você aplica a qualquer aplicação web bem projetada.

Você perguntou especificamente sobre utilização de memória — o Chef se sai muito bem nesse aspecto. Os processos de servidor individuais geralmente têm entre 14-50MB residente. O próprio cliente, rodando em modo daemon, geralmente fica em torno de 28MB residente.

Em nossos testes, o gargalo atual em um servidor Chef é CPU. O Chef é inteligente sobre como lida com transferências de arquivos — transferimos apenas arquivos que mudaram no servidor. Para suportar isso, calculamos um checksum para cada arquivo solicitado e atualmente não armazenamos os resultados em cache. Planejamos corrigir isso para o próximo lançamento principal do Chef (0.8.0), o que deve mudar o gargalo para a RAM.

Com o Chef 0.7, você deve ser capaz de suportar milhares de clientes a um intervalo de meia hora e splay de quinze minutos em hardware commodity razoável. As mudanças no Chef 0.8 devem elevar esse número dramaticamente — voltarei com alguns benchmarks assim que os patches estiverem prontos. :)

AkitaOnRails: Provavelmente relacionado à pergunta anterior: parece que especialmente após a Sarbanes-Oxley houve um interesse crescente em coisas como ITIL e CoBit. Você já viu implementações bem-sucedidas desses em infraestrutura no estilo Web? Quero dizer, posso vê-los funcionando em Bancos, Aeroespacial e Defesa, etc., mas não consigo ver funcionando conforme anunciado em um ambiente muito dinâmico como hospedagem de serviços Web. Quais são suas experiências com essa questão?

Opscode: Bem, acho que você pode pensar em ITIL da mesma forma que pensa no modelo clássico ‘Waterfall’ de desenvolvimento de software. Para alguns tipos de projetos e empresas, é essencial — é difícil imaginar trabalhar de outra forma. Na maioria das vezes, são empresas com grandes preocupações de fabricação ou controle de qualidade — saúde médica, aeroespacial, bancário e financeiro, etc.

O mesmo se aplica ao ITIL — quanto maior a organização, mais rigorosos os requisitos e maior o prazo de entrega, mais os processos que descrevem começam a fazer sentido. Como todos os grandes processos, porém, tendem a diminuir o elemento humano — as pessoas têm papéis a desempenhar e formulários a preencher. :)

Na cultura de Web Ops, as coisas são diferentes. Nunca vi um casamento bem-sucedido entre ITIL e Web Ops, e a razão é que os domínios são muito diferentes. Se há um bug no site, é melhor enviar a correção agora do que esperar por um processo de gestão de lançamento para garantir que o site não terá mais problemas com base na sua correção, por exemplo. Também é um ajuste cultural ruim — nas melhores equipes de Web Ops, o foco é intenso em comunicação, agilidade e respeito, em vez de processo, formalismo e ferramentas. A mudança que você começa a ver nas grandes empresas de Web Ops é que seu pessoal de operações se torna habilitador da organização, em vez de bloqueadores de linha final de mudanças (para manter a estabilidade alta).

Em geral, acho que os 4 passos descritos no visible ops para gestão de emergências não são ruins, mas o diabo está sempre nos detalhes. A pessoa que você deveria realmente perguntar sobre isso é Jesse — ele é em grande parte responsável pela cultura operacional da Amazon e sabe o que significa começar a hackear esse tipo de coisa de dentro de grandes organizações.

AkitaOnRails: Incrível, acho que é isso. Muito obrigado por esta entrevista!

Mas quando você tem mais de uma dúzia de máquinas, as coisas começam a ficar feias. Você acaba cometendo mais erros, esquecendo etapas importantes, e de repente gerenciar máquinas vira um pesadelo. Você acaba sendo acordado no meio da noite porque esqueceu de instalar algum componente crucial, e por aí vai.

Da mesma forma que você precisa de testes e ferramentas de integração contínua como desenvolvedor, você também precisa de ferramentas automatizadas, confiáveis e flexíveis para o papel de administrador de sistemas. É aí que ferramentas como o Puppet entram para ajudar.

Desta vez entrevistei Luke Kanies, do Reductive Labs, ex-contribuidor da famosa ferramenta CFEngine e criador do Puppet, uma das ferramentas de gerenciamento de configuração mais aclamadas para datacenters do século XXI.

AkitaOnRails: Para começar esta entrevista, seria ótimo ter mais informações de background sobre você. Como você chegou ao campo de gerenciamento de configuração? Entendo que você tem uma longa história com o desenvolvimento do CFEngine, certo?

Luke: Fui administrador Unix desde 1997, sempre escrevendo scripts e ferramentas para economizar tempo, e por volta de 2001 percebi que não deveria precisar escrever tudo sozinho — que alguém em algum lugar deveria ser capaz de me poupar tempo. Após muita pesquisa e experimentação, me fixei no Cfengine e tive sucesso suficiente com ele para começar a fazer consultoria, publicar e contribuir para o projeto.

AkitaOnRails: Qual é a história por trás do Reductive Labs, qual é sua missão e qual é a história da criação do Puppet?

Luke: Depois de alguns anos com o Cfengine, tinha muito mais insight, mas estava frustrado porque ainda parecia difícil demais — ninguém estava compartilhando código Cfengine e havia alguns problemas que exigiam muito trabalho para resolver. O maior problema, porém, era que seu desenvolvimento era muito fechado — era difícil contribuir com muito mais do que apenas correções de bugs.

Fiquei frustrado o suficiente para parar de fazer consultoria e procurar outras opções. Trabalhei brevemente no BladeLogic, uma empresa de software comercial nesse espaço, mas no final decidi que o insight que tinha e a falta de uma ótima solução eram um bom começo para um negócio — então decidi transformar minha empresa de consultoria em uma empresa de software e escrever uma nova ferramenta.

AkitaOnRails: Gostaria de dizer que apenas sysadmins amadores fazem tudo manualmente, mas acho que a maioria das corporações pequenas e médias ainda faz tudo manualmente ou com scripts aleatórios espalhados por todo lugar. A noção de “gerenciamento de configuração” ainda é nova para muita gente. Você poderia explicar brevemente o que é e por que é importante?

Luke: É surpreendentemente difícil descrever de forma concisa, mas para mim há duas regras principais: você não deveria precisar se conectar diretamente a uma máquina para alterar sua configuração, e deveria ser capaz de reimplantar qualquer máquina na sua rede muito rapidamente.

Essas duas regras combinadas exigem automação e/ou centralização abrangente de tudo que é necessário para fazer uma máquina funcionar. Irritantemente, elas também introduzem imediatamente ciclos de dependência, porque o seu servidor de automação precisa ser capaz de se construir, o que sempre é um pequeno desafio.

AkitaOnRails: Acho que um dos sistemas mais amplamente utilizados é o CFEngine2. Como o Puppet se compara a ele? Ou seja, qual o valor agregado ao migrar para o Puppet e quais são as ressalvas conhecidas?

Luke: Há várias diferenças funcionais importantes. A maior é a Resource Abstraction Layer do Puppet, que permite que os usuários do Puppet evitem muitos detalhes com os quais não se preocupam realmente, como como rpm, adduser ou init scripts funcionam — eles falam sobre usuários, grupos e pacotes, e o Puppet descobre os detalhes.

Também temos suporte explícito a dependências, o que faz uma enorme diferença — é fácil ordenar recursos relacionados e reiniciar serviços quando seus arquivos de configuração mudam, por exemplo.

A linguagem também é um pouco mais poderosa. Como o Cfengine, temos uma linguagem customizada simples, mas a linguagem do Puppet fornece melhor suporte para heterogeneidade, além de uma construção de recurso composto que permite criar facilmente tipos de recursos em linguagem como virtual hosts Apache que modelam recursos mais complexos compostos por múltiplos recursos simples.

AkitaOnRails: O Puppet tem muitos componentes. Você pode descrever brevemente alguns dos principais que trabalham juntos? O lado do cliente, o lado do servidor, as recipes?

Luke: A maioria das pessoas usa o Puppet no modo cliente/servidor, onde o servidor central é a única máquina que tem acesso a todo o código, e ele executa um processo capaz de compilar esse código em configurações específicas para cada host. Então cada máquina executa um cliente (incluindo o servidor), que recupera e aplica essa configuração específica do host. Isso tem boas implicações de segurança porque você não enviou seu código para cada máquina na rede.

Se esse modelo não funcionar para você, também é fácil executar o Puppet de forma standalone, onde cada máquina tem todo o código e o compila separadamente. Vários usuários do Puppet fazem isso por várias razões. Esse executável ‘puppet’ standalone é um interpretador padrão — pode ser usado para executar scripts de 1 linha ou milhares de linhas em uma configuração completa.

Além disso, temos alguns outros executáveis interessantes, como para acessar nossa funcionalidade de autoridade de certificação, e um executável interessante chamado ‘ralsh’ que fornece uma forma simples de gerenciar recursos diretamente do shell Unix, sem precisar escrever um script separado.

AkitaOnRails: O que você diria sobre a maturidade do Puppet? O CFEngine tem mais de uma década de uso, o que é difícil de superar. Você diria que é “maduro o suficiente”? Ou seja, já está em produção em empresas de muitos tamanhos, suas APIs não mudam muito e minhas recipes provavelmente funcionarão se eu atualizar para uma versão mais nova do Puppet? Acho que a versão 0.x deixa algumas pessoas nervosas :-)

Luke: Na verdade deveríamos ter chamado uma versão de 2007 de 1.0, mas é difícil saber o quão estável um lançamento será até que ele esteja disponível há algum tempo. :)

É obviamente difícil competir com a longa vida do Cfengine, embora eles estejam de certa forma migrando forçosamente para o Cfengine 3, que é uma reescrita completa, então essa maturidade não vale tanto assim agora.

No entanto, o Puppet está em uso em produção ao redor do mundo desde 2006 e atualmente é usado por mais grandes empresas do que eu poderia razoavelmente nomear — Twitter, Digg, Google, Sun, Red Hat e muitas outras — e nossa comunidade e base de clientes o consideram maduro. A virada aconteceu em algum momento no início do ano passado, quando descobri que a grande maioria dos problemas das pessoas eram problemas do lado deles, em vez de alguma falha ou limitação no Puppet.

Em geral as APIs são bastante estáveis e acho que nos saímos muito bem em manter a compatibilidade retroativa quando as APIs precisaram mudar. O ponto sobre estabilidade de API em um lançamento 1.0 não é tanto diferenciá-lo de esforços anteriores quanto fazer uma promessa para o futuro. Isso importa especialmente para empresas como a Canonical, que querem um lançamento que possam suportar no Ubuntu por cinco anos.

AkitaOnRails: O Puppet tem sua própria linguagem e você pode usar Ruby para os casos avançados. Provavelmente é perfeito para Rubistas, mas sinto que a maioria dos sysadmins está acostumada com Bash, Python e não é muito flexível a mudanças. Por que você escolheu usar Ruby em vez de uma linguagem mais difundida? O que os sysadmins precisam perceber para mudar de paradigmas?

Luke: Parte disso é que a maioria das pessoas não precisa realmente saber nada de Ruby para ser eficaz com o Puppet. Claro, você pode ter mais poder se souber, mas se você não é uma pessoa de linguagens, funciona perfeitamente com apenas Puppet.

Outra coisa boa é que temos uma escala bastante suave em termos de conhecimento de Ruby — você pode começar escrevendo templates ERB ou extensões de cinco linhas para o Facter, que é nosso sistema de consulta do lado do cliente, e crescer suavemente até escrever tipos de recursos customizados.

No fim das contas, escolhi Ruby porque era mais produtivo nele. Provavelmente deveria ter escolhido Python, dado seu benefício de velocidade e popularidade no Red Hat e outros lugares, mas descobri que simplesmente não conseguia escrever código nele. Comecei a pensar em Ruby depois de apenas algumas horas de uso, então era impossível para mim me afastar dele.

AkitaOnRails: Sysadmins acostumados ao CFEngine reclamam das dependências do Ruby e do peso geral. Porque para o Puppet rodar você precisa do Ruby instalado. Nem todas as distros têm Ruby na mesma versão (embora a maioria já tenha migrado para 1.8.7). Depois há o problema do peso. O Puppet pode chegar a centenas de megabytes. O que não querem é ter clusters de máquinas Puppet (que, por si só, também precisam de manutenção, adicionando à complexidade geral). Como você lida com datacenters com milhares de servidores? Sei que é difícil medir com precisão, mas qual seria uma proporção razoável entre servidores Puppet x servidores gerenciados?

Luke: É tão impossível te dizer quantos clientes um servidor Puppet pode atender quanto é te dizer quantos clientes um servidor Rails pode atender — tudo depende da complexidade das tarefas. O Google escalou para 4500 máquinas clientes em um único servidor, mas a maioria das pessoas tende a adicionar outro servidor em torno de 500-1000 clientes.

É verdade que é difícil manter o uso de memória baixo em um processo Ruby, mas fizemos grandes avanços nos nossos lançamentos recentes fazendo coisas como deduplicar strings em memória e ser mais eficiente em nossos code paths. Mas na verdade gastamos muito mais tempo em features e correções de bugs e menos tempo em otimização — até recentemente éramos uma equipe de desenvolvimento pequena e simplesmente não tínhamos largura de banda para isso.

Agora que minha empresa, Reductive Labs, tem algum investimento, conseguimos adicionar três desenvolvedores em tempo integral, o que vai ajudar muito nessa área.

Quanto a dependências, essa é uma área onde nos afastamos fortemente da comunidade Ruby — não exigimos uma única gem, a não ser nossa própria ferramenta Facter (e normalmente não é enviada como gem). Os Rubistas tendem a não se preocupar muito com dependências de pacotes — eles simplesmente colocam no vendor, como gosto de dizer — mas isso não funciona quando você tem que implantar milhares de cópias. Então sim, você pode ter que instalar Ruby, mas não haverá outras dependências com as quais você tenha que lidar, o que simplifica muito.

Geralmente é tão difícil saber como você precisará dimensionar seu puppetmaster quanto seria dimensionar um servidor web — depende de quão complicada é a carga de trabalho. Em geral, em algum ponto entre 500 e 5000 clientes, você precisará de um segundo servidor, mas a maioria das pessoas provavelmente encontra isso mais perto de 500. Mas, se você tem 3000 clientes acessando um serviço, provavelmente quer torná-lo horizontalmente escalável para estabilidade além de performance.

AkitaOnRails: Segurança é uma grande preocupação hoje em dia. O Puppet se preocupou desde o início com o procedimento de handshake entre clientes e servidor. Você pode descrevê-lo um pouco? Também existe alguma recipe embutida para hardening de máquinas, por exemplo? Ou pelo menos algum desejo de adicionar tais ferramentas no futuro?

Luke: O Puppet usa certificados SSL padrão para autenticação e criptografia, incluindo uma fase de assinatura de certificados. Por padrão, o cliente gera uma chave e uma requisição de certificado (CSR) e depois envia o CSR para seu servidor. Esse envio, junto com o download posterior do certificado, são as únicas conexões não autenticadas permitidas por padrão.

A partir daí, um humano normalmente precisa acionar a assinatura do certificado do cliente, mas muitas organizações, incluindo o Google, assinam automaticamente os certificados dos clientes porque confiam em sua rede interna.

Quanto ao hardening automático, não há recipes que eu saiba agora, mas é algo que definitivamente me interessa. Anos atrás era grande fã do TITAN, que é um pacote de hardening para várias plataformas *NIX, e foi parte da inspiração para escrever o Puppet — sempre quis uma política de segurança portável e executável.

AkitaOnRails: O puppetmaster usa Webrick por padrão, mas a documentação também descreve o uso do Mongrel ou Passenger. Há ganhos reais em usá-los? É mais para conveniência ou temos melhorias de performance/robustez?

Luke: Nossa, o Webrick é lento. É realmente fantástico para provas de conceito — sobe e roda em minutos. Uma vez que você passa dessa prova de conceito, porém, você realmente precisa mudar para Mongrel ou Passenger. Se você tiver mais de uma conexão concorrente no Webrick, seus clientes começam a sofrer, mas você pode escalar para muito mais com as outras soluções disponíveis.

AkitaOnRails: Há algum caso de clientes sobre o qual você pode falar? Ou seja, mais detalhes sobre o tipo de infraestrutura, dificuldades, ressalvas, boas práticas?

Luke: As possibilidades aqui são bastante abertas. O Google usa o Puppet para manter seu TI corporativo, o que significa que o estão executando em milhares de laptops e desktops — o que é bem diferente. A MessageOne, uma divisão da Dell, é realmente interessante porque seus desenvolvedores têm que enviar código Puppet para gerenciar as aplicações que enviam, então se um app não está aparando seus logs ou fazendo backup de si mesmo, é um bug que o desenvolvedor do app tem que corrigir em vez do sysadmin. Isso realmente ajuda a fazer a ponte entre dev e ops, o que funcionou muito bem para eles.

Fora isso, há muitas histórias e boas práticas, mas temo que isso seria um segundo artigo completo. :)

AkitaOnRails: Já vi Andrew Shafer falar sobre Agile Infrastructure por alguns anos, mas ainda acho que a maioria das organizações de TI desconhece esse conceito. Você pode elaborar o que significa ser Ágil fora do campo de desenvolvimento?

Luke: Acho que a Infraestrutura Ágil tem ainda menos adoção do que o Desenvolvimento Ágil. A grande maioria dos departamentos de TI não mudou as práticas significativamente em anos e está amplamente despreparada para o crescimento no número de servidores que estão experimentando. Eles tentam principalmente escalar adicionando mais pessoas, que chamamos de meatcloud, em vez de escalar suas ferramentas e práticas.

AkitaOnRails: Provavelmente relacionado à pergunta anterior: parece que especialmente após a Sarbanes-Oxley houve um interesse crescente em coisas como ITIL e CoBit. Você já viu implementações bem-sucedidas dessas em infraestrutura no estilo Web? Quero dizer, posso vê-las funcionando em Bancos, Aeroespacial e Defesa, etc., mas não consigo ver funcionando conforme anunciado em um ambiente muito dinâmico como hospedagem de serviços Web. Quais são suas experiências com essa questão?

Luke: Em geral, acho que esses tipos de políticas de alto nível são ótimas para fins regulatórios, mas não são tão boas para realmente resolver problemas. Quanto maior a empresa e mais pública ela for, mais provável é que se importem com ITIL e similares, mas na minha experiência isso não as ajuda realmente a resolver problemas além do aspecto de relações públicas. Você pode ser compatível com ITIL e disfuncional, ou completamente fora de conformidade, mas em ótima forma. Considerando que os melhores padrões são derivados de implementação e boas práticas — o que poucos desses são —, não tenho muita esperança de que eles sejam adotados pelas melhores equipes por aí.

Minha experiência pessoal é que muito poucas empresas perguntam ou se importam com esses padrões, e as que se importam geralmente o fazem de uma forma de checklist — querem garantir que podem marcar coisas como CMDB, mas não estão realmente preocupadas com os detalhes.

AkitaOnRails: Acho que é isso! Muito obrigado por esta conversa!

Desta vez passei algum tempo com Joshua Peek. Foi anunciado recentemente que ele é o novo membro da Equipe Rails Core.

Ele conseguiu a honra por causa do seu duro trabalho para o próximo Rails 2.2 resolvendo o problema de thread-safety no Rails. Por causa do seu projeto no Google Summer of Code, guiado por Michael Koziarski, eles foram capazes de tornar o Ruby on Rails verdadeiramente seguro para threads, o que pode ser muito importante para máquinas virtuais com suporte a threads nativas, como o JRuby.

A parte interessante: ele tem apenas 19 anos e 4 anos atrás sequer era programador. Ele começou no Ruby com o Learn to Program e agora é membro do Rails Core. Vamos conhecê-lo melhor.

AkitaOnRails: Ok, então vamos começar. Primeiramente, seria legal saber mais sobre você. Por exemplo como encontrou Ruby, porque se enganchou nele.

Josh Peek: Como muitas pessoas, eu originalmente encontrei Ruby através do Rails. Na época, eu estava apenas fazendo web design como html, css, js. Eu não tinha experiência de programação. Acho que cheguei a comprar um livro de php, mas nunca fui muito adiante. Então ouvi falar sobre esse tal de “Rails” e fui olhar. Eu rapidamente aprendi que precisava aprender como programar e aprender Ruby, então eu peguei os livros Pickaxe e Agile Web Development with Rails e fui dali.

AkitaOnRails: Isso é interessante, um dos meus objetivos de te entrevistar é porque eu vi que você é bem jovem e existem muitos jovens programadores que acham que aprender Ruby é difícil. E você ainda diz que nunca programou antes de Ruby, então como foi a curva de aprendizado para você?

Josh Peek: Sim, eu tenho agora 19 anos e comecie a programar Ruby cerca de 3 anos atrás. Antes de ler o Pickaxe, encontrei este pequeno livro de programação com Ruby do Chris Pine. Me ajudou muito a entender como programar. A parte mais difícil sobre programação, para mim, foi entender os conceitos de orientação-a-objetos. Realmente é uma coisa que você precisa praticar para realmente entender.

AkitaOnRails: Oh, esqueci de perguntar, de onde você é? E você é estudante de ciências da computação?

Josh Peek: Atualmente estou morando em Chicago, Illinois onde eu frequento a faculdade. E sim, estou estudando Ciências da Computação.

AkitaOnRails: Quando você começou a programar com Rails, o que mais te incomodava, se é que tinha algo?

Josh Peek: Hmm, não consigo pensar em alguma coisa que me “incomodava”. Nunca foi um problema porque você poderia fazer monkey patch ou consertar e liberar para o resto da comunidade Rails.

AkitaOnRails: Então você começou a trabalhr com Rails como freelancer? Você fez alguma gem ou plugin open source também?

Josh Peek: Sim, comecei como freelancer. Tecnicamente ainda sou. Eu costumava publicar toneladas de plugins de Rails. Acho que exagerei um pouco no começo. Realmente não tenho mais nenhum deles por aí, mas seria legal dar uma olhada neles de novo para ver quanto minha visão de programação mudou desde então.

Agora mesmo, todos os meus plugins e códigos atuais estão no github.com/josh. Eu acabo publicando todo projeto pessoal em que estou trabalhando no Github mesmo que não esteja pronto ou eu ache que será útil.

AkitaOnRails: Ok, então ao prato principal, Thread-Safety! Você disse que não estava particularmente “incomodado” por nada no Rails, mas decidiu atacar esse desafio mesmo assim, como tudo isso começou?

Josh Peek: Eu realmente queria participar de um projeto no Google Summer of Code por algum tempo. Entretanto quando fui me inscrever acabei fazendo tudo de última hora, e perguntei pelo Rails Core e algumas idéias apareceram, uma delas foi thread safety.

Eu não estava realmente muito interessado em fazer isso, eu queria mesmo trabalhar no ActiveModel como meu projeto. Entretanto o projeto de thread safe foi o único que foi aceito, então fiquei preso nele. Antes de começar o projeto, eu não tinha experiência alguma com threads.

Eu não sabia sequer o que era um mutex, mas eu aceitei isso como uma boa experiência de aprendizado.

AkitaOnRails: Talvez fosse interessante se você desse um resumo de como o Google Summer of Code funciona. Quero dizer, quais os objetivos, como participar, quão difícil é. Alguns brasileiros provavelmente não estão familiarizados com isso.

Josh Peek: Google Summer of Code é um programa controlado pelo Google que patrocina estudantes para trabalhar em projetos open source. Os estudantes criam propostas de projetos para a organização com quem querem trabalhar, no meu caso foi a Ruby Central, e eles aprovam ou não o projeto.

Você também trabalhar com um mentor da organização. Michael Koziarski (Rails Core) originalmente sugeriu que eu fizesse o projeto e então “demos um jeito” para trabalharmos juntos.

Ao fim do programa, você envia seu código e se você completou o projeto então recebe USD 5.000. E eu acho que USD 500 vai para a organização open source.

AkitaOnRails: E você completou o projeto?

Josh Peek: Sim.

AkitaOnRails: Legal, e quanto tempo durou o programa?

Josh Peek: Acho que cerca de 3 meses.

AkitaOnRails: Ok, de volta à parte mais técnica. Tem uma coisa que me perturba um pouquinho. Claro que é um grande trabalho tornar o Rails thread-safe e isso é uma coisa que muitas pessoas já queriam. Mas por outro lado, o Ruby MRI não tem threads nativas, o que essencialmente significa que eles nunca são executados de forma verdadeiramente concorrente, correto? Talvez outros projetos como JRuby podem se beneficiar? Existe algum benefício para o MRI?

Josh Peek: Correto. JRuby é a única solução de verdade se você quiser concorrência real de threads. Ruby 1.9 suporta threads “reais”, entretanto a maior parte do código interno em C não é thread-safe então existe uma interrupção ao redor desses métodos, mas estou esperançoso que talvez o Ruby 2.0 seja totalmente thread-safe.

AkitaOnRails: Você provavelmente rodou testes para ambos o MRI e JRuby? Notou melhorias de performance/responsividade por causa do novo código thread-safe? Ou ele acaba adicionando um peso extra em vez disso?

Josh Peek: Nossos testes mostraram melhorias pequenas no MRI, entretanto a aplicação que estávamos testando era muito simples. Não tínhamos uma aplicação real que pudéssemos usar para benchmark já que nada era thread-safe na época. JRuby demonstrou algumas boas melhorias, novamente, não era uma aplicação de uso real.

AkitaOnRails: Você mirou apenas para as partes thread-safe ou também encontrou e consertou outros tipos de gargalo no framework? Você provavelmente andou pelo código todo várias e várias vezes e já conhece de cabeça para baixo, certo?

Josh Peek: Eu fiz vários trabalhos em pré-carga de caches no momento do boot. O jeito fácil de sair disso seria simplesmente colocar um mutex ao redor desses caches e pronto, entretanto eu tinha tempo sobrando então re-escrevi uma tonelada de código de ActionView.

Pré-carga significa que estamos construindo o cache no boot de forma que ele não precise ser modificado (ou sincronizado) enquanto estiver servindo requisições e isso deve beneficiar aplicação que não usam threads também.

E é uma grande vantagem para o Passenger, se você estiver usando a funcionalidade de copy-on-write, já que caches construídos no boot do Rails serão compartilhados entre múltiplos processos.

AkitaOnRails: Muito legal, o pessoal da Phusion vai gostar de ouvir isso. E eu sei que algumas pessoas ficarão perdidas ouvindo sobre mutexes, poderia explicar um pouco disso para o público?

Josh Peek: O maior problema de múltiplos threads rodando ao mesmo tempo é a memória compartilhada. Se duas threads tentarem acessar e modificar o mesmo objeto, isso pode causar grandes problemas. Um “mutex” é um tipo de trava que “sincroniza” suas threads de forma que apenas uma thread possa acessar um pedaço da memória de cada vez.

Entretanto, isso tem um impacto de performance porque outras threads precisam parar enquanto uma está acessando a memória compartilhada.

AkitaOnRails: Eu acho que esse é um trabalho incrível, especialmente para o JRuby. Você chegou a conversar com o Charles, Nick ou alguém do JRuby Core? Eu lembro de ter entrevistado o Charles e ele me disse que embora eles estejam avançando muito na otimização do runtime JRuby, a performance de aplicações Rails não estava melhorando tanto, então o próximo passo seria tentar descobrir como modificar o próprio Rails para se comportar melhor. Você ouviu alguma coisa a respeito?

Josh Peek: Sim, nós trabalhamos com o Charles em otimizações específicas de JRuby. Ele foi uma grande ajuda e respondeu todas as minhas questões relacionadas a como o JRuby sincroniza threads e quais operações são atômicas.

Nick Sieger realmente se voluntariou (antes do GSoC) para lidar com o pool de conexões do ActiveRecord. Realmente um grande obrigado ao Nick, eu realmente não tenho experiência em lidar com esse problema e ele fez um grande trabalho com isso.

AkitaOnRails: Ok, embora o Ruby VM não tenha threads concorrentes verdadeiras, ele tem que lidar com recursos concorrentes, nesse caso conexões de banco de dados, então um pool foi necessário. Foi um problema grande de implementar? Foi alguma coisa que você teve que fazer do zero ou havia trabalho anterior com pools de conexão para Ruby?

Josh Peek: Bem, eu acho melhor perguntar isso ao Nick. Mas aqui vai o que entendo sobre isso: a implementação anterior de conexões do ActiveRecord suportava threadas, entretanto era fácil maximizar o número permitido de conexões ao banco se o servidor fosse sobrecarregado.

O pool de conexões basicamente recicla conexões antigas e previne o ActiveRecord de estabelecer muitas. Você pode configurar o máximo de conexões no seu database.yml com a opção “pool”. Ach que o padrão são 3.

AkitaOnRails: E como o papel de mentor funciona? Quero dizer, o Koziarski te guiou em pontos específicos que ele queria que você olhasse?

Josh Peek: O Koz realmente me ajudou a me manter na linha. Ele fez muita auditoria de código, e apontou locais específicos que eu deveria olhar por problemas na grande base de códigos do Rails.

AkitaOnRails: Olhando de fora provavelmente deve parecer ‘fácil’ dizer ‘ok, nós adicionamos suporte thread-safe no Rails’, mas isso não é como uma gem ou plugin externo, você realmente precisa lidar com as entranhas do framework. Como você pode ter certeza que realmente tocou em todas as partes do código que precisavam de medidas de segurança para concorrência?

Josh Peek: Isso é realmente a parte difícil de tornar o código ‘thread safe’: não existe maneira de saber com certeza. Você pode escrever um monte de testes unitários e dizer ‘olhe, eu posso provar que está tudo certo’. Entretanto, os maiores problemas não estão visíveis. De agora em diante, decidimos classificar qualquer novo problema com thread safe como bugs normais.

AkitaOnRails: Você acha que isso já está pronto para lançamento? Ou ainda pretende refinar mais?

Josh Peek: Acho que já está pronto para as pessoas que estavam esperando por um Rails thread-safe. As pessoas precisam começar a auditar e testar suas próprias aplicações para problemas thread-safe e se alguma coisa aparecer, nós vamos corrigir no Core. É realmente difícil testar as coisas a menos que pessoas reais comecem a testar contra aplicações reais.

AkitaOnRails: Pelo menos dizer “Rails não é thread-safe” já não é mais um argumento bom o bastante para não se usar Rails. Isso deve calar os críticos. Esse Rails 2.2 será interessante, derrubando algumas críticas. A outra é “Rails não suporta internacionalização”, graças a Sven. O que você gosta mais na próxima versão do Rails?

Josh Peek: Meu próximo pequeno projeto no Rails é mudar para usar Rack. O Rails 2.2 incluirá um processador Rack que o deixa usar qualquer servidor Rack, entretanto ainda não estamos mudando totalmente para Rack. No 2.2 o Rack será opcional.

O ./script/server ainda rodará o antigo processador CGI. Espero ver CGI deprecado na próxima versão para que possamos ter o Rack somente lá pelo 3.0.

AkitaOnRails: Quais os benefícios de ir para Rack? Pode não ser muito óbvio para muitas pessoas sobre porque mudar código que já está funcionando (a parte CGI).

Josh Peek: Deve haver alguns benefícios de performance, entretanto isso não seria suficiente para convencer. Agora mesmo temos toneladas de hacks de CGI no Rails. Isso deve limpar as coisas um pouco.

O que eu realmente gosto é a interface padronizada para Rails. Isso significa uma API mais universal para escrever plugins relacionados a ActionController que funcionarão com qualquer framework compatível com Rack. Eu espero que isso significa mais plugins Rails que funcionarão com Merb e vice-versa.

AkitaOnRails: Tendo terminado seu projeto GSoC lhe deu as chaves para o repositório oficial do Rails, correto? Como o Rails Core se organiza? Cada pessoa é responsável por alguma parte em particular, ou todos olham um pouco de tudo?

Josh Peek: Parece que cada um tem suas pequenas responsabilidades dependendo no que estavam trabalhando. Já que eu reescrevi uma tonelada do ActionView, devo assumir qualquer problema ou tickets relacionados com isso. Não acho que qualquer um tenha uma área pré-determinada. As pessoas mudam seus interesses o que está bem.

AkitaOnRails: Mas agora você pode dar ‘git push’ em qualquer coisa no Edge? E aliás, você mencionou que mexeu bastante no ActionView, mas o que exatamente mudou?

Josh Peek: Sim, eu já tinha acesso de commit um pouco antes do projeto GSoC (pouco antes de mudarmos para git). O ActionView foi refatorado para suportar o esquema de pré-carga que falei antes. Então templates ERB são pré-compilados e colocados em cache no boot em vez de em tempo de execução.

AkitaOnRails: Então, em 3 anos você foi do zero para o Rails Core, realmente o “problema de thread-safety” e ainda conseguindo tempo para estudar e trabalhar em projetos como freelance. Como se sente, olhando em retrospectiva? Alguma vez pensou que fosse contribuir tanto?

Josh Peek: 4 anos atrás, eu realmente nunca me vi programando. Eu definitivamente nunca pensei que acabaria no Core Team do Rails.

AkitaOnRails: Depois de tanto que aprendeu, quais as áreas em computação que te interessam mais? Desenvolvimento web, ou outra área como compiladores, sistemas operacionais, etc? O que pretende fazer agora?

Josh Peek: Eu ainda adoro desenvolvimento web. Eu recentemente tentei programação de iPhone, mas ainda não sei como me sinto sobre isso.

Eu gostaria de tentar coisas de mais baixo nível. Eu ainda não tive a chance de usar a API C do Ruby e ouvi dizer que é legal. Ultimamente tenho feito muito trabalho em um projeto javascript que será anunciado em breve e será open source.

AkitaOnRails: Oh, e falando nisso, você também é usuário de Mac? :-) E eu acho que é isso! Alguma consideração sobre o que falamos?

Josh Peek: Sim, tenho usado Macs por cerca de 6 anos já. Não sou um desses que mudou depois de descobrir Ruby :-)

E acho que é isso … eu fui puxado para falar no RubyConf este ano, pela coisa do GSoC. Então vocês provavelmente vão ouvir sobre “thread safety” por lá. Provavelmente é a última vez que vou falar sobre Rails e threads de novo.

Obrigado pelas questões.

AkitaOnRails: Ok. Vamos começar. Primeiramente, obrigado pelo seu tempo. É curioso porque temos como 5 horas de diferença. Você está em Paris agora, mas entendo que é da Argentina. Pode nos contar o que está fazendo atualmente?

Luis Lavena: Sim, curioso mesmo. Agora sou Diretor Técnico de uma agência de design e interação com escritórios em NY e Paris. Meu trabalho é fazer a ponte entre o campo de design e o tecnológico, principalmente no desenvolvimento de aplicações web.

Sou da Argentina, moro lá, família e amigos. Agora me mudei por alguns meses para impulsionar alguns desenvolvimentos e dar os primeiros passos na nova organização.

Sou de uma pequena província chamada Tucumán, na área noroeste da Argentina (1200 km de Buenos Aires, para ser exato).

AkitaOnRails: Incrível. Você já foi ao Brasil? Tem contato com outros Railers da América Latina?

Luis Lavena: Apesar de o Brasil ser tão perto da Argentina, nunca fui lá, o que é uma pena. Tenho vários amigos que moraram lá ao longo dos anos.

Mantenho contato com vários Rubistas e Railers da América Latina, mas principalmente com os da Argentina por causa de vários encontros que tivemos ao longo dos anos em que a lista RubyArg vem funcionando.

AkitaOnRails: Tenho muito interesse em entender como os Railers estão se organizando na Argentina, já que nós, no Brasil, somos uma comunidade em crescimento também. Você vê novos programadores indo direto para Rails ou é o movimento habitual de Java/outros para Rails? As empresas estão adotando, ou Ruby/Rails ainda tem um longo caminho a percorrer por lá também?

Luis Lavena: Bem, há um número enorme de desenvolvedores que vieram de Java e dotNET (principalmente Java) e estão experimentando Rails. Também há muitos desenvolvedores que usam Ruby para tarefas administrativas ou até para criar jogos.
As empresas de desenvolvimento de software ainda precisam adotar Ruby/Rails nos seus negócios. O maior problema é a falta de suporte na forma de empresas como a Sun ou alguns serviços de consultoria para Java — ou mesmo Microsoft.

AkitaOnRails: Voltando ao passado, como você começou na programação em geral? Estudou ciência da computação, ou chegou até lá de outra forma? E, finalmente, como você tropeçou no Ruby e no Rails?

Luis Lavena: É engraçado. Comecei a programar em 1989, brincando com sprites e GOTOs em BASIC num computador Z80.

Oficialmente não terminei minha graduação em CC, porque trabalho e diversão me distraíram. Conheci o Ruby pela primeira vez em 2001, adorei a sintaxe, gostei da sua verbosidade, mas não estava maduro o suficiente para as minhas necessidades, pelo menos não no Windows.

Embora eu tenha usado Python por muitos anos, internamente usava Ruby para gerenciar várias coisas, desde scripts simples até rake tasks que nos ajudavam a construir nossas ferramentas.

Com Rails foi diferente — começamos a procurar alternativas ao Zope e apostamos no Rails naquela época (versão 0.10 ou 0.12, se a memória não me trai).

Posso dizer que não me arrependo da aposta no Rails naquela época.

AkitaOnRails: É muito interessante ver profissionais como você saindo da zona de conforto em direção ao “desconhecido” como Ruby e Rails. A maioria dos programadores é muito defensiva e até agressiva na busca de justificativas para não usar nenhum dos dois. Você se sentiu assim na época? O que te levou ao Ruby?

Luis Lavena: Bem, estou acostumado a mudar de linguagens conforme minhas necessidades.
Considere que nossa primeira escolha foi a era pré-J2EE ou o dotNET. Analisamos o que nos daria melhores soluções a longo prazo e decidimos evitá-los.

As coisas de Java pareciam — e ainda parecem até hoje — caras para os negócios. A Argentina não é um país onde você vai encontrar clientes com orçamentos enormes para cobrar o custo de usar ferramentas desenhadas para outros mercados.

Bancos e similares podem se dar ao luxo de ter tudo rodando com J2EE, mas isso não funciona quando você tenta ser menor e ágil — baseado principalmente em experiências com o fluxo do mercado na Argentina.

AkitaOnRails: É ainda mais desafiador considerando que você decidiu que queria Ruby no Windows, provavelmente não encontrou nada razoável e decidiu atacar o problema você mesmo. Foi assim que aconteceu?

Luis Lavena: Fui obrigado a usar Windows por muitos anos, principalmente relacionado ao desenvolvimento de hardware no campo de transmissão de vídeo. Além disso, sou usuário de BSD e Linux, até brinquei alguns anos com Macs e ultimamente com OSX.

Então essa restrição me forçou a construir a maior parte das minhas ferramentas em torno dessa limitação.
O Ruby me permitiu aproveitar essa limitação sendo expressivo, o que me tornou mais produtivo nessa área.

Ruby não é capaz de lidar com meus requisitos principais para processamento de vídeo, mas ainda alimenta 70% do meu ambiente, junto com software Open Source e Freeware.

Usei Ruby por tanto tempo que pensei que a comunidade, agora que estava crescendo, talvez valorizasse a experiência e a disposição de ajudar nesse cenário específico.

Então, em vez de continuar coçando minha coceira nas sombras, decidi contribuir de volta e ajudar outros que buscam a mesma coisa. Pode dizer que estou tentando equilibrar meu karma.

AkitaOnRails: Os americanos provavelmente não entendem isso, mas em países emergentes como o Brasil, as pessoas não têm muita escolha. A maioria não tem instrução suficiente (cof inglês cof) e encontra muitas barreiras. O último recurso para todo mundo é o Windows. Acho que é a mesma coisa na Argentina. Os Railers aqui não simplesmente migram para Macs ou Linux — diria que pelo menos 90% de todos os desenvolvedores estão presos ao Windows por um motivo ou outro. É a mesma coisa na Argentina, imagino?

Luis Lavena: Mesmo que eu não goste, tenho que concordar. Felizmente as universidades começaram a mudar isso alguns anos atrás, dando palestras e sendo mais abertas à comunidade Linux, que cresceu muito.

Ainda assim, há muitos usuários e desenvolvedores presos em ambientes corporativos/médios ou que precisam rodar Windows por algum hardware proprietário ou similar.

Então, nós (como comunidade) não conseguimos chegar a esses desenvolvedores sem sermos mais abertos ou fornecer ferramentas que facilitem o caminho entre o ambiente atual deles e ferramentas alternativas.

AkitaOnRails: Mas por algum motivo parece haver quase zero interesse da comunidade em suportar Ruby no Windows. Quer dizer, existem pessoas como você, alguns desenvolvedores de RubyGems que se dão ao trabalho de disponibilizar binários para win32, mas parece não ser suficiente. Como o One-Click Ruby Installer começou? Você o criou ou herdou?

Luis Lavena: Sim, concordo, mas não posso culpá-los — afinal, cada um coça sua própria coceira. ;-)

Herdei o One-Click Installer do Curt Hibbs, que também herdou do Andy Hunt e outros contribuidores.

A verdade é que por muitos anos usei minha própria versão do Ruby, compilada internamente, então tínhamos controle sobre ela. Não a modificávamos de forma alguma — gostamos de ter todo o processo documentado e automatizado, para poder identificar os componentes específicos atualizados que introduziram conflitos.

O One-Click Installer, por outro lado, depende de builds feitos pelos atuais desenvolvedores e mantenedores do ruby-core, o que torna o processo de encontrar as dependências corretas um pouco difícil. Esse build também impôs outros problemas, mas isso exigiria mais tempo para explicar.

AkitaOnRails: Haha, quero mergulhar nas partes mais técnicas para que as pessoas possam entender melhor a situação atual no Windows. Quão diferente é o Ruby no Windows comparado ao Ruby no Linux? A coisa mais óbvia é que qualquer Gem com Extensões C sem binários adequados para Windows vai falhar. Tentar executar comandos shell vai falhar e o RubyInline também. O que mais?

Luis Lavena: Hehe, isso é só a ponta do iceberg. Deixe-me mostrar um exemplo. Suponha que você tem um pacote ABC construído para sua distribuição atual de Linux. Essa versão específica de Linux está vinculada a um runtime comum que cuida de comandos básicos como manipulação de arquivos, console, etc. Isso é geralmente chamado de CRT (C Runtime) e no Linux é a glibc.

Então sua distribuição de Linux está vinculada a esta versão glibc A.B.C. Se sua distribuição atualiza a versão da glibc (por exemplo de 2.2 para 2.5), você é forçado a:

1. atualizar todos os seus pacotes instalados, ou
2. recompilar tudo do zero.

Já ouvi de algumas dessas atualizações dando tão errado que os usuários são forçados a começar do zero. O Windows, por outro lado, não pode quebrar 2 bilhões de aplicações por causa de uma mudança de CRT, então mantém versões antigas e preserva a compatibilidade no arquivo MSVCRT.dll (onde a versão base é 6.0).

Uma vantagem do Windows é que você pode ter vários CRTs coexistindo no seu sistema operacional. A parte ruim é que você não pode vincular com segurança a um CRT e usar componentes que se vinculam a outra versão sem se preocupar com segfaults e afins.

Tentei condensar essas informações num post algum tempo atrás. Como você pode ver, a falta de ferramentas de desenvolvimento não é o pior problema no desenvolvimento Windows.

AkitaOnRails: Interessante. E outra coisa é o compilador Visual Studio vs MinGW. Você pode nos dar uma ideia de por que escolheu o MinGW? É só porque o VS é comercial e os desenvolvedores teriam que pagar?

Luis Lavena: O Visual Studio é ótimo, mas só quando você pode pagá-lo. As versões gratuitas carecem de algumas coisas muito úteis, como a Profile-Guided Optimization (PGO) que está sendo usada para construir binários Windows do Python, por exemplo.

O problema com o VS, mesmo as versões gratuitas, é que você não tem permissão de distribuí-las. Acho que é até ilegal vincular à URL/página de download. Então, mesmo para o nosso projeto de sandbox automatizado, o Visual Studio precisaria ser baixado, instalado e configurado manualmente.

Felizmente nas últimas versões você não precisa instalar o Platform SDK, que era 1GB. As versões do VS se vinculam apenas à versão mais recente do MSVCRT, o que nos força a relinkar cada biblioteca da qual o Ruby depende (e o código fonte do Ruby depende de muitos externos).

Além disso, o Ruby não usa a versão safe do CRT para funções de cópia de strings, então você precisa de flags de compilador só para evitar isso… Então depois de semanas de muito trabalho para compilar com VC8 e todas as dependências, você acaba com algo que tem performance quase igual, já que não há ganho de performance — mas agora você tem menos cabelos.

O MinGW, por outro lado, era mais próximo de um ambiente Linux, então a maioria das ferramentas funcionava imediatamente. A parte boa é que não precisávamos compilar todas as dependências com ele, já que por padrão tudo se vincula ao MSVCRT (o CRT padrão no Windows). O MinGW também fornece algumas ferramentas de cross-compilação que permitem construir, usando o ambiente Linux, bibliotecas compartilhadas (dll) e executáveis para Windows.
Considero isso uma vantagem, não sei o que os outros pensam.

AkitaOnRails: Uau, isso é realmente avassalador e recomendo a qualquer pessoa interessada nos detalhes que dê uma olhada no seu blog. Mas tudo isso dito, agora você tem tudo no lugar, um processo adequado e tal, presumo. Se eu sou um desenvolvedor C Windows e quero contribuir, onde devo ir primeiro para saber quais ferramentas usar, como compilar as coisas, etc.?

Luis Lavena: Essa é a parte boa! Gordon Thiesfeld e eu temos trabalhado em dois pacotes para o novo One-Click Installer: Runtime e Developer Kit.

O Runtime vem com o mínimo de Ruby+RubyGems para você começar e também pode ser usado como módulo para outras instalações. O DevKit fornece o ambiente MinGW para você criar extensões Ruby ou mesmo instalar aquelas que não são pré-compiladas para Windows mas são fáceis de obter.

Este DevKit não vai apenas facilitar o trabalho com Ruby no Windows (e dar acesso a algumas ótimas Rubygems), mas também permitir que você contribua de volta para o projeto Ruby. Como? Fácil — o projeto Ruby Installer (no Github) é auto-hospedado. O que isso significa? É possível replicar nosso ambiente de desenvolvimento em qualquer lugar, hackear suas mudanças ou até debugar o próprio código C do Ruby e contribuir de volta para a comunidade. Temos feito isso por vários meses e está funcionando. Que legal, né?

AkitaOnRails: Parece incrível. Não sabia disso e aposto que muitos desenvolvedores também não. Espero que os desenvolvedores C que leram isso possam se atualizar agora. Outro detalhe: RubyGems. Quão difícil é portar uma Gem com Extensões C para fornecer um binário Windows quando você a instala?

Luis Lavena: Oh, isso requer que alguns desenvolvedores não caiam em truques específicos de plataforma para fazer suas ferramentas funcionarem. Um exemplo, que também é uma má prática, é usar caminhos hard-coded…

Outro é depender da existência de algumas ferramentas externas que às vezes não estão disponíveis ou os desenvolvedores/usuários não instalaram. E não estou falando de problemas de plataforma Linux-Windows — mesmo entre distribuições Linux isso é um problema.

Instalando Gems no RubyInstaller de Luis Lavena no Vimeo.

AkitaOnRails: Então depende bastante da qualidade da Gem original, certo? Quanto mais limpo o código, mais fácil de portar, claro. Mas seu DevKit fornece alguns atalhos para isso? E quanto ao RubyInline, ele simplesmente quebra?

Luis Lavena: Sim, aprendi ao longo dos anos que você não deve supor nada sobre o ambiente em que sua aplicação vai rodar — assim você evita esses erros.

Felizmente o RubyInline funciona bem com o Ruby Installer (One-Click Installer que usa MinGW) há algumas versões atrás — graças ao Ryan Davis por incluir esses patches.

O build atual em VC6 do One-Click Installer não é seguro, pois você precisa do VS6 para funcionar, que não está mais disponível. Já ouvi de usuários aproveitando Sequel, Ambition e ImageScience no Windows graças a esses patches.

AkitaOnRails: Me corrija se estiver errado, mas não é uma forma de incorporar snippets de código C misturado com código Ruby? Isso significa que ele compila nativamente esse snippet para executar? Como consegue isso num ambiente Windows que não tem compiladores por padrão?

Luis Lavena: Conseguimos incluir alguns patches no Hoe e no RubyInline que “empacotam” as extensões pré-compiladas dentro das gems, então os usuários não precisam de um compilador nesses casos.

De qualquer forma, agora usar o build VC6 do Ruby exige mão de obra para manter essas gems e acompanhar os novos lançamentos, o que leva tempo. Até agora era só eu na jogada (já que temos algumas licenças VC6). Construir tudo para todo mundo é um fardo que estou ansioso para transferir para o DevKit.

AkitaOnRails: São vocês que mantêm as versões Windows das Gems ou cada desenvolvedor cuida do seu próprio projeto? Há um repositório central para Gems prontas para Windows? O DevKit já está disponível, aliás?

Luis Lavena: Para alguns projetos sou o único que mantém gems para Windows; para outros apenas contribuí com patches e outros usuários gerenciam os builds. Não há repositório central para gems Windows porque quero que o RubyForge seja o central.
De qualquer forma, estou publicando as específicas do MinGW baseadas em forks do github aqui:

gem list --remote --source http://gems.rubyinstaller.org

O devkit já está disponível, mas estamos embrulhando-o num bom pacote de instalação Windows. Você pode sujar as mãos e pegar o projeto sandbox do Github para ter seu ambiente, ou simplesmente baixar os pacotes.

AkitaOnRails: Então, no que diz respeito a ferramentas e processos, você está fazendo um ótimo trabalho. Mas então há o código Ruby que, por si só, é um grande desafio pelo que ouço. Você me mencionou que nem parece C. Quais são os maiores problemas? Técnicos ou conseguir ajuda da lista ruby-core, ou ambos? E quanto aos test suites, como você está eliminando bugs de compatibilidade?

Luis Lavena: Para ser honesto, às vezes olhar para o código C do Ruby me dá dor de cabeça. Há muitas macros, definições e condições de macro que aparecem no meio de um bloco if..else... A parte mais difícil, além de rastrear o bug, é obter feedback do ruby-core. Várias vezes expressei minhas preocupações em listas de e-mail, IRC e no meu blog.

Várias vezes perguntei se era OK ter alguns erros nos unit tests do próprio Ruby e às vezes obtive respostas, mas às vezes não. Felizmente não precisamos mais basear nossa qualidade de testes nos unit tests incluídos no Ruby. Começamos a encontrar problemas com a implementação do Ruby no Windows usando as Ruby Specs criadas pelo pessoal do projeto Rubinius e que a maioria das implementações (IronRuby e jRuby) contribui ativamente e usa como base de seus interpretadores.

AkitaOnRails: Falando nisso, RubySpecs — quão longe está o Ruby no Windows de passar por elas? Ou já passa?

Luis Lavena: Bem, é uma tarefa grande. Primeiro começamos fazendo o MSpec funcionar corretamente no Windows, já que o RubySpec requer alguma auditoria para remover caminhos hard-coded. Então começamos a adicionar guards em torno de coisas que não são suportadas ou não funcionam no Windows no MRI.

Isso leva mais tempo já que precisamos revisar os resultados em cada plataforma, mergulhar na documentação do Ruby (que às vezes é insuficiente) ou respirar fundo e olhar para o código C para descobrir o que está fazendo.

Se tivéssemos mais mão de obra, talvez conseguíssemos terminar de proteger todo o código e ter specs rodando limpas no Windows. Agora há muitas que simplesmente falham ou causam segfault.

AkitaOnRails: Você deveria documentar esse processo para que as pessoas possam ajudar, se ainda não o fez :-) Agora falando de coisas mais práticas: Ruby no Windows, hoje, é um runtime viável para rodar apps Rails no Windows? Mesmo apps em produção? Você trabalhou com Zed Shaw no Mongrel para Windows, certo? Experimentou o mais recente suporte FastCGI da Microsoft para IIS?

Luis Lavena: Hehee, documentação, documentação — é totalmente superestimada. Planejamos ter vários screencasts no site do RubyInstaller, mas continua como 'em breve' por enquanto.

Não só você pode desenvolver aplicações Rails no Windows (como eu também faço), mas conheço várias empresas que rodam lado a lado com IIS ou mesmo Tomcat.

Mesmo 2 anos após o Zed tê-lo criado, o Mongrel ainda domina o cenário de servidores web Ruby. Não fiz muito ao próprio Mongrel, já que o Zed criou algo que funcionava no Windows com pequenos ajustes.

Criei algo para rodar o Mongrel como serviço (mongrel_service), o que ajudou várias pessoas a introduzir Ruby e Rails em seus ambientes corporativos, inclusive conversando com servidores MSSQL.

Pessoalmente não testei o suporte a FCGI no IIS, mas fui eu quem o corrigiu para ser incluído no One-Click Installer para que alguns usuários pudessem aproveitá-lo. Podemos dizer que funciona.

AkitaOnRails: Sobre performance, o Windows parece ter uma condição inerente: na mesma máquina quando inicio, digamos, um simples IRB no Windows, depois dou dual boot para Linux e rodo, parece abrir muito mais rápido (não é exatamente um experimento científico :-). Qual é sua experiência com a performance do Ruby no Windows?

Luis Lavena: Há problemas de performance relacionados ao código C gerado pelo compilador e problemas relacionados ao SO e I/O gerenciados por ele. Carregar o IRB no Windows pode estar exigindo RubyGems em segundo plano, que por sua vez precisa varrer e carregar todas as especificações de gems. Tento manter RUBYOPT=rubygems fora das minhas variáveis de ambiente.

AkitaOnRails: Aliás, por que tenho a impressão de que vejo RUBYOPT=rubygems sendo recomendado em todo tutorial Windows que vejo?

Luis Lavena: RUBYOPT=rubygems é a parte da mágica que devemos evitar.
No Linux, se você começa a criar um script e precisa de uma gem, começa com:

require 'rubygems'
require 'some_gem'

O mesmo deveria ser feito para Windows. Não é doloroso, é boa prática. RUBYOPT é um atalho que não gosto — nunca vi uma distribuição Linux que ative isso por padrão e não gosto que seja configurado no Windows (é claro, esse é meu ponto de vista pessoal).

Então, para evitar cair em procedimentos de teste padrão, continuo usando um solver de sudoku simples mas bom que exercita recursão, arrays e condições da VM em vez de ser I/O bound.

Você pode ver isso, com resultados interessantes no meu blog (veja a seção "Rubinius, RubySpecs, and speed." do post).

O principal é que o VC6 torna tudo lento. Depois você tem as coisas I/O bound (I/O no Windows não é tão bom quanto no Linux). Considero o build padrão VC6 do Ruby no Windows dolorosamente lento. Por outro lado, o do MinGW é mais ágil, mas ainda acho que há um longo caminho a percorrer para melhorias.

AkitaOnRails: Então, no geral, Ruby no Windows está sempre evoluindo — o que é ótimo —, roda bem no Windows — o que é notável —, mas poderia usar um pouco mais de ajuda, certo? Você acha que mais desenvolvedores C Windows ajudariam? Ou seja, adicionar mais mãos ajudaria a melhorar a qualidade?

Luis Lavena: Definitivamente!

AkitaOnRails: Que tipo de desenvolvedores — o que uma pessoa deveria saber para ajudar?

Luis Lavena: Não sei se o "core" do Ruby vai aceitar isso — ultimamente só ouço a palavra fork em torno do Ruby MRI. Além disso, podemos corrigir bugs na implementação Ruby para Windows, mas não podemos melhorar muito a qualidade já que essas mudanças afetariam outras plataformas também.

A parte ruim é que não há separação clara por plataforma de código específico — tudo é uma série de macros e condições de compilação que dificultam o rastreamento (para desenvolvedores não-masoquistas).

AkitaOnRails: O que me lembra o pessoal da Phusion com a sua Enterprise Edition, que é um fork do MRI. Você tentou analisar os patches de GC copy-on-write deles? Talvez incluí-los na versão Windows? O Ruby no Windows em si é um "fork". Você acaba tendo que sincronizar seu trunk com o deles — é assim que funciona?

Luis Lavena: Honestamente não tive tempo de analisar a Enterprise Edition, mesmo tendo acompanhado todos os posts e a discussão desses patches no ruby-core. O engraçado é que os últimos lançamentos da branch Ruby 1.8.6 estão me dando dores de cabeça (mais do que olhar para o código C). Eles não conseguem nem completar os self-tests e causam segfault com algumas extensões como a gem mysql.

AkitaOnRails: Sim, tem gerado muito barulho na comunidade — e com razão. Espero que possam resolver logo. Bem, acho que já tomei muito do seu tempo. Há algum assunto que você gostaria de abordar, ou pelo menos alguma mensagem para a comunidade brasileira mais jovem?

Luis Lavena: Sim — não tenha medo de fazer perguntas, não se envergonhe de usar Windows como plataforma. Você pode realizar ótimas aplicações usando Windows e pode se infiltrar mais facilmente em ambientes corporativos com ele.

AkitaOnRails: Ah, o que me lembra de uma última pergunta que todo mundo me faz o tempo todo — e vou repassar para você, já que é um desenvolvedor Windows: quais são suas ferramentas preferidas para editar projetos Ruby/Rails?

Luis Lavena: Uso principalmente coisas gratuitas ou open source, então tenho usado o Komodo Edit (não Pro) e o Programmer Notepad, já que às vezes os uso para trabalhar com código C, FreeBASIC e Assembler para hardware embarcado.

Ultimamente tenho usado um editor leve chamado Intype que vem com alguns bundles para imitar o TextMate, mas realmente não aproveito muito. Usei NetBeans por um tempo, mas depois de 500MB simplesmente fechei :-)

AkitaOnRails: Haha, e o que você recomendaria para um programador Rails iniciante?

Luis Lavena: Para começar, o NetBeans é bom, mas com a prática aprenderão que até o notepad é suficiente para programar.

(PS: Já estamos incluindo os patches da Enterprise para os últimos problemas no build MinGW! :-)

AkitaOnRails: Haha, certo. Bem, acho que é isso. Espero que isso alcance um público mais amplo e chame atenção dos desenvolvedores Windows por aí. Muito obrigado!

Luis Lavena: Obrigado a você, Fabio.

AkitaOnRails: Então, deixa eu explicar primeiro que meu principal objetivo ao entrevistar pessoas de alto perfil como você é trazer informação de qualidade para nossa crescente comunidade Rails no Brasil. É sempre bom perguntar sobre seu background, como você chegou ao Rails e qual foi sua experiência com ele.

Blaine Cook: Comecei com Rails num projeto pessoal pequeno em dezembro de 2004, depois que Evan Henshaw-Plath (rabble) ficou muito animado com Ruby e Rails.

Logo depois, comecei a trabalhar no Odeo. Gosto muito de Rails e tive uma experiência excelente com ele. Construir web apps costumava ser um parto (ou seja, uma chatice) porque você acabava reconstruindo as mesmas peças repetidamente.

O Rails resolveu isso. Já existiam frameworks antes, mas o Rails reformulou a questão de forma humana, e é isso que vemos em todos os outros frameworks que vieram depois.

AkitaOnRails: E o que você fazia antes do Rails? Java Enterprise? Coisas Microsoft? Outros projetos open source?

Blaine Cook: Fazia principalmente PHP e Perl, no contexto de projetos open source e trabalhos de consultoria.

AkitaOnRails: Então Odeo e Twitter são seus maiores projetos em Rails? Antes de entrar no Twitter, pode nos contar como foi seu trabalho no Odeo?

Blaine Cook: Claro — o Odeo foi OK. O grande problema lá era foco. O podcasting ainda não tinha provado seu valor (e a forma que o podcasting assumiu hoje é bem diferente do que as pessoas imaginavam em 2004/2005), então era difícil ganhar tração com o produto.

Construímos coisas incríveis, muitas das quais estão só agora virando produtos. Coisas como mixagem multilista na web, mensagens em vídeo (como o seesmic), etc.

AkitaOnRails: É um assunto paralelo interessante: podcasting. Faço um podcast brasileiro de Rails com um amigo e hoje em dia as pessoas estão muito acostumadas com podcasts. Qual era a visão 3, 4 anos atrás sobre o que o podcasting se tornaria?

Blaine Cook: Acho que é razoavelmente parecida, mas parece que a maior tração (ou seja, ouvintes) do podcasting veio de programas de rádio que buscavam distribuição mais ampla.

Havia um sentimento de que o podcasting seria muito mais popular entre blogueiros em geral. Todo mundo ia ter um podcast.

Mas na realidade é um meio com muito menos publicadores do que o blog.

AkitaOnRails: Você ajudou a fundar o Odeo, ou seja, você foi um dos criadores? Ou foi contratado para resolver o problema deles? E por que você saiu do Odeo?

Blaine Cook: Não — entrei no Odeo alguns meses depois que o desenvolvimento tinha começado. Na verdade nunca saí formalmente do Odeo — o produto foi vendido, e a empresa continuou como Obvious. O Twitter era um projeto paralelo dentro do Odeo.

AkitaOnRails: Ok, e o Twitter é enorme hoje. Você pode nos dar uma ideia de como surgiu toda a ideia do “O que você está fazendo”? Na época você achava que se tornaria um sucesso tão grande?

Blaine Cook: O Twitter começou como um projeto paralelo no Odeo, mas na verdade era uma ideia que o Jack já vinha desenvolvendo de diversas formas há vários anos.

Ele e Noah Glass (o fundador do Odeo) criaram uma subempresa dentro do Odeo para trabalhar nisso, na primavera de 2006. Inicialmente, eu detestei a ideia, principalmente porque era para ser só via SMS.

Olhando para trás, é difícil dizer, mas na época eu diria que o Twitter tinha poucas chances de dar certo. Acho que o sucesso teve muito a ver com sorte e abertura.

AkitaOnRails: Então, talvez um dos maiores motivos para o sucesso do Twitter fosse também seu calcanhar de Aquiles? Ou seja, o acesso via API que ele tem hoje?

Blaine Cook: Sim, com certeza.

AkitaOnRails: Entrando no assunto espinhoso: é bastante óbvio que o Michael Arrington não gosta do Twitter. E especialmente parece que ele tem algo contra você pessoalmente, pelo menos considerando o tom dos artigos dele no Techcrunch. Você pode comentar isso?

Blaine Cook: Não muito — não sei por que ele tem esse ranço. É levemente irritante, mas no fim das contas faz o Techcrunch parecer mais uma fofoqueira do que um veículo de notícias respeitável. Perda dele.

AkitaOnRails: E não só isso: parece que parte da mídia de tecnologia quer correlacionar a instabilidade do Twitter com o fato de que parte do front-end é movido a Ruby on Rails, daí a discussão “Rails Escala?”. Como Railer, me parece óbvio que relacionar Rails e instabilidade gera muitos pageviews. Você acha que é isso mesmo?

Blaine Cook: Acho que é pelo menos parte disso. Pageviews são uma atração enorme, obviamente.

AkitaOnRails: Talvez fosse útil alguém como você explicar para nossa audiência a diferença entre ‘performance’ e ’escalabilidade’, já que a maioria das pessoas parece não saber a diferença entre as duas.

Blaine Cook: Performance e escalabilidade são coisas muito diferentes. Performance é como o limite de velocidade — é uma questão de quão rápido você vai do ponto A ao ponto B. Nesse caso, estamos falando de quão rápido você consegue renderizar e entregar uma página ao usuário.

Escalabilidade é uma questão de quantos usuários você consegue atender. Estradas, por natureza, não escalam — quando estão cheias, você tem engarrafamento. Em arquiteturas web, o que buscamos são sistemas que expandem (geralmente adicionando mais hardware) para lidar com mais tráfego.

Obviamente estão relacionadas — se você tem um engarrafamento, o limite de velocidade efetivo é menor que o teórico. Mas aumentar o limite de velocidade não resolve engarrafamentos.

Há várias formas de diminuir o congestionamento — adicionar mais faixas na estrada, incentivar as pessoas a usar transporte público, ou melhor ainda incentivá-las a trabalhar mais perto de casa.

Da mesma forma, existem muitas técnicas para tornar sites mais escaláveis, e a maioria delas não envolve tornar as coisas muito mais “rápidas”.

AkitaOnRails: Ótima explicação. O Twitter se envolveu em várias controvérsias desde o ano passado, e acho que você não estava envolvido na maioria delas, mas talvez possa lançar luz sobre essas questões já que nem todo mundo acompanha todas as notícias. A primeira foi aquela entrevista em que Alex Payne reclamou que o Rails não suportava múltiplos bancos de dados. David Hansson respondeu irritado. Depois o Dr. Nic iniciou uma solução. Você pode explicar esse assunto para nossa audiência?

Blaine Cook: Claro — é verdade que o Rails não suporta múltiplos bancos de dados out of the box, mas isso é facilmente resolvido. Acho que a entrevista com o Alex não entrou nos detalhes e deturpou nossos desafios.

Se fosse apenas uma questão de suportar múltiplas conexões com banco de dados, isso seria facilmente resolvido. O problema real era muito mais complexo e tinha a ver com sharding customizado para nosso dataset específico.

Eran Hammer-Lahav tem uma série excelente (partes 1, 2, 3) em que ele descreve alguns dos desafios associados a construir sites de microblogging para escalar.

Nada do que ele descreve no artigo é difícil de fazer com Rails. De fato, acho que o David (Hansson) está errado quando diz que Rails não é flexível — ele é muito mais flexível do que a maioria dos outros frameworks.

AkitaOnRails: Certo. E a outra controvérsia recente é, claro, por causa do TechCrunch de novo, onde dizem que o Twitter tem apenas meia dúzia de servidores e é por isso que cai com frequência. Você pode descrever grosseiramente como é a arquitetura de hardware do Twitter?

Blaine Cook: O Twitter tem muitos servidores, definitivamente mais do que meia dúzia. Não posso entrar em mais detalhes sobre o hardware, mas posso dizer que o back-end é um sistema assíncrono baseado em mensagens. O Starling (o servidor de filas que eu escrevi e que o Twitter lançou em janeiro) é o mecanismo usado para passar mensagens entre processos.

O maior problema é que o Twitter lida com muitas requisições de API caras devido ao polling frequente necessário para manter os tweets dos seus amigos atualizados. O grande desafio era encontrar uma forma barata de tornar essas requisições caras mais baratas.

Usamos memcache extensivamente e tínhamos um monte de caching em operação há mais de um ano, mas não era suficiente.

AkitaOnRails: No ano passado, Alex e Britt falaram na RailsConf sobre Scaling Rails e parecia que o problema do Twitter logo acabaria. Era principalmente sobre caching e otimizações do tipo, e uma das mensagens principais era “faça cache de tudo”. Vi você falando este ano sobre database sharding e como é diferente arquitetar para 1 mil pessoas e para 1 milhão e que não dá pra prever o que fazer antes. O Twitter ainda cai às vezes, então o que mudou entre o ano passado e agora em relação a Scaling Rails?

Blaine Cook: Sim — sabíamos há muito tempo que o sharding de banco de dados era importante, mas por várias razões não conseguimos avançar nisso.

O negócio com sharding é que, enquanto alguém não aparecer com algo parecido com o que o Google tem (e não me refiro ao Bigtable), a forma que sua aplicação assume antes do sharding é muito diferente da forma depois. O sharding torna certas coisas mais difíceis e é geralmente caro.

Quando as pessoas falam em “sharding” ou “denormalização”, o que querem dizer é “duplicar dados de formas específicas para tornar certas consultas mais rápidas.”

Isso sempre envolve custo adicional. Se você está construindo um app novo que provavelmente nunca verá centenas de milhares de usuários — ou se você não sabe se verá ou não — geralmente não vale investir muito dinheiro em hardware e tempo de engenharia para construir uma arquitetura “escalável”.

A realidade é que a maioria dos desenvolvedores conhece SQL e consegue construir aplicações CGI com PHP, Rails ou o que for, mas relativamente poucos têm experiência em pegar esses datasets normalizados e diretos e quebrá-los em sistemas sharded muito mais complexos.

AkitaOnRails: Claro, às vezes as pessoas acham que vão construir o “próximo” Twitter. Entrevistei o Ezra, da Engine Yard, na RailsConf e ele reconhece que o grafo de amigos-de-amigos é um problema tão complexo que quem resolver vai ganhar muito dinheiro. Ou seja, designs SQL tradicionais não funcionam sempre, né?

Blaine Cook: Claro — a questão é: o que mais você vai usar? O Google tem uma arquitetura que permite gastar quantidades infinitas de dinheiro para construir listas denormalizadas de tudo e acessar essas listas rapidamente. Há vários projetos — HBase, Hypertable, CouchDB e muitos outros — que visam resolver esses problemas, mas nenhum deles está pronto para uso em produção.

A realidade é que 10 anos atrás as pessoas construíam aplicações web com tcsh, e agora temos ferramentas melhores.

AkitaOnRails: Onde o Twitter está hospedado? Por alguma razão vi a Engine Yard falando muito sobre questões de escalabilidade durante toda a RailsConf deste ano. Você acha que o meme “Rails não escala” está deixando os Railers preocupados com perspectivas futuras? Mesmo que não devesse assustar tanto assim, já que temos sites de alto tráfego como Scribd e YellowPages no topo da lista — embora as arquiteturas sejam completamente diferentes, é claro. O que você acha?

Blaine Cook: Não tenho certeza, mas acho que o Twitter tem mais tráfego que o YellowPages ou Scribd — a API é realmente poderosa.

AkitaOnRails: Ah, entendo. O Alexa e outros não contabilizam requisições de API, né?

Blaine Cook: O Twitter está hospedado na NTT/Verio. Acho que houve um post no blog sobre isso em fevereiro. Certo, o Alexa não contabiliza tráfego de API/SMS/XMPP.

Quanto à perspectiva de que Rails não escala — acho que é um efeito colateral infeliz dos problemas do Twitter, com certeza, e acho que algumas pessoas se preocupam com isso. Para contextualizar, porém, o Friendster foi escrito em Java inicialmente e migrou para PHP. O Myspace foi escrito em ColdFusion e migrou para ASP.NET.

Quando as pessoas têm problemas ao escalar sites frequentemente pensam que a linguagem é o problema, mas acho que raramente é o caso.

Ruby é mais lento que PHP ou Java (dependendo de qual framework você usa) ou, bem, a maioria das linguagens, mas está ficando mais rápido. E “mais lento” se traduz apenas em custo adicional.

AkitaOnRails: O que me lembra da última controvérsia: o Twitter abandonando Rails. O fato é que você já tem um ambiente misto, certo? A maioria dos pundits acha que “sabe” resolver os problemas do Twitter, embora não façam ideia do que estão falando. Alguns culpam o Rails, outros culpam o MySQL (“vá para Oracle”, dizem). Você pode elaborar sobre isso?

Blaine Cook: Certo — a maior parte do nosso desenvolvimento era em Ruby/Rails, mas havia código em outras linguagens. Python, Java, e alguns experimentos com Scala. O que ignora o fato de que rodávamos partes significativas da nossa infraestrutura com código não-Ruby — Apache, Mongrel, MySQL, memcached, ejabberd, etc., são todas aplicações excelentes e críticas para construir sites escaláveis.

O Oracle definitivamente tem algumas dessas coisas resolvidas, mas é muito mais fácil contratar para MySQL, e as taxas de licenciamento e suporte do Oracle não são de se desprezar.

Construir sua arquitetura em torno de um sistema que só vai ficar mais barato com o tempo, em vez de mais caro, é sempre uma boa ideia.

AkitaOnRails: E tenho que perguntar: você pode divulgar alguns números significativos, ou ordens de grandeza, como tweets por dia, tempo médio de inatividade, ou algo assim, só para termos uma ideia do tamanho dos problemas do Twitter? Vindo de alguém que de fato teve que lidar com uma situação tão enorme — que a maioria das pessoas provavelmente nunca vai enfrentar —, o que você diria serem as melhores funcionalidades do Ruby/Rails para você?

Blaine Cook: Infelizmente, não — há muitas estimativas na web, mais notavelmente o compete e os números de fan-out do Dave Winer.

Acho que o melhor recurso do Ruby é que é divertido de desenvolver com ele. E nunca deixa de ser divertido. É uma linguagem expressiva e poderosa. O Rails torna o desenvolvimento web indolor, comparado a fazer tudo na mão. Isso é algo que não deveria ser subestimado, ou cujo valor deveria ser esquecido.

Além disso, são muito flexíveis. Precisávamos construir uma ferramenta de denormalização, por exemplo, e fazer isso em Ruby era tão fácil/difícil quanto em qualquer outra linguagem, exceto na hora de integrá-la ao restante do sistema — sem busca e substituição, sem subclasses nem nada. É só ligar e funciona.

AkitaOnRails: Por fim, você pode nos contar por que saiu do Twitter? Quais são seus novos projetos? O Twitter sobreviveu à WWDC da semana passada, o que é muito, considerando que eventos tão grandes costumavam derrubá-lo no passado.

Blaine Cook: Estou me mudando para o Reino Unido, e o Twitter entrou/está entrando numa fase em que o foco principal é confiabilidade. Quando saí, a esperança era que o sistema estava estabilizado e o roadmap estava claro para colocá-los em melhor posição. Na época, eles tinham tido um período prolongado de uptime ininterrupto e haviam sobrevivido com louvor à SXSW. Infelizmente não durou, mas parece que as coisas estão melhores de novo.

Ainda não estou pronto para revelar o que vem a seguir, mas tenho várias coisas empolgantes acontecendo. Vou continuar mantendo o Starling e o xmpp4r-simple, e ainda estou ativo no grupo de trabalho da especificação OAuth.

AkitaOnRails: No fim das contas, o Twitter já se tornou quase parte da nossa cultura (pelo menos no nosso mundo tech). As pessoas reclamam quando cai porque agora dependem tanto dele. Pessoas como Michael Arrington, Robert Scoble, Leo Laporte vivem reclamando, dizendo que vão migrar para Pownce ou Jaiku, mas continuam lá. Você tem algum palpite de por que os usuários do Twitter são tão fiéis?

Blaine Cook: Não! Acho que o rico ecossistema de ferramentas que você pode usar para interagir com o Twitter nos seus próprios termos é uma grande parte disso. Muitos usuários têm um investimento pessoal e querem ver esse investimento retornar.

AkitaOnRails: Ok, acho que cobrimos tudo. Alguma consideração final para nossa jovem comunidade Rails brasileira?

Blaine Cook: A web é notavelmente jovem, e há muito espaço para acontecerem coisas incríveis. Fico sempre animado ao ver o que as pessoas estão construindo e o que é possível com essa coisa toda chamada Internet. Com todos os comentários mesquinhos e desinformados do Arrington, acho que sites como Techcrunch, Mashable e Silicon Alley Insider são interessantes porque apresentam um fluxo interminável de coisas incríveis que as pessoas estão construindo na web.

O foco financeiro é infeliz, já que há muitos apps que sobrevivem e proporcionam renda para seus criadores sem precisar escalar para proporções galácticas.

O ponto principal é que há muito a fazer, e não se preocupe com escalabilidade ou modelo de negócios ou qualquer coisa — a menos que você seja apaixonado pelo que está fazendo, nada disso importa.

Se você é apaixonado pelo que está fazendo, há uma boa chance de você descobrir os detalhes no caminho.

AkitaOnRails: Fantástico! Muito obrigado pela sua gentileza, tenho certeza que minha audiência vai adorar. E só para você saber: nós, brasileiros, tweetamos muito sim! :-) Valeu!

Blaine Cook: Que ótimo! Não foi nada, obrigado por ser um ótimo entrevistador.

Hongli Lai e Ninh Bui, da Phusion, sacudiram o mundo Rails alguns dias atrás. Eles lançaram o Santo Graal do deploy Rails: o mod_rails, recebido com muito entusiasmo — e merecidamente.

Eles finalmente resolveram o grande problema que envergonhava os Railers no passado. Isso também vai aliviar dezenas de serviços de hospedagem que não faziam ideia de como resolver essa equação. Agora, esses dois estudantes de ciência da computação estão acima de todos com essa solução inteligente. E ainda têm mais por vir.

Tive a sorte de conseguir entrevistá-los. Acho que esta é a segunda entrevista — a InfoQ furou a notícia com esta outra entrevista, que recomendo muito para entender melhor os mecanismos internos do Passenger. Eles são muito tranquilos e foi um prazer conversar com eles.

AkitaOnRails: Acho que a primeira coisa que gostaria de saber são os seus históricos. O que veio primeiro? mod_rails ou Phusion? Ou seja, vocês tinham uma empresa chamada Phusion que acabou desenvolvendo mod_rails, ou foi o mod_rails que motivou a criação do negócio?

Phusion: Bem, como você provavelmente já leu, somos ambos estudantes de ciência da computação na Universidade de Twente e estamos atualmente nas etapas finais para concluir nossos bacharelados. Desde o início, já inferíamos que o estudo não pode te ensinar tudo, então ao longo dos anos também fizemos muito trabalho tanto comercialmente quanto para a comunidade open source.

Depois de nos familiarizarmos com as habilidades, filosofias e traços pessoais um do outro e com base em nossa experiência anterior trabalhando em TI, achamos que seria uma boa ideia combinar nossas forças em uma empresa que pudéssemos chamar de nossa, e assim surgiu a Phusion.

Então a Phusion veio antes do Passenger (mod_rails). Mais especificamente, nossa intenção era criar uma empresa que fornecesse estritamente produtos, ideias e serviços de TI de primeira linha para apoiar os negócios de nossos clientes. Passenger, coincidentemente, acaba sendo nosso primeiro produto, e pelo que temos ouvido tanto da comunidade quanto das empresas, parece estar perfeitamente alinhado com a filosofia da nossa empresa.

Além disso, depois de anos de desenvolvimento (web) em outras linguagens/frameworks como PHP, J2EE, ASP.NET etc., chegamos a realmente apreciar Ruby on Rails. Achamos que é realmente elegante e fácil de usar. Infelizmente o deploy parecia estar fora de linha com o resto da experiência Rails, especialmente a parte de convenção sobre configuração. É por isso que criamos o Passenger: queremos que a experiência de deploy seja igualmente tranquila.

AkitaOnRails: Phusion é uma empresa de consultoria ou uma empresa de produto? Agora vocês lançaram um dos projetos mais interessantes do mundo Rails até agora, que é o mod_rails. Agora vocês estão preparando o lançamento do Ruby Enterprise Edition. Algum produto novo no pipeline que possam nos contar?

Phusion: Bem, a Phusion é primariamente uma empresa orientada a serviços e achamos que nossa declaração de missão responde melhor a essa pergunta:

“Fornecer exclusivamente produtos, serviços e ideias de primeira linha, a fim de apoiar os negócios de nossos clientes.”

Se os negócios de nossos clientes exigirem consultoria, também somos capazes de fornecer isso, uma vez que temos alguns anos de experiência nessa linha de negócios específica.

Para alcançar essa missão, é crucial para nós sermos bem versados em uma variedade de habilidades e estamos bem cientes do ditado “pau para toda obra, mestre em nenhuma”. É por essa razão que nossa equipe é composta apenas de pessoas altamente qualificadas das áreas da indústria que são de particular interesse para os negócios de nossos clientes. O leitor provavelmente notará que isso permite uma configuração dinâmica na organização, além de manter o trabalho desafiador: não acreditamos em manter pessoas por tempo indefinido sem razões racionais, então é crucial que nossos funcionários continuem aprendendo dentro da nossa organização (daí o apelido, “a empresa de ciência da computação”). Isso não só abre muitas portas no lado da inovação, mas também resulta em pessoas se tornando mestres em várias áreas. Então “pau para toda obra, mestre em nenhuma” pode ser verdade, mas acreditamos que “mestre em muitas áreas” pode ser igualmente verdade. Desnecessário dizer que isso é crucial, pois ciência da computação e TI cobrem uma área tão vasta, e isso é particularmente verdade para os negócios de nossos clientes.

Ruby Enterprise Edition foi na verdade concebido como resultado do Passenger: ele se esforça para reduzir dramaticamente o uso de memória de aplicações Ruby on Rails executadas através do Passenger.

Quanto a novos produtos, atualmente estamos trabalhando em alguns serviços web baseados em assinatura. Nosso amigo David Heinemeier Hansson recentemente deu uma palestra sobre startups que elabora sobre as razões pelas quais alguém gostaria de seguir esse caminho. Recomendamos muito ao leitor conferir isso e, por razões estratégicas, gostaríamos de deixar por aqui por ora.

Hongli Lai

AkitaOnRails: Por muito tempo toda a comunidade Rails estava um tanto confortável demais com a solução Mongrel. Quando Zed Shaw fez seu rant sobre a comunidade, foi um alerta e a partir daí vimos alternativas surgindo da noite para o dia como Thin e Ebb. O que vocês acharam dessa situação na época?

Phusion: Pelo que entendemos, soluções como Mongrel, Thin e Ebb se enquadram na mesma categoria conceitual. Ou seja, para o usuário final, funcionam de maneira similar, mesmo sendo tecnicamente diferentes. Em outras palavras, Thin e Ebb parecem ser como “Mongrel, mas mais rápido/menor”.

No entanto, o Passenger adotou uma abordagem de deploy diferente do Mongrel e afins: pretende tornar o deploy o mais simples possível e reduzir ao máximo o overhead de manutenção do sistema. Por exemplo, enquanto o Passenger lida com isso automaticamente, Mongrel, Thin e Ebb exigem que o administrador gerencie clusters. Como você disse, os mais técnicos já se familiarizaram bastante com a última abordagem, mas também é preciso levar em conta os iniciantes. Para eles, é um obstáculo considerável simplesmente fazer o deploy de uma aplicação. Se considerarmos os históricos desses iniciantes, muitos deles provavelmente já estão familiarizados com a forma de deploy do PHP, ou seja, de upload-and-go. Com o Passenger tentamos acomodar essas pessoas, pois achamos que isso é importante para o crescimento do mercado Ruby on Rails. Isso não quer dizer, no entanto, que não levamos em conta questões como robustez, performance e estabilidade.

De fato, testes independentes já mostraram que o Passenger está em paridade ou é mais rápido do que as soluções mencionadas. Outro problema é que os hosts compartilhados já estão rodando Apache como seu principal servidor web, e já vimos que configuração é necessária para colocar um cluster Mongrel funcionando com Apache… Desnecessário dizer que isso é bastante tedioso e propenso a erros, mesmo para muitos técnicos. O Passenger literalmente reduz esse processo para questão de segundos em vez de minutos. Isso não só economizaria muito tempo de uma empresa de hospedagem, mas também manteria seus administradores de servidor sãos (e pela nossa experiência, eles são as últimas pessoas que você quer ofender ;-)).

Além disso, configurar um cluster tipo Mongrel requer bastante recursos em um host compartilhado, e é por razões como essas que os custos dos planos de hospedagem compartilhada de Ruby on Rails são geralmente mais altos do que os de hosts PHP. O Passenger, no entanto, aborda esse problema também ao fornecer eficiência melhorada em relação às soluções mencionadas, especialmente em conjunto com o Ruby Enterprise Edition. Testes iniciais já mostraram que isso resultou em uma redução dramática no uso de memória e elaboraremos sobre isso em breve.

Se considerarmos esses fatores, fica evidente que o Passenger (em conjunto com o Ruby Enterprise Edition) tem o potencial de desencadear uma revolução na hospedagem compartilhada. Não só na redução de custos para empresas de hospedagem (e esperançosamente para os consumidores), mas também no aumento da popularidade do Ruby on Rails.

AkitaOnRails: mod_ruby parece estar estagnado há muito tempo e precisa de carinho. Dizem que funciona razoavelmente bem para sites pequenos, mas a muita “magia negra” do Rails o torna inadequado para mod_ruby. O que torna mod_rails diferente de mod_ruby, na forma fundamental como operam com frameworks complexos como Rails?

Phusion: Na verdade não conseguimos comentar sobre isso, porque não somos intimamente familiarizados com mod_ruby. No entanto, o mod_ruby não é mantido ativamente e há muitos comentários negativos sobre ele em geral (como na wiki do Ruby on Rails). Também parece que ninguém realmente o usa. É por essas razões que nunca realmente experimentamos o mod_ruby.

Do mencionado acima e do que as pessoas costumam esquecer é que entregar apenas um produto (excelente) não é suficiente. Marketing e promoção são realmente importantes para a aceitação de um produto. Não só fizemos muito desenvolvimento, mas também passamos muito tempo promovendo o Passenger. O fato de estarmos tendo esta entrevista agora é provavelmente o resultado de nossa campanha de promoção, então estamos bastante satisfeitos com isso. Nesse sentido, o mod_ruby não parece ser ativamente promovido, e talvez seja uma das razões pelas quais é relativamente desconhecido.

AkitaOnRails: Por que vocês acham que demorou tanto para alguém criar uma solução para um módulo Apache que pudesse operar de forma similar ao habitual mod_php ou mod_python? O que vocês acharam que foi o aspecto mais desafiador no desenvolvimento do mod_rails?

Phusion: Bem, como você disse, acreditamos que desenvolvedores experientes de Ruby on Rails não consideram o deploy um problema — no máximo chato. Eles automatizaram/padronizaram bastante o processo de deploy com scripts Capistrano. Os iniciantes, no entanto, veem o deploy como um problema intransponível. Consequentemente, acabamos numa situação em que as pessoas que podem resolver o problema ou não o veem como problema ou não estão motivadas o suficiente para corrigi-lo, enquanto as pessoas que veem o problema não conseguem resolvê-lo.

Além disso, por nossas experiências pessoais, os iniciantes geralmente querem ver resultados imediatos. É muito desmotivador para essas pessoas continuar usando Ruby on Rails se tiverem que gerenciar toneladas de configurações e clusters obscuros para “simplesmente fazer o deploy de uma aplicação com sucesso”. Isso leva a conclusões muito inteligentes, como “Ruby on Rails é uma porcaria”. ;-)

O aspecto mais desafiador é provavelmente o suporte multiplataforma e para elaborar isso em poucas palavras:

• Precisamos suportar uma grande variedade de sistemas baseados em Unix, como Linux, BSD e OS X. O Passenger trabalha em um nível bastante baixo (ou seja, usa recursos avançados do sistema Unix), e diferentes sistemas tendem a se comportar de formas sutilmente diferentes de tal forma que podem quebrar o Passenger se não formos cuidadosos.
• Muitos desafios são criados pelo MacOS X e pelo Apache. Há literalmente toneladas de maneiras diferentes pelas quais o Apache pode ser compilado e instalado, e isso é especialmente verdade no MacOS X. Cada instalação do Apache pode ser ligeiramente diferente, e precisamos suportar todas elas. Tivemos que escrever centenas de linhas de código de auto-detecção do Apache para tornar a instalação o mais tranquila possível. E o suporte para coisas específicas do OS X como binários universais não tornou o desafio mais fácil.

Ninh Bui

AkitaOnRails: A abordagem habitual de Shared Hosting com Rails envolve FastCGI; acho que é aí que mod_rails vai causar o maior impacto primeiro. Na arena de VPS, as pessoas geralmente estão mais confortáveis apenas subindo um cluster mongrel, talvez um monit ou god para monitorá-los ou até mesmo usar Swiftply para melhor controlar as instâncias mongrel. Há algum ajuste envolvido em ter interpretadores Ruby permanentes rodando, isso se deve principalmente ao fato de que se em algum momento a VM precisar de mais memória, ela vai alocar o quanto precisar, mas não devolver de volta ao SO. O mod_rails tem algum mecanismo para evitar um sistema de monitoramento como Monit, ou ele ainda é necessário?

Phusion: Levamos esse desafio em conta também. Aplicações Rails que ficaram ociosas por um tempo são desligadas, liberando todos os seus recursos para o sistema operacional. Além disso, é possível usar o Passenger em conjunto com ferramentas de monitoramento como Monit. Se o Monit matar um processo Rails, o Passenger automaticamente o (re)iniciará quando necessário, como se nada de ruim tivesse acontecido.

AkitaOnRails: Entendo que mod_rails opera mais ou menos como um gerenciador para um pool de VMs Ruby. Você tem um número mínimo e máximo de processos permitidos, mod_rails inicia tantos quanto necessário dependendo da carga e se um processo estiver ocioso, ele o matará após um período de timeout. Na maior parte do tempo, uma quantidade mínima de processos ficará rodando. É assim que funciona?

Phusion: É como você descreve, com a exceção de que não existe tal coisa como uma quantidade mínima de processos. O motivo para isso é que, uma vez que uma aplicação para um certo diretório Rails é iniciada, esse processo de aplicação não pode ser reutilizado para um diretório Rails diferente. Isso torna o conceito de uma quantidade mínima bastante inútil, exceto em servidores que hospedam apenas uma única aplicação Rails.

Claro, não ter uma quantidade mínima de processos significa que a primeira requisição após o timeout de ociosidade sofrerá uma penalidade de performance e será lenta. Resolvemos esse problema usando servidores spawner. Os servidores spawner fazem cache do código do framework Ruby on Rails e do código da aplicação, e podem reduzir o tempo de spawn em aproximadamente 50% e 90%, respectivamente. Você pode ter notado esses processos de servidor spawner na saída do ‘ps’. O segredo para reduzir o tempo de spawn estaria em alterar os timeouts de ociosidade desses servidores spawner. Atualmente estamos trabalhando em uma série de artigos em que elaboramos sobre os tempos de spawn das aplicações Rails, quais são os papéis exatos dos servidores spawner e como os administradores de sistema podem otimizar as configurações do servidor para reduzir o tempo de spawn.

Boa parte da mágica que reside no Passenger ainda precisa ser revelada e mal começamos, mas isso é principalmente para as pessoas interessadas, ou seja, os mais técnicos. Há um ditado em holandês que resume o pensamento por trás de por que não fizemos isso até agora: “Goede wijn behoeft geen krans”, que se traduz aproximadamente como “um bom produto não precisa de elaboração de apoio”. Uma publicação científica, por outro lado, precisa desse tipo de elaboração e é também por essa razão que estamos escrevendo esses artigos.

AkitaOnRails: Ficando no mesmo espaço de memória que o próprio Apache, você não tem o overhead de uma chamada FastCGI ou HTTP para uma instância mongrel. Essa diferença pesa muito nos seus benchmarks? Geralmente, pela sua experiência, quanto mais rápido é mod_rails agora comparado a um cluster mongrel básico rodando as mesmas aplicações? Os ganhos de velocidade são constantes ou variam o suficiente para não serem realmente mensuráveis?

Phusion: Na verdade isso não é verdade: os processos Rails não residem no mesmo espaço de memória do Apache. Em vez disso, são realmente processos separados, cada um podendo ser individualmente desligado sem afetar todos os outros. Não é uma boa ideia embutir um interpretador Ruby no Apache por causa de vários problemas, como estabilidade, fragmentação de heap e inchaço desnecessário do tamanho de VM de um processo. Pelo que entendemos, o mod_ruby adota a abordagem de embutir Ruby dentro do Apache, e suspeitamos que esse seja um dos motivos pelos quais as pessoas relatam tantos problemas com ele.

Nossos próprios testes mostraram que a performance do Passenger é mais rápida do que um cluster Mongrel atrás de Apache+mod_proxy_balancer. Testes independentes mostraram que a performance do Passenger está em paridade ou é ligeiramente mais rápida do que o cluster Mongrel, e isso parece estar perfeitamente alinhado com o que fomos capazes de inferir. Até agora não vimos nenhum teste em que o Passenger seja mais lento que um cluster Mongrel. Os ganhos de velocidade não são constantes: dependem da aplicação específica.

Galera da Phusion no Fingertips

AkitaOnRails: Ruby Enterprise Edition, pelo que entendo, é o resultado daquela série sobre “copy-on-write” da qual falamos. Essencialmente uma forma de patchear a VM Ruby para habilitar um GC modificado que não vai marcar cada objeto, permitindo assim que COW faça seu trabalho e economize uma quantidade considerável de memória. Você citou 33%. Assumiria que é “até 33%”, certo? Qual é o intervalo usual de memória economizada que vocês experimentam nos seus testes? O que mais afeta isso em apps Rails típicos, algum gotcha que vale mencionar para desenvolvedores Rails?

Phusion: Os 33% mencionados não são um máximo, mas uma média. Testamos com aplicações reais como Typo, e até agora inferimos uma economia média de memória de 33%. A economia real de memória depende da aplicação específica, então os resultados podem variar.

Não há gotchas para desenvolvedores de aplicações. Se sua aplicação funciona com Passenger, então Ruby Enterprise Edition também vai funcionar, sem necessidade de opções complicadas de configuração. Em outras palavras, é um aumento transparente. Em qualquer caso, podemos garantir que o uso de memória não será maior do que quando você usa o Ruby padrão.

AkitaOnRails: Entendo que vocês vão falar mais sobre a Enterprise Edition na RailsConf, mas esperava que pudessem revelar um pouco mais sobre ela. Vocês estão terminando a segunda rodada de doações para licenças Enterprise (eu doei! :-). Em primeiro lugar: quando vão lançá-la? Esse produto vai ficar comercial apenas ou vocês pretendem contribuir o patch do GC de volta ao trunk do Ruby algum dia?

Phusion: Obrigado por doar, e quanto ao último ponto: sim, é nossa intenção que um dia seja incorporado upstream. O leitor atento provavelmente vai notar que desviamos de uma pergunta como Neo desviou das balas do Agente Smith na Matrix: habilidosamente, exceto pela última bala, que na verdade acertou — mas chega disso por ora ;-).

AkitaOnRails: “mod_rails” é na verdade o alias para “Passenger”. Algumas pessoas estão perguntando se isso vai continuar sendo apenas para Rails ou se vocês pretendem torná-lo compatível com Rack para que outros frameworks como Merb e Ramaze possam rodar sob seu controle. É possível? Vocês estão considerando?

Phusion: Digamos apenas que preferiríamos que você o chamasse de Passenger em vez de apenas mod_rails eventualmente. ;-)

AkitaOnRails: Apache é a potência dos servidores web e faz muito sentido para um módulo Apache. Talvez esteja especulando demais, mas vocês acham que é possível refatorá-lo para módulos de outros servidores web como nGinx ou Litespeed? Por causa da falta de um bom mod_rails no passado, a comunidade Rails se afastou para outras alternativas. É razoável esperar módulos não-Apache?

Phusion: É tecnicamente possível. Para manter vocês em suspense e continuar especulando sobre essas questões, não vamos nos aprofundar nisso por enquanto. ;-)

Passenger sendo instalado!

AkitaOnRails: Do jeito que está agora, parece que mod_rails é um substituto plug-and-play para qualquer estratégia que tínhamos antes usando Apache. Há algum gotcha que vale mencionar para quem planeja migrar? Acho que regras mod_rewrite complicadas seriam a primeira coisa?

Phusion: Há um gotcha menor. Por padrão, sobrescrevemos o mod_rewrite da melhor forma possível. Isso ocorre porque projetos Rails vêm com um arquivo .htaccess por padrão, e esse .htaccess contém regras mod_rewrite que resultam em todas as requisições sendo encaminhadas para CGI ou FastCGI.

Isso é trivialmente resolvido deletando o .htaccess padrão e habilitando uma opção de configuração que diz ao Passenger para não sobrescrever o mod_rewrite. Isso permite que o desenvolvedor use regras mod_rewrite arbitrárias a seu gosto.

Além disso, o gotcha restante seria que o deploy de Rails se tornou bem entediante graças ao Passenger, pelo menos é o que as pessoas dizem. ;-)

Por fim, gostaríamos de agradecer a todos vocês pelo amor e suporte (financeiro) ao Passenger. Realmente apreciamos!

Com os melhores cumprimentos, seus amigos da Phusion,

Hongli Lai

Ninh Bui

Ele respondeu tudo com riqueza de detalhes e conversamos bastante sobre seus projetos open source, performance, escalabilidade e, claro, muito sobre Git e Github. Espero que isso deixe as pessoas ainda mais animadas com o ritmo em que a comunidade Ruby/Rails está movendo as coisas pra frente.

AkitaOnRails: Ok, de onde você é?

Chris Wanstrath: Atualmente moro em San Francisco, mas cresci em Cincinnati, Ohio. Me mudei para San Francisco em 2005 para trabalhar na C|NET, onde fiz PHP por um tempo em sites como gamespot.com, mp3.com e tv.com.

Em 2006 me mudei para o site chowhound.com dentro da C|NET para trabalhar com Rails, algo que eu vinha fazendo nas horas vagas há um tempo. Enquanto estava lá, P.J. Hyett e eu trabalhamos no chowhound.com e depois construímos o chow.com, que lançamos mais tarde naquele ano. Então em abril de 2007 os dois saímos da C|NET para formar nossa empresa de consultoria, Err Free.

Em dezembro de 2007 lançamos o FamSpam, um site para manter contato com sua família. É basicamente uma versão simplificada do Google Groups com ênfase em participar de uma thread pelo menos uma vez por semana e encontrar facilmente fotos ou outros arquivos enviados.

Enquanto P.J. e eu trabalhávamos no FamSpam, Tom Preston-Werner e eu trabalhávamos no GitHub nas horas vagas. Começamos em outubro trabalhando noites e fins de semana. Queríamos basicamente uma maneira fácil, bonita e cheia de recursos de jogar nossos repositórios Git no ar e compartilhá-los com as pessoas. Conforme fomos nos aprofundando, percebemos como coisas como o dashboard poderiam mudar a forma como lidamos com contribuições open source. Depois disso, todas as funcionalidades sociais começaram a se encaixar. O beta privado do Github foi lançado em janeiro e em abril vimos o lançamento público.

AkitaOnRails: Uau, cara, você é muito ocupado mesmo. Quero entrar em detalhes em cada tópico que você mencionou, mas primeiro: eu soube que você trabalhava na C|Net por causa das suas palestras sobre memcached. Tenho 2 perguntas: você era programador PHP, o que te fez mudar para Ruby on Rails? E aí, trabalhar para uma rede de alto perfil como a C|Net te expôs a sites muito exigentes. Como você descobriu como aproveitar o memcached com Rails e depois o plugin cache_fu?

Chris Wanstrath: Comecei a fazer Rails no início de 2005 e peguei meu primeiro emprego com PHP em fevereiro de 2005 (antes disso eu fazia ASP e Perl, sobre os quais prefiro não falar). Então, honestamente, nunca me considerei um “programador PHP” mais do que um programador Rails. Eu realmente gostava de sites e sabia que podia me pagar fazendo PHP, então foi o que fiz. Enquanto isso, estava constantemente fazendo Ruby nas horas vagas.

Quando a C|Net começou a fazer Rails, soube que seria uma combinação perfeita para mim. Eu gostava muito de PHP e adorava Gamespot, mas era simplesmente absurdo passar a noite inteira brincando com Ruby enquanto trabalhava profissionalmente com PHP.

Na verdade, uma das coisas que me contrataram no Gamespot foi meu parser de yaml em PHP puro chamado SPYC (simple PHP yaml class). Foi inspirado (obviamente) no parser syck yaml do _why. Eu queria uma forma fácil, sem extensões, de lidar com YAML em PHP porque estava muito mimado pelo Ruby.

Acho que hoje os frameworks CakePHP e Symfony o usam e fazem suas configurações em yaml. Mas mesmo escrevendo PHP eu queria estar escrevendo Ruby. O motivo principal pelo qual aprendi Ruby foi que eu conhecia PHP e Perl, mas queria algo que pudesse usar tanto para escrever sites quanto scripts de linha de comando. Perl era ótimo para scripts e PHP era ótimo para sites, mas eu estava simplesmente cansado de usar os dois.

Então enquanto estava aprendendo Python, o Rails apareceu.

Quanto ao cache_fu, eu tinha muito interesse nos aspectos de “escalabilidade” de manter um site enquanto trabalhava no Gamespot.

Embora bom design OOP e afins possam ser aprendidos por qualquer um que escreva código suficiente, não dá para aprender sobre escalabilidade a não ser que você esteja trabalhando em um site grande. Há truques demais e partes móveis demais, e é muito difícil simular a carga em um ambiente controlado.

Então, enquanto estava no Gamespot, como disse, tentei aprender o máximo possível sobre coisas como replicação MySQL, clustering de bancos de dados, sharding de bancos de dados e memcached com base em como os caras espertos da C|Net configuraram tudo ao longo dos anos. Eles tinham muitas máquinas servindo muito tráfego, então era perfeito.

No Chowhound, estávamos reescrevendo um antigo site HTML estático em Rails e preocupados com a transição de arquivos planos para chamadas de banco de dados dinâmicas e geração de páginas. Tinha um tráfego considerável de um grupo de fãs fanáticos, e sabíamos que o novo visual “web 2.0” do site não iria agradar os usuários mais antigos, então pelo menos queríamos que o site fosse performático para dar a eles um motivo a menos para reclamar. Então basicamente pegamos muito do que eu aprendi no Gamespot e as informações disponíveis livremente na internet em listas de e-mail e discussões, e tentamos fazer uma forma mais amigável ao Rails de cache de objetos com memcached.

Ruby é tão bom em eliminar repetição e criar APIs amigáveis. Por isso o cache_fu faz cache de fragmentos e cache de objetos, porque em sites maiores você acaba usando ambos para propósitos diferentes, que foi basicamente como era no Gamespot.

AkitaOnRails: Interessante. E não é muito comum eu encontrar pessoas que lidaram com sites realmente grandes. Você pode nos dar uma ideia de que tipo de carga seus apps Rails tiveram que suportar? Alguns especialistas que conheço reclamam da distribuição vanilla do Rails e recomendam muitos ajustes como abandonar completamente o ActiveRecord e vários outros hacks. Você precisou hackear muito o Rails para atingir a escalabilidade que precisava, ou acha que a maior parte é boa o suficiente para evitar muito tweaking?

Chris Wanstrath: Não consideraria o Chowhound um grande site Rails mais. Agora que temos scribd, twitter, friends for sale e Yellowpages, o Chowhound não entra mais na lista.

Acabamos fazendo muita otimização prematura naquele site e pouca otimização do mundo real. Aprendi muitas lições lá que apliquei em outros sites pelo caminho. No entanto, recentemente tive a chance de trabalhar com os caras do friends for sale no app deles para Facebook, que recebe milhões de visualizações de página por dia e lida com uma quantidade insana de registros no banco.

Pelo que sei, o único hack no AR que fizemos foi aplicar o patch de atualizações parciais do Pratik Naik. Isso porque, com tantas linhas e índices tão grandes, você quer evitar modificar índices quando não precisa, então salvar apenas as colunas/atributos alterados pode ter um ganho de performance bem grande. Felizmente, as atualizações parciais agora estão no Rails Core.

Na minha experiência, você passa muito mais tempo tentando escalar o SQL antes mesmo de precisar endereçar o AR. E quando chega na parte do AR, geralmente é o código da sua aplicação. Buscar e salvar registros demais em callbacks de before/after_save, gravações de linhas completas como eu acabei de descrever, e geralmente não ser um bom cidadão SQL. Só abandonaria o AR completamente se sentisse que não tinha controle sobre o SQL gerado por ele. O que, como qualquer um sabe, não é o caso — você tem muito controle sobre ele.

Há momentos, no entanto, em que o AR é exagero e você realmente precisa de velocidade. No Github, precisamos autenticar você toda vez que tenta fazer pull ou push de um repositório via ssh. Carregar um ambiente Rails inteiro, ou mesmo o activerecord, era notavelmente lento, então mudamos para usar sequel em um script ruby simples. Como não precisamos do enorme conjunto de funcionalidades do AR e das boas capacidades de OOP para uma busca de linha única tão simples, fez muito sentido para nós.

AkitaOnRails: Concordo com isso, foi o que experimentei também em relação ao AR. Então, você é também autor de vários outros plugins Rails famosos como will_paginate, Ambition, o original Sexy Migrations. Pode comentar brevemente sobre cada um? Estou esquecendo algum outro plugin? Parte do que você fez se tornou o padrão “de facto” para desenvolvimento Rails, algumas pessoas aqui usam esses plugins sem realmente saber que você fez todos eles.

P.J Hyett na SXSW'06

Chris Wanstrath: Err the blog são na verdade duas pessoas, P.J. Hyett e eu. Eu não escrevi o will_paginate — P.J. escreveu a versão original e depois Mislav Marohnić a reescreveu. Mislav é agora o mantenedor. Mas eu ainda fico com todo o crédito, o que me está bem.

Quanto aos outros plugins, há mofo, ambition, sexy migrations, cache_fu, acts_as_textiled, fixture_scenarios_builder e gibberish.

Mofo é um parser de microformatos baseado em Hpricot. Está no Github e infelizmente não recebe tanto carinho meu ultimamente, mas pelo que sei ainda é o padrão ouro para parsing de microformatos em Ruby.

Foi o primeiro gem que lancei que também funcionava como plugin Rails, que é como acho que a maioria dos plugins deveria ser distribuída no futuro. Gems já têm um sistema de distribuição sólido e esquema de versionamento, e se o Github se tornar uma fonte de gems então praticamente não há razão para não lançar plugins como gems.

Sexy migrations foram inspiradas pelo Hobo. Infelizmente a versão deles era específica para Hobo, então escrevi uma versão amigável para plugins. O DHH depois escreveu sua própria versão e incorporou ao core, totalizando 3 implementações distintas de sexy migrations.

Gibberish é um plugin de localização bem divertido que escrevi pro bono para um cliente, simplesmente porque sentia que as APIs de todos os plugins de localização existentes eram muito difíceis de trabalhar. Esperançosamente, com a ajuda de quem tiver interesse, podemos começar a localizar o Github em breve.

Ambition foi inspirado por uma incursão no Erlang. Li um post de blog explicando que a sintaxe de consulta do mnesia, que é toda compreensão de listas (basicamente a versão Ruby do módulo Enumerable), foi possibilitada pela capacidade de percorrer a árvore de parse e construir uma consulta mnesia dessa forma.

Então comecei a brincar com o gem parse_tree para ver se conseguia fazer o mesmo para Ruby. Agora é, claro, um framework completo para gerar consultas arbitrárias para qualquer RubyGem baseado em Enumerable. Para consultas simples, realmente gosto de tratar tabelas como arrays — parece muito natural.

Acts_as_textiled foi o primeiro plugin Rails que lancei. É uma prova do Rails que o plugin ainda funciona na versão edge hoje. A única outra coisa notável que o Err iniciou é o termo “vendor everything”, que agora faz parte do Rails através do config.gems.

Isso e o gem Cheat (e o site).

Tom Preston-Werner

AkitaOnRails: (Claro, me desculpe P.J.!) E isso desperta outra curiosidade minha: de onde veio o nome “Err”? É tanto para o Err the Blog quanto para a Err Free, que é sua empresa. Você mencionou P.J. e Tom. E vocês três são Railers em tempo integral, certo? Como vocês se uniram e decidiram começar a própria empresa? Muitas pessoas me perguntam sobre empreendedorismo e você é mais um bom exemplo.

Chris Wanstrath: “err” é uma espécie de trocadilho com “Typo”, que era o motor de blogging em Rails mais popular quando começamos nosso blog, então pode ser um pouco confuso, mas na verdade sou cofundador de duas empresas distintas.

Há a Err Free e a Logical Awesome. Err Free é consultoria e treinamento em Ruby & Rails. P.J. e eu somos donos da empresa, e a usamos para fazer trabalho de cliente, palestras, treinamento corporativo, esse tipo de coisa. Ela também é dona e operadora do FamSpam, que usamos com nossas próprias famílias.

Logical Awesome, no entanto, foi fundada por mim e Tom. Isso porque eu estava desenvolvendo FamSpam com P.J. e GitHub com Tom ao mesmo tempo, separadamente. Hoje, no entanto, P.J. faz parte da Logical Awesome e é um dos desenvolvedores do GitHub.

Tom trabalha na Powerset e na verdade não faz muito Rails para o GitHub — ele faz principalmente flash, haxe, C, css, design e ruby. E porque ele é o autor do God, faço ele escrever todos os arquivos de config também. Quanto à decisão de começar uma empresa, sou alguém que precisa estar envolvido em tudo o que faço em todos os níveis. Na C|Net, há um limite de quanto você pode contribuir num site que emprega 30 pessoas, especialmente quando há pessoas dedicadas de produto e “visão”, enquanto no Github somos apenas eu, Tom e P.J.

Se o site for lento, confuso, ruim ou não melhorar seu fluxo de trabalho, posso assumir responsabilidade por isso. Mas se for rápido, simples, incrível e transformador, também fico com essa responsabilidade. O que é muito gratificante.

Também significa que, quando você é cofundador de uma empresa majoritariamente técnica, as discussões são muito mais lógicas. Vi decisões sendo tomadas na C|Net que contradiziam diretamente estatísticas de A/B que tínhamos coletado. Na Logical Awesome, isso nunca aconteceria. Não é nem lógico nem incrível. Basicamente: queria encontrar a empresa ideal, então encontrei boas pessoas e a fundei.

AkitaOnRails: Ok, chegamos ao prato principal do dia: o Github! Não consigo pensar em melhor exemplo de produto inovador que aproveita tão bem o poder do Git. Estou muito curioso para entender como você teve essa ideia. Ao mesmo tempo, muita gente ainda não consegue entender por que os Railers como um todo começaram a usar Git tão maciçamente de repente. O pessoal do Mercurial e Bazaar está muito desconfortável. O que você acha que o Git tem que atraiu os Railers em bando? Ou pelo menos o que você acha que o Git tem que nenhum outro tem? Comecei a evangelizar Git aqui no Brasil no ano passado depois de ouvir Randall Schwartz, e recentemente alguém me perguntou qual seria minha escolha para um killer-app Rails e Github me veio à mente imediatamente. Então você tem boa presença mental também.

Chris Wanstrath: Github é super emocionante para mim porque é realmente um site feito para mim. Tom e eu somos bem parecidos no sentido de que ambos temos uma quantidade considerável de projetos open source, todos usados e corrigidos por pessoas que nunca conhecemos.

Lidar com isso do jeito antigo estava bom até que eu e P.J. começamos a trabalhar no FamSpam… à medida que meu tempo livre diminuía, minha capacidade de manter meus projetos open source diminuía também. E isso é definitivamente um problema de fluxo de trabalho. Às vezes quando você não consegue encontrar tempo suficiente para fazer algo, você só precisa fazer esse algo demorar menos tempo.

Github foi literalmente escrito para chronic, god, ambition, will_paginate e o resto dos nossos projetos. Queríamos tornar muito simples para as pessoas contribuírem, e isso realmente não é possível sem Git.

Comecei a usar Git logo depois de assistir à palestra técnica do Linus em maio de 2007, que é muito boa para explicar Git de um nível conceitual bem alto. Então quando esse problema de tempo surgiu, eu já usava Git há alguns meses e Tom, coincidentemente, estava tentando resolver o mesmo problema.

Conversamos depois de um meetup local de Ruby em San Francisco, num bar é claro (onde todas as grandes ideias e parcerias começam), e decidimos trabalhar no problema juntos. Eu estava brincando com um Gitweb específico do Err, mas Github é obviamente muito mais ambicioso em escopo.

Quanto à adoção do Git, não tenho ideia do que foi o ponto de inflexão. Quando começamos a trabalhar no app em outubro, estávamos preocupados com ./script/plugin e tarballs e windows e espelhamento de svn. Não tínhamos nem certeza se conseguiríamos construir um negócio em torno de Git, porque o subversion ainda era tão dominante.

Como todos sabemos, no entanto, Git chegou ao ponto de inflexão no início de 2008 e todo mundo de alguma forma encontrou tempo para experimentá-lo. Talvez leve uns dois segundos para perceber o quanto é mais rápido, e depois mais alguns segundos para perceber o quanto é mais incrível. Então não é grande surpresa que esteja conquistando convertidos.

Quanto à comunidade Rails, definitivamente é por causa dos projetos. Quando Merb, Rubinius e Ruby on Rails todos migram para Git, você não tem escolha. É para onde a comunidade está indo. Quanto a outras linguagens, temos um grande número de projetos não-Ruby no Github. PHP, Java, Javascript, Lisp, Python — há alguns forks de Django, por exemplo, as linguagens de programação io e nu também estão hospedadas no Github.

Então o que realmente importa são os early adopters, acho. Nu é um lisp escrito em Objective-C, muito novo e muito de ponta. As pessoas que o usam agora são pessoas que percebem o quanto é poderoso e incrível rodar uma linguagem tão dinâmica em uma plataforma tão madura e estável. E naturalmente, os pensadores progressistas por trás do nu sabem que Git (e controle de versão distribuído) é um conceito igualmente poderoso e igualmente de ponta.

Com Prototype e Scriptaculous migrados, e rumores de outros frameworks Javascript migrando, é só uma questão de tempo até Git se tornar ainda mais difundido.

Acho que os Railers simplesmente gostam muito de blogar.

Quanto a outras soluções, é Rails vs Django de novo. Se você usa Mercurial, tudo bem. Os dois são tão parecidos (sim, Git funciona ótimo no Windows) que enquanto as pessoas migrarem para controle de versão distribuído, ainda é uma vitória.

Ah, mas espera, Mercurial não tem Github :-)

AkitaOnRails: Exatamente :-) E me pergunto quais foram os desafios de montar algo como o Github. Não é um simples app Rails, com código Ruby muito rápido e puro. Você provavelmente está lidando com milhares de chamadas de sistema para binários Git, vários jobs em background, manutenção, segurança. O que você acha que foram os maiores desafios ao montar o Github antes de lançá-lo recentemente ao público?

Chris Wanstrath: Bem, você acertou em cheio… escalar Rails é a parte fácil. Escalar sshd, Git, Git-daemon e nossos jobs em background é a parte difícil.

Chamamos Git diretamente muitas vezes por página, precisamos processar jobs que entram de muitos lugares diferentes (criar um repositório no site, fazer push de um repositório via ssh), precisamos ser seguros (ssl e ssh para todos os repositórios privados o tempo todo), precisamos garantir que tudo rode rápido (memcached tanto para chamadas Git quanto para o banco), precisamos garantir que você esteja “por dentro” com um feed de notícias agregando informações de todas as fontes diferentes dentro do nosso sistema (quase 1 milhão de linhas na tabela de feed quando lançamos).

Então definitivamente não foi fácil. Sem mencionar que ssl é essencialmente o “modo lento” para http, então precisamos garantir que estamos indo rápido porque coisas como seu dashboard já têm uma desvantagem de velocidade. Como exemplo, o sshd armazena suas chaves num arquivo authorized_keys. Bem, nem tínhamos terminado nosso beta ainda e o arquivo de chaves tinha mais de 4 megabytes de texto puro. Então tivemos um dos gurus de C da Engine Yard patcheando o sshd para nós para fazer pesquisas baseadas em MySQL, nos dando pesquisas mais rápidas e sem o custo de acrescentar/escrever num arquivo massivo.

Matthew Palmer é o referido guru, e planejamos tornar esse código open source em breve.

Também temos hooks de post-receive (quando você faz “Git push”) rodando que hospedamos e entregamos — então se você fizer push, faremos POST para uma URL arbitrária com JSON dos commits. Mas você também pode nos dar algumas informações e faremos post para campfire, irc, twitter ou lighthouse com payloads customizados.

Como temos flash, flash com haxe, Python, C, ruby, scripts bash, muito Javascript e algum erlang por vir nos bastidores, é definitivamente uma mistura interessante.

Temos a sorte de estar hospedados na Engine Yard, no entanto. Se não os tivéssemos, estaríamos perdidos. A configuração incrível de cluster deles com GFS significa que podemos hospedar nossos potencialmente centenas de gigabytes de repositórios em um drive compartilhado com RAID, redundância e backups. Se estivéssemos rodando Github em um VPS barebones, nem sei como compartilharíamos acesso a esses repositórios. Não seria divertido.

Eles também têm muitos especialistas disponíveis 24/7, o que é ótimo porque tenho tendência a esquecer de dormir e trabalhar até as 7 da manhã. Esses caras tiram muito da dor de rodar um site muito dependente de Unix.

AkitaOnRails: Interessante, Erlang? Adoraria saber o que você está fazendo com ele. Voltando, acho que vi um clone Git do trunk do Rails no Github muito antes de o DHH anunciar isso alguns dias atrás. Acho que foi Michael Koziarski quem fez primeiro, sem muito alarde. Vocês estavam planejando isso junto com o pessoal da 37signals, ou a migração do Rails Core para o Github foi algo que aconteceu naturalmente? E vocês têm algum tipo de parceria com o pessoal do Lighthouse também, porque vocês já têm alguns hooks para gerenciar tickets do Lighthouse através de mensagens de commit do Github, certo?

Chris Wanstrath: O material de Erlang vai ser muito legal, prometo. Faremos muito barulho sobre isso quando estiver pronto. Quanto ao Rails, o koz de fato tinha um espelho do seu repositório Git-svn no Github durante o beta. Era não oficial. Então em fevereiro ele escreveu um post explicando que o core estava pensando em migrar para Git.

Quando vi o post, enviei um e-mail para ele e conversamos um pouco sobre o que precisaria ser feito para mover Rails para o Github, que era obviamente algo que amo em um número enorme de níveis. Ele disse que voltaria a falar comigo, e então algumas semanas depois o time Core nos contactou e queria discutir a migração. O resto é história.

Realmente respeito o trabalho que o time do Lighthouse faz. O bug tracker é ótimo, e o novo redesign é ainda melhor, mas não temos nenhuma parceria oficial com eles. Escrevemos o hook post-receive do lighthouse porque queríamos, o Rails queria e um grande número dos nossos usuários queria.

AkitaOnRails: Muitos outros começaram a migrar para o Github durante o Beta. Acho que o Merb foi mais óbvio por causa do envolvimento do Ezra com a Engine Yard. Dr. Nic começou a usá-lo para os bundles do Textmate. Você pode apontar algum outro projeto relacionado a Rails de alto perfil hospedado no Github agora?

Chris Wanstrath: Merb foi na verdade o motivo pelo qual o Github entrou em beta. Lançamos o beta para que eles pudessem começar a usar o site para a reescrita 0.9 do merb-core. Quanto a projetos populares, a melhor coisa a fazer é verificar http://Github.com/popular/watched e http://Github.com/popular/forked. Datamapper, Rspec e Mephisto são alguns dos populares.

AkitaOnRails: Você está usando código Git vanilla, ou o customizou de alguma forma para melhor se adaptar ao seu ambiente? Já conversou com Junio Hamano ou algum outro mantenedor do core do Git? Com o Github provavelmente consumindo muito do seu tempo, como estão o Chow e o FamSpam agora? Como você está gerenciando todos esses produtos ao mesmo tempo?

Chris Wanstrath: Patcheamos o Git-daemon para registrar estatísticas, que em breve vamos surfacear no site na forma de atividade melhor e mais granular. Você poderá ver quantas vezes seu projeto foi clonado, projetos populares nas últimas 24 horas, projetos mais clonados de todos os tempos, esse tipo de coisa.

Enviamos e-mail para os caras do core do Git sobre o site, só para dizer obrigado por escreverem o Git e para informá-los sobre o Github, mas na verdade não tivemos ocasião de conversar sobre nada em particular. Se algum dia me cruzar com algum deles, definitivamente vou pagar algumas doses.

Na verdade, não trabalho mais no Chow. Meu último dia na C|NET foi há quase exatamente um ano, então meu tempo com Ruby é gasto no FamSpam, Github, open source e fazendo trabalho de cliente ocasionalmente.

FamSpam está indo bem. Agora que o Github foi lançado, há alguns recursos que queremos adicionar. Por sorte, no entanto, o site está muito polido e rodando sem precisar de muita intervenção. O que adoraríamos fazer, porque no fundo é uma ótima lista de e-mail baseada em Rails, é experimentar alguns conceitos diferentes.

Talvez um para open source, ou uma versão para times de liga juvenil — qualquer um que precise manter contato e ter seu fluxo de e-mail e compartilhamento de documentos otimizado. Por ora, no entanto, tento gastar o máximo de tempo possível no Github. Há tantos lugares para onde queremos levá-lo.

AkitaOnRails: Provavelmente já ultrapassei o tempo da entrevista (me desculpe por isso), mas essa conversa é super interessante. Um projeto que acabei de lembrar é o Sake. Para mim o Sake é muito bacana porque muita gente reclama de quão “difícil e complexa” é a linha de comando do Git, e soluções como Sake facilitam muito o fluxo de trabalho. Por exemplo, meu fluxo de trabalho Git inteiro para projetos Rails são apenas 4 pequenas tarefas sake como Git:update e Git:push. Se não me engano, alguém do Err fez o Sake, certo? Você ainda está evoluindo ele?

Chris Wanstrath: Sim, eu escrevi o Sake. Não é um plugin Rails, mas foi escrito para ajudar no desenvolvimento Rails. As “tarefas Git” para Sake estão ficando bem populares, pois Git realmente facilita um fluxo de trabalho melhor. Se você quiser implementá-lo, ou diferentes ramificações desse fluxo, você pode facilmente empacotar alguns comandos numa tarefa rake ou script bash.

E enquanto scripts bash são ótimos, as tarefas sake são portáteis. Muito do sake foi inspirado, de forma muito livre, no Git — você pode importar tarefas sake de qualquer arquivo de texto, seja na web ou local, e sake vem com seu próprio daemon para servir suas tarefas.

Então você poderia compartilhar tarefas via wifi, por exemplo, da mesma forma que poderia compartilhar repositórios Git numa rede adhoc. Sake está no Github, então fique à vontade para adicionar funcionalidades que achar que devem existir.

AkitaOnRails: Outra coisa sobre a qual gostaria de ouvir sua opinião. Recentemente fiz uma apresentação sobre estratégias de deploy Rails para iniciantes. A arquitetura simples mais comum gira em torno de Apache/Nginx/Litespeed + Mongrel/Evented Mongrel/Thin/Ebb. Geralmente é uma questão de balanceamento de carga entre um servidor web usando algum tipo de IPC para distribuir a carga de volta para VMs Ruby rodando sua app Rails.

Agora temos mod_Rails. Qual é sua opinião sobre ter todas essas escolhas, você tem alguma receita particular que prefere ou depende das necessidades de cada aplicação? Você teve tempo de testar mod_Rails? Acho que Hongli Lai está fazendo um trabalho ótimo em relação a coisas como mongrel_light_cluster e seus esforços para tornar o GC do Ruby mais amigável ao copy-on-write. Você deu uma olhada nisso?

Chris Wanstrath: A coisa boa da Engine Yard é que eles cuidam de tudo isso para mim. Então, enquanto antes passava muito tempo fazendo benchmark e brincando com diferentes soluções, como Mongrel vs Emongrel, agora simplesmente deixo os especialistas cuidarem disso para que eu possa me concentrar no Github.

Então não, ainda não brinquei com mod_Rails porque não estou numa situação em que pudesse implantá-lo mesmo que quisesse usá-lo. Que na minha opinião é a melhor situação para se estar, e é basicamente a razão pela qual mod_Rails foi escrito.

AkitaOnRails: E a propósito, você vai fazer alguma apresentação na RailsConf este ano?

Chris Wanstrath: Vou. Vou falar sobre “Beyond cap deploy”, que será basicamente um olhar aprofundado na arquitetura do Github, e depois vou estar num painel com Ben Curtis, Geoff Grosenbach, P.J. e Tom sobre ser um “programador lucrativo” com projetos paralelos.

AkitaOnRails: Estou muito satisfeito por ter tido a oportunidade de conversar com você.

Chris Wanstrath: Eu também. Obrigado!

Monday, Apr 1st, I was invited to participate in a series of interviews being published at FiveRun’s blog, called TakeFive. It was just published.

Thanks a lot for FiveRuns for choosing me, I am flattered as I don’t yet consider myself in the same luminary league as Chad Fowler, Peter Cooper, Pat Eyler, Satish Talim and all the others in the series. I hope to get up there, though :-)

This series revolves around 5 questions out of 15 that I could choose. Being prolific – as you well know – I actually answered all 15 of them. So I will publish here the remaining 10 that didn’t make into the interview. Hope you like’em.

FireRuns: What was your first “ah-ha” moment with Ruby and/or Rails and when did you know that the framework was a good fit for you (or your organization)?

AkitaOnRails: Back in 2005 I was a Java/SAP consultant creating web applications that integrates smoothly with SAP’s underlying processes and technologies. As an eager RSS reader since than, I suddenly started seeing a lot of buzz around Rails. I already knew about the Ruby language but never did anything with it, so I decided to take a closer look. Coming from a Java background, seeing Rails in action blew me away immediately. So decided to learn it, and once I got ahold of the basics I wanted to dig deeper and read the entire Rails source-code. The outcome of this journey was my book ‘Repensando a Web com Rails’, which is a comprehensive documentation of Rails written exclusively for the brazilian audience. As I was doing SAP stuff I also documented Pier Harding’s Rails connector for SAP.

FireRuns: In his RubyConf 2007 Keynote presentation Matz stated that “The suits people are surrounding us” – is this increasingly the case with the community, and what does this mean for the future of Ruby?

AkitaOnRails: Everytime I do a presentation about Ruby or Rails I emphasize that the best thing about them is not only the tecnology, but the community. The reason for Rails catching up so fast is that the community embraced it very deeply and rapidly started to fill in the several gaps. This lead to many amazing products such as RSpec. The Ruby oriented tools now surpasses those from other platforms in many ways now.

I firmly believe that adoption begins from the inside. The suits guys will not decide by themselves. The developers working inside will make the switch first and start convincing their coleagues and bosses. It is a time consuming process, but done correcly, can change the way we develop for corporations.

FireRuns: Do you have any secret techniques, tools, or other Jedi strategies that you can share with our readers?

AkitaOnRails: Unfortunately I am not in the same league as Rick Olson and other Ruby Jedi Masters. My job has been mainly trying to help our local community through information. I am a very prolific writer and I try to help the word-of-mouth process here, though we are still way behind the US in Rails adoption.

What I always recommend is to learn your tool. The first mistake many novice programmers do when they switch to Ruby is try to write in the same way they wrote C# or Java. That’s also one reason some novice programmers get frustrated because the resulting code becomes very ugly and different from those they see in the various screencasts and blogs. Buy Beginning Ruby, from Peter Cooper; The Ruby Way, the classic from Hal Fulton and watch as many Peepcode, Railscasts screencasts as possible. Learning is part of the process that makes adopting Ruby so enjoyable.

FireRuns: Where do you go for Rails-related news and insight – any particular website, blogs, forums, etc. that are of particular value?

AkitaOnRails: Of course. Actually I subscribe to a lot of RSS feeds, dozens. So the only website I go is Google Reader. Some of my favorites are Peter Cooper’s Ruby Inside, probably the best source of Rails related news. DZone, to me, is becoming more and more relevant. Some of my favorite blogs incluse Err the Blog, Josh Susser’s has_many :through, Charles Nutter’s Headius, etc. There are so many great blogs that it’s, again, difficult to list them all. Jamis Buck, Obie Fernandez, Geoffrey Grosenbach, Ezra Zygmuntowicz and so on. I usually read the digest version of the Ruby on Rails Core and Ruby on Rails Talk Google Groups as well, which are very informative.

FireRuns: Let’s talk about Rubinius – what do you see as the major advantage here, even though we’re obviously in the early stages? A test suite at last? A VM that folk can easily hack?

AkitaOnRails: As I always say in my blog, Rubinius is the technology that will become the most important one for the future of the Ruby community. Sorry Matz, but Rubinius is ‘Ruby done Right’. But don’t get me wrong, I don’t say this in a way to diminish the MRI. On the contrary, I love the MRI for what it is, but Rubinius are making all the bold decisions that will make it or break it.

I like Avi Bryant’s motto of ‘Turtles all the way’, and Rubinius represents what I would love to have: Ruby written in Ruby. Just that would be excellent. But Evan is not stopping there, he is making several breakthrough stuff in this project. For instance, I believe the Git buzz in the Rails community really started when Rubinius adopted it. The way of giving the keys to the castle to every single person that contributes is another different paradigm shift as well.

The marriage of Rubinius and Engine Yard is delivering in spades. Rubinius was also probably important to make RSpec even more well known. Now we finally have a full suite technically describing and testing the MRI that both JRuby and IronRuby are making good use of. So it should make Ruby implementations that much more compatible and well behaving.

Evan is a very clever engineer. The way he approached a new Ruby implementation using Smalltalk’s concepts is spot on. So we get the best of both world: the elegant architecture of a Smalltalk VM with the elegance of the Ruby language. It’s a win-win situation. As soon as web framework such as Rails and Merb run without modification on Rubinius, that’s when adoption rates will explode, without a doubt.

FireRuns: Is Rails still waiting for its killer app, or are we already there with Basecamp, Highrise, Twitter, Hulu, Revolution Health, etc.?

AkitaOnRails: You probably listed all the high profile Rails apps out there. Twitter is definitely a killer-app but I am not sure if it is ‘the’ killer-app. For coders, in my opinion, Github has the potential of growing to become a killer app as well. But up until this point I will be honest and say that no, we still don’t have that kind of killer app that would make people come in flocks to Rails.

FireRuns: There was a great article recently on the Rails community in Austin and the Austin on Rails user group specifically. Are you part of a local user group? Tell us about your local community, what you love about it, how it is grown, and what challenges the group sees ahead of itself, in both the near and long term.

AkitaOnRails: Yes, I subscribe to many groups though I don’t participate actively on all of them. Our local group is Rails-br at Google Groups where brazilian Railers discuss about several Rails related subjects everyday. There are a lot of noobs and we try to answer their questions and also we help each other.

It’s growing very slowly, unfortunaly. Different than the US or Europe is that Brazil is an under-developed country. As such, people here give less value to quality of life and enjoyment of their work. They want to be hired, that’s all. And right now people learn Java and C# because they need to. So Ruby adoption is very slow over here. We still wasn’t able to get enough traction to start a positive spiral. There is only my book in portuguese about Rails, the community is small, the media is also small and not paying attention, therefore companies don’t want to try Rails because of shortage of programmers, and programmers don’t want to learn Rails because there are not that many jobs. I hope we can reverse this situation soon.

FireRuns: Obie Fernandez’s new startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. Obie has written about ultra- productivity here, but we have to ask – what are your own tips around, to paraphrase Obie and 37Signals, getting real — on steroids?

AkitaOnRails: I’ve been working with Surgeworks, which is a consulting firm, since June last year. So, I have less than a year of full time Rails experience. Before that I wasn’t doing full time Rails works. But we learned a lot and we still do a lot of mistakes, it’s part of the learning process. If someone tells you that they don’t make mistakes, they are lying.

Getting Real is about being pragmatic. It’s easier if you’re a startup, or yourself a product oriented team. But if you’re a more traditional company, the ‘Getting Real’ approach may feel too radical. It’s funny to say this, but it’s the truth. For them, low prices are higher priority than better quality. They expect Rails to deliver both very high quality and very low prices. There is a lot of convincing and explaining to be able to fully delivery Rails apps that the clients are going to really like.

To me, being a pragmatist is remembering Fred Brooks: ‘there is no silver bullet’. Rails is amazing but is no Silver Bullet either. It is a more elegant tool. But not every tool is able to fit in every job. Some projects are just not suitable for Rails, that’s a fact, but it doesn’t mean Rails is less good, on the contrary: it is great on the kinds of problems it was built to solve.

Programmers have to learn more than simply code. They have to get acquainted with processes and how companies operate. Being an offshore outsourced developer makes it even harder to use Agile methods, for example, so we have to stretch very hard to compensate for that. Communication is key. If the client is not willing to communicate, the project will fail, be it in Rails or not.

FireRuns: The Rails community at large, like many open-source communities, is in our mind very much defined by its charitable work, from the recent acts_as conference Merb/Runinius sessions, to Chad and Marcel’s yearly RailsConf testing tutorials. Is charity in many ways the glue that binds the community together? Any charitable events or initiatives that you’d like to see happen over the next year?

AkitaOnRails: What binds the community together is the common excitement around a subject: in this case Rails. As when you fall in love, passion vanishes very fast if you don’t maintain it. Events are a good way of doing that. You have two for one: you gain exposure for yourself, your project and your company and at the same time you contribute back with knowledge and guidance, helping promote the community all around the country. Whenever Ezra talks, it accumulates more positive points for Engine Yard and makes this brand that more easier to remember by all attendants. Marketing is very important.

In the US there are plenty of events already and still room for more. I would really like to see more action here in Brazil. But without sponsor and more support it is very difficult to make something on the scale of a RailsConf, which is sad. We will keep trying, though.

FireRuns: Charles Nutter recently said that “Not liking JRuby because it is written in Java is like not liking Ruby because it is written in C.” That objection put aside, what is the single greatest challenge for JRuby going forward? Peter Cooper has suggested that Ruby’s only real downside is its lethargic start-up time compared to MRI, do you agree?

AkitaOnRails: I agree with Peter about JRuby being slow to start up, but that’s something that Charles can’t do much about because the JVM behaves like that for everything, not only JRuby. The important part about JRuby is it being fully compatible with the MRI, making it easy to develop using the MRI and then deploying into a Java application server over JRuby.

Being a former Java programmer I don’t dislike. On the contrary, I think it is a great platform, with several amazing libraries and tools that the Ruby community still don’t have. Dismiss Java is a mistake, the same way it is a mistake to dismiss C: everything is written in C.

JRuby is the second most important Ruby project, Rubinius being the first. On the other hand, JRuby is more mature and available right now so you can run your Rails app inside your corporation’s Java servers. It’s very important for a niche that needs access to legacy software – lots of old Java code. It is also important for making the point that Java doesn’t need to be the sole language to run on top of the JVM and helped making Sun more flexible towards new advancements.

Ele também postou um excelente screencast sobre o novo framework MVC alternativo da Microsoft e achei que seria ótimo tê-lo aqui no blog para falar sobre tecnologia e frameworks web. Como já disse antes, acho que não devemos ficar alheios ao que está acontecendo em outras frentes, e Scott é uma pessoa de pensamento avançado e mente aberta.

AkitaOnRails: Antes de tudo, deixa eu te parabenizar sr. progman.exe :-) Entendo que isso foi algo pelo qual você estava muito animado. Pode nos contar um pouco mais sobre sua transição para a Microsoft e suas novas responsabilidades?

Scott Hanselman: Estou trabalhando para Simon Muzio, que cuida de www.asp.net, www.iis.net e grandes sites cheios de conteúdo como esses. Gosto de pensar que meu trabalho é escrever um livro que nunca vai terminar, onde esse livro são posts de blog, artigos, screencasts, vídeos, palestras, etc. No fundo sou um professor, então mesmo tendo o título de “Community Liaison”, prefiro “Professor”.

AkitaOnRails: Conta pra gente sobre sua história. Como você começou no mundo da computação? Você sempre foi mais voltado para Windows ou tinha uma base no mundo Unix também? E antes de sua recente saída para a Microsoft você trabalhava na Corillian. Qual era sua função lá?

Scott Hanselman: Este post de blog fala sobre meus primeiros anos na escola.

Viu aquele livro à direita? Foi assim que aprendi a programar. Esse livro era O livro em 1984. Digitei o livro inteiro num Commodore 64.

E uma professora MUITO influente que me colocou no caminho certo.

Marianne Mayfield é minha professora da quinta série e a razão pela qual estou em computação hoje. Ela esteve no meu casamento, em formaturas, em eventos de família. Vinte anos depois ainda somos próximos. Quando eu era jovem, ela reconheceu que eu estava “em risco de dar problema” e se sentou com minha família para encontrar uma forma de me colocar de volta nos trilhos. Ela viu que eu estava fascinado pelo Apple II na nossa sala de aula e arranjou para que a gente pudesse levar o computador para fora da escola, desde que estivesse de volta antes do domingo à noite sem que ninguém notasse.

(clique nos links acima para mais detalhes)

Scott Hanselman: Eu era o Arquiteto-Chefe na Corillian, trabalhando com outros engenheiros e arquitetos em toda a empresa, planejando, projetando e codando a próxima geração da Plataforma de Internet Banking da Corillian.

AkitaOnRails: Aplaudo sua campanha Team Hanselman para ajudar no combate à Diabetes. Entendo que você também tem Diabetes e que, felizmente, conseguiu controlá-la hoje em dia. Pode nos contar essa história e os objetivos da sua campanha?

Scott Hanselman: Minha história pessoal está aqui:

Atualmente tomo três injeções de Symlin por dia enquanto uso uma bomba de insulina 24 horas por dia, inclusive enquanto durmo. A bomba me poupa de mais seis injeções por dia, que tomei durante 8 anos antes da bomba. Meço minha glicose picando meu dedo entre 8 e 10 vezes por dia — são cerca de 46.500 picadas até agora, e ainda há um longo caminho pela frente.

E tem uma boa explicação da diabetes aqui:

É aqui que a analogia fica interessante. Lembre que na analogia estamos voando de Los Angeles para Nova York, mas só podemos verificar nossa altitude sete vezes. E só podemos mudar de altitude (tomar insulina) menos de dez vezes. Mas quando verifico minha glicose, estou vendo o passado. Estou vendo uma leitura de como estava minha glicose há 15 minutos. E quando tomo insulina, ela só começa a reduzir minha glicose depois de pelo menos 30 minutos.

A campanha acabou arrecadando mais de USD$30.000, e esse dinheiro será aplicado em pesquisa, educação e programas relacionados à diabetes.

AkitaOnRails: “O que diabos você estava fazendo numa RailsConf?” Isso é o que acho que pessoas de fora do mundo de blogs Microsoft perguntariam a você :-) Então, você é apenas curioso sobre Rails, ou chega a desenvolver aplicações baseadas em Rails? Estou muito interessado em conhecer sua opinião sobre Rails. Como você o encontrou? O que você acha de melhor no Rails? E mais importante, o que você acha que Rails poderia melhorar?

Scott Hanselman: Estou sempre experimentando diferentes linguagens de programação e frameworks. Tenho feito Rails de vez em quando há cerca de 18 meses, mas ainda não clicou pra mim. Tenho certeza que vai em breve. O padrão MVC é muito antigo… eu fazia isso em Java há mais de 10 anos, e certamente o padrão remonta a 30 anos. Acho que Rails é um bom framework considerando sua pouca idade. Mas acho que é o Ruby que tem a magia de verdade, e vejo que a estética do Ruby está muito em linha com a minha.

AkitaOnRails: Então, seguindo minhas preferências tendenciosas, o próximo artigo de que gosto é seu screencast sobre o framework CTP ASP.NET MVC. Vejo que esse novo framework se parece muito com Rails. Claro, pode parecer assim apenas porque ambos implementam MVC. Por outro lado, ele usa expressões muito similares ao Rails em todo lugar. Falta um pouco de “mágica de convenção-sobre-configuração”, mas pelo que vi parece muito melhor do que fazer ASP.NET convencional. O que você acha dele? Pode resumir um pouco para quem não conhece esse produto? E o que você acha que ainda vai melhorar nele?

Scott Hanselman: Se alguém aponta para Rails e diz “isso é MVC” então tudo mais vai se parecer com Rails, claro. Qualquer bom framework MVC precisa não só seguir o padrão adequadamente, mas também abstrair o HTTP (assumindo que é um framework web) de forma limpa, mas não completa. A implementação do ASP.NET MVC ainda carrega alguma bagagem que sempre vai precisar carregar porque o ASP.NET WebForms veio primeiro e não foi projetado do zero com testabilidade em mente. Dito isso, tudo se resume a alternativas. Use o framework que te deixa feliz e em que você se sente mais produtivo. Alguma fração, talvez 20%, dos desenvolvedores ASP.NET vai preferir MVC. Agora eles têm uma opção com suporte da Microsoft e boa integração com C# 3.0.

na RailsConf'07

AkitaOnRails: E o que seria o mundo tech sem discussões e flame wars? Entendo que a maioria dos desenvolvedores .NET nem presta atenção a Rails ou outros frameworks. Até ouvi que há alguns desenvolvedores questionando coisas como “Por que mais um framework web se o ASP.NET já existe?” Ou seja, por que reinventar a roda e dividir atenções? Particularmente acho que esse novo MVC é o caminho a seguir, mas é inegável que o velho ASP.NET tem muito mais aceitação e suporte. Como reconciliar os dois pontos de vista?

Scott Hanselman: Isso é puro FUD (fear, uncertainty, and doubt — medo, incerteza e dúvida). Que pensem o que quiserem, esse framework é apenas sobre alternativas. WebForms é ótimo, e se você está fazendo aplicações Line of Business (LOB) com grids complexos e afins, ele não vai a lugar nenhum. No entanto, se você é uma equipe ágil que preza TDD e ficou frustrado com ViewState, então confira ASP.NET MVC. Não há nada a reconciliar. Algumas pessoas vão de carro, outras de moto, outras a pé. O que importa é chegar do ponto A ao ponto B e se sentir bem durante a jornada.

AkitaOnRails: Falando em flame wars, há provavelmente um assunto que me dá arrepios: as teorias conspiratórias paranoicas sobre Miguel de Icaza e o Mono. Muita gente acredita de fato que Miguel está “vendendo” parte do mundo open source para a Microsoft. Você já usou? O que você ouve da comunidade e qual é sua opinião sobre o assunto?

Scott Hanselman: Sim, já usei Mono e acho que é uma ótima forma de fazer sua aplicação .NET funcionar no Linux ou Mac. Acho Miguel brilhante e um excelente dançarino. Ouço na comunidade que as pessoas estão felizes por Mono existir e estar disponível como uma opção.

AkitaOnRails: Provavelmente vou levar uma maldição por isso, mas não sou “fortemente” contra a Microsoft como alguns fundamentalistas são. É público e notório que a Microsoft é uma grande corporação e, como tal, cometeu sua parte de atos equivocados. Muitos deles já foram resolvidos na justiça. Então é mais complexo do que as pessoas geralmente pensam. Prefiro assumir que dentro da Microsoft há muitas pessoas muito inteligentes.

Scott Hanselman: Fico fora de questões legais. A Microsoft é uma empresa enorme com muita gente inteligente, mas na prática é muitas empresas de porte médio trabalhando juntas (geralmente). Não posso falar sobre “atos equivocados”. Só posso dizer que faço meu melhor todo dia para não ser mau, assim como meus colegas de trabalho. Não há nenhum plano maléfico mestre no meu grupo.

AkitaOnRails: Particularmente gosto do roadmap para Windows Server 2008 (com sua abordagem minimalista, finalmente tendo instalado apenas o que você precisa). No ano passado você estava experimentando o IIS 7 e seu novo suporte a FastCGI. Acho que era destinado principalmente ao suporte de PHP mas teoricamente poderia lidar com Ruby on Rails também. Você já tentou Rails lá? Acho que a Microsoft claramente está indo atrás do segmento de menor custo com Windows Server 2008 + IIS 7, contra as caixas baratas de Linux+Apache. Acho que não conseguirão chegar lá em termos de preço, mas o que você acha dele como competidor de serviços de internet?

Scott Hanselman: Tenho pouco poder nessa arena, mas toda vez que alguém quiser ouvir estou defendendo um SKU barato de Servidor Web. Sou um grande fã do IIS7 e gostaria que o máximo de pessoas possível o experimentasse. Não testei IIS7+Rails mas ouvi rumores de pessoas conseguindo fazer funcionar.

AkitaOnRails: Há muitos recursos novos no .NET 3.5. LINQ é o que mais me interessa. Pode nos dar uma breve descrição de por que é tão interessante? E o que você acha das melhores melhorias da versão 3.5? Você já está usando o Orcas? Qual é sua opinião? Ah, e você conhece o projeto Sapphire in Steel?

Scott Hanselman: LINQ é interessante porque é sua própria Linguagem de Domínio Específico para consultar objetos de todos os tipos, e está vivendo diretamente dentro de VB e C#. É um compilador MUITO mais inteligente e é um prazer trabalhar com ele. Instalei o Sapphire In Steel e conheço algumas pessoas que adoram. Estou animado para ver Rails no .NET.

AkitaOnRails: Uma das vantagens da estratégia Microsoft .NET foi estar preparada desde o primeiro dia para ser agnóstica em relação a linguagens. Agora temos o DLR que foi derivado dos trabalhos no IronPython e não no IronRuby. Mas há ainda outra linguagem interessante que poucas pessoas conhecem: F#, a linguagem inspirada em OCaml. Você já experimentou?

Scott Hanselman: Sim, e fiz dois podcasts sobre ela, um com Robert Pickering, autor de um livro sobre F# e outro com Dustin Campbell, um entusiasta. Estou animadíssimo que ela vai ser uma linguagem de primeira classe dentro do VS.

com John Lam

AkitaOnRails: Não sou contra comparações técnicas, precisamos fazer esse tipo de coisa para decidir nossos passos em projetos. Mas sou contra desafios sem sentido. Rails está longe de ser perfeito e sou o primeiro a dizer isso. Dito isso, é ótimo para um nicho específico de desenvolvimento web. Costumo recomendar que bons programadores devem expandir seus horizontes e aprender o máximo possível de coisas novas. Não dá para saber tudo perfeitamente, mas é sempre bom estar ciente das possibilidades. Você escreveu algo nessa linha. O que você acha disso?

Scott Hanselman: Rails é bom no que faz dentro do seu nicho. Você não cria aplicativos desktop Windows com Rails e tudo bem. É por isso que não comparamos Rails com WPF, mas com frameworks web. Comparação é boa e sempre há algo bom para encontrar dos dois lados. Evito flame wars também. É inútil. Se o sapato aperta, não use. Mas experimente o máximo de sapatos que puder!

AkitaOnRails: No ano passado você escreveu um post interessante sobre o futuro. Google é esse grande gigante, Amazon lançou produtos surpreendentemente bons nos últimos meses como S3, EC2, SimpleDb. Não estou bem a par da estratégia atual do Microsoft Live. Pode dizer algo sobre para onde está rumando?

Scott Hanselman: Não estou nesse grupo então não tenho nenhum conhecimento além do que já foi dito. No entanto, ainda mantenho minhas previsões naquele post!

A computação vai se mover para a Nuvem. Já está acontecendo, estamos 20% lá. A ideia existe desde o começo e vai, na minha opinião, continuar surgindo até que realmente aconteça e construamos a Skynet. Uma dessas nuvens de computação vai certamente acabar em órbita.

AkitaOnRails: E claro, de certa forma “preciso” te perguntar isso: você usa Windows Vista? Como tem sido para você considerando que há uma enorme campanha underground contra ele? Você acha que é tão ruim quanto todo mundo diz? Não posso comentar porque nunca o testei fora da minha máquina virtual (sou um cara de Mac), mas eles venderam 100 milhões de licenças.

Scott Hanselman: Com certeza. Rodo Vista 64-bit em 3 máquinas e Vista 32-bit em 2 máquinas. Foi difícil nos primeiros 3 meses enquanto o suporte a drivers deixava a desejar, mas agora está ótimo. Tenho 2 máquinas com Vista que não foram reinicializadas há meses, apenas colocadas em modo de suspensão e acordadas. Depois que você consegue bons drivers de vídeo, geralmente tá tranquilo.

As pessoas implicam com o Vista, mas esquecem a vasta gama de hardware em que ele tem que rodar. O OS X só precisa rodar em Macs, e em uma faixa estreita deles. O Vista tem que rodar em milhões de combinações de hardware. Drivers de terceiros são DE LONGE o que mais trava o Vista, e ele leva a culpa. Por isso rodo 64-bit e uso apenas drivers assinados. Estou encantado com o 64-bit. Funciona muito bem.

AkitaOnRails: Ok, é isso :-) Muito obrigado!

English Readers: click here

Foi Avi Bryant que evangelizou a idéia de “tartarugas o caminho todo”, querendo dizer que para uma linguagem se considerar ‘completa’ ela deveria ser capaz de estender a si própria. Então, o mundo ideal teria Ruby sendo estendido por Ruby, não em C. JRuby vai tão longe quanto pode construindo um sandbox para código Ruby rodar sobre a JVM. Por mais legal que seja, ainda precisamos de Java para podermos estendê-la.

Entra Rubinius e seu autor Evan Phoenix , atualmente contratado em tempo integral pela EngineYard. Rubinius pega pesadamente emprestado dos conceitos de virtual machine de Smalltalk e faz o menos possível em C somente para conseguir o boot inicial e todo o resto é desenvolvido em Ruby puro.

Rubinius responde a várias questões sobre o futuro do Ruby MRI mas também levanta diversas perguntas que espero que possamos responder hoje nesta entrevista com o próprio Evan.

Então, vamos começar.

AkitaOnRails: Já é uma tradição em minhas entrevistas perguntar sobre o histórico do programador. Qual foi seu caminho? Quero dizer, o que o fez entrar no mundo da programação e como entrou em Ruby?

Evan Phoenix: Eu comecei a programar no colégio com um amigo meu. Começamos uma pequena empresa de computador fazendo várias coisas e eu realmente entrei nisso de cabeça. Eu entrei em Linux alguns anos atrás, então programação se tornou uma extensão natural no meu uso de Linux.

Quando entrei pra faculdade, apliquei para o curso de Ciências da Computação, e venho fazendo isso desde então eu acho.

Sobre Ruby, eu entrei nisso mais ou menos em 2002, logo que me mudei para Seattle. Um amigo tinha acabado de descobri-la e estava escrevendo coisas legais nela e eu peguei por sugestão dele. Eventualmente, encontrei o grupo seattle.rb e tenho trabalhado em Ruby desde então.

AkitaOnRails: A EngineYard parece ter uma grande fé no futuro do Rubinius. Como esse relacionamento começou? Pode nos dizer quais são as expectativas da EngineYard sobre seu trabalho para eles?

Evan Phoenix: O relacionamento começou principalmente com eles se aproximando de mim sobre trabalhar para eles, no Rubinius. Então eles viram promessa no Rubinius por conta própria, das minhas apresentações e tal, e eles se aproximaram.

As expectativas deles é que eu faça Rubinius ser a melhor VM de Ruby que possa existir. Essa é a minha ordem básica deles. Eles são provavelmente os melhores supervisores para esse projeto. Eles me permitem trabalhar no ritmo que quiser, eles entendem os rigores do trabalho que estou fazendo, e me dão muita liberdade.

AkitaOnRails: Agora, vamos entrar no Rubinius. Para iniciantes como você definiria Rubinius? Todos sabemos que é uma implementação alternativa de Ruby, então talvez fosse interessante dizer o que o torna diferente do MRI. Quais são os objetivos do projeto?

Evan Phoenix: Um dos objetivos primários é ter o máximo possível do sistema escrito no próprio Ruby. No MRI, nenhuma das classes principais são escritas em Ruby, tudo é em C. Então nós queríamos um sistema que fosse fácil de se trabalhar, e portanto escrito no próprio Ruby.

Outra coisa que fizemos é enriquecer o número de coisas que são objetos, o que adiciona poder considerável. Um exemplo simples é a classe CompiledMethod que o Rubinius tem. Ele contém a representação em bytecode de um método e ele pode ser inspecionado, manipulado, etc, como qualquer outro objeto. Isso abre várias portas em relação a como problemas podem ser resolvidos.

AkitaOnRails: Não é tão óbvio para a audiência brasileira falar sobre “Squeak”, “Garnet”. Smalltalk é provavelmente menos conhecido por aqui do que Ruby (estou chutando). O que quero dizer é que é bem sabido que você se inspirou na maneira como Squeak é implementado. Isso levou a funcionalidades como “Cuby”. Pode nos explicar o que é tão legal sobre a maneira como Squeak é implementado e como isso o ajuda no projeto Rubinius?

Evan Phoenix: Bem, estamos atualmente no processo de desenvolvimento do Garnet/Cuby, então essas ferramentas ainda não estão em uso. Mas quase toda a arquitetura do sistema do Rubinius é modelado a partir da Virtual Machine Smalltalk-80 original. Ele definia coisas como CompiledMethod, etc, que eu copiei nome por nome no Rubinius.

Além disso, o modelo de execução do Rubinius é quase idêntico ao Squeak. Um bom exemplo é a maneira como o sistema chama métodos e entende como rastrear o retorno de controle ou quando uma chamada de método retorna. Toda essa informação é mantida em objetos de primeira classe chamadas MethodContexts. Em uma linguagem como C, essa informação é armazenada na pilha de memória dos processos. Mantendo os dados em objetos de primeira classe, somos capazes de consultá-los diretamente para encontrar informações sobre o sistema em execução. Isso também largamente simplifica como o garbage collector funciona.

AkitaOnRails: Hoje vocês tem o Shotgun. Li em algum lugar que você considera isso ‘trapaça’ porque não é um interpretador para Ruby escrito em Ruby, e isso nos levaria a Cuby. É mais um tipo de facilidade para o desenvolvimento. Qual o estado atual do shotgun, podemos usá-lo fora de seu propósito de desenvolvimento do Rubinius?

Evan Phoenix: Shotgun é uma virtual machine escrita em C que fornece instruções e operações primitivas para rodar uma linguagem parecida com Ruby. O Shotgun por si próprio não tem conhecimento sobre parsing, compilação, etc. Ele tem uma maneira muito simples de carregar código nele, e uma maneira de executá-la. Você poderia facilmente desenvolver uma linguagem para o shotgun, de fato, Ola Bini e eu falamos algumas vezes sobre escrever uma linguagem simples no estilo de Lisp que rodaria diretamente no shotgun.

As operações primitivas que ele fornece são meio parecidas com syscalls em um sistema unix. Ele fornece operações bem de baixo nível. Por exemplo, existe uma primitiva de adição que adiciona objetos Fixnum juntos e coloca o resultado na pilha.

AkitaOnRails: Isso é apenas uma curiosidade pessoal. O MRI hoje usa um simples garbage collector (GC) mark and sweep enquanto o Java usa um altamente customizável GC de geração. O que você escolheu como gerenciamento de memória na VM do Rubinius?

Evan Phoenix: Rubinius usa um GC de geração, combinando um copy collector para objetos jovens, com um coletor mark and sweep para a geração velha. Isso de provou funcionar bem para nós. O truque tem sido otimizar quanto tempo um objeto existe antes de promovê-lo para o espaço de objetos velhos. Otimizamos apenas um pouco. Há muito mais trabalho que poderia ser feito no GC, e ele é arquitetado para apenas interagir com o resto do sistema em alguns poucos pontos, então sua lógica é completamente substituível se for preciso sem atrapalhar nada de fora.

AkitaOnRails: Temos partidos que favorecem green threads, outros que são pró-threads nativas. Como está lidando com o assunto de threads no Rubinius? Ainda vamos ter o mesmo tipo de trava global que o MRI tem hoje?

Evan Phoenix: No momento, Rubinius tem somente green threads, construídos sobre os objetos MethodContext de primeira classe. Isso atualmente usa libevent para permitir threads esperar objetos de IO rapidamente.

O plano (provavelmente para 2.0) é suportar threads nativas também em paralelo às green threads. Você será capaz de alocar um pool de threads nativas que as green threads podem compartilhar. Então talvez você tenha 100 green threads, e poderia alocar 10 threads nativas para elas dividirem o tempo entre elas. Por causa da arquitetura, é trivial migrar entre green threads e threads nativas.

Sobre a trava global em threads nativas, não, não consideramos uma trava global uma solução para usar threads nativas. Se existir uma trava, não há razão para usá-las em vez de green threads. Como muito do Rubinius é escrito em Ruby, temos mais facilidade de entender como travar coisas apropriadamente para manter todos os objetos no sistema seguros. Na realidade ainda nem começamos esse trabalho, mas têm se falado bastante sobre isso.

AkitaOnRails: O objetivo atual é provavelmente fazer o Rubinius o mais compatível com o MRI 1.8 quanto possível. Já começaram algum trabalho em direção à compatibilidade com YARV? E falando em YARV, ela é a virtual machine e compilador de bytecodes oficial para a próxima versão do Ruby. Existe alguma chance de fazer Rubinius e YARV terem bytecodes compatíveis ou isso não é um objetivo de curto prazo?

Evan Phoenix: Estamos ativamente trabalhando em direção à compatibilidade com 1.8.6. Esse é um grande objetivo porque existe muita funcionalidade lá. Faremos um lançamento 1.0 do Rubinius quando ele for capaz de rodas todas as especificações do 1.8.6 e rodar Rails apropriadamente, que é um bom benchmark.

Não, não fizemos nenhum trabalho em direção a compatibilidade com YARV, mas da forma como as coisas foram arquitetadas, talvez sejamos capazes de simplesmente criar um flag —yarv que você passará ao Rubinius para que ele use coisas compatíveis com YARV.

Não estamos atualmente trabalhando em direção a um bytecode comum entre Rubinius e YARV, principalmente porque não há nada a se ganhar fazendo isso. Da última vez que olhei, o bytecode do YARV é uma coisa interna do YARV somente, e você não poderia facilmente salvá-la para um arquivo. O Rubinius primariamente trabalhar sobre arquivos .rbc, que contém um CompileMethod serializado, e portanto contém os bytecodes. Isso dito, eles são similares e poderiam ser unificados se virmos necessidade disso.

AkitaOnRails: Performance é sempre assunto para muita discussão e ainda é prematuro falar sobre performance no Rubinius, já que ainda é um trabalho em andamento. Mas eu li no seu blog que ele está ficando rápido depressa, mesmo ultrapassando o MRI em muitos testes. Como a performance está evoluindo?

Evan Phoenix: Atualmente, a performance está evoluindo devagar. Isso principalmente porque não é uma prioridade para as pessoas escrevendo o kernel do Rubinius (a maior parte do código Ruby que a constrói). À medida que formos chegando mais próximos da compatibilidade, começaremos a otimizar as coisas. Isso dito, eu realmente escrevo código para tornar Rubinius mais rápido aqui e ali. Fomos adiante e implementamos operações matemáticas rápidas para acelerar a matemática mais comum que as pessoas fazem. Temos um profiler simples que pode ser facilmente ligado para dar feedback aos desenvolvedores sobre como seu código está rodando.

AkitaOnRails: Um dos principais problemas para qualquer implementação alternativa do Ruby é que ele tem um monte de extensões em C, incluindo um monte de bibliotecas principais. Então, se quiser se manter “Ruby-puro” tem que reimplementar todas elas em Ruby. O pessoal do JRuby teve que passar por algo assim. Existe alguma colaboração entre projetos sobre esse assunto?

Evan Phoenix: Na realidade, isso não é bem verdade. Também vimos que Ruby inclui muitas extensões em C. Para tornar a migração para o Rubinius mais rápida, escrevemos uma camada no Rubinius que permite que todas essas extensões C rodem (quase) sem modificação, somente requerendo uma recompilação. Funciona de tal maneira que coisas como ImageScience, RMagick, bindings de postgres, etc possam ser usadas sobre Rubinius sem ter que ser reescritas.

AkitaOnRails: Ainda sobre código C, sei que é difícil entregar bytecode de virtual machine e ainda ser dependente de código C não-gerenciado. Java tem coisas como JNA, .NET tem pinvoke. Você planeja algo similar para Rubinius de tal forma que ele possa mais ou menos facilmente falar com bibliotecas em C?

Evan Phoenix: De fato nós suportamos diretamente um mecanismo chamado de FFI (Foreign Function Interface), que permite a um desenvolvedor ligar funções C diretamente como chamadas de métodos. Aqui vai um exemplo simples:

module LibC
 attach_function nil, :puts, [:string], :void
end

LibC.puts "hello!"

Essa linha de attach_function é a interface primária para o FFI. Você simplesmente indica em qual biblioteca a função está (nesse caso, nil é usado porque está dentro do próprio processo), o nome da função (puts), os tipos dos argumentos que ele leva (apenas 1, um string) e, finalmente, o tipo do retorno (void, ou seja, nada).

Usando isso, você pode ligar diretamente a funções C sem ter que escrever um wrapper em C.

AkitaOnRails: Você está muito certo quando diz que especificações formais de linguagem muito cedo podem dificultar como a linguagem evolui. Ruby tem crescido nos últimos 10 anos já, e parece que este é o momento certo de começarmos a pensar em alguma coisa desse tipo, de tal forma que tenhamos uma base a partir de onde qualquer outra implementação alternativa possa começar. Você vê esforços para isso?

Evan Phoenix: Nós temos ativamente trabalhado no desenvolvimento de um conjunto de especificações (em formato rSpec) para o 1.8. Isso forma o mecanismo principal como qual testamos como o Rubinius está indo. Essas especificações estão sendo ativamente utilizadas pelo JRuby e IronRuby para testar seus respectivos ambientes Ruby. Estamos atualmente no processo de mover essas especificações em um projeto genérico de especificações Ruby para tentar a começar a mover as coisas para um padrão mais formal.

AkitaOnRails: Outra pergunta recorrente é sobre Rails, claro. Qualquer nova implementação de Ruby hoje terá que encarar a pergunta inevitável: ele já roda Ruby? :-) Rails está servindo meio que como uma ‘mini suite de testes’ e uma base para a maioria das implementações. Como Rubinius está nesse sentido?

Evan Phoenix: Quando rodarmos Rails, saberemos que estamos próximos o 1.0 :-)

AkitaOnRails: Você tem uma proposta interessante em relação a gerenciamento de projeto open source: todos que lhe enviam bons patches ganham acesso de commit ao repositório. Como isso está funcionando para você? Não é um pouco confuso ou as pessoas tendem a seguir sua liderança e sua lista de prioridades?

Evan Phoenix: De fato está funcionando muito bem até agora. Por ser orientado a especificações/testes, as novas pessoas tem um lugar por onde começar, seja escrevendo especificações que estão faltando ou fazendo as existentes passar. Isso se tornou uma grande introdução a todo o sistema para eles. Então eles começam a explorar um pouco mais e normalmente encontrar mais e mais do que gostar a ajudar. Como temos um monte de trabalho a fazer em várias diferentes partes, as pessoas não tem que se preocupar com minha lista de prioridades, já que ela envolve coisas que os outros não precisam ficar ativamente preocupados a respeito.

Realmente o que eu disse não é suficiente para descrever como as pessoas tem contribuído. A barreira de um patch provou funcionar muito bem porque embora tenhamos mais de 60 committers, nenhuma vez precisei revogar esse acesso de alguém. Claro, as pessoas erram, mas em todos os casos, a pessoa corrigiu o comportamento e/ou código.

AkitaOnRails: Um sub-produto nesse esquema de acesso de commit é a integração com o rSpec no projeto Rubinius de tal forma que você tem uma ótima ferramenta de requerimentos e uma suíte de testes. Você pratica Behavior Driven Development? Ou isso está cobrindo apenas um pequeno sub-conjunto do projeto?

Evan Phoenix: Eu sou ainda um amador em testes, simplesmente seguindo guias feitos pelo Brian Ford, o principal mantenedor de especificações do projeto. Isso se provou ser uma grande ferramenta para ver como o projeto está progredindo.

AkitaOnRails: Assim como muitos projetos Ruby, Rubinius também é gerenciado sobre GIT. Tem havido muito barulho sobre Git e Ruby ultimamente. Você acha que é uma nova tendência? Por que decidiu ir com Git?

Evan Phoenix: Sim, acho que Git está pegando como uma tendência, por causa das funcionalidades que ele oferece sobre o subversion, principalmente.

A grande razão para nós foi seu conjunto de funcionalidades. Uma grande que eu adoro são branches locais, permitindo a uma pessoa gerenciar várias mudanças grandes sem atropelar os outros.

Ainda não fizemos, mas planejamos exercitar as grandes capacidades de merge e branches públicas.

AkitaOnRails: Ouvimos do Ezra numa entrevista recente sobre seu novo experimento sobre multi-VM. Isso seria uma bênção para deployment sem ter que lidar com diversos processos em um cluster mongrel. Poderia nos descrever essa funcionalidade e apontar suas vantagens?

Evan Phoenix: Atualmente é bastante experimental, mas ele vai se estabilizar com o tempo. A idéia é que você pode subir uma nova VM no processo atual. Essa nova VM é completamente separada das outras VMs, vivendo em sua própria thread nativa e tendo seu próprio garbage collector, etc.

Existe um mecanismo para as VMs se comunicarem entre si, e isso permite que elas coordenem tarefas. Isso poderia significar que uma thread primária poderia aceitar novas conexões, então passá-las a uma nova VM para realmente processar. Isso lhe permite processar conexões realmente em paralelo, e além disso, como as VMs estão completamente separadas, isso funciona até mesmo para aplicações que não são thread-safe como Rails.

AkitaOnRails: Ezra também mencionou sobre um possível mod_rubinius no forno. Como isso está indo? Isso definitivamente torna o pacote Rubinius ainda mais forte. Junto com Merb, Rubinius mais capacidades de multi-VM mais mod_rubinius seriam um pacote de deployment matador.

Evan Phoenix: Sim, um projeto mod_rubinius está apenas começando. O código de multi-VM e do mod_rubinius se sobrepõe um pouco, então você será capaz de ter pools de VMs para sites, todas gerenciadas através do Apache. Esperamos que mod_rubinius possa realmente simplificar o cenário de deployment Rails/Ruby. Ele operará de maneira similar ao mod_python, permitindo a uma VM permanecer rodando entre requisições, e talvez até rodando tarefas em background.

AkitaOnRails: Quanto tempo acha que estamos de um lançamento totalmente compatível com o MRI 1.8?

Evan Phoenix: Ainda não temos uma data firme, principalmente porque o que é ser compatível com MRI 1.8 ainda é incerto. Ainda estamos adicionando especificações, trabalhando para definir apropriadamente o 1.8. Isso dito, estamos realmente atingindo um ponto decisivo e avançando rapidamente. Estamos muito próximos de rodar apropriadamente o Rubygems. Ezra recentemente foi capaz de rodar o Merb sobre Rubinius, rodando sobre Webrick.

Estarei lançando uma versão 0.9 esta semana, porque fizemos muito progresso desde a 0.8. Minha grande esperança é que até a RailsConf, em maio, seremos capazes de rodar Rails. Mas não me comprometa. Isso é um projeto open source afinal de contas. :-)

AkitaOnRails: Obrigado! Acho que isso é tudo.

Evan Phoenix: Muito obrigado pela paciência.

The Ruby Way é, sem discussão, o livro obrigatório na estante de qualquer Rubyist. Em vez de ser um livro de referência, ele explica o que é preciso para mergulhar de verdade nas sutilezas e maravilhas do estilo de programação Ruby.

Hoje estou muito feliz em conseguir bater um papo com um dos meus autores favoritos, Hal Fulton. Foi uma conversa excelente e tenho certeza que o pessoal vai curtir bastante. Ele é um dos veteranos do Ruby e, com certeza, tem muito a compartilhar. Então, vamos lá:

AkitaOnRails: Antes de tudo, é tradição aqui no blog perguntar sobre a trajetória do convidado. Há quanto tempo você está na carreira de programação? Como tudo começou? O que te inspira no mundo da computação?

Hal Fulton: Comecei a faculdade no curso de física, mas percebi que estava fazendo disciplinas de computação por prazer. Migrei para ciência da computação e o resto é história.

Ao contrário da maioria dos jovens de hoje, só tive contato com computadores aos dezesseis anos, porque computadores pessoais eram muito menos comuns na minha época. Fiquei viciado imediatamente. Enxerguei o computador como uma “caixa mágica” capaz de fazer qualquer coisa que eu fosse inteligente o suficiente para programar. Honestamente, ainda me sinto assim.

AkitaOnRails: Já virou quase um clichê, mas preciso perguntar: você foi um dos Rubyists de “primeira geração”. Como você descobriu Ruby e o que foi que “encaixou” pra você na linguagem?

Hal: Eu estava em um contrato na IBM em Austin no outono de 99. Numa conversa com um amigo do corredor, me queixei de que nunca estava no início de nenhuma tecnologia nova — sempre era um adotante tardio. Ele disse: “Bom, então você deveria aprender Ruby.” E eu respondi: “O que é isso?” Aí entrei na lista de e-mails em inglês e comecei a aprender Ruby (versão 1.4).

Minha experiência anterior era com linguagens muito estáticas. Tinha começado (como muita gente na época) com BASIC, FORTRAN e Pascal. Depois aprendi C, C++, Java e várias outras coisas pelo caminho. Mas nunca me aprofundei em LISP e nunca conheci Smalltalk. Então o conceito inteiro de linguagem dinâmica era um pouco estranho pra mim. Eu sempre soube que queria mais poder, mas não sabia exatamente o quê. Tentei imaginar macros que me dessem a flexibilidade que buscava, mas parecia a solução errada.

Aí aprendi Ruby e senti que não tinha dado um salto, mas três saltos de uma vez. Ficou claro que era muito parecido com o que eu vinha buscando inconscientemente.

AkitaOnRails: O Pickaxe é outro livro indispensável, mas cumpre o papel de livro de “referência” completo, enquanto o seu trata das entranhas e fundamentos da linguagem — caramba, você gasta 40 páginas só falando de String, se isso não é detalhado o suficiente eu não sei o que seria. Qual era sua intenção quando escreveu a 1ª edição? Como ela surgiu?

Hal: Conheci Dave Thomas e Andy Hunt online naquela lista de e-mails. Na época, o excelente livro deles The Pragmatic Programmer tinha acabado de sair e eles estavam trabalhando no livro de Ruby. Fui um dos revisores — ajudando a corrigir imprecisões e problemas.

Um pouco depois, a Sams Publishing foi em busca de alguém para escrever um livro. Na época, a lista de e-mails em inglês tinha pouquíssimos falantes nativos de inglês, então eu tinha boas chances de ser escolhido. Enviei uma proposta e eles gostaram.

O Pickaxe ainda não estava nas prateleiras, mas eu tinha conhecimento íntimo do seu conteúdo. Então quando montei a proposta do meu livro, me certifiquei de que não seria concorrência direta — queria que fosse complementar. Se você olhar a página de elogios da primeira edição, há uma citação minha dizendo “Este é o primeiro livro de Ruby que você deve comprar.” Mas em privado eu já pensava: “E eu sei qual deveria ser o segundo.”

AkitaOnRails: Por mais detalhado e completo que você tente ser, Ruby tem várias sutilezas e nuances difíceis de capturar. Havia algo que você não cobriu na época mas teria gostado de explorar mais?

Hal: Certamente existem algumas sutilezas sobre classes e módulos, reflexão, metaprogramação e afins que não foram mencionadas ou não foram suficientemente enfatizadas. Mas, em geral, um programador não deveria tentar ser “esperto demais” no código de qualquer forma.

A omissão mais gritante, na minha opinião, é a ausência de cobertura sobre como escrever extensões em C. Na primeira edição, simplesmente fiquei sem tempo, energia e espaço — não consegui cobrir isso. Na segunda edição, omiti porque achei que a API C passaria por mudanças radicais conforme nos aproximávamos do Ruby 2.0 — mudanças mais radicais do que as classes principais, por exemplo. Isso, no entanto, está se mostrando incorreto.

AkitaOnRails: Você provavelmente encontrou muitos estudantes e entusiastas de Ruby aprendendo através do seu livro. Pela sua experiência, o que você acha que mais impressiona as pessoas na linguagem, e quais são os recursos que mordem os iniciantes logo de cara?

Hal: Acho que a concisão é um recurso muito atraente. Dê uma olhada nesta única linha de Ruby, que cria dois acessores para uma classe:

attr_accessor :alpha, :beta

Como você faria isso em C++? Você declararia dois atributos; depois escreveria um par de funções “leitoras” e um par de funções “escritoras”. Isso é pelo menos sete linhas de código ali. Mas aí, e se você quiser atribuir tipos diferentes a esses atributos? Aí você entra no overloading. Vira um pesadelo rapidinho. Enquanto isso, em Ruby — continua sendo uma única linha de código.

AkitaOnRails: O que você mais gosta no Ruby que o diferencia de outras linguagens similares?

Hal: Uma das melhores características do Ruby é a tipagem dinâmica. Variáveis não têm tipos; apenas objetos têm tipos (ou devo dizer, classes). A tipagem estática estava tão enraizada em mim que eu assumia que era o jeito certo. Mas quando a abandonei, senti como se tivesse removido pesos que nem sabia que estava carregando.

Sua regularidade também é um recurso atraente. Por exemplo, uma classe em Ruby é, em certo sentido, algo “especial” — mas muito menos especial do que em C++, por exemplo. Uma classe é “apenas um objeto”, então você pode fazer com classes o que faz com outros objetos — passá-las adiante, armazená-las em arrays, testar seus valores, e assim por diante.

AkitaOnRails: E o que você melhoraria se fosse o guardião da linguagem?

Primeiro de tudo, fico feliz de não ser o guardião. Matz faz um trabalho excelente e é muito mais inteligente do que eu. Acho que existem alguns problemas com reflexão e programação dinâmica que precisam ser resolvidos — exatamente como, não tenho certeza.

Aguardo ansiosamente uma máquina virtual realmente usável e alguma forma de combinação de métodos (pre, post, wrap). Admito que há pequenas mudanças de sintaxe e de núcleo que gostaria de fazer — na maioria, bem pequenas.

Por exemplo, sempre quis um operador “in” que fosse açúcar sintático para chamar o método include? — por exemplo, “x in y” significaria “y.include?(x)” — esse operador seria essencialmente igual ao operador de pertinência de conjuntos da matemática (em vez de ser o inverso) e às vezes tornaria o código mais legível, inclusive tornando parênteses desnecessários em alguns casos. Uso o operador “in” do Pascal desde os 18 anos; Python tem ele, SQL também em certa medida. Queria que Ruby também tivesse.

Várias vezes senti necessidade de uma estrutura de dados que fosse acessada como um hash, mas que preservasse a ordem especificada no código. Por exemplo, imagine um tipo de “case statement dinâmico” — passamos possíveis correspondências e código para executar (como procs) para cada uma delas. (Teria a vantagem sobre um case statement de podermos controlar o número de ramificações e o código associado em tempo de execução.) Vamos implementá-lo como um método chamado “choose” que chamamos assim:

choose regex1 => proc { handle_case1 }, regex2 => proc { handle_case2}

Qual é o problema? A sintaxe nos engana a pensar que regex1 de alguma forma precede regex2 — mas quando iteramos sobre um hash, a ordem não é garantida como no código. (Isso é uma propriedade dos hashes, claro, não um bug.) Então não podemos controlar ou prever a ordem em que eles são aplicados. E encontrei vários outros casos onde queria algo assim — um array associativo, um conjunto de tuplas, com sintaxe conveniente para literais e com uma ordem.

Há duas respostas usuais para meu desejo de um “hash ordenado”. Alguns dizem que estou louco, que hash não é ordenado e pronto. Outros dizem que posso sempre criar minha própria classe que se comportasse assim — o que é verdade, exceto que não teria a conveniência de representá-lo como “cidadão de primeira classe” na sintaxe Ruby. Afinal, um hash “poderia” ser representado como cidadão de segunda classe também — eu poderia escrever:

Hash["a",2,"b",4,"c",6]

em vez de:

{"a" => 2, "b" => 4, "c" => 6}

Mas sou grato pela expressividade desta última sintaxe.

AkitaOnRails: Sua segunda edição cobre Ruby 1.8. Você já está pesquisando sobre Ruby 1.9 (YARV)? Sendo um veterano de Ruby, o que você acha das direções que Matz e Koichi vêm escolhendo para a próxima versão? Te satisfaz? Para você, quais são o bom, o ruim e o feio sobre Ruby agora e na próxima versão?

Hal: Houve pontos menores onde discordei de Matz de vez em quando. Mas como eu disse, fico feliz que ele esteja no comando. Gosto do YARV pelo que vi até agora. Estou ansioso para que fique 100% estável para que eu possa realmente ter uma noção de como funciona.

AkitaOnRails: Seu livro está na segunda edição e é um livro enorme, cobrindo não só a linguagem em si mas alguns componentes de terceiros como o pdf_writer. Você está trabalhando em uma 3ª edição? Talvez teremos “The YARV Way”?

Hal: Não estou trabalhando em uma terceira edição e acho que seria muito difícil escrever uma. A segunda foi mais difícil do que eu esperava — embora muito conteúdo tenha sido reaproveitado, ainda precisou ser reexaminado linha por linha — e mais de 50 erros ainda se infiltraram nessas 800+ páginas.

Uma vez brinquei que se houvesse uma 3ª edição, talvez precisaria ser dois volumes. Mas na verdade, não seria uma má ideia — conceitos básicos e classes principais em um volume, bibliotecas padrão e de terceiros no segundo. Mas isso é especulação. Há uma espécie de complemento para o livro sendo planejado — mas não vou mencionar isso até sabermos mais detalhes. Me pergunte daqui a alguns meses.

Quanto ao YARV — acho que Ruby sempre será Ruby. Podemos mudar o interior, mas o nome permanecerá o mesmo pelo futuro previsível.

AkitaOnRails: Por volta de 2002 Ruby não era amplamente adotado e apenas um punhado de hobbyistas e entusiastas o usavam e ajudavam a melhorar a linguagem. Você mesmo, David Black, Nathaniel Talbott, e muitos outros pesados do que chamo de “primeira geração Ruby”. Mas em 2004 surgiu esse framework web completo chamado Rails que tornou Ruby publicamente conhecido e reconhecido, atraindo muitas mentes brilhantes mas também muitos trolls e amadores. Ouço dizer que alguns da primeira geração lamentam isso, porque o que era uma comunidade tranquila e perspicaz ficou muito barulhenta. O que você acha desse status de celebridade repentino que Ruby ganhou e seus efeitos colaterais?

Hal: Bem, Ruby não é um clube privado. Será que os japoneses se sentiram ofendidos quando europeus e outros começaram a se interessar por ela? Acho que certamente perdemos um pouco dos velhos tempos, mas não perco tempo pensando nisso. Também ganhamos bastante. E é interessante que a “amizade” da comunidade escalou melhor do que muitos de nós esperávamos. Ruby ainda é Ruby e Rubyists ainda são Rubyists. Apenas há mais de nós agora — também mais projetos, mais atividade, mais oportunidades. Só pode ser algo bom.

AkitaOnRails: Você trabalha com desenvolvimento de sistemas em Ruby puro ou usa Ruby on Rails para desenvolvimento web hoje? Qual é sua ocupação ou trabalho principal?

Hal: Fiz um pouco de trabalho com Rails aqui e ali, mas sou mais um generalista antiquado. Não sou um cara de web. Muitos programadores mais jovens, claro, parecem não perceber que existe qualquer outro tipo de programação a ser feita. Mas se você estivesse escrevendo um compilador ou interpretador, um servidor web customizado, qualquer tipo de daemon ou aplicação de rede em background… você pegaria seu livro de Rails? Claro que não.

Já fiz trabalho em nível de sistema no passado, mas não consigo imaginar Ruby sendo adequado para os tipos de coisas que eu fazia naquela época. Para essas coisas, usávamos C (o assembly universal). No meu trabalho principal, estou feliz codando Ruby todos os dias — trabalhando remotamente para uma empresa de Dallas chamada Personifi. Descreveria meu trabalho como aplicações e ferramentas internas — muita análise de texto e indexação, um pouco de crunching de números e muito crunching de palavras.

AkitaOnRails: Aqui no Brasil temos muita gente que foi inicialmente atraída pela máquina de hype do Rails e agora está se batendo para aprender a linguagem Ruby. Metaprogramação, Closures, Mixins deixam o pessoal maluco. Você tem recomendações para os iniciantes?

Hal: Qual seria um bom jeito de começar a experimentar com a linguagem? Bem, você pode manter uma cópia de The Ruby Way por perto. :-)

Na verdade, tenho apenas três recomendações. Primeiro de tudo, a lista de e-mails ou newsgroup é uma poderosa fonte de informação e ainda há pessoas simpáticas e conhecedoras lá que responderão suas perguntas. Segundo, há milhões de linhas de código Ruby lá fora. Estude e aprenda com eles. Terceiro, e mais importante: Apenas brinque! Você não aprende realmente uma linguagem lendo sobre ela, mas usando-a.

AkitaOnRails: A propósito, você já está escrevendo uma nova edição? :-)

Hal: Não estou e não consigo enxergar tão longe. Mas espere seis ou sete meses, e espero ter uma pequena surpresa para você…

AkitaOnRails: À luz do episódio atual do Zed, ele disse muita coisa especificamente contra o Pickaxe. Uma das coisas é a alegação dele de que o Pickaxe não mencionou claramente toda a questão de metaprogramação. Depois fui conversar com ‘arton’ — um autor de livros Ruby do Japão — e ele me lembrou: americanos e japoneses parecem fazer Ruby de jeitos diferentes. Ele disse que eles normalmente não fazem toda aquela metaprogramação no nível que o Rails faz, por exemplo. Como você disse, eles não tentam ser “espertos demais”.

Agora, não quero ser apologético porque não acho que Dave precisa disso, mas isso explica bastante considerando que o Pickaxe tinha apenas fontes japonesas como referência lá em 2001. Pessoalmente aprendi boa parte do meu Ruby lendo o código-fonte do Rails no início (e livros como o seu depois). O que você acha disso? (quero dizer, sobre o episódio do Zed em geral, e sobre os estilos de programação americano/japonês diferentes?)

Hal: Quanto ao Zed, não vou tomar partido nessa discussão. Zed pode dizer o que quiser, e normalmente faz. Tenho certeza que há alguma verdade dos dois lados em qualquer controvérsia.

Quanto à metaprogramação — bem, acho que essas capacidades estão no Ruby por um motivo. Foram pensadas para serem usadas. Mas qualquer ferramenta tem usos adequados e inadequados. É impossível generalizar e dizer “isso é sempre ruim”, mas certamente a metaprogramação pode ser mal utilizada.

Quanto ao Rails em si, não tenho dúvida de que há código bom e ruim nele. Suspeito que os desenvolvedores que trabalham nele admitiriam isso. É possível que tenham usado “magia demais” aqui e ali, embora eu não possa dizer especificamente onde. Mas o Rails poderia existir sem recursos de metaprogramação? No seu sentido atual — em qualquer sentido significativo, diria que não.

AkitaOnRails: Entrevistei Avi Bryant, famoso pelo Seaside, e um dos seus lemas é que “uma linguagem não está terminada até poder se estender” ou “tartarugas até o fim” como ele diz. Significa que Ruby ainda depende muito de extensões C até hoje. Claro, as motivações iniciais para Ruby são diferentes das do Smalltalk. Por outro lado, pessoas como Evan Phoenix estão perseguindo exatamente esse objetivo: tornar Ruby extensível usando Ruby puro. O que você acha dessa nova direção?

Hal: Gosto da ideia de “Ruby em Ruby” em geral, embora Matz não goste. E estou impressionado com o que vi do Rubinius até agora — acho que é um projeto importante e vai crescer em importância.

Se for possível caminhar para a eliminação de extensões C sem sacrificar velocidade, suponho que seja algo bom. Não tenho certeza se é possível. Poderíamos pelo menos criar um “Ruby em Ruby” que não dependa diretamente do MRI (Matz’s Ruby Interpreter). Mas não espero ver o “Ruby original” ser substituído tão cedo.

AkitaOnRails: Foi uma conversa muito esclarecedora, obrigado!

O Ruby Inside é um dos maiores websites de Ruby/Rails disponível e uma grande fonte de notícias. Seu criador é o empreendedor britânico Peter Cooper, também autor do livro recentemente publicado Beginning Ruby, from Novice to Professional, uma excelente fonte para qualquer um querendo aprender a linguagem Ruby.

Peter fala sobre Ruby on Rails, negócios, iniciantes e, como um exclusivo de última hora, ele comenta o recente episódio nuclear do Zed que chocou muitas pessoas da comunidade. Apenas para deixar claro, Peter respondeu minhas perguntas antes do Ano Novo, é somente a última pergunta que foi adicionada depois.

AkitaOnRails: Para a comunidade Ruby Peter Cooper significa Ruby Inside. Eu pessoalmente gosto de ler seu website já que ele acumula a maioria dos websites importantes de Ruby e Rails por aí. Deixe-me agradecer novamente por adicionar meu blog à lista do seu site. Mas como ele começou? O que você acha que foram os passos mais importante que tomou para construir sua boa reputação?

Peter Cooper: Ruby Inside começou como um veículo para promover meu livro (já lançado) “Beginning Ruby.” O nome mesmo veio de um comentário feito numa entrevista para o podcast de Rails por Geoffrey Grosenbach onde alguém adaptou Ruby no velho slogan “Intel Inside”, que soou como um grande nome para um blog cobrindo coisas de Ruby. Inicialmente, o blog foi simplesmente para promover o livro, mas rapidamente se tornou um resumo de notícias de toda a comunidade Ruby. Acho que a chave de seu sucesso foram os grandes blogs Ruby da época, o blog de Ruby da O’Reilly sendo um bom exemplo, estavam postando cada vez mesmo uma vez que seus escritores estavam pegando mais e mais trabalhos de Ruby. Ruby Inside preencheu o buraco de fornecer notícias altamente digeridas de toda a comunidade Ruby, com apenas um ou dois posts por dia, permitindo desenvolvedores Ruby se manter atualizados com as coisas, mas sem precisar assinar centenas de blogs.

AkitaOnRails: Olhando seu perfil no LinkedIn vejo que esteve bastante envolvido com negócios de internet nos últimos 10 anos. Você também se descrever como um ‘empreendedor serial’. Empreendedorismo é algo muito, muito difícil aqui no Brasil, principalmente por causa da economia e da quantidade absurda de burocracia envolvida. Quão difícil é na Inglaterra para ter seu próprio negócio?

Peter: É muito fácil começar um negócio na Inglaterra. Dependendo do que quer fazer, pode apenas dizer que é um negócio logo de cara, sem preencher nenhum documento (embora você precise contactar o departamento tributário para que eles saibam!), e operar como um sole trader. Registrar um negócio oficialmente, entretanto, é razoavelmente fácil também e lhe dá várias proteções legais e uma imagem mais profissional. Receber investimento e tal não é particularmente fácil aqui, comparado com os Estados Unidos, mas se estiver disposto a começar, então o Reino Unido é muito bom por bancos fáceis, comunicação rápida e negócios com o resto do mundo. Com a vantagem natural da linguagem inglesa, o mercado americano é fácil de mirar do Reino Unido.

AkitaOnRails: Seus outros produtos bem conhecidos devem ser Code Snippets e Feed Digest. Poderia apresentar ambos aos brasileiros que podem não conhecê-los? Como a idéia lhe ocorreu? Foi algo como “coçar a própria coceira” ou foi algo totalmente não relacionado e talvez seguindo alguma tendência que identificou? Que ferramentas usou para construí-las? Muitas pessoas tem interesse em saber o que é necessário para construir um produto de sucesso. O que acha que é necessário para ser um bom empreendedor na internet?

Peter: Code Snippets foi o primeiro repositório de trechos de código “tagueados” no estilo del.icio.us. De fato, acho que foi a primeira aplicação Rails a usar tags, já que eu escrevi o código inicial que foi apropriado em várias bibliotecas de taggings. O site foi lançado no começo de 2005 e eu o vendi em fevereiro de 2007 para a DZone. Feed Digest é um serviço para mashing, processamento e republicação de feeds RSS e Atom para outros formatos, como HTML, Javascript, Flash, imagens e assim por diante. Eu vendi a uma empresa russa no verão de 2007.

Ambos os negócios / sites foram resultado de “coçar a própria coceira” como disse. Eu precisava de um sistema para armazenar trechos de código com tags, e del.icio.us não servia para isso, então Code Snippets saiu depois de uma maratona de 24 horas, foi lançada publicamente, e então cresceu para milhares de usuários com o tempo. Feed Digest evoluiu de um serviço inicial chamado RSS Digest que eu criei para coçar outra coceira, republicar meus links del.icio.us para o cabeçalho do meu blog. Ele cresceu para bem mais que isso, e agora tem mais de 25 mil usuários e serve talvez meio bilhão de requests todo mês. Eu não possuo nem tenho interesse direto em nenhum desses projetos agora, mas eu devo estar indo bem na lista de pessoas vendendo aplicações Rails!

AkitaOnRails: Eu o parabenizo pelo livro recentemente publicado, pela Apress, Beginning Ruby, from Novice to Professional. Como Larry Wright diz em seu review, ele está certo que o Pickaxe é um bom livro de referência, mas você toma um caminho diferente sendo mais cuidadoso sobre o aspecto ‘didático’ do ambiente. Ele preenche um vazio já que há cada vez mais pessoas interessadas em aprender Rails mas não tem um livro introdutório para aprender o próprio Ruby. Por favor, descreva seu livro para nossa audiência já que acho que muitos brasileiros ainda não conhecem seu livro. Qual é seu público-alvo? Do que você fala?

Peter: O livro atualmente está disponível apenas em inglês, infelizmente, então os Estados Unidos foram definitivamente o maior mercado alvo até agora. Sobre o conteúdo, o livro é muito remanescente dos livros “clássicos” de ensino de programação que eu tinha nos anos 80. Ele é bem passo-a-passo, com a instalação do Ruby vindo primeiro, seguindo por um passo-a-passo dos conceitos principais sobre orientação-a-objetos, sintaxe do Ruby, e a idéia básica de tipos de dados. Eventualmente, pelo final do livro, o leitor passou por operações em arquivos, uso de banco de dados (há até uma introdução a SQL), desenvolveu um jogo de aventura em texto, construiu uma simples aplicação Rails e assim por diante. É realmente um livro para iniciantes, do começo ao fim, e então ele pode ir para livros mais avançados como o Pickaxe ou The Ruby Way. Quem sabe não vemos o livro em português um dia!

AkitaOnRails: E falando em iniciantes, novamente eu acho engraçado ler seu perfil no LinkedIn: “‘Larguei a escola aos 16’ conta? Se sim, estou dentro. Educação é boa pra maioria, mas superestimado se você for um autônomo…” Eu também larguei a faculdade para trabalhar na bolha da internet (embora não como empreendedor, o que eu me arrependo). Eu não recomendo que as pessoas larguem a faculdade como eu fiz, claro, é uma escolha pessoal e todos devem tomar decisões conscientes sobre seu próprio futuro. Mas existem muitas pessoas – pelo menos aqui no Brasil – que se orgulham de certificações e diplomas mais do que experiência. Claro, existem grandes desenvolvedores certificados, mas há mais maus desenvolvedores que realmente ‘acreditam’ em seus próprios certificados como garantia de competência! Eu não vejo nenhuma correlação entre diplomas e bons desenvolvedores. Qual sua opinião sobre isso?

Peter: Tenho muito respeito por pessoas que seguem a rota acadêmica, e acho que no geral eles se tornam melhores no trabalho do que as menos educadas. Uma das desvantagens de ser doutrinado pela academia, entretanto, é que pessoas com muitos graus, certificações e diplomas normalmente agem como autômatos tecnológicos, somente entendendo um caminho de ação, sem capacidade de pensar dinamicamente em tempo real, e incapazes de tentar novas direções radicais. Há muito espaço no mundo para pessoas assim, mas por outro lado precisamos muito de pessoas “loucas” que tentam coisas que inicialmente parecem idiotas ou radicais.

O outro problema com pessoas que exibem suas certificações é que em muitos casos eles estão apenas provando que conseguiram passar um teste. Passar um teste e ter muito conhecimento não significa necessariamente que você desenvolve boa capacidade de resolução de problemas ou consegue trabalhar como um verdadeiro desenvolvedor, arquitetando soluções do zero. Por exemplo, um peão pode ser excelente construindo casas, mas ele provavelmente é muito ruim em realmente desenhar construções, que é o trabalho de um arquiteto. Em TI, especialmente em empresas pequenas, normalmente é necessário que os desenvolvedores usar ambos chapéu de arquiteto e desenvolvedor, e muitas pessoas com certificação, mas pouca experiência real, penam com desenho de sistemas.

AkitaOnRails: Somos ambos evangelistas de Ruby e Rails, claro, mas como eu, não o vejo como um desenvolvedor ‘cego’, quer dizer, do tipo que precisa fazer todo o resto parecer ruim para justificar colocar Ruby num pedestal. Eu realmente acredito na ‘ferramenta certa para cada trabalho’. Nem mesmo DHH afirma que Rails é a solução para todos os casos de uso. Isso dito, acho que Rails é o melhor para um nicho de desenvolvimento web. Recentemente eu me envolvi – e me arrependo disso – contra um troll defensor de .NET. Não desgosto de .NET, longe disso. De qualquer forma, você se vê envolvido em discussões como essa? Ou você tenta evitá-los totalmente? Qual sua opinião sobre esse tipo de discussão ‘X vs Y’?

Peter: Acho que é possível ter jogos políticos interessantes em qualquer situação. Como um ser humano normal eu tenho, claro, minhas preferências, mas é importante reconhecê-los pelo que são e ainda ser capaz de enxergar o quadro completo. Acredito em tentar usar a ferramenta certa para o trabalho (ou, mais especificamente, a ferramenta mais eficiente para o trabalho – eu não vou aprender uma linguagem nova para resolver apenas um problema), então o Ruby Inside roda em WordPress , uma plataforma de weblog em PHP. Em termos de predisposição, eu certamente sou meio anti-Microsoft, embora precise admitir que para desenvolvimento de aplicações GUI eles estejam anos-luz à frente de todo mundo.

Eu não tenho evitar me meter em discussões do tipo X vs Y, embora eu tende a ser meio advogado-do-diabo nesses casos. É importante se manter o mais científico e objetivo quanto possível nessas situações, mas eu certamente deixarei um pouco de predisposição se mostrar de tempos em tempos, como qualquer humano faria. Por exemplo, eu (e estou longe de ser o único nisso, embora muitos não queiram atirar pedras publicamente) particularmente não sou muito chegado na proteção excessiva do David Heinemeir Hansson dos termos Ruby e Ruby on Rails, e especialmente o logotipo Rails ao ponto de rejeitar seu uso em livros em que ele não trabalhou pessoalmente. Não tenho medo de mostrar alguma predisposição e problemas de referência como essa de tempos em tempos.

AkitaOnRails: Isso nos leva à outra questão: todos os dias as pessoas aqui me perguntam “Por que eu deveria escolher Ruby on Rails em vez de X?” Pessoalmente, acho que não há resposta clara para isso. Sendo experiente em muitas plataformas como ASP.NET, Java, PHP, Perl, eu fiz minha escolha baseado não apenas em performance bruta (que Ruby não tem, por enquanto), nem mesmo um conjunto maduro de bibliotecas (que está evoluindo depressa). Algumas razões foram baseadas unicamente em eu estar feliz com esta plataforma. Acredito que Ruby me permite escrever mais código ‘bonito’ como Marcel Molina Jr. explica. Mas “a beleza está nos olhos de quem vê.” Qual sua opinião? Sendo um programador experiente em outras plataformas, por que escolheu Rails?

Peter: Eu era um desenvolvedor Perl antes de cruzar com Ruby e Rails, e quando vi Rails, a primeira coisa que fiz foi tentar cloná-lo em Perl. Infelizmente, eu definitivamente não estou entre na elite de programadores, nem de longe, então minha tentativa foi bagunçada. Tentei usar Rails diretamente, meio relutante, com uma promessa a mim mesmo de não me deixar envolver e aprender uma nova linguagem, mas meramente para desenvolver o que eu precisava na época. Claro, o resto é história e eu me converti inteiramente a Ruby, pela sua consistência, facilidade de uso, e pela forma como ela parece uma linguagem “natural”.

Em 2004, a biblioteca Ruby era pobre, RubyGems não era popular, e não haviam muitos livros disponíveis, então parecia uma escolha ruim, mas essas coisas mudaram muito rápido, e eu diria que a biblioteca Ruby em 2007 compete muito fortemente com, digamos, Python, e mesmo estando atrás em quantidade numérica ao CPAN do Perl, a qualidade e modernidade das bibliotecas Ruby superam isso. Ruby é agora uma forte escolha.

AkitaOnRails: Eu preciso estender esse tema porque acho que é relevante já que vemos mais e mais pessoas mudando para Rails. Eu vejo 2 tipos de desenvolvedores vindo à bordo: o primeiro sendo programadores experientes que não estão satisfeitos com seus trabalhos atuais e ferramentas e querem tentar algo novo e renovador. O segundo sendo desenvolvedores iniciantes que acham que Java ou .NET tem uma curva de aprendizado muito mais alta do que Rails. Eles me preocupam um pouco porque tendem a pensar que Rails é fácil demais para ser considerado profissionalmente e outros se frustram em descobrir que Ruby não é Basic, e você precisa se esforçar para aprender seus caminhos. Você faz treinamentos também, qual sua experiência lidando com iniciantes?

Peter: Nunca lidei com alguém que seja completamente novo à desenvolvimento de aplicações Web, então não posso dar uma resposta concreta. Entretanto, eu certamente não acho que as pessoas estejam escolhendo aprender Ruby ou Rails porque são percebidas como “fáceis”. De fato, acho que são os desenvolvedores mais experientes que consideram Rails fácil, e é por isso que estão a estão experimentando. Iniciantes tendem a ir com seja lá que esteja na moda no momento ou o que é mais popular. Não há falta de iniciantes para todas as maiores linguagens agora, é somente que Ruby está finalmente recebendo sua fatia.

AkitaOnRails: 3 anos atrás a maioria dos desenvolvedores previram a “queda” do Rails como uma alternativa viável. Hoje vemos Rails 2.0 saindo e a comunidade Rails crescendo depressa e mais forte a cada dia. Agora as pessoas acham que Rails é o competidor a derrotar. Acho que é algo bom porque nós tendemos a correr mais rápido (desenvolver mais gems, inovar mais) quando estamos sobre pressão. Você acha que as pessoas estão aceitando Rails mais ou ainda vê barreiras para a adoção do Rails, pelo menos aí na Inglaterra ou Europa em geral?

Peter: Não concordo que 3 anos atrás a maioria dos desenvolvedores previam a queda do Rails. Acho que haviam apenas muitos programadores defensivos escolhendo ignorá-la. Não acho que a maioria dos desenvolvedores de outras plataformas vejam Rails como algo a se derrotar. Na realidade há muita cegueira nos galhos da comunidade de programação para os esforços feitos em outros galhos. A maioria dos programadores .NET não se importam, e muito provavelmente nem ouviram falar disso, Ruby on Rails. Desenvolvedores em plataformas que estão morrendo, como Cold Fusion, estão mais familiarizados com Rails, simplesmente porque eles tem procurado alternativas, mas Java e .NET ainda estão tomando os novos desenvolvedores a uma taxa muito maior que Ruby e Rails. Existe uma grande diferença no que os blogs e a mídia online quer relatar e o que realmente está acontecendo por aí.

AkitaOnRails: Existem muitas coisas que o Ruby ainda não tem e agora estamos vendo Ruby 1.9 sendo lançado. Ainda não é um 2.0 estável mas é um sinal claro que a linguagem está evoluindo depressa como uma plataforma madura. Performance de graça sempre é bem vinda, mas este lançamento quebrará muitas coisas. Já está usando 1.9 ou sente que ele ainda não está pronto para começar?

Peter: Eu brinquei com Ruby 1.9 um pouco, mas não uso rotineiramente. Eu não me considero um programador no sentido acadêmico. Gosto de saber e brincar brevemente com tecnologias extremas, mas não sou um desses super-programadores que fazem download digamos, de Erlang ou Haskell e tentam aprendê-los num fim de semana. Ruby 1.8 definitivamente continuará sendo meu interpretador Ruby por pelo menos mais alguns meses.

AkitaOnRails: Nossa comunidade brasileira ainda é muito jovem e pequena, eu normalmente a descrevo como a comunidade americana em 2004 ~ 2005. Ainda não atingimos massa crítica. Como estão as coisas por aí na Inglaterra ou Europa? Sua comunidade já é grande o suficiente o suficiente para o mercado já demandar profissionais relacionados a Rails?

Peter: O mercado no Reino Unido ainda é muito pequeno. Não houve literalmente nada em 2005 mas as coisas cresceram rapidamente nos últimos anos, embora ainda seja talvez um milionésimo do tamanho do mercado para serviços de Java ou .NET. Existe normalmente alguns trabalhos relacionados a Rails flutuando por aí, mas até agora descobri que Rails é uma tecnologia que agências estão usando para seus clientes por trás das cenas, em vez de ser algo sendo ativamente demandado. Não estou diretamente envolvido na comunidade britânica de Ruby ou Rails, entretanto, então não posso dar muitos detalhes disso.

AkitaOnRails: Isso é só pela brincadeira: se você fosse DHH ou Matz o que gostaria de mudar no Rails ou Ruby? Ou talvez, para onde vê os dois indo?

Peter: Se eu fosse o DHH, provavelmente Rails não existiria, simplesmente porque eu acho que muito muito do seu excelente evangelismo de Rails é dirigido por uma ponta de vontade de fama. Por um lado mais prático, eu faria Rails menos ‘opinionated’ (de opinião) e mais customizável, simplesmente porque muitas das opiniões são muito rígidas para serem práticas no mundo real. A opinião inicial de depender do banco de dados para dar informações sobre a estrutura do Model foi legal, mas então vieram as migrations … e de repente estamos definindo layout de tabelas no código afinal, normalmente em muitas dezenas de arquivos! Por que não colocar os atributos diretamente no Model e deixar Rails tomar conta das mudanças de schema transparentemente? DataMapper faz isso, e ActiveRecord está começando a ficar para trás em comparação com esse estilo bizarro.

Do lado do Ruby, acho que Matz fez um excelente trabalho tecnicamente, embora apesar do DHH pontuar mais alto na escala de Relações Públicas, Matz parece relutante em promover o Ruby. Acho que ambos é um pouco de modéstia ser uma coisa honrável na cultura japonesa, mas também porque Ruby é algo que ele desenvolveu para coçar uma coceira, e outros milhão de desenvolvedores usando a linguagem não o beneficiaria significantemente. Ele é um grande cara, mas falta a loucura de um Larry Wall (Perl) e a autoridade de Guido van Rossum (Python) e tem muita sorte que pode depender de uma comunidade muito forte e vocal para promover Ruby. Um dos benefícios do jeito mão-na-massa do Matz é que as pessoas sentem que podem ter autoridade sobre várias áreas da linguagem e comunidade para si sem ter que perguntar à uma autoridade maior.

Do lado técnico, a única coisa que eu talvez faria se estivesse em controle do desenvolvimento da linguagem Ruby seria fazer investidas mais fortes em direção a construções mais funcionais. JavaScript e Perl 6 estão andando bastante no mundo da programação funcional, e Ruby precisa seguir. Eu também consideraria concorrência muito fortemente e tornar isso um foco principal para desenvolvimento de novas funcionalidades na linguagem.

AkitaOnRails: Qual seria sua recomendação para iniciantes em Rails aqui no Brasil? Quero dizer, para aqueles que querem aprender tanto Ruby e Rails mas podem precisar de alguma guia no começo?

Peter: Bem, se você consegue falar inglês, então naturalmente eu sugeriria meu livro “Beginning Ruby” publicado pela Apress! Infelizmente não tenho familiaridade com recursos em português para aprender Ruby ou Rails, embora tenho certeza que você tenha! Um recurso grátis que eu definitivamente recomendaria a novos desenvolvedores é o “Aprenda a Programar” de Chris Pine. Está disponível como livro, mas tem uma versão mais crú disponível para ler grátis online.

AkitaOnRails: Agora, falando em informação, tivemos um começo de ano bem explosivo. Zed Shaw literalmente explodiu em reclamações, ofensas e toda forma de comunicação agressiva. Como eu disse num artigo anterior, eu me choquei no começo, mas lendo até o fim – tentando filtrar todo o ódio e maneirismos não civilizados – e realmente há alguma informação enterrada lá. Qual sua opinião sobre esse episódio?

Peter: Pessoalmente, acho que o Zed acertou em cheio. Não gosto do jeito que ele especialmente ataca algumas pessoas (Kevin Clark, por exemplo) por causa de pequenas infrações. Sua linguagem é severa, e ele claramente tem muito ácido. Por trás de todas as palavras de ofensas e bater no peito, entretanto, há muita verdade. Eu simpatizo com seus argumentos principais, especialmente aqueles levantados na atualização do “Round 2” publicado em 3 de janeiro.

Zed toca na maneira como as pessoas se formam em gangues elitistas e dirigidas pelo ego, como o Rails Core e o caboo.se. Eu me envolvi com o caboo.se por um tempo, e tenho muito respeito por muitos membros (Courtenay Gasking e Amy Hoy, por examplo), mas a coisa tanto fedia muito elitismo para mim, e eu me distanciei de toda essa socialização online relacionada a Rails. Eu me lembro de alguns incidentes condescendentes patéticos de membros dessas comunidades, mas ao contrário de Zed eu deixei quieto. Acho que uma das maiores causas dessa tensão, formação de gangues e infantilidade generalizada é que muitas das pessoas envolvidas com essas gangues não tem vida social fora dessa comunidade. Isso provavelmente explica esses joguinhos medievais como Werewolf (Máfia) e bobagenzinhas em geral são tão populares nas conferências, em vez de, digamos, realmente revolucionar a área.

Por fim, Zed acertou em cheio com seus comentários sobre o livro “Programming Ruby” mais comumente conhecido como o “Pickaxe.” Eu tendo a me manter politicamente correto nesse assunto, especialmente porque tenho um livro concorrente, mas o Pickaxe realmente é incrível na sua mediocridade. Ele vende bem porque tem a vantagem de ter sido o primeiro com nome reconhecido, e ninguém se incomodou em escrever um livro de referência melhor (The Ruby Way é excelente, mas não é um livro de referência). Por ter o único livro de referência de Ruby impresso, Dave Thomas merece crédito, mas ainda assim é medíocre.

AkitaOnRails: Para o bem ou para o mal, tenho sentimentos misturados sobre esse episódio. Não vou julgar ninguém ainda. Vejamos como isso se desenrola. E claro, eu realmente agradeço a paciência do Peter Cooper comigo, gentilmente respondendo todas as minhas perguntas. Muito obrigado!

Traducción en Español

Como prometi depois da entrevista com Avi Bryant , aqui vai outra grande conversa com Adrian Holovaty, o conhecido criador do framework web Django escrito em Python.

Para mim esta é uma matéria importante porque eu sempre disse que tecnologia não tem que ser sobre divórcio. Tecnologia é sobre integração. Sou um programador e evangelista Ruby on Rail tempo integral, mas acima de tudo, eu tento ser um ‘bom’ programador. E bons programadores reconhecem boa tecnologia e a conquista de seus criadores. E o Django de Adrian é uma dessa conquistas excepcionais que merecem a atenção e o sucesso.

Então, como meu primeiro post do ano (publicado às 0:01h!), gostaria de celebrar as grandes mentes da nossa comunidade de ‘desenvolvimento’, esperando que os bons desenvolvedores usem seu tempo criando grandes tecnologias em vez de desperdiçar em guerrinhas inúteis.

AkitaOnRails: Como sempre faço, vamos começar falando um pouco sobre você. Há quanto tempo é programador?

Adrian Holovaty: Vamos ver – venho lidando com computadores desde que era um garoto brincando com o Commodore 64 no meio dos anos 80.

Um programa que escrevi na época foi para a calculadora TI-85 na classe de matemática do colégio. Quando me graduei um monte de estudantes estavam usando, porque eu tinha todas as fórmulas e coisas assim.

Eu não levei nenhuma dessas coisas a sério até a faculdade, quando estudei ciência da computação. Mas não terminei o curso, que é uma coisa que sempre me incomodou.

Meu curso principal na faculdade foi em jornalismo, pois originalmente eu queria ser um repórter de jornal, mas depois que eu trabalhei com um web site no jornal do campus (The Maneater – o melhor nome de jornal que já vi!), percebi que seria muito mais divertido trabalhar online do que com um produto em papel.

Então acabei achando uma maneira de combinar jornalismo/notícias e programação, e eu tive vários trabalhos fazendo exatamente isso!

AkitaOnRails: E o que o levou ao mundo dos computadores?

Adrian: Acho que foi minha criação, já que meu pai foi programador de computador desde os anos 70, nos dias do cartão perfurado. Eu lembro de ver todos os tipos de cartões em nossa casa enquanto crescia.

AkitaOnRails: E, claro, como conheceu e se apaixonou por Python?

Adrian: Meu caminho de desenvolvimento web foi (eu acho) bem típico, pelo menos baseado nas experiência de meus amigos e colegas. Eu originalmente aprendi a escrever scripts CGI em Perl em um curso de desenvolvimento web da faculdade. Então eu me ensinei PHP porque alguém me recomendou.

Depois de fazer desenvolvimento Web com PHP por alguns anos, eu meio que me cansei disso. Naquela época, estava trabalhando com Simon Willison no website de um jornal na cidade de Lawrence, no Kansas. Simon e eu estávamos cansados de PHP e decidimos “mergulhar em Python” (trocadilho intencional) lendo o excelente livro de mesmo nome do Mark Pilgrim , que foi lançado na época. Isso deve ter sido no fim de 2002.

Imediatamente nos apaixonamos por Python. E quando eu digo “imediatamente”, realmente quero dizer isso. Foi como uma revelação, algum tipo de momento divino. Foi o equivalente em programação à amor à primeira vista.

Então Simon e eu decidimos que, dali em diante, iríamos codificar tudo em Python. Essa é uma das coisas interessantes em se trabalhar em um pequeno grupo de desenvolvimento Web – podíamos tomar esse tipo de decisões instantâneas!

AkitaOnRails: Eu fui apresentado a Python pela primeira vez acho que em 2000. Mas foi através de desenvolvimento web usando Zope. Acho que ele ganhou muita atenção naquela época. Você já tentou ele?

Adrian: Não, nunca tentei Zope. Ainda, até hoje, nunca tentei. E me disseram que isso foi uma coisa boa, porque evidentemente ele afastou algumas pessoas de Python na época, seja lá por qual razão. (A versão nova supostamente é muito melhor, mas eu não mexi com ele, também).

AkitaOnRails: Você está certo, e é meio engraçado porque um monte de pythonistas brasileiros ainda usam Plone (eu acho que ele evoluiu do Zope mas eu não tentei ele também). Então, todos sabemos que Django nasceu da necessidade quando você estava desenvolvendo websites para a World Online. Por favor nos descreva como você começou e como é o dia-a-dia de trabalho lá. Talvez o que o levou a Django durante seus dias de trabalho.

Adrian: Claro! Bem, geralmente quando as pessoas pensam em jornais, elas pensam em editores irritados e ultrapassados e repórteres rascunhando em blocos de papel com lápis. Esse jornal do Kansas em que trabalhei era o oposto disso. Está além do escopo desta entrevista, mas por várias razões o website desse jornal atraiu (e ainda atrai até hoje) uma grande equipe de desenvolvimento – uma que eu colocaria contra qualquer equipe 10 vezes o seu tamanho.

Estávamos fazendo coisas “Web 2.0” em 2002 e 2003, e estávamos construindo aplicações web em dias, não semanas ou meses. Isso era principalmente devido ao ambiente jornalístico – pessoal de jornal gosta de datas.

Então estávamos nessa cultura de “desenvolvimento web com datas de jornalismo” e precisávamos de ferramentas que nos deixassem criar aplicações web rapidamente. Olhamos algumas bibliotecas Python que haviam na época (2003), e terminamos decidindo escrever nossas próprias coisas.

Não decidimos parar para fazer um framework – foi um caminho bem clássico e clichê, na realidade! O que aconteceu foi, nós construímos um site com Python. Então construímos mais um, e percebemos que os sites tem uma boa parte de código em comum, então fizemos a coisa certa e extraímos os pedaços comuns em uma biblioteca.

Continuamos a fazer isso – extraindo e extraindo, baseado em cada nova aplicação Web que criávamos – e eventualmente tínhamos um framework.

AkitaOnRails: Como anotação, realmente isso é meio que interessante! Eu adoraria ouvir o que você acha que a World Online tinha que atraía bons desenvolvedores como você para lá! Apenas um resumo está bom. É o tipo de percepção que empresas brasileiras precisam aprender melhor. Deixá-los usar Python provavelmente foi uma delas :-)

Adrian: Sim, meio que recai em dar poder aos empregados. Meu chefe, que liderava a equipe Web, delegava todas as decisões de tecnologia para mim e o Simon. Esse tipo de cultura realmente encoraja trabalho de qualidade, porque torna todos da equipe mais investidos.


AkitaOnRails: É verdade. Empresas tradicionais preferem um estilo mais hierárquico (e burocrático), com um gerente idiota segurando o chicote. Mas voltando ao assunto. Então, eu particularmente não gosto desses tipos de comparação linguagem x VS linguagem y ou framework a Vs framework b. Em vez disso gostaria de ouvir o que você acha que é legal sobre Python – a linguagem e a plataforma – e Django. Quais as funcionalidades em Django que você mais gosta, quero dizer, aqueles pedaços que realmente acha para você como “as” grandes idéias?

Adrian: Bem, eu amo abstrações – como, eu suspeito, qualquer programador. No seu núcleo, Django é somente um conjunto de abstrações comuns às tarefas de desenvolvimento Web. Me dá muito prazer criar abstrações de algo nível, para encapsular problemas maiores de uma maneira que as torna simples.

O que eu realmente gosto sobre Django é a profundidade e extensão das abstrações que ele dá. E em muitos casos (eu espero!), são limpas, fáceis de usar e entender. Deixe-me dar um exemplo de uma abstração: criar um feed RSS.

Quando se cria um feed RSS, você não quer se lembrar de cada tag, da exata formatação do feed – você apenas de importa sobre os itens no feed. Então Django dá uma biblioteca bem simples que recebe um punhado de itens e cria o feed a partir delas.

Isso foi um exemplo óbvio, mas o que realmente me empolga são as abstrações de alto nível, como o conceito de um “site admin”. Django vem com uma aplicação completamente dinâmica que cria um maravilhoso site CRUD pronto para produção para seu banco de dados. Não há código para escrever – é apenas um pouco de configuração opcional. Também tem algo chamado Databrowse, que é uma abstração do conceito de “Me mostre meus dados, como hiper-textos inteligentes”.

Então, sempre que explico Django a alguém, eu sempre termino dizendo, “é apenas um monte de abstrações de tarefas comuns em desenvolvimento Web” – do encapsulamento de baixo nível de HTTP para conceitos de maior nível. Quanto mais alto nível, mais produtivo você pode ser. Desculpe se isso foi muito conceitual!

Já sobre Python – o que posso dizer? É maravilhoso. É como poesia. É tão limpo, tão lógico, tão regular, tão óbvio. E o sistema de importação é de morrer.

Muitas pessoas dizem que código Python é fácil de ler/entender por causa da consistência de espaços em branco e simplicidade da linguagem. Eu concordo com isso, mas eu acho que também tem a ver com a elegância do sistema de importação. Por que? Porque se quiser saber como qualquer módulo Python funciona, apenas olhe para o código, e olhe para os módulos que ele importa. Como o Zen do Python diz, “Namespaces é uma grande idéia buzinante – vamos fazer mais disso!”

AkitaOnRails: Comunidades de tecnologia são legais porque são tão energéticas e apaixonadas. Por um lado você tem aqueles que contribuem e fazem a tecnologia crescer mais depressa. Do outro, tem os espertalhões e trolls que gostam de guerrinhas. Você se queima de vez em quando, ou tende a evitar esse tipo de discussão? Especialmente, algum tempo atrás você e o DHH estiveram juntos na apresentação Snakes and Rubies. Eu acho que foi muito legal porque não acabou em mais uma guerrinha. Qual sua opinião sobre esse tipo de discussão aberta e não inflamatória?

Adrian: A resposta a isso é óbvia – claramente discussões construtivas são mais produtivas.

Por vezes, eu tive minhas paixões por Python/Django tirarem o melhor de mim, mas eu melhorei muito com o tempo. Percebi uma coisa: no fim do dia, o que realmente importa são os sites que as pessoas criam com essas ferramentas, não as ferramentas em si. Se você vai julgar alguém, julgue os sites que essa pessoa faz, em vez das ferramentas que ela usa.

Atualmente, se eu me envolvo em algum tipo de discussão desse tipo, normalmente é para tentar acalmar as pessoas

AkitaOnRails: Bem dito. Voltando às funcionalidades, você mencionou ‘Databrowse’ antes. Eu gostaria de saber mais sobre isso. Acho que o Django não tinha isso na época em que eu tentei da primeira vez. É uma nova funcionalidade (ou eu estou atrasado?) Poderia elaborar mais essa construção?

Adrian: Databrowse ainda é pouco conhecido! Aqui vai o Caso de Uso.

Digamos que você tem um monte de dados no seu banco de dados, e tudo que quer é olhar para ele. Aqui vão suas opções atuais: você pode cair no console do psql ou mysql e rodar um punhado de SELECTs, mas isso fica cansativo. Você poderia rodar alguma coisa como PHPMyAdmin, mas isso é mais uma ferramenta administrativa do que uma ferramenta de navegação. Você poderia usar algum tipo de aplicação externa que permite navegar pelas tabelas do banco, no estilo MS Access, mas isso está no domínio de aplicações de desktop.

Databrowse automaticamente cria um site web que mostra seus dados, de forma que você pode clicar por aí como quiser.

A outra coisa que ele faz é apontar pesquisas interessante e não-óbvias. Por exemplo, se tiver uma tabela que tem uma coluna DATE (tipo Data), ele automaticamente criará uma visão de calendário dessa tabela.

O objetivo não é para as pessoas usarem isso para criar sites públicos – o objetivo é que as pessoas usem isso para explorar seus dados, sem nenhum esforço adicional.

Outro caso de uso vem do mundo do jornalismo. Eu costumava trabalhar para um cara chamado Derek Willis no jornal Washington Post. O trabalho dele era adquirir enormes bancos de dados e colocá-los na intranet do jornal, para que os repórteres pudessem procurar e navegar pelos dados para pesquisas.

Derek não queria ter que fazer uma nova aplicação Web toda vez que recebesse um novo conjunto de dados, então ele usou Databrowse para fazer sites de intranet que mostrasse seus bancos de dados – com pouco ou nenhum esforço.

Isso volta para o que eu estava dizendo sobre abstrações de alto-nível. Databrowse é um tipo particular de abstração, e é realmente legal que ele incluiu algo assim para as pessoas usarem, se precisarem.

AkitaOnRails: Parece muito legal, espero poder usar isso logo. Até certo ponto se parece um pouco com Dabble Db – apesar que é dentro da sua aplicação. Acho que você conhece Avi Bryant ? Acabei de entrevistá-lo e foi uma conversa muito legal. Você já tentou Seaside? (apenas de curiosidade eu tenho uma foto de você e Avi olhando para o macbook dele sentados na grama, o que foi aquilo?)

Adrian: Sim, isso foi inspirado no DabbleDB – é essencialmente uma simplificação do DabbleDB para seus próprios dados. Mas eu não diria nem isso, porque DabbleDB é todo um universo mais sofisticado do que Databrowse. DabbleDB é incrível.

Sim, eu me encontrei com Avi diversas vezes e sempre gosto de sua companhia. Até tocamos música juntos – ele é um fantástico tocador de harmônica!

A foto a que você se refere foi tirada na Foo Camp 2007. Eu nunca tentei Seaside, mas está na minha lista de tarefas. Se um dia eu tiver que desenvolver uma aplicação como DabbleDB que precisa manter uma tonelada de estado, eu me viraria para Seaside primeiro.

AkitaOnRails: Entendo, eu sinto que bons músicos tendem a ser bons programadores também. Então, meu primeiro parabéns a você é sobre seu novo livro de Django que acabou de ser lançado. Acredito que seja uma grande conquista para a comunidade Django. Mais do que isso você conseguiu torná-lo disponível online sobre uma licença Creative Commons.

Como você se envolveu com esse livro? Foi difícil convencer sua editora a ter um livro prontamente disponível online? Pergunto isso porque pelo menos no Brasil essa é uma idéia que é MUITO difícil de empurrar para as editoras. Nos conte mais sobre sua experiência escrevendo, os desafios e obstáculos pelo caminho.

Adrian: Muito obrigado. Não há muita história aqui – o co-conspirador Jacob e eu fomos contatados pelo pessoal da Apress, que estavam interessados em publicar um livro de Django, e fizemos. Bem, devo completar: nos tomou um longo tempo , mas fizemos. Não foi difícil convencer a Apress a nos deixar disponibilizar o livro online. Eles tiveram uma experiência anterior fazendo o mesmo com o livro Dive Into Python de Mark Pilgrim e eles são pessoas legais.

Em retrospecto, publicar o livro online foi uma decisão fantástica. Não somente o livro final está disponível online, mas tornamos capítulos disponíveis online enquanto as escrevíamos, com uma funcionalidade muito legal de comentários por parágrafo que deixa os leitores enviar erros, opiniões pelos quais estamos imensamente agradecidos. Tendo experimentado isso, eu não gostaria de publicar um livro de tecnologia de outra maneira.

AkitaOnRails: Agora, meu segundo parabéns é por causa do Batten Award por conquista excepcional em jornalismo online. O ChicagoCrime.org é muito legal e um bom exemplo de mashup feito direito. Infelizmente nosso governo local e instituições públicas têm muito pouco ou nenhum dado disponível online para usarmos. De onde veio sua idéia? Como foi seu desenvolvimento?

Adrian: Obrigado – e não deixe isso os assustar de visitar a maravilhosa cidade de Chicago. 

AkitaOnRails: haha, eu moro em São Paulo. Não pode ser pior ;-)

Adrian: A idéia para o chicagocrime.org veio quando eu estava olhando o web site oficial do Departamento de Polícia de Chicago e descobri que eles publicavam dados sobre crimes – embora em uma interface que é mais adequada para procura do que para navegação. Pensei, “uau, são dados muito legais!” e comecei a escrever um extrator de tela em uns 10 minutos.

Na mesma época, eu estava lidando com o site do Google Maps, que havia acabado de ser lançado, para ver se poderia colocar mapas do Google em meus próprios web sites. Eu percebi que dados de crime dariam uma grande aplicação de mapas, então coloquei os dois juntos, e nascia um dos primeiros mashups de Google Maps. Enquanto estava desenvolvendo o site, HousingMaps.com (Craigslist + Google Maps) saiu, então ele me venceu ao ser o primeiro machup real de Google Maps – mas chicagocrime.org veio logo depois.

A coisa que eu mais me orgulho disso foi o fato de chicagocrime.org ter sido um dos sites que influenciou o Google a abrir sua API de mapas. Na época quando os primeiros mashups apareceram, tínhamos que fazer engenharia-reversa do Javascript do Google!

AkitaOnRails: Sei que você provavelmente tem duas grandes paixões em sua carreira: uma é desenvolvimento baseado em Python, claro, e a outra é jornalismo (não sei a ordem correta aqui). Você criou uma grande reputação na mídia online. Você está trabalhando para o Washington Post agora, correto? Eu li um artigo no OJR onde você explicou sobre tecnologia sendo usada para dar poderes aos jornalistas. Você pretende ser um repórter algum dia, ou está mais para o back-end do jornalismo? Acho que você tem opiniões fortes sobre o futuro do jornalismo na Era da Internet, não é?

Adrian: Bem, eu diria que minha principal paixão é música, mas é difícil viver disso. (Django foi batizado inspirado no famoso músico de jazz Django Reinhardt)

Eu não estou mais trabalhando no Washington Post. No meio de 2007 eu ganhei um prêmio de dois anos da Knight Foundation para criar um site de notícias local. Então fundei a EveryBlock em Julho. Somos uma equipe de quatro pessoas e estamos trabalhando duro para fazer uma aplicação realmente legal.

Mas sim, voltando à sua pergunta, eu certamente tenho fortes opiniões sobre como o jornalismo é praticado na Internet. Isso provavelmente é fora do escopo dessa entrevista, mas você pode ler meu artigo/reclamação estranhamente entitulado Uma maneira fundamental que sites de notícias precisam mudar para terem uma idéia.

AkitaOnRails: Agora, isso é novidade para mim. Não sabia que você havia começado sua própria empresa (desculpe, eu ainda preciso alcançar a comunidade Python). Poderia nos dizer mais sobre sua nova empreitada?

Adrian: Ei, não posso te culpar – estamos nos mantendo fora dos radares. Não há muito a se dizer sobre a EveryBlock neste ponto além do que é um chicagocrime.org vitaminado. É como chicagocrime, mas para mais cidades do que somente Chicado e mais informações do que somente crime.

AkitaOnRails: Você deveria tentar para o Brasil :-)

Adrian: Graças à internacionalização do framework Django, isso é inteiramente possível.

AkitaOnRails: Sim, e falando nisso (fugindo um pouco do assunto) eu recomendo o filme brasileiro Tropa de Elite agora que sei que você se interessa por dados relacionados a crimes ;-)

Adrian: Anotado! Adicionei “Tropa de Elite” à minha lista de FILMES_PARA_ASSISTIR.TXT :-)

AkitaOnRails: Prosseguindo. Muitos grandes websites já são desenvolvidos em Django. Seus próprios trabalhos na World Online, Washington Post sendo alguns deles. Outro grande novo é o Pownce de Kevin Rose’s (o criador do Digg). Você, Kevin e outras pessoas influentes costumam de encontrar durante conferências, não é? O que acha que o influenciou a tentar Django? Outra coisa legal sobre o Pownce tem que ser Leah Culver. Uma programadora como ela simplesmente inexiste aqui no Brasil, o que é uma pena. Você deveria torná-la símbolo oficial do Django!

Adrian: Nunca me encontrei com Kevin Rose, mas pelo que ouvi falar, acredito que Leah escolheu Django porque ou foi recomendado a ela ou ela gosta de Python, ou algo assim. Não conheço os bastidores. Também não me encontrei com Leah, mas ela foi legal o bastante para viajar a Lawrence, no Kansas, para nosso último Django sprint algumas semanas atrás (que eu não pude ir pessoalmente, infelizmente).

AkitaOnRails: Não é uma regra escrita em pedra, mas na comunidade Rails nós ‘tendemos’ a gostar de tecnologias relacionadas a Mac. Claro, não é um requerimento para nenhuma linguagem e Linux é tão bom quanto. Mas o que posso dizer? Sou um fã de Apple. Eu gostaria de saber qual é seu ambiente de desenvolvimento. Quais ferramentas você usa para desenvolver websites baseados em Django?

Adrian: Recentemente mudei para Mac depois de muitos anos usando Linux no desktop, mas não assuma nada lendo isso – não sou um fã, nem de Linux ou Mac. Eu sinto falta do Linux, para ser honesto, e em diversas coisas não me impressionei pelas funcionalidades Unix do OS X. (Coisas básicas como suporte a readline no Python padrão está quebrado, etc).

As coisas legais sobre o Mac fazem valer a pena a mudança, entretanto. Mesmo depois de ter usado Mac como minha máquina principal por 6 meses, eu ainda me impressiono que eu posso somente fechar o laptop e ele dorme automaticamente. Isso nunca funcionou com Linux!

AkitaOnRails: Pergunto isso porque muitas pessoas olhando para Rails ou Django são programadores Java ou C# acostumados a ter uma IDE completa. Eu normalmente digo que qualquer editor de texto comum faz o serviço, e se realmente quiser poder, vim e emacs se encaixam perfeitamente. O que diz disso?

Adrian: Eu nunca usei uma IDE para programar, então sou a pessoa errada para perguntar. Na realidade, mais ou menos – eu usei algo como uma IDE na faculdade para programar em assembly. Ele mostrava o conteúdo de acumuladores e coisas assim.

AkitaOnRails: Oh, quase esqueci de perguntar: você e o Guido van Rossum já se encontraram? Gostaria de saber sua opinião sobre o desenvolvimento do Python 3000 . Tem alguma coisa na nova versão que você espera muito?

Adrian: Sim, eu me encontrei com Guido várias vezes e tiver sorte o suficiente para jantar com ele uma vez! É quase idiota e desnecessário dizer isso, mas ele é incrivelmente esperto.

Eu realmente gosto dos novos conceitos e funcionalidades no Python 3000, e eu tive a oportunidade de participar do sprint no Google Chicago alguns meses atrás. Minha funcionalidade favorita é a migração para strings Unicode por padrão, porque isso força os assuntos sobre encoding.

AkitaOnRails: Finalmente, o que foi esse barulho sobre o Django ser versionado 1.0 ou pular direto para 2.0? Não segui as discussões, apenas li os títulos algum tempo atrás. E o que as pessoas podem esperar da próxima versão do Django? Entendo que você não faz grandes lançamentos que mudam o jogo, mas o que você vê sendo lançado nos próximos meses em termos de novas funcionalidades?

Adrian: Há – essa é uma história engraçada. Eu me cansei das pessoas constantemente perguntando “Quando o 1.0 vai sair? Quando o 10 vai sair?” Minha resposta sempre é, “Por que você precisa de um número arbitrário assinalado no produto? Muitas pessoas estão usando a versão corrente, então não se segure. Números de versões são muito sem sentido.”

Então eu sugeri na lista django-developers para assinalar uma versão “2.0” para reforçar o fato que números de versões são de fato arbitrários. Mas, tendo pensado mais sobre isso, mudei de idéia. A quantidade de confusão que isso causaria não justificaria a quantidade de prazer de rebelião que eu teria nisso.

E sobre funcionalidades vindo, existe alguns branches acontecendo no código Django que eventualmente serão unificadas no trunk principal. Um desses branches é chamado newforms-admin, que dramaticamente melhora a quantidade de customização que os desenvolvedores precisam fazer para o site admin do Django. Outro é o queryset-refactor, que é um refatoramento da camada de banco de dados, novamente, para torná-lo mais extensível. Fora isso, existem pequenas funcionalidades que precisamos terminar, e aí será a hora para 1.0.

AkitaOnRails: Haha, Acho que você está certo, eu não gosto desse ‘culto do ponto-zero’ também, é bem sem sentido para um projeto open source que está em constante evolução. Mas algumas pessoas se preocupam com isso principalmente em ambientes mais corporativos. De qualquer forma, e para pessoas que querem ver Django em ação, quais websites você recomendaria que elas visitem? Alguns do Washington Post, talvez? Claro, algumas das grandes funcionalidades – como o site admin – são apenas para admins (duh) Mas as pessoas gostam de ver coisa ‘vivas’ em vez de um monte de tutoriais.

Adrian: Apenas para comentar, vejo que o David, do Rails, escreveu uma reclamação sobre esse mesmo tópico.

Bons sites em Django? Vejamos – existe o Tabblo, um site de edição e compartilhamento de fotos que tem algumas funcionalidades interativas muito legais. Existe o Curse.com, site de um jogo massivamente online. Tem o lawrence.com, um site que eu ajudei a construir, que é um dos melhores sites de entretenimento local do mundo (se posso dizer isso!). E tem um site (esqueci o nome) que imprimirá um livro em papel de uma série de artigos do Wikipedia que você especificar – isso me impressionou muito da primeira vez que vi.

AkitaOnRails: Então, acho que acabamos :-) Foi uma conversa muito prazerosa. Espero que você tenha um grande Ano Novo!

Adrian: Obrigado pelas grandes perguntas e a conversa, e Feliz Ano Novo!

Se ainda não leu, dê uma olhada na Parte 1 onde conhecemos mais sobre Avi Bryant e seu incrível produto Dabble DB. Nesta Parte 2 Avi elabora um pouco mais suas opiniões e pontos de vista acerca de tecnologia. Uma leitura muito inspiradora para todo programador.

Como sempre diso – e Avi é competente em apontar -, Ruby tem seus problemas – muitos sendo melhorados no Ruby 1.9, JRuby e Rubinius. Avi nos dá boas razões de porque Smalltalk é mais uma grande plataforma para se aprender, trazendo décadas de evolução e maturidade. Então, aqui vai, a versão completa da entrevista.

E fiquem ligados! Espero ter Evan Phoenix, Hal Fulton, Peter Cooper e Adrian Holovaty como meus próximos convidados. Muito material para começar 2008 em grande estilo!

AkitaOnRails: Algumas pessoas tentam fazer o caso a favor de Smalltalk como sendo “a linguagem OO mais pura. Mesmo isso sendo um fato, você acha que esse motivo apenas é suficiente para criar um caso com todas as outras linguagens, como Ruby que é meio que uma linguagem multi-paradigma? Espero que você não seja ‘chato’ sobre ‘pureza de linguagem’ :-)

Avi Bryant: Na realidade, eu sou chato sobre isso – não de um ponto de vista acadêmica ou estético, mas pragmático. Linguagens ‘puras’ tornam muitas coisas mais fáceis: ferramentas de desenvolvimento, VMs e infraestrutura como sistemas de objetos distribuídos ou persistência transparente, tudo fica mais simples e melhor quando se tem uma linguagem pequena e consistente.

Uma experiência que eu tive, por exemplo, foi ser contratado para portar minha biblioteca cliente para o banco de dados de objetos GOODS de Smalltalk para Python; eu gastei um tempo enorme lidando com casos especiais na semântica Python (isso é uma classe? um tipo? um novo tipo de classe? implementado em python ou em C?) que nunca apareceria em Smalltalk.

Ruby faz muito bem nesse ponto, melhor que a maioria das linguagens de script – eu não chamaria Ruby de “multi-paradigma”, aliás – mas ele poderia fazer ainda melhor.

AkitaOnRails: Acho que uma vez você disse que considera uma linguagem “finalizada” quando ela é rápida o suficiente para estender a si mesma. Isso é muito verdade no caso de Smalltalk, Java e outras plataformas. Ruby sem dúvida está devendo na sua posição atual. Foi uma das razões de termos esforços em paralelo como o IronRuby de John Lam, JRuby de Charles e Thomas e o Rubinius de Evan. Um dos pontos mais criticados no Ruby é não ter uma especificação formal para a linguagem ou suas bibliotecas padrão. Você também disse que a Java VM não é boa o suficiente como Strongtalk seria, por exemplo. Isso ainda se mantém hoje, agora que estamos vendo JRuby 1.1 no horizonte?

Avi Bryant: Ainda se mantém. O JRuby atualmente parece ter um benchmark no mesmo nível do MRI, e os melhores números de qualquer outra implementação Ruby são talvez 3 vezes mais que o MRI na média. Acho que podemos fazer 25 vezes mais para funcionalidades básicas da linguagem (envio de mensagens, execução de blocos, etc), que deveria ser o suficiente para tornar possível a implementação das bibliotecas padrão no próprio Ruby. Mesmo que o resultado final seja similar aos números atuais, os benefícios colaterais seriam de extremo valor.

AkitaOnRails: Lembro que você começou o projeto Smalltalk.rb há algum tempo, e se não estou enganado era um esforço para traduzir Ruby em código equivalente em Smalltalk para que ele pudesse rodar em qualquer das VMs Smalltalk que existem. Esse projeto ainda está andando, você acha que é possível perseguir esse objetivo?

Avi Bryant: Ainda acho que é um objetivo que vale a pena e realista. O projeto ainda está andando no sentido que eu ainda estou falando às pessoas sobre como fazer isso acontecer, mas não tenho tempo para escrever código eu mesmo no momento. Tenho motivos para acreditar que esse projeto fará progressos mais concretos no ano que vem, mas vamos ver.

AkitaOnRails: Algum tempo atrás eu li um trecho de uma transcrição de chat via IRC entre você, Evan, Chad e até Charles. Você começou falando sobre padronização de primitivas (que são em C no MRI de hoje). Minha aposta é que Rubinius é o projeto destinado a ser a “próxima grande coisa” para a comunidade Ruby. Para mim parece que você e Evan colaboram bastante, é correto dizer isso?

Avi Bryant: Eu não diria isso, mas o Rubinius é certamente o projeto Ruby que mais perto se alinha com meus próprios interesses e objetivos no momento, e é muito legal ver quanto esforço está sendo posto nele. A Engine Yard merece muitos parabéns por seu suporte financeiro ao projeto.

Tenho grande esperança que o trabalho de Evan e sua equipe serão de grande benefício não apenas para Rubinius mas para todas as implementações Ruby – que foi o motivo de porque eu estava defendendo um conjunto padrão de primitivas.

AkitaOnRails: Você conhece muitas pessoas, eu imagino se já conversou com o próprio Koichi Sasada para discutir suas idéias para o projeto YARV, já que ele será a virtual machine Ruby ‘oficial’ daqui alguns meses.

Avi Bryant: Não, acho que nunca nos falamos. Eu certamente adoraria encontrá-lo qualquer dia.

AkitaOnRails: Então, subimos um nível acima para aplicações. Seu framework Seaside é muito incrível. Você está muito certo sobre WebObjects também. Como um programador Java eu sempre lamentei que ele nunca se tornou popular. Hoje está basicamente relegado a websites relacionados à Apple, enquanto frameworks menores Java tomaram a dianteira. Tapestry e Cayenne tentam chegar às funcionalidades do WebObjects mas parece que ainda estão longe. Você ainda programa em Java? Quais suas opiniões sobre frameworks populares da atualidade como Spring, JSF? Para iniciantes, o que havia em WebObjects que o tornava diferente dos demais?

Avi Bryant: Eu não faço mais nenhum trabalho Java (felizmente), então não poderia dar uma opinião de qualidade sobre o estado dos frameworks de agora. Entretanto, a principal coisa que acho que o WebObjects fazia direito era focar no estado e comportamento da aplicação, em vez das mecânicas de URLs e HTML e requisições HTTP.

Então em vez de se preocupar sobre como um campo era nomeado, você apenas diria “este campo é ligado à esta variável de instância no meu model”, e em vez de se preocupar sobre qual URL um link iria, você diria “este link ativa este método no objeto da minha página”.

Transicionar entre página era feito construindo um novo objeto de página e configurando-o diretamente em Java, em vez de construir uma URL que seria decomposta para construir a página. Essa atitude direta e estilo geral é algo que pesadamente influenciaram Seaside.

AkitaOnRails: Muitas pessoas podem não entender imediatamente, já que é uma palavra nova a muitos: “continuações”. Significa que em vez de manualmente controlar o fluxo entre eventos, com serialização e desserialização manual de objetos, você programa tudo como um fluxo coeso e contínuo. Poderia explicar isso de uma maneira que um novato possa entender? Quais os benefícios e desvantagens dessa técnica?

Avi Bryant: Bem, realmente tem tudo a ver com ser capaz de um comportamento model a uma aplicação web. Em uma aplicação desktop, por exemplo, você ocasionalmente poderia ter uma chamada como “file = chooseFile()” ou “color = pickColor()” que abriria um janela dialog modal, pegaria um resultado do usuário, e seguiria dali.

O uso de continuações do Seaside é somente para permitir exatamente esse tipo de interação no contexto da Web. A parte complicada é que por causa do ‘botão-voltar’ dos browsers, o usuário poderia escolher um cor diferente do mesmo dialog depois, e a chamada “pickColor()” teria que retornar uma segunda vez. Isso é confuso de se pensar, mas na maioria dos casos apenas funciona.

Do ponto de vista de implementação, o que estamos fazendo é salvando uma cópia da pilha no momento em que a chamada é feita para que possamos retornar depois, mais de uma vez se for preciso.

AkitaOnRails: Você começou esses conceitos em Ruby com IOWA. Há muito tempo havia um framework chamado Borges que também foi descontinuado. Então Koichi mencionou tirar o suporte a continuações do próximo Ruby. Você acha que Ruby estará dando um passo para trás sem suporte a continuações?

Avi Bryant: Continuações são uma grande abstração, e permite um monte de experimentações interessantes com semântica de linguagens. Entretanto, eu não consideraria uma tragédia se isso desaparecesse de Ruby; existem coisas mais importantes com o que se preocupar. Da perspectiva de web, eu acho que AJAX está começando a substituir um monte de casos de uso onde ter lógica model server-side costumava ser importante – Dabble DB, por exemplo, praticamente não usa as funcionalidades de continuações de Seaside.

AkitaOnRails: Seu blog tem um nome peculiar, HREF considered harmful (HREF consideradas perigosas). Você provavelmente tirou sua inspiração do artigo de Edsger Dijkstra/Niklaus Wirth’s chamado Goto Statement Considered Harmful (GOTO considerado perigoso), onde Edsger tornou famoso seu caso contra o comando GOTO. No nível de assembler é impossível não fazer JMP (salto) o tempo todo (pelo menos não sem alguma ajuda de macros) mas no nível de C você pode evitar totalmente GOTOs. Mesmo Basic tinha tanto GOTO quanto GOSUB e você poderia simplesmente ignorar o primeiro. Estou sendo simplista aqui, mas agora você está meio que dizendo que URLs tem um papel similar pela maneira que interrompem o fluxo normal, indo para trás de maneira imprevisíveis e assim por diante. Por outro lado a Internet talvez não fosse o que é sem URLs. Como lidar com esse dilema?

Avi Bryant: Não acho que seja um dilema. Acho que sua analogia é muito boa: é impossível não fazer JMP o tempo todo, e também é impossível não usar URLs o tempo todo, mas não precisamos ficar alertas o tempo todo sobre nenhuma das duas. Antigamente quando todos escreviam assembler, as pessoas provavelmente era obcecadas sobre ter etiquetas de JMP com significado e “bonitas” da mesma maneira que hoje existe a obcessão em ter URLs bonitas. Acho que precisamos nos permitir a dar o mesmo salto de abstração na web que fizemos com linguagens de programação de alto nível.

Não estou dizendo que nunca devemos pensar sobre URLs: qualquer website precisa exportar URLs com significado para serem referenciadas e usadas externamente, assim como qualquer biblioteca C precisa exportar nomes de funções significativas para que possam ser ligadas a outros programas. Mas é o máximo até onde precisamos ir.

AkitaOnRails: Componentes foram uma grande coisa no começo dos anos 90, com ferramentas RAD e assim por diante. Hoje parecem que estão se mostrando mais devagar, com iniciativas como JSF e ASP.NET. Rails inicialmente vinha com um suporte bem crú a ‘componentes’ mas foi derrubado logo no começo por ser ruim (por causa da maneira meio gambiarra em que foi implementada). Nada de novo veio substituí-lo o que parece sugerir que não havia muita necessidade disso de qualquer forma no Rails. Por outro lado Seaside é pesado em componentização. Poderia expôr um pouco mais sobre as diferenças nessas técnicas?

Avi Bryant: “Componente” é um desses termos como “MVC” ou “aberto” que são usadas para descrever tantas coisas diferentes que é difícil falar seriamente sobre elas. Uma funcionalidade concreta na forma Seaside é que cada peça da interface gráfica é bem independente de outras peças de interface na mesma página.

Não existe um controlador central que é responsável por processamento de requisições, escolhendo um template e assim por diante – todas essas responsabilidades são distribuídas entre muitos pequenos objetos. Também não há chance de conflitos de nomes porque você não nomeia links ou campos de formulários diretamente, então se pode ter muitas cópias do mesmo form/widget/etc na mesma página sem nenhuma confusão.

Isso permite um nível de modularidade que é muito difícil de reproduzir em frameworks mais tradicionais.

AkitaOnRails: Outra coisa que pode chocar algumas pessoas é que não existe um sistema tradicional de template no Seaside, sem mistura de código e tags HTML por todos os lados. Em vez disso todo HTML é abstraído em uma hierarquia de objetos que renderiza a si mesmo. Em Rails existem algumas alternativas que tentam algo parecido como HAML, Markaby. O que você acha que são as principais diferenças?

Avi Bryant: A API de renderização de HTML é uma peça muito chave no Seaside, e uma boa parte do framework foi desenhada com essa aproximação interna em mente. Acho que a principal diferença quando comparada com HAML ou Markaby, é que elas foram feitas para serem jogadas em outros frameworks.

Uma vez que você se livra de templates e muda para a geração de HTML programático, o espaço de design muda completamente, e você precisa reconsiderar quase toda decisão que faz – esse foi um processo que eu passei com Seaside entre o lançamento inicial, que usava templates e as versões 2.x, que não usavam.

Então acho que precisaremos ver um framework que usar, digamos, Markaby como o ponto de partida e se pergunta “para onde podemos ir daqui” antes de fazer qualquer comparação real.

com Adrian Holovaty, do Django

AkitaOnRails: Você também discute a respeito do dilema ‘shared-nothing’ vs ‘share-all’ (não compartilha nada vs compartilha tudo). E você obviamente tem um caso forte porque isso não é apenas baboseira tecnológica mas você tem um produto de sucesso rodando sobre essa visão. Ainda acha que vale a pena sacrificar um pouco de performance por código mais limpo e produtividade? De certa forma é meio o que o próprio DHH disse sobre Rails quando as pessoas disseram que ele é mais lento que PHP ou Perl. De fato isso tem a ver com sua conversa sobre ser ‘herético’ no sentido que está fazendo coisas de maneira diferente do que todos nós agora. Poderia elaborar sobre isso?

Avi Bryant: “Share nothing” é um grande conselho para tirar o máximo uso dos recursos do seu servidor. Para sites como yahoo.com ou Facebook, isso é claramente muito importante porque seu modelo de negócio é servir milhões de usuários todos os dias.

“Share everything” é realmente pesado nos seus servidores, mas ele faz máximo uso dos recursos de seus desenvolvedores. Para uma startup como Dabble DB, onde temos 4 desenvolvedores, isso é realmente importante. E já que nosso modelo de faturamento somente requer servir milhares de usuários todos os dias, não milhões, está tudo bem gastar um pouco mais por usuário em hardware de servidor. Tem sido uma troca muito vantajosa para nós.

AkitaOnRails: E falando de DHH, vocês provavelmente se encontraram em várias ocasiões. Ambos são pessoas de muita opinião com visões antagônicas. Smalltalk vs Ruby. Seaside vs Rails. Share-all vs Share-nothing. Alguém poderia ser tentado a desenhá-los numa disputa como Super Homen vs Batman. Embora eu saiba que pessoas inteligentes não brigam sobre mesquinharias. O que acha dele e suas idéias, como acha que ambas as comunidades poderiam cooperar, se houver alguma chance disso?

Avi Bryant: Tenho um grande respeito por David. A única ocasião onde me senti antagônico a ele foi no verão passado na Foo Camp. Estávamos jogando Werewolf, eu era o Werewolf e ele era um camponês. Agora, como werewolf a melhor coisa que você pode fazer é fazer a pessoa mais próxima a confiar em você, e aconteceu de ser o DHH. E isso funcionou – Kevin Rose estava totalmente sobre mim mas David conseguiu persuadí-lo a não me linchar, e eu comi os dois e ganhei o jogo! :-)

Enfim, provavelmente existe uma lição nisso em algum lugar. Também, em uma disputa entre mim e DHH, Neal Stephenson ganharia.

AkitaOnRails: Finalmente, o Brasil ainda tem uma comunidade jovem e em crescimento. Algum comentário final para nossa audiência?

Avi Bryant: Olá e boa sorte! Me disseram que o Rio é ainda mais bonito que minha cidade de Vancouver, e espero visitá-los algum dia.

Não perca a entrevista no podcast TWiT com Avi!

Alguém uma vez desafiou todos os outros frameworks implicando que ninguém conseguiria chegar ao nível de Rails … exceto por Avi. Seaside é tão diferente do status quo que o próprio Avi o descreve como um framework herético. E ele está certo. Ele voltou na história e pegou o que é considerado “o” pai – e provavelmente “a” melhor implementação – das linguagens orientadas a objeto: Smalltalk.

Pegando dicas do venerável Apple WebObjects, ele implementou Seaside e seu produto de grande sucesso, Dabble DB. Vejam aqui quem é o homem, quais suas opiniões e porque ele é tão relevante na comunidade Ruby e Rails mesmo sendo defensor de outra linguagem e outro framework. Parece estranho, mas quando Avi fala, você ouve.

Ele foi muito gentil de me dar uma longa entrevista. Tão longa que eu dividi em 2 partes. Esta é a primeira. Vou liberar a segunda em alguns dias. Espero que todos gostem.

AkitaOnRails: Legal. Eu estou meio nervoso. Até agora somente entrevistei o pessoal de Ruby on Rails, incluindo Matz e DHH, esta é a primeira vez que estou procurando por um ponto de vista de fora.

E eu sei que você tem muitas opiniões a respeito de Smalltalk e Seaside, mas ao mesmo tempo tem conexões fortes com a comunidade Ruby. Posso começar perguntando mais sobre Avi Bryant, a pessoa? Quero dizer, qual sua história no campo de programação?

Avi Bryant: Comecei a programar quando era bem jovem; foi uma coisa que eu fazia com meu irmão e meu pai de brincadeira, na maior parte escrevendo jogos em C nos primeiros Mac. Quando fui chegando próximo à faculdade, meu interesse se voltou mais ao cinema e filmes, então quando comecei a universidade foi essencialmente no curso de filmes.

Mas com o passar do tempo, ciências da computação me sugou, e eu terminei me graduando em computação e trabalhando e um laboratório de engenharia de software no campus. Foi quando comecei a programar sério, e particularmente onde me tornei especialmente interessado em ferramentas de software.

Foi na época quando as primeiras construções do Mac OS X – quando era essencialmente ainda apenas NeXTStep, sem Aqua ou Carbon ou qualquer coisa – começaram a se tornar disponíveis, e como eu sempre programei para Mac me coloquei a aprender Objective-C e Cocoa. Essa foi minha primeira exposição à OO “real”, e foi viciante.

Ao mesmo tempo, estava fazendo consultoria web por fora para ganhar um extra, então estava procurando por uma linguagem que me lembrasse de Objective-C mas fosse mais dinâmico e mais indicado para a web, e então eventualmente cruzei com Ruby, que se encaixava muito bem.

Eu ainda estava enamorado com tudo sobre NeXT e Objective-C, então comecei a trabalhar em ferramentas web para Ruby. Eu peguei o framework WebOjects da NeXT como meu modelo, e terminei com IOWA, que é muito próximo de ser um port do WebObjects para Ruby. Eu o apresentei na primeira RubyConf, que foi, acho, em 2000.

RubyConf aconteceu próximo com a OOPSLA nesse ano, que eu também estava participando para falar da minha pesquisa no laboratório de engenharia de software. Agora, quando o OOPSLA começou, estava cheio de Smalltalkers, e mesmo que o mainstream de desenvolvimento de software OO – e portanto o foco principal da OOPSLA – moveu de Java para C#, os Smalltalkers continuaram comparecendo. Mas em vez de participar do resto da conferência, eles faziam um semi-oficial “Camp Smalltalk” com seus próprios projetores e cronograma e hackeavam e demonstravam coisas de Smalltalk o dia todo.

Claro que eu conhecia Smalltalk, como a fonte de um monte de idéias por trás de coisas que eu me interessava – Objective-C e Ruby, obviamente, mas também TDD, wikis, mesmo o Mac até certo ponto – mas eu nunca realmente o usei; os ambientes eram muito diferentes, a documentação muito esparsa, etc.

Sentado por um dia no Camp Smalltalk foi o empurrão que eu precisava para ultrapassar isso. E uma vez que senti o gostinho de Smalltalk, eu não consegui mais largar – eu comecei imediatamente um port do IOWA para Smalltalk, e convenci meus próximos clientes em projetos web que eu deveria usar Smalltalk em vez de Ruby. Esse port se tornou Seaside, e nos muitos anos seguintes construí um negócio de consultoria ao redor de treinamento de Seaside e desenvolvimento.

Desenvolvimento web com Smalltalk pode parecer um pequeno nicho onde construir um negócio, mas o fato é que ninguém mais estava fazendo isso na época (também, ninguém estava fazendo desenvolvimento web com Ruby na época – esta situação é um pouco diferente agora).

Algumas pessoas para mencionar nesta história – Julian Fitzell foi meu antigo parceiro de projetos web, e trabalhamos juntos na primeira versão do Seaside. Colin Putney foi um dos primeiros clientes, que veio até mim baseado no meu trabalho com Ruby e eu tive que trabalhar duro para convencê-lo a usar Smalltalk; ele agora é um Smalltalker e trabalha comigo no Dabble DB. Andrew Catton trabalhou comigo no laboratório e foi um colaborador freqüente em vários projetos pelos anos.

Alguns anos depois, um pouco cansado de consultoria, Andrew e eu começamos a trabalhar em um projeto por fora, e isso se tornou Dabble DB. No verão passado, tivemos sorte para conseguir funding para trabalhar nisso tempo integral, e é o que estamos fazendo desde então.

AkitaOnRails: Vejo que você gosta do fato que Smalltalk não é “mainstream” como Java. Posso ver as vantagens e concordo com você. É como dizer “somos um pequeno grupo, mas de pessoas muito inteligentes.” Muito parecido com a campanha da Apple “Think Different”. Por outro lado as massas tendem a gostar de grande marketing e suporte. O que acha dessa diferença cultural? A parte mais importante é: aqui no Brasil o mercado é muito fechado para tecnologia não-largamente-comercialmente-suportadas. O que significa que a maioria não gosta de nada diferente de Java ou .NET. Como você convence seus clientes sobre Smalltalk – se isso de fato for um problema aí nos EUA?

Avi Bryant: Sim, isso é um equilíbrio complicado. Algumas das pessoas que conheci nos primeiros dias da popularidade de Ruby – após-Pickaxe, mas pré-Rails – reclamavam sobre quão popular Ruby ficou ultimamente, porque inevitavelmente a taxa de sinal claro vs. barulho vai pra baixo nos mailing lists e conferências. Smalltalk não tem esse problema – em particular, Smalltalk tem uma boa mistura de hackers muito experientes – pessoas como Dan Ingalls, que escreve implementações de linguagens por mais de 30 anos, e tem um profundo conhecimento para compartilhar – e jovens encrenqueiros como eu. Quando você se torna muito popular muito rápido, recebe um grande fluxo de jovens, inexperientes, pessoas enérgicas, e a voz da experiência tende a afundar. Não que novas idéias não tenham valor – elas são essenciais – mas acho que nesta área tendemos a ignorar a história demais.

Sobre usar tecnologias não-padrão, acho que a melhor forma de olhar para isso é como uma vantagem competitiva. Paul Graham aponta que na média, startups falham, e o mesmo pode provavelmente ser dito sobre projetos de software em geral. Então se você não quiser falhar, você precisa fazer alguma coisa diferente da média, e usar tecnologias melhores é uma grande forma de fazer isso.

Mas você claramente precisa estar numa situação onde resultados importam mais do que política – é praticamente impossível vender Smalltalk para departamentos corporativos de TI. Por outro lado, um dono de um negócio pequeno não está nem aí para qual tecnologia você usa para lhe construir a aplicação – não é que ele tem um exército de desenvolvedores Java que irão dar manutenção nele.

Em geral, quanto mais próximo o alinhamento entre a pessoa que usa a aplicação, e a pessoa que assina os cheques, mais irão se importar em ter alguma coisa que de fato funcione, e menos sobre palavrinhas de marketing.

Essa foi minha estratégia quando fazia consultoria de Smalltalk, e essa é nossa estratégia com Dabble DB – vendemos para usuários, não CIOs.

AkitaOnRails: É exatamente como penso. O que me leva às startups. Posso entender se cansar de consultoria, mas o que o levou a escolher abrir sua própria empresa para vender seus próprios produtos? Ouvi dizer que Tim Bray também é um investidor para sua empresa? Muitas pessoas não gostariam de perder seus empregos confortáveis por algo tão arriscado como isso. Qual foi a razão para essa direção na sua carreira?

Avi Bryant: Quando fazíamos consultoria, ficou muito claro para Andrew e eu que a) a maioria das empresas, especialmente negócios pequenos, não podiam nos pagar, e b) mesmo os que podiam, apenas nos contratariam para os projetos realmente importantes. A única maneira de escalar nosso negócio, e ajudar o máximo de pessoas possível, seria efetivamente nos substituir com software: construir um produto que os deixariam fazer os projetos simples eles mesmos.

Não abandonamos tudo para construir isso, entretanto – mantivemos nossos clientes (de fato, pegamos alguns novos para conseguir um capital extra para contratar um web designer, etc), e trabalhamos no produto à noite, aos fins de semana, onde podíamos.

À medida que o projeto avançava, e se tornava mais e mais claro que seria alguma coisa que valia a pena, começamos a trabalhar com mais afinco, mas ainda mantendo alguma renda entrando com consultoria.

Eventualmente, quando o produto estava pronto para ser lançado, sabíamos que não poderíamos lidar com clientes Dabble DB ao mesmo tempo que nossos clientes de consultoria, então os abandonamos completamente. Foi quando pegamos algum investimento da Ventures West e Tim Bray.

Então foi uma transição razoavelmente gradual, o que foi mais fácil para nós.

AkitaOnRails: E na época, vocês faziam apenas consultoria de Smalltalk/Seaside? Ou trabalhavam em diferentes linguagens/frameworks para clientes e Smalltalk depois do trabalho? E para os iniciantes como você brevemente descreveria Dabble DB? Ouvi dizer que estão para lançar um produto companheiro para ele, não é? Como o descreveria?

Avi Bryant: Durante esse período, a consultoria era toda ao redor de Seaside, sim – houve períodos negros no começo quando eu tinha que pegar trabalhos em Java :-)

Dabble DB é uma aplicação web para empresas pequenas e equipes que precisam de algum tipo de gerenciamento customizado de dados – talvez precisem de gerenciamento customizado de projetos, ou um banco de dados de contatos, ou uma aplicação customizada de RH, ou planejamento de eventos, ou suas coleções de DVD, seja qual for a razão os softwares de caixinha não tem o que eles precisam. Dabble permite a eles interativamente construir relatórios muito ricos dos seus dados, com agrupamento estruturado e filtro, cálculos simples e sub-totais, e os mostra como uma tabela, ou um gráfico, ou um mapa, ou um calendário. Daí você pode compartilhar esses relatórios com pessoas, ou convidá-los a entrar e modificar os próprios dados.

O produto companheiro que você se referem, acho que é Dabble Pages. Isso é realmente apenas uma nova funcionalidade sobre o Dabble DB, que todos os clientes atuais tem. O que descobrimos é que numa organização normalmente existe um pequeno número de pessoas que querem o poder total da interface de usuário do Dabble DB, e querem construir novos relatórios ou adicionar campos ou re-estruturar seus dados, etc. Mas também existem um grande número de pessoas que querem apenas uma simples página web onde possam entrar com novos dados ou ver relatórios. Então Pages permite um pequeno grupo construa alguma coisa para um grupo maior. É algo como uma versão misturada de construtor de forms como WuFoo, mas com Dabble DB como o backend administrativo.

Isso torna o Dabble DB quase como uma ferramenta de desenvolvimento web, no sentido que os usuários administrativos estão realmente construindo aplicações simples para as pessoas nas suas empresas – mas sem nenhuma programação, então claro que as aplicações são bem limitadas.

AkitaOnRails: Mudando de assunto um pouquinho, uma coisa que admiro a seu respeito é seu relacionamento com a comunidade Ruby/Rails. São paradigmas e tecnologias diferentes, mas você nunca mergulha em flame wars como ‘Smalltalk é melhor que Ruby’ do nada. Pelo contrário, para mim parece que você gosta de Ruby, e até apresentou na RailsConf sobre a possibilidade de rodar Ruby sobre uma VM moderna como da GemStone. Mas, você migrou de Ruby para Smalltalk. O que que ‘clicou’ para você sobre Smalltalk? Continuations? A história de codificar dentro do runtime? A integração mais estreita com o ambiente?

Avi Bryant: Então, primeiramente, realmente gosto de Ruby, tanto é que DabbleDB inclui mais ou menos 3000 linhas de código Ruby (acabei de confirmar), junto com todo o código Smalltalk (e um bocado de Python).

O que me chamou a atenção sobre Smalltalk foram algumas coisas: um foi simplesmente a maturidade, tanto da comunidade e da tecnologia. Implementações Smalltalk foram refinadas durante 25 anos, e eles realmente se beneficiaram disso.

Um dos maiores benefícios, na minha opinião, é que VMs Smalltalk são rápidas o suficiente que é razoável implementar todas as bibliotecas padrão – Array, Hash, Thread, etc – no próprio Smalltalk. Então não há barreiras onde você muda do código Ruby para a implementação C por baixo; é ‘tartaruga do começo ao fim’. Isso pode não parecer grande coisa mas uma vez que tem isso, é realmente difícil desistir.

Rubinius, claro, está se movendo nessa direção para Ruby, e muitos parabéns a Evan e todos trabalhando nesse projeto.

Para mim, o ambiente Smalltalk é também chave.

De alguma forma é a mesma coisa que falo com Dabble DB: você não tem que escolher um jeito de organizar seus dados, você pode ter uma visão agrupada por data e outra filtrada por cliente e outra onde um mapa é a única maneira de entender. Em Smalltalk, você não precisa escolher um layout de arquivo ou ordem dos métodos e classes no seu código; você está constantemente mudando visões sobre o que é basicamente um banco de dados de código.

Meu amigo Brian Marick odeia isso, porque você perde qualquer ‘narrativa’ que poderia ter existido colocando seu código em uma certa ordem em um arquivo, e é difícil se acostumar a isso, mas para mim, essa é a mais poderosa ferramenta para hackear grandes bases de código.

Esta foi a Primeira Parte. Fiquem ligados para mais Avi falando sobre Smalltalk e Ruby na segunda parte da entrevista.

Faz algum tempo desde minha última entrevista internacional, e estou de volta com ninguém menos que um dos responsáveis pelo Ruby rodar sobre a plataforma .NET. Isso mesmo, eu tenho coberto muito sobre JRuby e Rubinius mas não podemos negligenciar que uma das maiores plataformas do mercado está recebendo tratamento de Ruby também. Então convidei John Lam , que gentilmente respondeu diversas perguntas sobre essa empreitada.

Lembrando que IronRuby – nomeado depois de IronPython, a primeira das principais linguagens dinâmicas construídas sobre o .NET – é um verdadeiro projeto open source, e também tem um add-on de terceiros para Visual Studio.NET, de forma que programadores acostumados ao fluxo de trabalho do VS.NET poderão vir à bordo com uma curva menor de aprendizado.

A despeito de opiniões contrárias à Microsoft apenas com o objetivo de criticar, o fato persiste que Java e .NET representam os maiores mercados de desenvolvimento corporativo hoje. E também é um fato que a influência Ruby está se espalhando depressa. Poder rodar sobre ambos JVM e CLR representa permitir o Ruby em mercados de nicho que ele não alcançaria de outra maneira, e isso é um grande ganho. Eu falei um pouco sobre isso no meu artigo Para eu ganhar o outro precisa perder. Existem pessoas muito inteligentes na Microsoft, John Lam sendo um deles.

Isso dito, vamos começar:

AkitaOnRails: Primeiro de tudo, eu sempre pergunto a meus convidados sobre suas carreiras: qual foi seu caminho até aqui? Quero dizer, como você começou com computação, o que o trouxe até aqui?

John Lam: Eu escrevi muito software antes de me formar no colegial, em 1986. Lancei vários softwares comerciais para a ‘plataforma’ Commodore (como PET, VIC-20, C-64/128) lá atrás. Em 1986 decidi que não havia futuro em computação (que mostra porque as pessoas não devem levar minhas opiniões muito a sério :)) e decidi estudar ciência física na universidade. Me graduei em 1995 com um doutorado em Química Orgânica e decidi que não havia futuro em química (que, se vocês olharem como a engenharia reversa da vida hoje é baseada em muita interação entre disciplinas com outros galhos de ciências da vida, mostra porque as pessoas não devem levar minhas opiniões muito a sério :))

Quando decidi trabalhar com computação novamente, eu peguei uma nova e obscura plataforma de desenvolvimento chamada Delphi que lançou a versão 1.0 na época que voltei a esse campo. Gastei bastante tempo trabalhando na integração de Delphi com COM, que é onde eu originalmente suspendi meu chapéu. O lado negro do COM me puxou à sua órbita e tenho trabalhado com coisas relacionadas à Microsoft desde então.

AkitaOnRails: Vejo que está na Microsoft desde janeiro de 2007, é isso? Como entrou lá, você foi contratado por causa do projeto IronRuby? Essa é sua tarefa principal hoje?

John Lam: Sim, comecei em janeiro. Antes de integrar a empresa, trabalhei em uma ponte open source entre Ruby e o CLR chamado “RubyCLR”. Quando decidi começar a promover esse trabalho nas conferências, cruzei meu caminho com a equipe do DLR da Microsoft. Mahesh Prakriya gentilmente doou metade do seu tempo na Tech Ed em 2006 para que eu pudesse falar sobre o RubyCLR. Depois de muita ansiedade e condicionamento mental acabei aceitando a oferta deles de trabalhar em tempo integral em uma implementação de Ruby sobre o DLR e nós (minha mulher, dois filhos e um cachorro) chegamos em Redmond em janeiro.

AkitaOnRails: Qual foi a motivação para começar IronRuby? Como ele iniciou? Você foi o único desenvolvedor original da implementação de Ruby sobre o .NET?

John Lam: Queríamos demonstrar que o DLR é um verdadeiro runtime para múltiplas linguagens dinâmicas, então precisávamos construir várias linguagens sobre ela. Ruby certamente se encaixava nesse critério: dinâmica, forte comunidade de usuários, muita atenção, então fazia sentido implementá-la. IronRuby definitivamente forçou muitas decisões de mudanças no DLR, tornando-a menos “Pythônica” o que é uma coisa boa para outras pessoas interessadas em construir linguagens dinâmicas sobre nossa plataforma.

Definitivamente não sou o único desenvolvedor do IronRuby. Temos dois grandes desenvolvedores trabalhando no projeto: Tomas Matousek e John Messerly, e eles estão fazendo um trabalho incrível. Nossa pessoa de testes, Haibo Luo, está fazendo um grande trabalho para garantir que vamos lançar uma implementação de alta qualidade. O trabalho de Haibo será lançado junto com o IronRuby, o que significa que a comunidade vai se beneficiar desta suíte de testes.

AkitaOnRails: Nem todos estão familiarizados com o DLR e Silverlight. Poderia descrever rapidamente para os iniciantes? O que torna o “DLR” diferente do “CLR” além de saltar da letra “C” para “D”? :-)

John Lam: O DLR é uma plataforma que forma uma camada sobre o CLR. Isso significa que podemos rodar em qualquer lugar onde o CLR rodar, o que obviamente inclui Silverlight. Silverlight é nossa plataforma “multi-plataforma” baseada em browsers que roda em Windows, Mac e Linux (através do projeto Moonlight). Nós lançamos uma versão multi-plataforma do CLR o que significa que você será capaz de rodar linguagens baseadas em DLR com um download inicial de apenas 5Mb no seu browser web.

AkitaOnRails: Isto é delicado: uma vez eu li Ola Bini e Charles Nutter criticando o “jeito Microsoft”, dizendo que seria extremamente difícil – se não impossível – para você escrever uma implementação 100% completa do Ruby 1.8 sobre o .NET sem poder olhar para seu código-fonte. A razão disso por causa da política da empresa em relação a licenças open source. Foi esse o caso?

John Lam: Acho que o IronPython é a prova de existência que você pode construir uma implementação compatível de uma linguagem dinâmica sem olhar para o código-fonte original. Em nosso trabalho com IronRuby, posso lhe dizer que não poder olhar o código-fonte não nos impediu de entender como o Ruby atinge certas funcionalidades – tem tudo a ver com desenvolver os experimentos certos.

AkitaOnRails: Também vi que IronRuby será lançado sob uma licença compatível com open source, da Microsoft, fazendo dela o primeiro projeto verdadeiramente open source da Microsoft. O que significa que vocês não apenas permitiriam as pessoas a dar uma olhada no código-fonte mas também de contribuir de volta. Quão longe estamos disso?

John Lam: A Microsoft Public License foi oficialmente sancionada pelo OSI no começo de outubro. IronRuby, IronPython e o DLR estão todos sob essa licença.

Nós já aceitamos contribuições de volta da comunidade, e estamos continuando a aceitar mais contribuições.

Na realidade não somos o primeiro projeto Open Source na Microsoft a aceitar contribuições de volta da comunidade. Essa honra pertence ao AJAX control toolkit do ASP.NET que é um projeto enormemente bem sucedido com mais de 1 milhão de downloads até hoje.

AkitaOnRails: O DLR foi originalmente concebido como um jeito experimental de rodar Python sobre .NET. Isso tornou mais fácil para uma implementação Ruby ou você acha que Python e Ruby são diferentes o suficiente para garantir muitos ajustes no DLR para torná-la possível?

John Lam: É justo chamar a versão original do DLR como “Python Language Runtime”. Adicionar Ruby à mistura forçou várias mudanças adicionais ao DLR, a mais significante sendo a refatoração do runtime para migrar todos os idiomas específicos de Python (que pensaram ser genéricas mas acabou não sendo o caso) para o IronPython.dll. O que restou é um núcleo que nossas 4 linguagens desenvolvidas pela MSFT (IronRuby, IronPython, Managed JScript and VB) continuam a usar efetivamente hoje.

AkitaOnRails: É um objetivo ser 100% compatível com o MRI 1.8? Ou vocês estão na direção de um sub-conjunto da implementação Ruby? Isso tornaria possível escrever programas .NET em Ruby, usando o conjunto completo de bibliotecas .NET e frameworks como ASP.NET, Windows.Forms, LINQ, etc. Ou estão planejando uma implementação totalmente compatível com o MRI, o suficiente para conseguir rodar uma aplicação inteira de Rails?

John Lam: Nossa prioridade nr. 1 é ser tão compatível com o MRI 1.8.x quanto possível. A única funcionalidade que não vamos suportar é continuações, o que é consistente com JRuby. Além disso (e na falta de uma especificação de Ruby), a compatibilidade será julgada se podemos rodar aplicações reais de Ruby e suítes de teste desenvolvidos pela comunidade. Obviamente Rails é uma aplicação Ruby extremamente importante, que nós absolutamente vamos rodar sobre o IronRuby.

Interoperabilidae .NET é nossa prioridade nr. 2. Vamos integrar com a plataforma .NET e permitir escrever aplicações Ruby usando o rico conjunto de bibliotecas .NET. Obviamente coisas como Silverlight, WPF, LINQ, WinForms e ASP.NET serão suportadas.

AkitaOnRails: Ruby cresceu como um esforço coletivo e discreto que realmente explodiu 3 anos atrás por causa de Rails. É uma das razões porque ninguém nunca se importou em escrever uma especificação formal e uma suíte de testes. Temos Alioth, a suíte de testes do YARV. Você teve dificuldades por causa da falta de uma especificação formal? Você está em contato com pessoas como Charles do JRuby, Koichi Sasada do YARV ou Evan Phoenix do Rubinius? O que acha de todos esses esforços acontecendo em paralelo? Há alguma maneira onde vocês possam contribuir entre vocês?

John Lam: Estamos usando a suíte de especificações do Rubinius hoje, e planejamos lançá-lo junto com nossos fontes para garantir que iremos pegar bugs de compatibilidade cedo no processo. Sou culpado de não participar tanto quanto gostaria em falar mais com Charlie, Evan e Koichi sobre colaboração em especificações. Estamos focados em trazer o núcleo da linguagem rodando hoje, e temos vários outros projetos acelerados negligenciando documentar as coisas que temos aprendido. Quando desacelerarmos um pouco, serei capaz de gastar mais tempo me comunicando com os outros implementadores.

AkitaOnRails: Ruby tem várias deficiências conhecidas. Koichi está tentando melhorar algumas delas para o Ruby 1.9. Como você está lidando com problemas como a falta de threading nativo, o garbage collector mark and sweep simples, nenhuma máquina virtual e portanto nenhuma compilação em byte-code, problemas de performance, falta de internacionalização nativa (Unicode), várias extensões escritas em C?

John Lam: Nós ganhamos muitas coisas de ‘graça’ ao rodar sobre o CLR. Threading nativo é suportado em IronRuby. Nós usamos o garbage collector do CLR, que é um GC de classe mundial. Nós compilamos nativamente para IL, e nosso IL é compatível com o GC também o que é uma ótima coisa para aplicações de servidor que ficam de pé por um longo período. Nós obviamente suportaremos strings do CLR, que são strings Unicode e também suportaremos strings mutáveis do Ruby, que são baseadas em array de bytes. Não vamos suportar extensões baseadas em C, em vez disso estamos portando as bibliotecas baseadas em C, existentes no Ruby Standard Library para C# (ou Ruby).

AkitaOnRails: Existe algum benchmark comparando IronRuby ao MRI? Vocês acham que já o ultrapassaram? Existe algum problema hoje sobre a performance do Ruby sobre o DLR? Ou mais interessante: existe alguma comparação entre Ruby no DLR e C# ou VB.NET sobre o CLR?

John Lam: Somos mais rápidos que o MRI nos benchmarks do YARV, mas esse número muda diariamente. Uma coisa ótima sobre nossa equipe é que temos uma suíte de testes de regressão de performance que rodamos regularmente por todo nosso código. Isso torna trivial localizar uma compilação que causa uma regressão na performance, mesmo que deixemos para lidar com isso para mais tarde.

Não temos feito nenhuma otimização de performance até agora, estamos apenas usando funcionalidades que existem no DLR hoje, como caches inline polimórficos para caching eficiente de métodos call-site. À medida que nossa implementação amadurece, vamos otimizar IronRuby para performar bem em benchmarks de nível de aplicações (não micro-benchmarks, que são úteis para nós mas não tão interessantes para clientes reais). O DLR (e CLR) está se tornando mais rápido o tempo todo, e qualquer linguagem dinâmica construída sobre ele se beneficiará dessas melhorias.

Obviamente, linguagens como C# e VB.NET são mais rápidos que Ruby hoje. Mas estamos confiantes que podemos diminuir essa diferença significativamente com o tempo.

AkitaOnRails: E sobre ferramental? Vi que você mexeu no seu Visual Studio.NET para ter o tema Vibrant Ink que nós – usuários de Textmate – estamos acostumados, e ficou legal. Vi também uma foto de tela de code folding do Ruby dentro do Visual Studio. Como está esse suporte para Ruby?

John Lam: Neste momento nossa equipe não está envolvida com integração VS. Entretanto, o pessoal da Sapphire in Steel está fazendo um grande trabalho integrando IronRuby ao VS.

AkitaOnRails: Você mencionou numa entrevista sobre a possibilidade de Ruby rodando sobre o Silverlight. Quão possível isso é hoje?

John Lam: Demonstramos IronRuby rodando sobre o Silverlight na RubyConf. A conversa deve ser publicada logo. Estamos planejando em convergir com o Silverlight a tempo para seu próximo CTP (fim deste ano, começo do ano que vem). Nessa época, vocês serão capazes de codificar Ruby que roda no seu browser.

AkitaOnRails: A Microsoft está aprendendo como lidar com as comunidades open source. Você acha que a adoção de tecnologias como Python e Ruby estão ajudando a empresa a entender o jeito open source? O que acha que ainda precisa melhorar? Quero dizer, se pudesse, o que você mudaria?

John Lam: A Microsoft é uma empresa grande e estamos trabalhando com muito empenho em colaborar com a comunidade Open Source. IronRuby é um dos projetos open source mais visíveis da empresa, e estamos ajudando a pavimentar o caminho para outras equipes que querem se engajar com a comunidade open source. Mudanças acontecem incrementalmente em grandes empresas e tem sido legal fazer parte dessa mudança!

AkitaOnRails: Silverlight foi lançado sobre uma licença open source também, de tal forma que o pessoal do Mono foi capaz de rodá-lo muito rapidamente sobre o Mono. Você é próximo a Miguel de Icaza? O que pensa sobre o Mono? Um IronRuby rodando sobre ele significa um Ruby multi-plataforma que pode rodar sobre o Linux (com .NET). Se você atingir 100% de compatibilidade com o MRI e Rails, isso significa rodar sobre um Apache+mod_mono no Linux e sobre o IIS no Windows, tudo desenvolvido sobre Orcas. Existe algum plano para esse tipo de integração e solução ponta-a-ponta?

John Lam: Na realidade, o Silverlight não está sob uma licença Open Source. O DLR, IronPython e IronRuby estão todos sob a Microsoft Public License, o que torna possível para Michel e sua equipe lançá-lo sobre sua implementação Moonlight (que é a versão open source do Silverlight).

Eu adoro quão pragmático o Miguel é. Ele mostrou IronRuby rodando sobre o Mono na RubyConf e isso foi em grande parte por causa da equipe Mono consertar um monte de bugs de última hora para que pudéssemos fazer a demonstração (valeu!). DLR + Iron* tende a empurrar fortemente o C# e o CLR. Nós encontramos bugs no compilador C# da Microsoft, e também no gmcs do Mono. Mas felizmente, ambas as equipes de C# e Mono têm sido ótimos consertando esses bugs para nos desbloquear.

AkitaOnRails: Acho que é isso por hoje. Algum comentário para a audiência brasileira?

John Lam: Muito obrigado por enviar um grande conjunto de perguntar! Boa sorte com suas aventuras Ruby e espero que tenham uma chance para checar IronRuby no futuro.

English Original: here

Esta é outra grande entrevista. Desta vez com Jamis Buck, o programador que ajudou o próprio David Hansson bem no começo da Era Rails, na 37signals.

Hoje é mais conhecido por suas conquistas com Capistrano e um monte de outras bibliotecas Ruby como os bindings sqlite-ruby e Net::SSH. Jamis foi muito gentil de nos dar a oportunidade de conhecer mais sobre sua carreira e o começo da história de Ruby on Rails.

AkitaOnRails: Ok, então vamos começar. A primeira coisa que pergunto a todos os meus convidados: qual é seu passado? Quero dizer, quando, como, por que você começou com programação? Foi o começo clássico, como um hobby, ou foi uma coisa mais recente por causa da carreira ou coisa parecida?

Jamis Buck: Eu comecei a programar quando estava na décima série, quando minha mãe um novíssimo computador pessoal Tandy. Ele tinha 20 Mb de espaço em disco, e vinha com GW-BASIC. Eu tinha programado antes, gráficos-tartaruga e um pouco de BASIC, mas foi com o Tandy que comecei a levar a sério. Eu me ensinei GW-BASIC com o pequeno livro de referência que veio com o computador e escrevi alguns jogos simples e utilitários. Então eu me ensinei Turbo Pascal e Turbo C++ na 11a e 12a séries, e começou daí :)

AkitaOnRails: Então você decidiu ir para Ciência da Computação na faculdade? Eu li no seu perfil no WorkingWithRails que você é um programador Java arrependido? Quanto tempo você programa em Java?

Jamis Buck: Sim, então eu pulei para Ciência da Computação quando entrei na faculdade. Me graduei um pouco tarde, em 1999, depois de trabalhar tempo integral para a universidade (BYU) como programador por alguns anos. Foi onde fiz todo meu trabalho com Java. Na realidade nós fazíamos aplicações Web em C, o que não é tão insano quanto parece! Mas então tivemos uma mudança de liderança quando um novo CIO chegou, e ele basicamente deu uma ordem cega: “aprendam Java, enterrem C!” Então tivemos que re-ferramentar massivamente, tirar certificados e assim por diante. Eu estava na equipe que liderou a pesquisa sobre que ferramentas Java deveríamos usar, então ganhamos muita experiência com isso. Eu trabalhei com Java em tempo integral lá por uns 2 anos, até a 37signals chegar em Fevereiro de 2005 e me fazer uma oferta melhor, e eu nunca mais olhei para trás!

AkitaOnRails: Uau, então você pulou direto de Java na universidade para Rails na 37signals? Ainda é um pouco cedo do que eu esperava, mas já que você mencionou: como você entrou em contato com o pessoal da 37signals? Como começou em Ruby estando tão ocupado com Java antes?

Jamis Buck: Bem, eu estava envolvido com Ruby (primariamente como hobby) desde cerca de 2001. Eu escrevi algumas bibliotecas como os bindings sqlite e sqlite3, e na RailsConf 2004, eu conheci o DHH. Eu fiz alguns trabalhos lá na conferência para fazer Rails falar com banco de dados sqlite. Depois disso, lá para Novembro de 2004, eu acho, David me perguntou se eu não estaria interessado em fazer alguma consultoria para a 37signals. Em Dezembro de Janeiro fiz alguns trabalhos esquisitos para eles como adicionar SFTP e suporte a time zones no Basecamp. E então, em Fevereiro, eles me fizeram voar para Seattle para participar do workshop Building of Basecamp lá e eles me fizeram uma oferta.

AkitaOnRails: Eu entendo que a 37signals é uma empresa pequena em termos de número de empregados e muito da sua força interna vem justamente desse fato. Ela mudou muito desde que você começou, quero dizer, nos últimos 2 ou 3 anos? O que você gostava mais na época e o que gosta mais agora?

Jamis Buck: Bem, quando eu cheguei, eu fui o quinto empregado, e o segundo programador. Antes de eu chegar, David fazia toda a programação e trabalho de administração de sistemas, então eu acho que foi um grande alívio para ele ter alguém com quem dividir a carga! Certa de um ano atrás, contratamos mais dois programadores, e desde então contratamos mais duas pessoas, incluindo um administrador de sistemas tempo integral. Eu não consigo expressar quanto eu odiava ser um administrador, já que eu tinha pouca idéia do que estava fazendo!

AkitaOnRails: Você parece ser o tipo de pessoa que gosta do encanamento porque esteve envolvido com coisas de ‘baixo-nível’ como bindings sqlite, Net::SSH e assim por diante. Esse é o tipo de coisa que o empolga mais? Ou é apenas coincidência e na realidade você prefere trabalho com GUI também?

Jamis Buck: Na realidade eu jurei, alguns anos atrás, que eu nunca seria um desenvolvedor de aplicações web :) Eu sempre preferi escrever as ferramentas do que escrever as aplicações. Mas eu realmente gostei de descrever aplicações web na 37signals. A equipe é ótima e o ferramental (Rails!) é fantástico. Eu ainda gosto de escrever bibliotecas (trabalhando no Net::SSH e Net::SFTP v2 agora mesmo, de fato) mas aplicações não são tão ruins também :)

AkitaOnRails: Mas lá atrás quando você literalmente era segundo-em-comando não tinha muita escolha, tinha? Aposto que você fez muitas interfaces do Basecamp? E você mencionou que não gosta muito do trabalho de administração porque não sabia muito bem o que fazia, mas provavelmente agora é um expert porque Capistrano arrasa nesse campo. Eu lembro dele ser chamado de SwitchTower antes. Pode nos contar essa história?

Jamis Buck: Eu trabalhei um pouco em todos as aplicações, algumas mais do que outras. Eu realmente não escrevo a interface (esse é o domínio de Jason Fried e Ryan Singer), mas eu as conecto e faço funcionar.

Aprendi uma tonelada de coisas sobre administração de sistemas desde que comecei. Ainda sou um grande amador nisso mas aprendi mais do que imaginava aprender sobre como mysql realmente funciona, por exemplo :)

Quando lancei Capistrano da primeira vez, um ano e meio atrás mais ou menos, ele era chamado de SwitchTower, mas por volta de Março de 2006 eu recebi uma carta e desistência de uma empresa que tinha o nome registrado, e então eu procurei por um novo nome. O Core Team do Rails ajudou imensamente na época, eles ofereceram uma tonelada de sugestões para nomes. Marcel eventualmente me mandou uma mensagem e sugeriu “Capistrano” que simplesmente “clicou” para mim e eu fui com esse. Recebi críticas de algumas pessoas, que acharam o nome pobre, mas eu rio agora porque a maioria das pessoas que usam Cap hoje provavelmente chegaram a ele depois da mudança de nome e nunca souberam o outro nome, e nem pensam duas vezes sobre isso.

AkitaOnRails: Você provavelmente está muito ocupado agora por causa do lançamento do Capistrano 2.0. Ele é um grande desvio do 1.4.1, se entendo corretamente. Você reescreveu muita coisa, teve que quebrar a compatibilidade. Acha que conseguiu o que queria com o lançamento ou está querendo mais em um lançamento 3.0?

Jamis Buck: Cap2 é basicamente o que eu queria que fosse. Existem alguns pequenos ajustes na minha fila, mas nada significante. Ele é cerca de 90% compatível com Cap1, então a maioria das pessoas não deveria ter problemas na troca. E desde o lançamento do 2.0, a carga de manutenção para cap tem sido realmente pequeno. Estou muito satisfeito com ele. Ainda preciso me ocupar com documentação, no entanto :) Isso é o que ainda segura muitas pessoas para trás.

AkitaOnRails: O que é o que você mais gosta sobre cap? Obviamente usou-o em seus próprios deployments na 37signals. Eu fantasio que você tinha um monte de scripts shell, mais de um ano atrás, então os costurou juntos para construir o que foi o primeiro lançamento do Capistrano.

Jamis Buck: Antes de SwitchTower/Capistrano, tínhamos uma ferramenta escrita pelo David para deployment do Basecamp. Na época, Basecamp rodava em um único servidor, então o deployment não era mais do que um “svn up”. Mais tarde, movemos Basecamp para múltiplos servidores e lançamos o Backpack, e então entendemos que precisávamos de algo mais poderoso para deployments. Então eu fui incumbido de escrever alguma coisa e Capistrano foi o resultado. O “cap shell”, em particular, o deixa imediatamente e facilmente executar comandos arbitrários em múltiplos servidores, simultaneamente, o que é muito útil. Claro, “cap deploy” é legal também :)

AkitaOnRails: Me lembro de um episódio onde David relatou sobre 72 horas de um problema que deixou Basecamp fora do ar. Você estava envolvido nesse episódio? :-) Dores de cabeça como esse parecem engraçados quando nos lembramos deles agora, mas obviamente não tão engraçados na ocasião.

Jamis Buck: Ha, sim, isso realmente aconteceu alguns dias depois que fui contratado :) Estávamos adicionando suporte a UTF-8 no Basecamp e a migração de banco de dados não se deu bem. Varamos noite. Uma bela apresentação da cultura da 37signals :) Felizmente, esse tipo de coisa não aconteceu desde então, embora tenhamos tido nossa cota de emergências, claro.

AkitaOnRails: Lições aprendidas? Acho que é o que melhor se pode tirar dessas situações :-)

Jamis Buck: A lição principal que aprendi na época: quando brincando com charsets, garanta que tenha testado no maior número de charsets não-Latin1 quanto possível :) Naturalmente, nós testamos muitas vezes antes do deployment, mas realmente não pensamos em checar dados em russo ou japonês que estavam no banco de dados depois do teste, o que parece óbvio vendo agora. Nós tentamos alguns alfabetos não-Latin1 durante os testes mas os que tentamos funcionavam apesar da existência de alguns bugs. Outra lição aprendida: não importa quão bem você se prepare, alguma coisa sempre vai dar errado!

AkitaOnRails: Eu liderei uma equipe de voluntários e traduzimos seu livro Getting Real para português do Brasil algum tempo atrás. Acredito que você se envolveu nisso também? Esse livro é uma referência ao espírito da 37signals, eu acho. Vocês realmente se movem da forma como está escrito? :-)

Jamis Buck: Na realidade eu não estava tão envolvido na composição do livro, embora tenha dado minha contribuição no processo de escrita. Mas sim, o livro descreve nossos processos. Realmente não há qualquer coisa no livro que não fazemos.

AkitaOnRails: Como vocês operam? Acredito que nem todos trabalhem no mesmo local físico? Vocês fazem muito trabalho remoto? Quantos programadores/administradores/designers trabalham lá agora?

Jamis Buck: Chicago é definitivamente o “coração” da 37signals: Jason, Ryan, David e Sam todos moram e trabalham lá. Temos um escritório lá também, e eles vão para lá regularmente trabalhar (embora eles também trabalhem de casa). Matt Linderman é nosso escritor, ele mora e trabalha em Nova Iorque. Mark Imbriaco, nosso administrador de sistemas, mora e trabalha em Chesapeake, na Virginia e Jeremy Kemper é outro programador, morando em Pasadena, na California agora. A natureza distribuída disso funciona muito bem para nós. Eu realmente amo trabalhar de casa, isso me possibilita estar mais envolvido com a vida de meus filhos, por exemplo, do que seria possível de outra maneira.

AkitaOnRails: Ouvi que você é de Provo, em Utah? É uma coincidência porque meu chefe atual, Carl Youngblood, também é de lá e também estudou na BYU :-) Por acaso vocês não se conhecem?

Jamis Buck: Na realidade moro em Caldwell, em Idaho, mas eu fui de Provo por cerca de 8 anos e sim, eu conheço Carl! Ambos participávamos do Utah Ruby Users Group. Ele é um grande cara.

AkitaOnRails: Você participou de muitas conferências para a comunidade Ruby. Não me lembro se escreveu algum livro. Está escrevendo algum agora?

Jamis Buck: Eu ia originalmente escrever um livro sobre Capistrano para a Apress, mas isso esfriou. Não estou ativamente envolvido em nenhum livro no momento, e realmente não tenho muito interesse nisso, honestamente. Eu prefiro muito mais escrever software! E eu tento postar no meu blog de vez em quando também.

AkitaOnRails: Sim, o buckblog, tem dicas muito legais que eu gosto de ler. Você começou o blog por cause de Rails ou já tinha um blog de Java na época?

Jamis Buck: Eu comecei antes de Rails. Se ler os primeiros artigos, verá que sou bem eclético. Ainda estava tentando entender esse negócio todo de “blog” :) Desde então foco em desenvolvimento de software e uso o meu blog familiar para posts mais pessoais atualmente.

AkitaOnRails: Eu também fui um programador Java e ainda tento me manter informado sobre o que está acontecendo em outras comunidades como Java, algum PHP, Python. O que você acha ou sente sobre outros frameworks e tecnologias como CakePHP, o Seaside de Avi Bryant ou mesmo Django?

Jamis Buck: Honestamente, estou um pouco envergonhado de admitir que não tenho acompanhado outros frameworks tanto quanto deveria. Seaside tem idéias legais e meu desejo de melhorar minhas habilidades de programação Smalltalk me tem feito querer cutucar isso mais a fundo. Mas mais do que isso, não tenho pesquisado muito (para meu detrimento pessoal, estou certo).

AkitaOnRails: E ainda sobre Java, ando muito empolgado atualmente sobre JRuby. Eu entrevistei Ola Bini e meio que estou perseguindo Charles Nutter. Você conheceu esse pessoal? Se interessou sobre isso?

Jamis Buck: Sei quem são, e eu encontrei Charles em algumas conferências, mas nunca tive a chance de conversar com ele mais a fundo. JRuby definitivamente soa empolgante. Estou muito curioso, de fato, de saber se ele pode suportar Net::SSH ou não já que isso significa que você poderia rodar Capistrano sobre ele. Mas não tive a chance de realmente tentar isso.

AkitaOnRails: Insistindo no assunto de Java, eu postei algum tempo atrás sobre algumas discussões sobre Design Patterns apontarem defeitos nas linguagens, e eu acabei de ler um post que você escreveu sobre Dependency Injection e sua biblioteca Net::SSH. O que acha de Design Patterns agora que é um programador Ruby em tempo integral?

Jamis Buck: Design Patterns são maravilhosos. Eles nos dão uma linguagem para falar mais concisamente sobre programação. É muito mais fácil dizer “use um método factory” do que dizer muitas palavras e confundir uns aos outros. Sobre design patterns específicos, alguns são mais úteis que outros em diferentes ambientes. Como escrevi no meu post, Dependency Injection é uma das coisas que você não precisa em Ruby, mas em ambientes como Java, pode ser um salva-vidas.

AkitaOnRails: Sobre a 37signals novamente, vocês estão bem comprometidos com produtos Apple. Eu vi aquele vídeo na Apple Education com Jason e David. Agora vemos que o Leopard não trará somente Ruby mas também Rails, Mongrel e até mesmo Capistrano. Como é a relação de vocês com a Apple?

Jamis Buck: Não diria que existe qualquer “relacionamento” com a Apple. Somos grandes fãs de seus designs e interfaces e acho que isso reflete em nosso próprio trabalho. A própria Apple está incluindo Rails, Mongrel e Capistrano por causa do despertar de sucesso dessas ferramentas. Mac OS X realmente é um ambiente poderoso para programadores e adicionar essas ferramentas no pacote os fazem maiores ainda. Faz sentido incluir as populares ferramentas Ruby também, já que Ruby se tornará um cidadão de primeira classe no desenvolvimento de aplicações OS X, graças à adoção pela Apple dos bindings de Cocoa para Ruby.

AkitaOnRails: Você obviamente usa um Mac para seu trabalho. Quais são as ferramentas que usa mais além do Textmate?

Jamis Buck: Bem, Capistrano :) Firefox com Firebug, Parallels (para testes com IE), iTerm (embora eu esteja aguardando o novo Terminal.app no Leopard), Campfire é indispensável, AdiumX, NetNewsWire, Knox (para acesso simples a filesystem encriptado). Eu ainda decaio e uso vim de vez em quando, para edições rápidas. Provavelmente tem mais :) Mas não consigo lembrar deles de cabeça.

AkitaOnRails: Existe muita conversa sobre GTD hoje em dia. Acho que vi seu perfil no 43folders. Você está por dentro desse tipo de filosofia de organização também? Como você mantém sua rotina organizada? Muitas pessoas (eu incluso) sofrem para diferenciar trabalho de hobby e para nos manter dentro das datas dos projetos e tal.

Jamis Buck: Eu não sou um fanático por GTD. Eu acho que tento ser bem pragmático sobre isso. Embora seja terrível com procrastinação. Na maior parte, das 8 às 5 eu tento me focar nas tarefas que foram assinaladas para mim e fora disso, trabalho com meus hobbies … que acabam cruzando com trabalho de vez em quanto :) Realmente sou a pessoa errada para perguntar sobre ser organizado! Se não fosse pela minha esposa, acho que faria muito pouca coisa, na realidade.

AkitaOnRails: No que está mais interessado atualmente além de Rails, Capistrano? Não necessariamente sobre tecnologia. Algum hobby?

Jamis Buck: Recentemente tenho me interessado sobre história militar, o que me levou a ler sobre a Guerra Civil Americana entre outras coisas. Minha esposa e eu realmente estamos gostando do Harry Potter 7 neste instante também :) E estou muito ligado a meu Nintendo Wii ultimamente! Eu costumava gostar de RPG, mas não tenho jogado por alguns anos. Ainda tenho uma tonelada de livros para D&D, embora, talvez algum dia me livre deles :) Gosto de gastar tempo com meus filhos (Nathaniel tem 5 anos e Katie tem 3). Vamos sair para acampar por alguns dias em uma semana ou duas, na realidade. Sempre alguma coisa para me manter ocupado!

AkitaOnRails: Haha, entendo. E você viaja bastante? Fora dos Estados Unidos, quero dizer.

Jamis Buck: Não realmente. Ano passado eu fui para Londres pela primeira vez, para a RailsConf lá, e este ano eu fui para a República Tcheca. Mas fora disso, sou muito caseiro. Eu até gostaria de viajar mais, mas não gosto de viajar sozinho, e ter crianças põe um freio no aspecto espontâneo de “levantar e ir” viajar. Fazemos viagens ocasionais de carro, o que é legal.

AkitaOnRails: Você ouve sobre o que acontecer nas comunidades Ruby/Rails pelo mundo? O que sente sobre o crescimento meteórico de Rails nos Estados Unidos? A 37signals, claro, foi o combustível para tudo isso e a razão que nós – ambos Rubistas agora – estamos conversando hoje.

Jamis Buck: Eu ouço algumas notícias, mas eu limei bastante meus feeds. Acho que assino somente de 30 a 40 feeds agora. Foi realmente empolgante ir para a República Tcheca e ver a excitação lá sobre Rails. Me lembrou muito de como as coisas eram nos Estados Unidos alguns anos atrás.

O crescimento de Rails tem sido incrível. Existem dores decorrentes do crescimento, claro. Com uma adoção maior se começa a acumular pessoas que não estão apaixonadas pela ferramenta, e somente querem aprender por causa do currículo, ou porque um cliente pediu por isso, e eu acho que isso dilui bastante as águas. Mas sempre haverá um núcleo de usuários apaixonados e é isso que torna a comunidade tão maravilhosa. Tem sido uma experiência realmente fantástica ser parte desse núcleo, quase desde o começo de Rails.

AkitaOnRails: Você tem a rara oportunidade de ver tudo isso de uma perspectiva de um VIP, perto de Jason e David. E claro, você mesmo, sendo um dos propulsores da comunidade. Muitas pessoas pensam no David como um arrogante :-) Eu posso entender perfeitamente seu ponto de vista de opiniões. O que acha disso, da perspectiva de alguém que realmente conhece o homem?

Jamis Buck: David é uma das pessoas mais confiantes que já conheci. Minha maior frustração com ele é que ele está CERTO quase sempre. Ele é um pensador muito claro e pula direto ao núcleo das questões, o que pode ser bem desconcertante se não estiver acostumado. Todos esses atributos combinam, eu acho, para fazer as pessoas que não o conhecem considerá-lo “arrogante”. Mas ele não é arrogante. Ele não coloca as pessoas para baixo para se parecer acima. Ele é apenas extremamente talentoso, muito esperto e não divaga. Estou muito honrado de poder conhecê-lo. Aprendi muito com ambos, ele e Jason.

AkitaOnRails: Não sei se entendi corretamente mas Jason Fried foi quem começou a 37signals? Poe nos dar uma pequena pincelada sobre as origens da empresa? Eu sei que David não dos Estados Unidos, como eles se conheceram?

Jamis Buck: Jason co-fundou a 37signals, no final dos anos 90. Originalmente era uma consultoria de design. Em 2003, Jason começou a trabalhar em um projeto em PHP, e perguntava online sempre que travava. David respondia suas perguntas diversas vezes e Jason finalmente perguntou se David não escreveria o projeto. David veio como meio-período por um tempo então, já que estava terminando seus estudos. Mas eventualmente, Jason quis escrever Basecamp, e David fez todo o trabalho, meio-período, em Ruby. Suas experiências com aquilo, claro, levaram a Rails. E eventualmente David se tornou um parceiro na empresa. Isso foi em 2004, se me lembro corretamente.

AkitaOnRails: Legal. E voltando a falar de você. Agora que Capistrano 2.0 foi finalmente lançado, você está envolvido em alguma nova ferramenta open source?

Jamis Buck: Com Cap2 lançado, estou realmente focado em reescrever Net::SSH e Net::SFTP. Algumas frustrações com suas limitações escrevendo cap2 tornaram isso necessário :) A única coisa “nova” que saiu disso é Net::SCP, que é uma implementação de um cliente SCP em Ruby e que vou lançar quando lançar a versão 2 do Net::SSH e Net::SFTP.

AkitaOnRails: Oh, e falando nisso, eu lembro que o antigo Cap 1.4.1 não tocava muito bem em Windows. Isso é correto? Algum avanço nessa área ou você acha que suportar Windows é muita coisa?

Jamis Buck: Bem, até onde eu sei, cap 1.4.1 funcionava bem em Windows. A limitação é que você não poderia fazer deploy PARA máquinas Windows. Deployment A PARTIR de Windows funciona bem. E sobre fazer cap deploy funcionar PARA Windows, não tenho planos. A dificuldade é que Windows não é um ambiente POSIX, que é uma das premissas do Capistrano, a respeito das máquinas destino.

AkitaOnRails: Ah sim, eu nunca tentei isso, daí minha confusão. Você está certo. Bem, eu acho que já tirei muito de você. Alguma coisa que gostaria de dizer à comunidade Brasileira? :-)

Jamis Buck: “Mantenham-se apaixonados” :) Mantenha a paixão por Rails queimando, é o que faz valer a pena pertencer à comunidade.

AkitaOnRails: Não poderia ser melhor. Algum plano de vir para cá?

Jamis Buck: Ha, nenhum no futuro imediato :) Tenho um bebê chegando em Setembro, o que coloca um freio em planos de viagem :) Mesmo assim, eu adoraria visitar o Brasil algum dia.

AkitaOnRails: Não sabia disso. Parabéns!

Jamis Buck: Obrigado.

AkitaOnRails: Bem, muito obrigado por seu tempo. Foi uma conversa muito instrutiva. Sei que as pessoas vão gostar disso

Jamis Buck: Muito obrigado, Fabio. Estou muito grato por esta oportunidade!

Essa será uma entrevista interessante. Meu convidado desta vez é ninguém menos que meu chefe. Ele não somente é funcionário da Surgeworks mas também um contribuinte ativo na comunidade Ruby e participa principalmente do Grupo de Usuários de Utah (URUG). Muitos dos seus valores e idéias são parecidas com as minhas.

Carl Youngblood trabalhou profissionalmente como engenheiro de software por mais de 10 anos e atualmente é Rails Practice Manager na Surgeworks, uma consultoria de engenharia de software (onde, por acaso, eu também estou :-). Além disso Carl também é dono da Confreaks, uma empresa que grava conferência, seminários e grupos de trabalho, e também é diretor da Mormon Transhumanist Association. Ele se formou bacharel em Língua Portuguesa pela Universidade Brigham Young e também em Ciências da Computação pela Universidade de Washington.

Original English Version: Chatting with Carl Youngblood

AkitaOnRails: Então, vamos começar. É bem estranho entrevistar alguém que já se conhece. Mas vamos tentar. Antes de falarmos sobre Ruby, a primeira coisa que muitos dos meus leitores ficam intrigados é sobre suas excelentes habilidades com o Português. Pode nos dizer o que levou a isso?

Carl Youngblood: Sim. Minha primeira introdução ao Português foi como um missionário Mórmon no Brasil. Eu cheguei em São Paulo tendo recebido um curso rápido de dois meses de Português. Quando cheguei aqui, me pareceu que eu teria que aprender tudo de novo – essa não era a linguagem que nos ensinaram! Mas depois de passar dois anos no Brasil em um contexto em que era imperativo conversar com as pessoas, eu aprendi Português bem. Entretanto, eu diria que minhas habilidades eram primariamente de conversação. Mais tarde eu descobri a literatura portuguesa e desenvolvi melhor minhas habilidades de escrita.

Ao retornar aos Estados Unidos, eu decidi fazer duas faculdades, de Português e Ciências da Computação. Decidi aprender Português porque gostei muito da língua, e senti que tinha talento para isso. Escolhi Computação porque me apaixonei por computadores desde que tinha 12 anos e ganhei meu primeiro Commodore 64. Ou talvez tenha sido 10 anos. Não lembro exatamente.

AkitaOnRails: Onde ficou durante esses dois anos no Brasil? Quais eram suas responsabilidades aqui?

Carl Youngblood: Eu fiquei em Monte Mor (uma pequena cidade perto de Campinas), Campinas, Marilia, Umuarama, Maringá e Campo Grande.

AkitaOnRails: Mas você fazia alguma coisa relacionada com computadores aqui durante esse período? As pessoas aqui ficariam interessadas em saber o que achou do nosso país, sendo um estrangeiro que passou um bom tempo entre nós. Quais suas impressões pessoais sobre o país, as pessoas, a cultura, nossos hábitos locais? Talvez algumas palavras sobre algumas coisas boas e ruins :-)

Carl Youngblood: Meus primeiros quatro meses foram gastos na maior parte encontrando com pessoas nas ruas e em suas casas e tentando ensiná-los sobre nossas doutrinas. Apenas para deixar claro, Mórmon é um apelido dado à minha igreja porque eles acreditam em um livro de escrituras chamado O Livro do Mórmon, junto com a Bíblia. Mas o nome completo da igreja é A Igreja de Jesus Cristo dos Santos dos Últimos Dias. De qualquer forma, gastei os primeiros quatro meses ensinando as pessoas e ajudando a conduzir reuniões da igreja e andando um bocado – andávamos mais de 20 km por dia, e eu frequentemente me lembro de andar no meio da noite com dores nas pernas :-) Depois dos primeiros quatro meses, fui chamado para trabalhar no escritório da missão em Campinas como Historiador da Missão – um tipo de secretário. Aí minhas habilidades de computação foram usadas.

Depois de gastar quatro meses em Campinas como historiador da missão, fui chamado para ajudar a abrir uma nova missão em Marília, e gastei outros quatro meses trabalhando no escritório dessa missão no computador.

Eu realmente não desenvolvi nenhum grande software para a missão, embora eu tenha ajudado a desenhar um banco de dados Access que imediatamente caiu em desuso depois que eu fui embora :-)

De maneira geral eu realmente gostei muito do meu tempo no Brasil. Eu descobri o quanto gosto de aprender outra língua, e essa fascinação recém-descoberta me levou a estudar essa língua mais tarde na universidade. As pessoas brasileiras que conheci foram na maior parte muito amigáveis. Não era incomum ser convidado às casas das pessoas para comer mesmo antes de nos conhecermos, e eles normalmente estavam dispostos a dar mais do que podiam oferecer. Eu também gosto muito de música Brasileira, especialmente Música Popular Brasileira (MPB). Tom Jobim é meu herói, junto com outras lendas como João Gilberto, Luiz Bonfá, Vinícius de Moraes, e outros artistas mais modernos como Caetano Veloso, Gilberto Gil e Djavan. Foi maravilhoso descobrir um mundo completamente novo de música e literatura que se abriu para mim quando aprendi Português. A comida foi muito boa também, embora eu tenha sentido falta de alguns itens de casa, como milho frito e manteiga de amendoim, por mais estranho que pareça.

Por outro lado, eu frequentemente notava uma profunda falta de ambição. A maioria dos Brasileiros que conhecemos se contentavam em ter um teto sobre suas cabeças, comida na geladeira e uma TV. Claro, minhas observações devem ser meio limitadas pelo fato de ter interagido mais com a classe mais pobre da população que não moravam em grandes condomínios, que eram difíceis para nós visitarmos sem ter agendado com antecedência. Um dos problemas mais difíceis do Brasil é a grande disparidade entre rico e pobre e a conseqüente pequena classe média. Quando o Brasil aboliu a escravidão (um dos últimos países a fazer isso), pouco ou nenhum esforço foi feito para assistir os escravos emancipados na transição para empregos no novo sistema econômico, que levou ao desenvolvimento de muitas cidades autônomas cruas que eram praticamente completamente isoladas dos mais “respeitáveis” centros de comércio. Essa isolação continua hoje. Não é incomum ver um subúrbio bem abastado bem ao lado de uma favela decadente, como se uma estivesse ignorando a existência da outra. Apesar disso, no geral o Brasil está avançando e o padrão de vida melhorando dramaticamente.

Um evento que eu me lembro bem foi o advento da internet pública e a WWW em 1995 enquanto eu estava em Maringá, acredito. Antes eu comentava sempre com meu irmão, na época das BBS baseadas em texto que seria legal criar uma linguagem de markup que permitisse computadores renderizar gráficos através de uma conexão discada de modem. Quando eu vi a WWW em 1995, disse, “Alguém roubou minha idéia!” :-)

AkitaOnRails: Haha, então você estava envolvido em atividades online desde antes do advento da Web propriamente dita? E, você entrou na faculdade depois desses dois anos aqui?

Carl Youngblood: Eu estava envolvido em BBSes baseadas em modem em nossa cidade de Provo, Utah, desde 1990 mais ou menos. Meu irmão tinha uma BBS chamada ‘London after Midnight’. Ele estava meio que nesse cenário de gótico/cyberpunk (ou pelo menos queria estar :-). Na maior parte do tempo usávamos para piratear joguinhos, antes de eu crescer e entender que outras pessoas estavam tentando se sustentar com essas coisas.

Eu já tinha feito um ano de faculdade de música (performance de Clarinete) antes de ir para a missão. Depois da missão eu retornei à faculdade e mudei de cursos.

Falando nisso, também estávamos conectados a uma rede mundial chamada Fidonet, onde participávamos de grupos de notícias e tínhamos discussões offline. Toda noite nosso computador discava para um sistema em Nevada para baixar as novas mensagens.

AkitaOnRails: Oh, isso é legal. Voltando ao assunto, eu também estava em BBSes por causa do meu vizinho. Ele tinha uma BBS hacker chamada Medusa e nós brincávamos muito de quebrar senhas, usávamos Blue Box e assim por diante. (Caramba, estamos confessando muitos crimes aqui, espero que ninguém nos processe ;-) ) De qualquer forma, então você também foi pego na época da Bolha da Internet? Fazendo sites PHP e coisas do tipo?

Carl Youngblood: Haha, bem lembrado. Essa época de BBS foi divertida. Nos sentíamos como se estivéssemos na vanguarda. Omniture (chamado de MyComputer.com na época) estava no meio de uma aquisição pela NetObjects. Entretanto, antes da aquisição ter sido fechada o preço das ações da NetObjects caíram ao ponto deles serem depreciados para a metade do custo da aquisição, o que basicamente significava que isso não ia acontecer. A MyComputer.com demitiu muitas pessoas, mas eu saí alguns meses antes disso acontecer. Meu chefe, falando depois do acontecido, me disse que eu teria conseguido me manter no trabalho (fui um dos primeiros empregados), mas vi sinais de problemas e tive outra oportunidade, então peguei o emprego na Legato Systems desenvolvendo drivers de espelhamento no Windows.

AkitaOnRails: Mesma coisa para mim aqui no Brasil. Eu estava envolvido com empresas ponto-com que faliram mas eu pude sair com alguns meses de antecedência. De qualquer forma, então você foi direto para programação baixo nível. Quantas habilidades de programação você tem? De assembler de baixo-nível até Ruby, sem mencionar Pascal, VB, PHP, etc?

Carl Youngblood: A Legato acabou fechando seus escritórios em Orem, Utah, e nesse ponto eu voltei para a escola para me graduar. Eu comecei pensando em fazer mestrado em Português e eventualmente trabalhar como um professor de uma universidade depois de pegar meu PhD. Entretanto, eu me via constantemente trabalhando com projetos de software, mesmo quando eu lecionava aulas de português e fazia meus estudos de graduação. Eventualmente decidi que deveria encarar o óbvio e continuar minha paixão por desenvolvimento de software. Então eu mudei para o departamento de Ciências da Computação e comecei a trabalhar na direção de um mestrado em Computação. Tudo isso foi na Universidade Brigham Young em Provo, Utah.

Primeiro eu aprendi Pascal e C++ no colégio. Minha primeira experiência profissional foi como programador C++ desenvolvendo aplicações Windows usando MFC. Então consegui um emprego fazendo desenvolvimento PHP/MySQL para a Omniture. Depois disso eu estava fazendo drivers Windows em C mas também fazendo Ruby, Perl e PHP em paralelo. Drivers são bichos totalmente diferentes porque você não tem nem mesmo as bibliotecas comuns ANSI C disponíveis para você. Então a sintaxe C é a mesma, mas é só isso. Mais tarde consegui um trabalho na Boeing fazendo mais desenvolvimento C++ em plataforma Linux, e ao mesmo tempo aumentando minhas habilidades em Ruby/Rails com projetos paralelos. Eu também aprendi programação funcional com
Scheme, assim como com algumas outras linguagens como OCaml, Prolog e ZPL durante meu mestrado. Eu não me chamaria mais que um amador na maioria dessas linguagens, mas eles definitivamente abriram minha mente para novos paradigmas de desenvolvimento.

AkitaOnRails: Você tem seguido muito dos caminhos descritos pelos Pragmatic Programmers como David Thomas e Chad Fowler: aprender novas linguagens, especialmente as que tem paradigmas diferentes. Você já conhecia o trabalho deles sobre essas recomendações? Ou foi somente uma curiosidade natural que o levou a aprender tantas linguagens?

Carl Youngblood: Bem, os programas de Ciências da Computação que estudei em (BYU e Universidade de Washington) fizeram um bom trabalho em nos dar pelo menos alguma exposição para uma gama grande de conceitos e linguagens. Eu certamente estou agradecido pela minha educação porque me apresentou a novas idéias e conceitos que eu provavelmente não teria estudado se não fosse por isso. Eu também tinha lido Pragmatic Programmer e tentei seguir os conselhos de sempre aprender novas coisas e me expor a novas linguagens. Eu também sou meio que um viciado em informação. Eu sou praticamente viciado no meu leitor de feeds RSS, e me sinto incrivelmente ansioso se começo a ficar para trás na minha leitura – quase como se eu estive sendo deixado para trás enquanto o mundo se reinventa. A verdade é que normalmente não perco qualquer coisa extremamente revolucionária por estar fora do computador por alguns dias, mas algumas vezes me sinto assim.

Ou ainda, eu me preocupo que isso poderia acontecer :-) Pode ser um problema. É difícil chegar a um equilíbrio, especialmente com esposa e filhos para dar atenção também.

AkitaOnRails: Você está certo. Isso é outra coisa que eu sempre grito nos posts do meu blog: ser bem informado, sempre. Não há desculpas com ferramentas como agregadores de RSS atualmente. E se um americano pôde ir tão longe para aprender Português e ainda assim ser um especialista em tecnologia como você, há ainda menos desculpas para brasileiros não melhorarem seus Inglês e ler mais.

Carl Youngblood: Tenho certeza que você conhece a teoria de Maximizadores vs Satisfeitores. Eu li sobre isso no blog de alguém, tirado de um livro (que não me lembro qual). Algumas vezes eu … me preocupo tanto que possa existir uma solução mais elegante lá fora que eu não consigo me decidir quando está bom o suficiente e ir direto para o negócio de codificar.

AkitaOnRails: hm, sim, acredito que já li alguma coisa sobre isso.

Carl Youngblood: Esse é um problema nessa era de rápida inovação. Sempre é um alvo em movimento., e algumas vezes você tem que dizer que algo está bom o suficiente e seguir em frente.

Joel Spolsky falou sobre isso e compara às táticas militares de colocar a cobertura de fogo em camadas e atirar enquanto avança. Raramente uma nova tecnologia ou palavreado novo é tudo que promete ser, mas isso mantém a competição brigando pelo seu lugar.

Em geral, parece que a sociedade está avançando em direção a níveis de crescimento constante de abstração. Rails é um bom exemplo disso. Toda sua mentalidade é predizer o máximo possível as coisas que os desenvolvedores vão querer fazer o tempo todo e tornar as abstrações convenientes para eles. Mas estou certo que esse é apenas o começo. Podemos esperar futuros frameworks fazer mais e mais do trabalho pesado para nós, que por sua vez nos capacitará a atingir mais e mais com menos e menos esforço.

AkitaOnRails: Sim, é um bom ponto de vista. Porque as pessoas tendem a ‘se apaixonar’ com uma super-nova tecnologia em particular e esquecer sobre todo o resto. Isso leva a pura obsessão. E depois de um tempo, essa ‘nova tendência’ é esquecida totalmente e você apenas perdeu seu tempo.

Carl Youngblood: Sim, precisamos nos manter atualizados em novas tecnologias mas tentar não se tornar muito dogmáticos sobre eles. A recente apresentação de Chad Fowler na MountainWest Ruby Conference falou sobre isso.

AkitaOnRails: Ei, perdoe o trocadilho, mas vindo de alguém com tanta formação dogmática religiosa formal como você, é uma coisa muito interessante de ouvir: ‘não seja tão dogmático.’ No fim é tudo uma questão de bom senso, mas mesmo bom senso tem que ser treinado. Daí a necessidade de se manter sempre bem informado, constantemente estudando e mantendo a mente aberta para coisas novas e não fechando os olhos para todo o resto.

Carl Youngblood: Eu acredito que a estrutura de crença de qualquer um nunca deve ser tão rígido a ponto de não permitir modificações. Eu estou sempre disposto a re-examinar minhas crenças sob a luz de novas evidência e estou pronto a rejeitar ou modificar crenças que parecem erradas ou mal-informadas quando colocadas sob escrutínio.

Em defesa da minha instrução Mórmon, embora seja uma religião meio conservadora, ela valoriza boa educação, o que inevitavelmente leva à iluminação e normalmente à modificação de crenças anteriores. Felizmente meus colegas paróquios ainda me recebem bem, embora algumas das minhas crenças pareçam um pouco não-ortodoxas e são diferentes daquelas que eu tinha quando era mais jovem.

AkitaOnRails: Nós precisamos mais desse tipo de pensamento no Brasil: pragmatismo. Enfim, voltando outra vez, você esteve ocupado por um longo tempo. Aprendendo português, terminando sua graduação, trabalhando em companhias de Internet, companhias tradicionais. E todo esse tempo Ruby estava pelos lados, aguardando. Quando você finalmente entendeu que queria fazer mais Ruby? Foi durante algum projeto no seu trabalho, ou foi algo que você decidiu por si mesmo?

Carl Youngblood: Acho que acordei de verdade com o crescimento meteórico de Rails e da evangelização da 37signals sobre a mentalidade Caindo na Real. Eu assisti à palestra Construindo Basecamp em Seattle e fui à primeira RailsConf. Eu estava realmente inspirado pelo discurso de Nathaniel Talbott sobre homesteading.

Uma coisa que me pegou sobre minha experiência na RailsConf foi que eu vi colegas lá que começaram a usar Ruby ao mesmo tempo que eu e cujos nomes apareciam nas listas de discussão de Ruby junto com o meu. A principal diferença entre nós é que eles decidiram se tornar ativamente envolvidos, a desenvolver projetos open source deles mesmos, e a construir uma reputação para eles na comunidade, enquanto eu enrolava em Ruby mais como um hobby. Avançando quatro ou cinco anos à frente e eles já estavam dirigindo suas próprias empresas e realmente fazendo uma carreira em Ruby. A RailsConf foi um grande toque para eu entender que eu precisava estar mais envolvido na comunidade.

Então decidi lançar alguns trabalhos anteriores meus como gem e dar uma apresentação na nossa conferência Ruby local Mountain West. Eu lancei o gem SBN (Simple Bayesian Networks). Preparar minha apresentação e código foi estressante mas valeu a pena.

Alguns colegas e eu também estamos trabalhando em um negócio de gravação de conferências chamada Confreaks. Estamos esperando fazer uma trabalho melhor em gravar e disseminar conferências técnicas para motivos de posteridade. É uma vergonha que todas essas grandes conferências estão acontecendo e ninguém está gravando.

De qualquer forma, meu envolvimento crescente na comunidade tem me ajudado a acelerar minha carreira e me permitiu codificar em Ruby como um trabalho.

AkitaOnRails: Mas onde você estava na época em que Rails começou a chamar atenção? Seu trabalho permitia ter tempo suficiente para dedicar a Ruby ou você já tinha trocado de emprego? Quero dizer, você não estava satisfeito com o estado da época da sua carreira e as tecnologias que usava? Qual foi seu ‘ponto de virada’? Apenas ver a RailsConf e as notícias sobre Rails?

Carl Youngblood: Eu estava trabalhando para a Boeing quando Rails apareceu. Era um emprego confortável e sem muita pressão e um projeto do Departamento de Defesa com um cronograma fixo e longo que me permitia tempo para estudar. Eu já tinha o hábito de me manter atualizado nas tecnologias atuais (Ruby em particular) e ler vários tipos de blogs regularmente. Eu teria aceito uma posição de Ruby a qualquer momento mas ainda era difícil de arranjar. Quando pedi, meu chefe me pagou para que eu pudesse ir à RailsConf, então eu já estava bem interessado. Eu já vinha trabalhando em um projeto freelance que eu tinha escrito antes em PHP, e ofereci para reconstruir em Rails com um grande desconto apenas para ganhar experiência em Rails. Então você poderia dizer que eu estava bem interessado em tudo relacionado a Ruby desde 2000 mas apenas recentemente o mercado de trabalho começou a suportar posições Ruby em tempo integral.

AkitaOnRails: E sua primeira empreitada em direção a Ruby foi seu projeto open source SBN e a palestra na Mountain West? Poderia nos descrever como foi? Pelo menos para mim, quando eu quero ‘dizer’ alguma coisa, eu fico muito empolgado e particularmente ansioso em ter tudo escrito (no meu caso, em posts no meu blog). Eu posso imaginar que você quase não deve ter dormido antes da conferência. :-)

Carl Youngblood: Sim, eu fiquei acordado muitas noites preparando minha palestra. De fato, a maior parte das minhas noites foram gastas deixando o código pronto para consumo humano. Saber que o mundo em geral vai usar seu código o faz querer refinar mais que o normal, escrever mais testes unitários, etc. Então eu gastei um mês ou dois antes da conferência trabalhando no código e só tive uma semana para preparar os slides. O material da minha apresentação era bem técnica, então eu acabei escrevendo minha palestra como anotações nos slides, só para garantir que eu não explicaria alguma coisa errada por causa da pressão do momento. Se eu tivesse mais tempo eu gostaria de ter memorizado os pontos chave para que a apresentação ter sido mais natural, mas no geral fiquei contente de como as coisas funcionaram. Eu também estava trabalhando no projeto da Confreaks de gravar a conferência, então eu estive ocupado em duas frentes, sem mencionar meu emprego.

AkitaOnRails: E nessa época você ainda estava na Boeing? Ou você já estava na Surgeworks? Como começou a trabalhar na Surgeworks em tempo integral?

Carl Youngblood: Na época em que eu estava terminando o mestrado em Ciência da Computação na Universidade de Washington enquanto estava trabalhando na Boeing, eu recebi a oferta de um amigo para retornar à Utah e trabalhar para ele como CTO de uma construtora chamada Construction Capital Source. Uma das minhas responsabilidades seria desenvolver o sistema deles em uma tecnologia de minha escolha, que por acaso foi Rails. Eu mordi a isca e passei por um grande momento pelo ano e meio seguinte. Mas a empresa passou por dificuldades com o crash recente no mercado de construção. Embora seus clientes tivessem excelentes taxas de crédito, o mercado passou um pano por toda a indústria, e nossos investidores ficaram assustados. Eu terminei deixando minha posição e aceitando um trabalho na Surgeworks como “Rails Practice Manager,” o que significa que eu supervisiono todos os projetos de Rails da empresa, e com sorte gastando pelo menos metade do meu tempo codificando, embora no momento ainda não tenha funcionado bem assim. Temos ganhado muito mais trabalho desde que comecei, então muito do meu tempo tem sido gasto escrevendo propostas e estimativas de projeto até agora, mas estou estabilizando.

AkitaOnRails: Mas como você conheceu a Surgeworks? Lembro você ter mencionado que já conhecia Dane Falkner de outro lugar?

Carl Youngblood: Dane e eu ambos participamos das reuniões do grupo local de usuários de Ruby em Salt Lake City, então eu o conhecia de lá. Depois de deixar a CCS, eu postei uma mensagem na lista do URUG e fiquei feliz em ver que havia muitas posições de Ruby disponíveis. Acredito que não terei problemas em encontrar trabalho com Ruby no futuro enquanto estiver interessado em codificar em Ruby :-)

AkitaOnRails: Isso é legal. Existem vários grupos locais aqui também. Ainda estamos no começo desses grupos aqui no Brasil. O que você pode dizer sobre o crescimento e entusiasmo da comunidade? O que você vê para Rails daqui para frente?

Carl Youngblood: Na minha experiência, a chave para o sucesso de grupos de usuários é ter um ou dois indivíduos dedicados com paixão para organizar e promover as reuniões e alinhar o interesse nas apresentações. Se fizer isso, as pessoas vão participar. Nossos grupos locais passaram por altos e baixos dependendo do nível do entusiasmo dos organizadores. Outra coisa que parece ajudar é gerar conteúdo destinado a vários níveis de capacitação. Garantir que está recepcionando e ajudando iniciantes é importante. A comunidade ainda está crescendo, como evidenciado por muitas conferências regionais de Ruby que estão nascendo por todo os EUA.

Eu estava empolgado pelos planos das funcionalidades para o Rails 2.0 do DHH e sua retórica mais contida em oposição à primeira RailsConf, o qual alguns comentaram que pareciam mais um rally de Nuremburg :-) Acho que Rails vai continuar a amadurecer e tem pelo menos 2-3 anos de grande sucesso antes de sofre a eclipse de algum novo paradigma.

AkitaOnRails: Isso é importante e talvez você possa dar algumas idéias. Muitos dos principais colaboradores de Ruby e Rails no Brasil, dos nossos fóruns locais, grupos de usuários, blogs e websites ainda não tiveram a oportunidade de trabalhar em tempo integral com Rails. Então eles tem pouco ou quase nenhum tempo para devotar a Ruby ainda. Acredito que já houve um tempo assim aí nos EUA. O que você acha que foi o ponto de virada para a comunidade florescer?

Carl Youngblood: Acredito que acima de tudo, o incrível sucesso (especialmente o sucesso de marketing) do Rails tenha sido o maior colaborador para essa mudança. Mas isso não impediu desenvolvedores de Ruby apaixonados de trilharem seu próprio caminho antes disso. Eu acho que o que precisa mudar no Brasil é a mentalidade de “é somente mais um trabalho”. As pessoas precisam começar a seguir algumas das recomendações da Pragmatic Programmer a sério e encontrar tempo para atividades de capacitação extra-curriculares, incluindo reuniões de Ruby. Foi o que o pessoal nos EUA fizeram e eu acho que algo similar seja necessário no Brasil. Também acho que exista uma diferença cultural que podemos culpar parcialmente. Não quero afirmar que qualquer um dos sistemas seja superior, mas acho que Americanos (pelo menos os tipos ambiciosos que estão na comunidade Ruby) gastam mais de 40 horas por semana focando na sua arte, e por outro lado acredito que muitas pessoas no Brasil olham para desenvolvimento de software como algo apenas para pagar as contas.

Claro que temos muitos programadores aqui com a mesma mentalidade.

AkitaOnRails: Falando em paixão, David sempre reafirma sobre o senso de estética da comunidade, seu senso essencial de beleza em relação à codificação. Você sentiu isso quando começou? Muitos dizem que essa é uma das razões para a comunidade Ruby e Rails ser tão focada em direção a Macs. O que acha disso?

Carl Youngblood: Eu concordo. Matz normalmente menciona o provérbio Chines que diz algo como “o começo da sabedoria é dar nomes corretos às coisas”. O pessoal de Ruby tende a gastar muito tempo focando na semântica e garantindo que o código não só é útil mas elegante. Acredito que quanto você procura maximizar seu nível de abstração e, por conseqüência, seu poder de programação, esses tipos de coisas são muito importantes e podem fornecer um enorme ganho de produtividade.

A Apple parece refletir uma mentalidade similar em seus designs.

AkitaOnRails: Eu acho que seria legal mencionar que eu fiquei bastante surpreso de ver quase todo mundo na Surgeworks sendo fãs Apple. Nunca esperei por isso. Acho que a Apple está ganhando a mesa dos desenvolvedores valorizada como uma ferramenta de produtividade. Bem, eu sei que já abusei de você por muito tempo :-) Algum outro comentário para a audiência Brasileira?

Carl Youngblood: Acho que muito da paixão da Surgeworks por Apple vem do Dane, que é um grande fã. Meu principal conselho aos meus amigos no Brasil é de reconhecer a importância que seu esforço individual pode ter. Vocês tem uma indústria de TI relativamente forte para a América do Sul uma comunidade open source crescente. Eu tenho ficado muito impressionado com alguns dos techies Brasileiros de maior voz como você, Fabio, que começou a compartilhar suas opiniões na Internet. Mudança não é trazida pelas massas, mas por indivíduos corajosos e preocupados que se libertam do status quo. Quanto mais brasileiros levarem isso a seu interior, mais cedo os trabalhos de Ruby vão começar a aparecer. Eu me lembro de uma citação que dizia algo assim:

“Nunca duvide que um pequeno grupo de cidadãos cuidadosos e dedicados possa mudar o mundo. Aliás, é só assim que acontece.” (Margaret Mead)

AkitaOnRails: Muito bom. Bem, acho que podemos encerrar por hoje. Muito obrigado! Acho que as pessoas vão gostar disso.

Carl Youngblood: Legal! Obrigado por seu tempo, Fabio.