Phusion Passenger 2.0 and Ruby Enterprise Edition from Carl Youngblood on Vimeo.

We are a little bit late but this is a video interview conducted at RailsConf 2008 by myself and Carl Youngblood (Surgeworks, Confreaks) with Hongli Lai, Ninh Bui and Tinko Andringa of Phusion, creators of Phusion Passenger and Ruby Enterprise Edition, which is fast becoming the deployment method of choice for Rails developers.

Português: Estamos um pouco atrasados mas esta é a entrevista em vídeo feita na RailsConf 2008 por mim e pelo Carl Youngblood (Surgeworks, Confreaks) com Hongli Lai, Ninh Bui e Tinko Andringa da Phusion, criadores do Phusion Passenger e Ruby Enterprise Edition, que está rapidamente se tornando a escolha padrão para deployment.

Portland é uma cidade muito bonita

A viagem de São Paulo para Portland não é nada fácil. No meu caso fiz escala em Dallas. foram 10 horas daqui até Dallas. Mais 2 ou 3 horas de lay over por lá, e mais 4 horas até Portland. É uma viagem cansativa de pelo menos 16 horas de uma ponta a outra.

A melhor coisa de Portland? O MAX!

Aliás, deixo registrado que o aeroporto Dallas/Fort Worth é algo incrível! Segundo um amigo meu, nem é o maior, mas o lugar é imenso. Sem brincadeira, para ir de um terminal a outro você pega um trem elétrico suspenso chamado Skyline! São uns seis terminais, é praticamente uma mini-cidade ali!

Chegando em Portland, o Carl já estava me esperando. E outra boa surpresa: finalmente entendi o tal do sistema MAX de trens. Uma boa parte do centro da cidade e adjacências está ligado via um sistema de trens circulares, baratos, silenciosos, limpos e normalmente vazios. No centro da cidade, inclusive, você pega o trem de graça. Graças a isso várias vezes fomos ao centro, no mall, nos happy hours. Foi muito bom.

Carl e Vinicius, todos nós no Denny’s

A cidade de Portland é fantástica, pelo menos a porção que eu vi me deixou impressionado. Tudo muito grande, amplo, limpo, civilizado, coisa que para um paulista como eu só se vê em cinema. O Oregon Convention Center é um espetáculo à parte. O lugar é ridiculamente grande, sem brincadeira, acho que não existe lugar perto desse aqui no Brasil. 2 mil pessoas se disperçam rapidamente nesse lugar, nada de empurra-empurra, nada de apertos, tudo muito civilizado.

Esses hamburgers do Denny’s são enormes!

Nada é muito longe, meu hotel ficava a poucos quarteirões a pé. Pelo mapa achei que fosse precisar de taxi, mas na realidade é muito perto. O pessoal ficou espalhado por vários hotéis, o Double Tree que era o oficial, o Red Lions, o Holiday Inn, o Hilton. O meu foi o Shilo Inn que dividi com o Carl e com o Vinicius. Mesmo não sendo um dos maiores a qualidade dele já bate muitos dos melhores daqui.

Bem que tentei usar Pownce em vez de Twitter, mas ele também não escala!

Como tudo ficava próximo ao trem, ir até o Double Tree era questão de pegar dois pontos para cima. Queria ir ao centro, bastava uns 15 minutos e já estava lá. Isso com certeza vou sentir muita falta. O tempo foi bem escasso. Eu acordava lá pelas 7:30 e ia dormir lá pelas 2:00 todo dia. O evento ia das 9:00 até umas 21:00 dependendo do dia. Daí sair pra conversar, comer, e rapidamente já estava tarde. Foi uma longa maratona. No meu caso eu não podia ficar apenas assistindo as sessões, eu queria entrevistar, conversar, fazer contatos e tudo mais. O resultado disso vocês puderam conferir nos posts anteriores. Vida de blogueiro não é fácil.

Acho que a baleia do Twitter é mais legal que o Alien do Pownce!

Como o Geoffrey também falou, a parte mais legal dessa conferência é o contato com as pessoas. Poder encontrar com nomes que são “famosos” apenas para nos certificar que elas são normais e de carne-e-osso como você. Rapidamente você se acostuma e parece que conhece aquele pessoal faz muito tempo. No meu caso, até o último dia, claro que meu cérebro já estava praticamente uma geléia, então parecia até que eu estava meio no limbo.

Eu, o Vinicius e o Carl pagando mico do lado do Jim!

Foi legal que depois das sessões oficiais, todo dia havia o Birds of the Feather. Eram sessões independentes onde juntava uma galera para falar de diversos assuntos. Não participei de nenhuma, aliás, só de uma. Depois de jantar, o Carl nos levou de volta à convenção e o pessoal estava reunido tocando e cantando. O Chad, o Jim e vários outros. Como todos já devem saber, o Carl fala português perfeitamente. E mais: ele sabe muitas músicas brasileiras. E queria nos empurrar pra cantar também! Eu estava perdido, afinal sou péssimo em música e praticamente não conheço nenhuma música nacional (sou japonês :-P ). Male, male cantamos “Garota de Ipanema”. Mas foi interessante.

Rich Kilmer, Cindy, Chad (ThoughtWorks)

Muita gente vê esse pessoal todo em fotos, em screencasts, dá para imaginar que são todos frios, sérios, sisudos. Foi uma feliz constatação ver que não são assim. Mesmo os que tem cara mais séria (como um Ezra), sempre foram muito receptivos, abertos a conversar e discutir idéias. Muitos deles foram super-extrovertidos, tiraram fotos engraçadas, participaram de entrevistas, e muito mais. Muito da imagem de ‘arrogância’ vem porque nós só lemos os blog posts, mas o David Hansson, por exemplo, é um cara muito gente fina.

Evan Phoenix, Nick Sieger, Wilson Bilkovich

Como disse antes, eu fiquei bastante surpreso de encontrar diversas pessoas de vários países que conheciam meu blog. Isso com certeza me deixou muito contente e ao mesmo tempo um pouco ansioso, pois eu não imaginava essa recepção. Mais legal ainda foi encontrar vários brasileiros perambulando por lá. Ao total acho que tinha pelo menos uma dúzia!

Eu, Peter Cooper e o Chris Wanstrath (Err the Blog/Github)

Porém, nesses quatro dias eu não estava a 110% como o David disse na sua apresentação, eu certamente estava a 150%. Eu literalmente não estava parando um segundo. Peço até desculpas porque acho que deixei muita gente falando sozinha várias vezes. Minha atenção estava muito dividida (literalmente, acho que meu cérebro não escala :-)

Toda a galera do Brasil, em peso!

De qualquer forma, tivemos algumas chances de conversar, trocar algumas idéias, almoçar ou jantar, de uma forma ou de outra nos trombávamos por lá. Pessoal da Globo.com, UOL, BlogBlogs, Improve it e vários outros. Alguns brasileiros que moram nos Estados Unidos como o Bruno Miranda e o Márcio Castilho, e assim por diante. Aliás, eu não consigo lembrar o nome de todo mundo. Galera que esteve lá, por favor, deixem seus nomes no comentário para que eu saiba quem são! Aliás, ainda estou esperando os blog posts de vocês sobre o evento!

Eu sei, eu sei, essa foto ficou ‘esquisita’, mas não podia deixar o Bruno de fora.

O Carl tem razão, só dá para dar o devido valor a uma conferência como essa estando lá. Provavelmente eu não estava dando o valor necessário, mas felizmente, devido à uma sequência de eventos positivos, acabei sendo ‘empurrado’ em direção a Portland e, com muito sucesso, passei por ela trazendo ótimas experiências.

Jim Weinrich tem que ser o cara mais simpático que existe :-)

Fiquei muito contente de ter conhecido tanta gente, espero que ano que vem mais brasileiros possam comparecer, mas no que depender de mim, farei o possível para estar lá de novo!

Jantar no domingo com o pessoal da Phusion. O comilão é Josh Goebel (Caboose/Pastie.org)

Odeio despedidas, desta vez não foi diferente. Cada um foi para seu canto, o Carl de volta a Utah, o pessoal da Phusion indo para Cupertino (!), o Vinicius indo pra Chicago e assim vai. É para isso que existem encontros como esse: para nos juntar pelo menos uma vez por ano. Eu saí de Portland na segunda-feira de manhã, cheguei na terça-feira de manhã e dormi o resto do dia, desabei! Daí quarta e quinta-feira eu me fechei no meu cubículo com o intuito de compilar tudo que eu lembrasse e todo o material que eu trouxe. Finalmente, fecho aqui meu último post nessa série da RailsConf 2008, espero que todos tenham gostado!

Andando às margens do rio que corta Portland, muito legal!

Agradecimentos a todos que me deram apoio – em especial ao Carl e ao Vinicius, sem os quais eu não teria chego lá -, à grande organização da Ruby Central, a todos os meus amigos e espero encontrar todos novamente!

Este sou eu, exatamente sobre o trilho do MAX. Akita “On” Rails!

[]’s

A maioria dos patrocinadores tinha alguma coisa relacionada com escalabilidade. A Engine Yard apresentou o Vertebra, a FiveRuns apresentou seu TuneUp, a New Relic tem o RPM, a RightScale tem seu sistema sobre AWS, a Morph tinha o Morph eXchange, a Heroku também tinha sua solução AWS e assim por diante.

Aliás, de uma vez por todas, porque várias pessoas me apontaram a mesma coisa: os newbies estão o tempo todo confundindo performance com escalabilidade. Uma não é dependente da outra, você pode ter algo extremamente veloz mas extremamente não escalável e vice-versa. As tecnologias em torno de Ruby e Rails não são performáticas, mas são escaláveis. Se não entendeu, leia este artigo

Dentre as diversas soluções uma das mais interessantes foi o Fuzed, uma arquitetura de cluster escrita em Erlang que suporta instalações Rails, mas pode suportar qualquer outra tecnologia. É um cluster inteligente que cuida das suas instâncias. Difícil explicar em palavras. Infelizmente ainda não tem muita informação online, mas achei a apresentação do Tom Preston e do David Fayram. O objetivo é usar YAWS e Erlang para criar uma infraestrutura que torne trivial deployments de instâncias Rails em slices EC2.

David Fayram e Tom Preston explicando Fuzed

Aliás, serviços como o AWS e o próprio cloud computing da Engine Yard foram estrelas. O mundo está se movendo em direção a cloud computing. Sistemas como Fuzed e Vertebra são literalmente os back-bones que vão orquestrar essas instâncias dinâmicas. Está ficando para trás essa idéia de arquiteturas estáticas, alguns scripts capistrano e um número fixo de mongrels. A idéia agora é ser dinâmico, fazer sistemas elásticos e flexíveis que se adaptam às condições de uso.

Assim que conseguir vou liberar as entrevistas que gravei, mas uma legal foi justamente com o James Linderbaum, CEO do Heroku. Como disse antes, eu não assisti à apresentação dele, mas o Vinicius saiu de lá bastante impressionado. Fazer deployment de uma aplicação, no Heroku, significa apenas um ‘git push’.

Sistemas como a da New Relic e FiveRuns disputam outro nicho: o de monitoramento e análise, de forma que eles conseguem dissecar sua aplicação e lhe dar recomendações e opções de otimização. Uma coisa que o Blaine Cook disse na sua apresentação foi que é impossível testar carga. Mesmo que você tenha uma suíte de testes com 100% de cobertura, uma coisa que não tem como prever é o comportamento humano. Mil pessoas se comportam muito diferente de 1 milhão de pessoas e você jamais vai saber como preparar sua aplicação para isso até chegar nesse patamar.

O que me leva de volta ao tal ‘problema’ Twitter. Conversei com o Ezra, com o Obie, e todos foram categóricos: não existe problema em escalar Rails. Não é o framework que vai fazer a diferença e sim a arquitetura total do sistema. Os gargalos começam muito antes, no banco de dados, nos discos, na rede. Todas essas empresas ganham dinheiro com isso, elas sabem exatamente do que estão falando.

Existem pessoas que “acham” que sabem como resolver o problema do Twitter, muito me admira que eles não tenham conseguido sequer fazer um Hello World num site feito em Frontpage. Acham que ‘entendem’ de banco de dados “o problema é o MySQL, óbvio.” Acham que sharding resolve todos os problemas. Em lugares como Engine Yard estamos falando de engenheiros sérios, que enfrentam esse tipo de problemas como rotina. Quando o Ezra diz que o problema é a estrutura de dados, a enorme árvore de amigos-de-amigos que existem nas redes sociais, ele tem razão.

Phusion tirando sarro dos ‘enterprisey’

O recado de todos foi muito simples: você não tem para onde fugir, se sua aplicação fizer sucesso, é muito provável que você não terá uma solução imediata nem óbvia. Serviços como Heroku podem adicionar novos slices dinamicamente, mas se você realmente fizer muito sucesso, nesse caso estamos falando de reestruturar sua aplicação.

Mas não adianta refatorar do nada, criar novos componentes que você “acha” que vão “escalar” melhor. É burrice. Quando se fala que é um erro otimizar prematuramente, não quer dizer que não se deva fazer nada. Algumas coisas são bastante óbvias e devem ser feitas, por exemplo, garantir que suas tabelas tenham os índices corretos, garantir que seus plugins, serviços não estejam gerando gigabytes de arquivos de log por hora, etc.

Porém, criar uma arquitetura maluca baseada apenas em ‘feeling’ é burrice. Use o que você tem à mão, ganhe tempo, lance cedo e torne seu produto um sucesso. Se conseguir fazer isso, aí você terá dados suficientes para começar a entender como seu aplicativo realmente se comporta. Com esses dados em mãos, aí sim deve começar o trabalho pró-ativo de otimização, refatoramento e, talvez, de reescrita de partes da aplicação.

Nenhum de vocês será um Twitter, é muito difícil. Mas existem vários casos sérios e que deram muito certo. Um case que eu gosto é o do John Straw, sobre reescrever o YellowPages.com. Esse website server 23 milhões de visitantes únicos/mês. 2 milhões de pesquisas/dia. Mais de 48 milhões de requisições/dia.

Vejam a apresentação, mas no final, sabe onde eles tiveram a maior quantidade de problemas de performance? Pois bem, justamente com o Oracle que não gosta de muitas conexões. Outra coisa foi a performance de carregamento de páginas. O problema foi mais por causa de download de imagens, css do que qualquer outra coisa. Sigam o guideline do Yahoo! sobre performance.

Outro case interessante é do TJ Murphy com seu Warbook um jogo social online em Rails para Facebook. Ele literalmente tem um negócio que fatura US$ 100 mil/mês e gasta apenas US$ 2 mil/mês em infra-estrutura. No caso específico dele, foi possível jogar quase tudo em memcache (95% dos hits) e usar bastante da elasticidade do AWS. O mais importante: medir antes de otimizar, ele fala em ferramentas: mire antes de atacar.

equipe da Engine Yard respondendo perguntas

No Hosting with Woes a equipe da Engine Yard discorreu algumas dicas sobre o que eles já viram todos os dias. Coisas como “não use Ferret, use Sphinx, confie em mim!” Algumas coisas úteis como discussões ebb x mongrel x thin. O que eles disseram faz muito sentido: tanto faz: sua aplicação precisa ser gigantesca para você começar a sentir alguma diferença. Além disso parece que neste momento o Thin não é muito bom para lidar com actions que demoram muito.

De qualquer forma, use NginX (eles não tinham visto Passenger até então :-). Num slice como da Engine Yard, 3 mongrels por CPU é mais do que suficiente, seu I/O vai embora antes da CPU. Para tarefas muito demoradas não use BackgrounDRB, ela foi feita de maneira ingênua, atualmente o melhor é usar BJ (Background Job) que é muito melhor.

Eles também falaram para parar de se preocupar com picos de Digg, TechCrunch, etc. Pelo menos sendo clientes deles, quer dizer :-) O que acontece é que em precisando de mais recursos, ele liberam no momento de pico e pronto. O mais importante é que sua aplicação seja o mais cacheado possível, se pudar colocar Page Cache mesmo na sua front-page melhor ainda. Um Digg pode chegar a dar até 10 mil visitantes no dia, um TechCrunch uns mil, um Ruby Inside/Ruby Flow, de 500 a mil. TV é diferente, um The Today Show pode levar até 100 mil visitantes e uma Fox News Business Show cerca de 2 mil conexões. O problema é que a maioria dessas visitas é ‘baixa-qualidade’, ou seja, poucos se dão ao trabalho de se registrar no seu serviço. Eles apenas atropelam e vão embora, por isso nem é relevante buscar esse tipo de audiência.

A Engine Yard estava particularmente mais engajada na missão de desmistificar os problemas de escalabilidade do Rails. O Ezra é um forte proponente nessa área e acho difícil qualquer outro Railer ter cacife suficiente para peitar alguém com a experiência que ele tem.

entrevistando James Linderbaum, CEO do Heroku

E antes que alguém se engane: o Maglev é revolucionário, sem dúvida, mas não vai resolver nossos problemas tão cedo. Ele é voltado a um nicho muito específico que depende de bancos de dados orientados a objetos. Segundo os engenheiros da Gemstone, separar o Maglev do backend OODB não será simples porque eles são intimamente conectados. Com isso você é obrigado a sempre ter um servidor rodando, mesmo que não queira ou não precise. Ainda estamos meio longe desse divisor de águas. Por enquanto, a realidade nos leva de volta ao MRI e ao JRuby, que são os dois únicos realmente production-ready. E isso não é um problema, com todas as opções, ferramentas e soluções que temos, é preciso talento para não conseguir fazer Rails escalar.

Nessa época, Rails já estava em ritmo acelerado de crescimento desde o ano anterior. Isso com certeza ‘assustou’ muita gente e os ‘forçou’ a se posicionar. Grandes mestres como Martin Fowler já haviam demonstrado seu suporte ao Rails. Por outro lado, nomes conhecidos como Joel Spolsky deram uma cartada fora do baralho.

No meu artigo, eu descrevo os diversos posts que se sucederam naquela semana, envolvendo Joel criticando duramente o Rails e os vários posts do David contra-atacando. Depois Joel criticando a performance do Ruby e sendo contra-atacado por Avi Bryant e pelo Obie Fernandez.

Pois bem, quase 2 anos se passaram e qual não é minha surpresa ao ver na programação da RailsConf 2008 que o palestrante de abertura do evento é ninguém menos que Joel Spolsky em pessoa!?

Foi uma longa apresentação muito bem conduzida. Preciso dar o braço a torcer, o Spolsky é um orador fenomenal. Quem já preparou uma palestra sabe como a dele foi preparada com muito cuidado. Ele tomou muito cuidado para não mencionar Rails nem uma única vez.

O tema era “o que faz um produto ter sucesso?”

Ele começou comparando produtos. Um exemplo foi o iPod contra o Zune. Blue Chip contra Off Brand. Angelina Jolie contra Uma Thurman. Brad Pitt contra Ian Somerhalder. Brian e Angelina são iPods, Ian e Uma são Zunes. O tom dele foi como se quisesse dizer “eu sei, eu sei, concordo. isso é bullshitagem, um Ian mereceria ser tão famoso quanto um Brad, mas infelizmente não é assim que a vida funciona.”

Os pontos que ele explorou foram:

• Faça as pessoas felizes – Uma demonstração que achei engraçada foi que ele montou, na apresentação, uma interação com um Windows, (exagerando) sobre como é difícil conseguir extrair uma foto de uma câmera digital, com o Windows abrindo pop-ups esquisitos, pedindo CDs de instalação de drivers e falhando, etc. Ou seja, coisas que tornam as pessoas infelizes. Em seguida demonstrou 2 processos de checkout num e-commerce, no primeiro o estilo ‘quadradinho’ e pouco flexível de ‘wizards’, já o segundo – da Amazon – era uma tela onde você poderia fazer o que quisesse na ordem que quisesse. Segundo Spolsky, é preciso dar ao usuário a sensação de que ele está no controle.

• Seja obsecado com estética – ele comparou o Samsung Blackjack vs iPhone. Por exemplo, sobre a bateria não removível do iPhone. Ele mostrou como a Apple preferiu não ter um “corte” atrás do fone, ou seja, não ter uma tampa de bateria pela obsessão de ter um design limpo. Não importa que o Blackjack tem mais funcionalidades, o design do iPhone é tão perfeito que “dá a sensação que se eu engolisse ele iria escorregar direto até o fundo.”

Ele foi mais longe e viajou um pouco, falando sobre construções, prédios na França e nos Estados Unidos, e como não ter uma escada de incêndio na frente torna o design mais bonito, ou seja, na França é melhor morrer queimado do que enfeiar a fachada com uma escada. Sobre software, mostrou como coisas como Skins tornam um produto ridículo: se o software não funciona direito não é mudando sua cara que ele ficará melhor. Novamente ele parece pensar “infelizmente as pessoas preferem algo que seja bonito do que algo que funcione. Não brigue contra isso, siga o sistema.”

• Observe a Cultura do Código – ele discursa sobre percepção. Por exemplo, o Ford Explorer (SUV) contra o Toyota Camry (sedam). 88 pessoas morrem num Explorer por ano, contra 41 no Camry. Porém, a percepção é que o Explorer é mais ‘seguro’ que um Camry. Os SUVs tem ‘cantos arredondados’, airbags em todos os cantos, seguradores de copos e são altos. Eles nos enganam em nos fazer sentir seguros. Daí ele explica sobre ‘atribuição errônea’ ou seja, se você assiste um filme no cinema tomando um bom café, pode ser que diga que o filme foi bom por causa do café. Por outro lado se tomasse algo que não gostasse, diria que o filme foi ruim. Mas isso na realidade não tem a ver com a qualidade do filme, mas sim da reação fisiológica da pessoa.

No fim, parecia que ele queria dizer algo como, não importa se o Rails é bom ou não, mas as qualidades de tornar os programadores mais felizes, ser obcecado pela estética do código e toda a cultura ao redor o tornam um caso de sucesso. Independente se ele ache que Ruby seja lento ou que tecnicamente não haja muita coisa, não é ele quem vai mudar como as coisas funcionam.

Por isso mesmo acho que as reações foram adversas. O Ola Bini por exemplo, acha que não foi grande coisa. Muita gente elogiou o entrenimento, afinal o cara é muito bom apresentador. Mas muita gente também criticou, veladamente, a falta de ‘substância’.

Na mesma linha, no fim do dia, foi a vez do keynote do David Hansson. Ele também decidiu ir pela linha menos técnica e mais conceitual. Acho que ele acredita que finalmente já tem gente suficiente para falar das partes técnicas e ele pode falar sobre coisas que gosta mais. A apresentação de Rails 2, no ano passado na RailsConf Europe, foi ele mesmo quem fez. Mas a de Rails 2.1 foi terceirizada para o Jeremy Kemper, que também fez um trabalho competente.

O David começou falando sobre escolhas. Muita gente ‘reclama’ que Rails os força a fazer as coisas de uma determinada maneira, o tal ‘convention over configuration’. Porém, ele acha que as pessoas gostam mais de ter escolhas do que fazer escolhas. Na sua opinião, um dos fatores de sucesso do Rails é justamente porque ele faz as escolhas que você não quer ter que fazer e, se quiser, pode mudar. Nada impede que você faça as coisas diferentes da convenção, mas se seguí-la é provável que o padrão será o suficiente para a maioria.

Daí falou sobre o ‘surplus’ do Rails, ou o ‘extra’. Ou seja, Rails ainda é uma minoria no mundo de desenvolvimento, mesmo assim ele atrai muita atenção e felizmente hoje existem várias empresas e pessoas que vivem disso. Porém, David entende que esse surplus não vai durar para sempre.

Ele deu como exemplo a cidade de Dubai, que está usando o surplus do petróleo para se modernizar mais rápido do que o normal.

Algumas coisas podem acontecer, a competição pode ficar competente em copiar o Rails; ou algo dramaticamente melhor pode aparecer com um novo paradigma que torne o desenvolvimento ordens de grandeza melhor que o Rails; ou o próprio Rails poderia se tornar o mainstream.

Independente do que acontecer, precisamos usar esse ‘surplus’ para não ficarmos para trás. É como quem ganha uma bolada de dinheiro de uma só vez: você pode gastar tudo ou pode investir. É o que David sugere: que nós programadores temos que investir em nós mesmos.

Ele fala de como Rails ajudou muita gente. Normalmente os programadores precisam trabalhar 110% da sua capacidade, apagam incêndios todos os dias, se perdem na mecânica dessa rotina brutal, ficam fatigados, cansados, desmotivados. Agora, quem se encaminhou no mundo Rails, tem a chance de parar, pensar e agir de forma mais inteligente.

Na 37signals, por exemplo, eles estão investindo nas pessoas. Um dia útil da semana é dedicada para que eles façam o que quiser. Seja programação ou apenas um hobby que nada tem a ver com informática, como artesanato. O que eles entenderam é que iniciativas como essa tornam um programador melhor. E muita gente pode achar isso horrível, “perder 1/5 da semana em hobbies!?” Porém, criar um programador que pode render 10x mais que o normal com certeza vale perder 20% da semana.

E quando se fala em ser 10x mais produtivo não significa fazer 10x mais código. Pelo contrário, significa fazer 10x mais eficiente. Ou seja, codificar coisas que são realmente necessárias, em vez de apenas programar volumes de coisas desnecessárias. Esse é um ponto importante. Na média, um bom programador nunca será ordens de grandeza mais veloz apenas em digitação. Mas um bom programador é aquele que sabe priorizar as coisas, fazer as coisas que interessam primeiro.

Um ponto que meus amigos tiraram sarro na hora foi quando o David disse para “dormir mais!” Ok, eu admito, eu durmo muito pouco. E é claro que o David está certo, ninguém deve tentar ser um superman, eu mesmo não recomendo isso para ninguém. Já está mais do que comprovado que o nível de atenção, foco e, claro, produtividade, cai rapidamente com a falta de sono. No meu caso, minha desculpa é que além de programador eu sou um blogueiro. Vou dizer que é mais difícil ser um blogueiro do que um programador :-) Mas isso varia de pessoa para pessoas, de qualquer forma: “durmam mais!”

Algumas vezes é importante você começar um novo projeto do zero, em vez de apenas dar manutenção num sistema já existente. Ele contou como ele descobre mais sobre o próprio Rails quando pula para criar um novo produto. Ficar fazendo sempre a mesma coisa cansa, é sempre bom começar do zero de tempos em tempos.

Finalmente, outro ponto que eu gosto, compartilhe a mensagem, divida e ensine. Você sempre vai aprender mais quando ensinar. Não tem como ‘perder’ conhecimento quando se transmite conhecimento. Conhecimento gera mais conhecimento. Não deixe de compartilhar.

Portanto, o importante para todos nós entendermos é: esse ‘surplus’ do Rails não vai durar para sempre. Alguma coisa vai mudar as regras do jogo, como sempre acontece. Mas quando isso acontecer, devemos estar preparado para isso. Portanto devemos crescer enquanto programadores. Devemos abrir os horizontes para novas possibilidades, diversificar nossas capacidades, transmitir conhecimento. Enfim, nos tornarmos profissionais completos e não apenas mais um soldadinho de chumbo.

Embora nenhuma das duas palestras, tanto do David quanto do Spolsky não tenham sido técnicas, acho que foi importante porque Rails, mais do que uma tecnologia, é uma cultura. Pessoas como eles divulgam cultura e servem de modelo para todos nós. A mensagem implícita entre as duas palestras, para mim, é que briga de egos, rixas inacabáveis, inveja não declarada e coisas do tipo sempre são nocivas para os dois lados.

Quando o David convidou Spolsky ao palco e este subiu, eu vi um ciclo muito ruim se fechar. A rixa de 2006 ficou em 2006. Ambos são profissionais muito bem sucedidos em seus determinados nichos. Não há razão para haver rancor entre os dois. Tudo bem, Joel começou a disputa, David errou ao continuar. Não sei o que aconteceu por trás dos panos, mas independente do conteúdo das palestras (que no geral foram boas) o gran finale foi bom. Acho que a mensagem implícita foi mais interessante do que o que foi falado.

E isso me leva a Kent Beck , o pai do XP. O Vinicius Telles me disse que já havia assistido ele várias vezes e essa foi uma de suas melhores palestras. O desfecho David/Spolsky que eu disse acima me leva a pessoas como Kent. Um bom profissional precisa trilhar um caminho com desses dois para chegar ao nível de sabedoria de um Kent.

Ninguém é perfeito e não estou querendo dizer que Kent precisa ser endeusado, claro, mas não se pode negar que ele é uma presença forte. Ele é muito espontâneo. Não se ateve a slides. Teve meia dúzia, no máximo, na maior parte do tempo ele permaneceu sentado e contando três histórias de sua carreira. Da mesma forma como você ouviria seu avô contando sobre os bons tempos.

Um ponto que eu lembro porque achei engraçado foi sobre como ele começou com Test-Driven Development (TDD) “resolvi fazer um código que não funcionava, depois codificava o necessário para o teste passar, e fui fazendo assim. Nossa, eu tinha a sensação de estar trapaceando!”

Infelizmente eu não decorei a apresentação toda, ele falou muita coisa e respondeu a várias perguntas da platéia. Espero que alguém tenha gravado, porque o interessante é assistí-lo falar. Normalmente eu prefiro apenas fazer download do PDF e ler os bullet points. Mas no caso de pessoas como ele – que por sinal, sequer tem bullet points nos seus slides – o importante é absorver seu entusiasmo, apreciar sua história. Ali está ele, diante de nossos olhos, um dos pais das metodologias ágeis, falando com eloquência, calma, segurança.

E ele tem um ótimo senso de humor. No final, ele resolveu comentar sobre Zed Shaw. Foi algo na linha de “Entendo que esse sujeito, Zed Shaw, que chamou o Rails de Ghetto, incomodou vocês. Eu li e reli a reclamação dele. Se você considerar como um memorando de negócios, deveria ler somente os dois últimos parágrafos, afinal, qualquer memorando começa com baboseira e só nos dois últimos parágrafos é que estão as partes importantes.” Todos deram risada, claro :-)

“E lendo o final, eu entendi que esse Zed disse que o Rails precisa de um mercado transparente de serviços.” Mais risadas. “Bom, muito obrigado pela sugestão. De qualquer forma, resolvi ler de novo, retirando todos os palavrões, ameaças e coisas do tipo. O que sobrou foi que Rails precisa de um mercado transparente de serviços.” Mais risadas :-D

O cara é fantástico!

Achei mais interessante porque o keynote de fechamento foi uma mesa redonda com os demais do Rails Core Team, não estavam todos, mas David, Koziarski, Rick e Jeremy estavam respondendo perguntas da platéia. Uma das perguntas foi algo do tipo “Acho que REST é muito legal e tal, mas e quanto a SOAP? Acho que seria bom o ActiveWebService ser mais completo.” Eles concordam. “Alguém aí se habilita a abraçar essa gem?” O motivo é simples: eles não precisam dela, mas há quem precise. Qualquer um que precise de SOAP poderia contribuir e se tornar o mantenedor.

O próprio Jeremy, em sua apresentação, deu as boas vinda ao Pratik Naik, que resolveu abraçar a proposta de melhorar a documentação do Rails e, graças a isso, se tornou um Core Committer também.

Outra pessoa perguntou algo como “vocês do Core Team costumam observar o que os outros frameworks tem feito, por exemplo, Django, Seaside?” Todos disseram que sim, mas o David foi categórico: “eu gosto muito de Seaside, algumas idéias acabam entrando, porém o objetivo do Rails não é copiar o que os outros estão fazendo. Se você acha que Seaside vai lhe beneficiar mais, por favor, use Seaside. Não há nenhum problema nisso. Aliás, não consigo entender todos esses outros frameworks tentando clonar Rails. Se quer usar Rails, use Rails. Isso não faz sentido algum!”

Não sei se apenas com palavras consigo expressar o que eles quiseram dizer. Rails é um projeto open source que só está onde está graças à ajuda massiva da comunidade. Na apresentação do primeiro dia da “Andrea O.K. Wright”, ela discutiu sobre thread-safety. Um dos pontos que me chamou a atenção foi o projeto do Josh Peek em refatorar o código do Rails para que ele se torne verdadeiramente thread-safe. Seu mentor é o Core Maintainer Michael Koziarski. Vocês podem ver a aplicação dele aqui e o seu fork no Github.

Novamente, volto a tocar no ponto dos pundits. Existem dois tipos de pessoas, as ativas e as acomodadas. As acomodadas todos conhecemos, e normalmente conhecemos mais do que gostaríamos porque muito fazem barulho, como um bando de urubus disputando a carniça. Os ativos normalmente conhecemos pouco, pessoas como Josh. Eles fazem a diferença porque identificam problemas e automaticamente resolvem fazer alguma coisa a respeito. E normalmente são bem sucedidos!

Um exemplo disso foi o Fabio Kung, da Caelum. Ele encontrou problemas na maneira como se desenvolver com JRuby hoje: tendo que usar o Warbler para gerar arquivos .war e ficar fazendo redeployment o tempo todo. Em tempo de desenvolvimento isso é, literalmente, um saco.

O Jeremy concorda com isso. Na parte final da sua apresentação ele começou mostrando as diversas implementações de Ruby rodando Rails, incluindo Rubinius, Yarv e, claro JRuby. Mas nesse último caso ele explicou a mesma dor de cabeça de deployment e explicou como Nick Sieger (um dos Core Maintainers do JRuby) lhe indicou o projeto jetty-rails.

Daí, ele mostrou um slide com esse nome e mais, mostrou o bicho funcionando em tempo real! Mais um excelente exemplo de como os brasileiros se menosprezam, poucos acham que podem subir ao palco, mas o Fabio subiu, e com louvor, indicado pelo Jeremy e pelo Nick como uma excelente solução para JRuby. Que tal?

Quanto às novidades em si do Rails 2.1, o Jeremy foi bastante rápido e apenas pontuou as principais. Acho que todos que acompanham meu blog já sabem, uma vez que eu escrevi o tutorial completo faz algum tempo já. Aqui está a Parte 1 e aqui a Parte 2. Portanto não vou repetir tudo novamente :-)

Aliás, uma coisa que para mim foi muito gratificante, além dos brasileiros que encontrei por lá que me conheciam, ainda cruzei com diversos outros leitores, do Canadá, do México, do Uruguai, dos EUA mesmo. Foi muito engraçado porque nunca esperei que alguém lá fosse me chamar “você é o Akita?” Foi mais interessante porque encontrei com esse uruguaio na hora do almoço e ele me disse “Akita, o Obie está te procurando!” Eu pensei, “caramba! Eu é quem estou procurando ele!”

Fico muito contente que meu trabalho esteja sendo reconhecido lá fora também e espero que isso também ajude a trazer visibilidade para o Brasil. Já soube de algumas empresas e consultorias que enxergaram que podem contratar railers de boa qualidade aqui do Brasil.

E, pouco antes do último keynote, eu estava sentado no salão principal e, por coincidência, ainda consegui flagrar esta cena:

Someone reading my Rails 2.1 tutorial. Anyone knows him?

How cool is that!?

E eu quase ia me esquecendo! No evento havia um “Speaker Lounge”, uma grande sala onde os conferencistas se reuniam. Eu, claro, com minha famosa ‘cara-de-pau’ andei invadindo essa sala várias vezes. Inclusive no primeiro dia ainda almoçamos junto com o David, o Koziarski e o pessoal do Phusion:

Mas eu estou mudando de assunto! Pois bem, depois da apresentação do Rails 2.1 do Jeremy, fui falar com o Chad Fowler quando presenciei esta cena na Speaker Lounge:

Parece que deu algum pau no empacotamento do Rails 2.1 em Gems. Estavam todos do Rails Core reunidos tentando resolver o pepino, incluindo Chad e Jim Weinrich. Eu chamei essa cena de “Situation Room.” Quer algo mais cool do que ter problemas com gems e poder recorrer diretamente e ao vivo com alguns dos maiores contribuintes ao sistema de RubyGems como Chad e Jim? Muito legal!

Em vez disso, eles escolheram um painel de pessoas que já são importantes e decidiram os nominados entre eles, o que eu particularmente achei mesmo mais justo.

Os apresentadores da noite foram ninguém menos que Gregg Pollack (RailsEnvy) e Steven Bristol (Less Everything). Eles explicaram o conceito do prêmio e encorajaram todos a almejar por isso. O prêmio em si é legal, mas o verdadeiro “prêmio” é ver uma comunidade se formar à sua volta, ajudar os outros e ser ajudado em troca. Bons programadores são bons justamente porque dividem seu conhecimento e, com isso, se tornam melhores. Isso pode vir de diversas formas, escrevendo livros, escrevendo código, escrevendo blogs, etc.

O primeiro prêmio foi para Evan Weaver, um excelente programador que contribui com o Rails, com Mongrel e hoje trabalha no Twitter, além de escrever o blog snax.

O segundo foi para ninguém menos que Tom Copeland. Já ouço alguém ao fundo perguntando, “quem?” Bem, se você já instalou pelo menos uma RubyGem na sua vida, deveria agradecer esse cara, que é o responsável pelo RubyForge! Veja o que a O’Reilly tem a dizer sobre Tom:

What do all these numbers mean? Good question. I think, at the very least, it means that the Ruby community is doing very well in terms of library development and releases. I give Tom Copeland a huge amount of credit for that, in that I think the very act of creating RubyForge fostered an atmosphere of development (collaborative or otherwise) and inspired programmers new to Ruby to take the step of releasing their own software. I can’t prove it, of course. It’s just a gut feeling I have after watching the Ruby community grow for seven years.

Vou pular o terceiro porque senão ele vai eclipsar os outros, mas o quarto foi outro bem conhecido: Ilya Grigorik. Principalmente porque seus artigos são excepcionais! Se você nunca leu seus artigos, deveria. Ele consegue pegar temas complexos e explicar de maneira que todos conseguem digerir. Algumas pessoas são excelentes programadores e colaboram com código, outras são excelentes professores e colaboram com artigos, tudo é válido.

“ ”
Ryan, Yehuda, Ilya, Evan, atrás de Steven

O quinto foi Yehuda Katz ele participa de tantos projetos open source que fica difícil até de começar a descrever, mas acredito que alguns dos principais são JQuery on Rails e o DataMapper que é outra boa alternativa ao ActiveRecord e já é muito usado por quem adotou Merb.

Finalmente, o sexto foi Ryan Bates e acho que ele não precisa de apresentação. De todos os ganhadores acho que ele é o único que cairia no critério de “já é reconhecido o suficiente” mas mesmo assim posso dizer que eu aplaudi de pé :-) O Ryan é um cara que mostrou que com apenas um pequeno screencast toda semana, pode ser feito uma grande diferença na comunidade. Muita gente abriu as portas ao Rails graças ao seu trabalho e, nesse caso, tenho certeza que o prêmio foi muito merecido.

Agora, quem foi o terceiro ganhador da noite?

James Edward Gray II

Ele foi o responsável pelo famoso Ruby Quiz, escreveu os livros TextMate: Power Editing for the Mac, Best of Ruby Quiz. O Carl me contou sobre isso, e eu já havia ouvido falar não lembro onde, mas achamos que uma das razões porque ele escreveu, e gosta de TextMate, são as centenas de shortcuts que permitem que você seja produtivo nessa ferramenta.

E por que isso é importante para ele?

Bem, digamos que se você tivesse os problemas físicos dele, isso faria um mundo de diferença! James está numa cadeira de rodas há anos e nem por isso ele é o tipo de cara que vive deprimido e sentindo pena de si mesmo. E mesmo se o fizesse ninguém poderia culpá-lo. Em vez disso ele trabalha duro pela comunidade e nunca desistiu. Somente por isso acho que ele se encaixa numa categoria completamente diferente de heróis. Eu iria longe o suficiente para dedicar um Ruby Hero inteiro a ele. Mais um que merece aplausos em pé de todos nós, um grande exemplo de que “querer é poder.”

A principal mensagem desse award é: “Todos nós podemos ser Ruby Heroes.” O mais importante é não esperar sentado. Todos os grandes gênios, ou melhor, todos que hoje consideramos como grandes gênios, começaram exatamente como cada um de nós: da estaca zero, sem saber nada. Todos aprendemos aos poucos. Mas alguns andaram um pouco mais, fizeram um pouco mais, foram além. Todos nós deveríamos nos esforçar por esse “algo a mais”. Não importa o que seja. Talvez você seja um programador talentoso, por favor, escreva mais código. Talvez você seja um excelente comunicador, por favor, blogue, escreva tutoriais. Enfim, qualquer pequena contribuição nunca deve ser considerada ‘pequena demais’. Um único artigo pode fazer a diferença para muita gente.

Disclaimer: Mais um motivo de porque eu me irrito tanto quando vejo os reclamões gratuitos. Reclamar não é um problema, mas reclamar com o óbvio intuito de se parecer “superior” é de uma mesquinharia e de uma covardia que eu os categorizaria como sub-humanos. Pessoas que apenas querem pegar carona nos outros em vez de contribuir de verdade, movidos por pura inveja e todas as outras dezenas de qualidades que tornam uma pessoa um ser inferior. Tenham vergonha!

Parabéns ao Gregg e a todos os participantes do painel, acho que foi uma grande idéia. O Gregg também enviou e-mails acho que para vários outros que não foram os vencedores mas que receberam apoio de suas devidas comunidades. Como ele não menciona se posso ou não divulgar isso, acho que não tem nenhum problema. Muita gente votou em mim e o que posso dizer? Muito obrigado pelo suporte! Espero que eu continue ajudando e espero que todos vocês continuem a colaborar com toda a comunidade. A seguir, seguem algumas das mensagens que vocês enviaram ao Ruby Awards (sem os nomes, claro):

Because Akita is a great Rails evangelist in Brazil

He is the writer of the first Brazilian Rails book, he leads the translation to portuguese of the “Getting Real” book.

Great site about Ruby on Rails. Fabio really know what you say. He is Rail’s entusiast.

The first brazilian writer about Ruby and Rails

He translates books, records podcasts, write code, do interviews, have a great blog about Ruby

He is a hero in my country, Brazil

Site muito bom , bem atualizado

Akita is the brazilian ruby hero because he wrote the first brazilian book about RoR and he produce a lot of quality material about ruby and rails.

Fabio Akita is the most active rubist in the Brazilian community, making a lot of interesting articles, tutorials and screencasts, some of those in English too.

Fabio Akita has been a ruby an rails evangelist for years, writing on his blog and giving lectures and presentations.

The best railer brazilian.

Excellent author! Excellent content! Excellent tips!

Because the Akita is one of the pioneers of the language in Brazil, wrote the first book on the subject in our land and is always helping and encouraging community.

Fabio Akita is a great, the most active Ruby Evangelist in Brazil. His blog helps a lot the Ruby community, written in portuguese and english.

He has written the only RoR book in portuguese.

He write almost daily on his blog.

He it the co-author of the only RoR postcast in portuguese. http://rubyonrails.pro.br/podcasts

He is extremely active on the Brazilian community talking and spreading RoR to everyone.

Creator and maintener of the plugin “Acts As Replica” – http://github.com/akitaonrails/acts_as_replica/tree/master

He declares himself arrogant but he’s the pioneer brazilian ruby hero…

It’s the biggest brazilian Railer. His site helped me a lot too, and his comments in the brazilian rails list.

He write the only one rails book in portuguese. Share your discovery and studies with everyone everyday in your blog.

He made some great screencasts. And they were as free as a feather in the wind.

Great tutorials on Rails. Was a great place to go after Rails 2.0 was released to see what was new, and how to use it. The tutorials were well written, and very easy to follow. Even more impressive was that the tutorials were written in English, and Fabio does not speak English natively.

It’s Ruby Hero because he’s the main “railer” in Brazil. Write “Repensando a Web com Ruby on Rails” book; Member of RailsBrasil Podcast.

He’s a Rails pioneer in Brazil, wrote the first book about Rails in Brazilian Portuguese and is always trying to improve the Brazilian Rails community.

He’s the person who took the name to inside the country…

He is from a little group of people that are interested in creating a solid rails market in Brazil. His blog has a lot of rails tip, and great interviews with important persons of the global rails community, like DHH, Dr Nic, Geofrey, etc.

E não é só isso, hoje fui ver o Working with Rails e eu subi ainda mais de posição, indo para 11o!

“ ”

Acima de mim, e logo abaixo, vocês vêem que só tem pessoas geniais! Eu quase sinto que não deveria fazer parte desse grupo. Agradecimentos a todos que acreditam no meu trabalho e têm se beneficiado disso de alguma forma. Acho que me sinto um pouco como um “Ruby Hero” :-) Espero poder continuar correspondendo com as expectativas de todos (isso definitivamente coloca um grande peso nas minhas costas)!!

Desde então eles fizeram várias coisas:

• Lançaram a primeira versao do Phusion Passenger (a.k.a. mod_rails)
• Lançaram o quiz do Ruby Enterprise Edition
• Lançaram a campanha de doação para ganhar licenças Enterprise Edition.

O que vocês vão ler agora é o Inside Story de como muitas dessas coisas aconteceram :-)

Foi engraçado porque nossa comunidade brasileira foi a primeira a identificar que as licenças na realidade eram de mentira :-) Por alguma razão ninguém blogou sobre isso até agora e eu também segurei porque eles pediram (vocês não imaginam como é difícil para um blogueiro segurar uma informação como essas que vou contar!!). Se não me engano começou com o Julio Monteiro, que havia doado via duas empresas diferentes e, por isso recebeu duas vezes a licença, mas aí veio o interessante: duas licenças iguais a esta:

08abe6e5d8ae5e932e4a2808b484e41c

O script passenger-make-enterprisey mostra claramente que isso é nada mais nada menos do que o digest MD5 da string:

Saying “Rails doesn’t scale” is like saying “my car doesn’t go infinitely fast”.

Eles me contaram que estão tirando muito sarro de quem fala “Rails não escala”. É uma não-afirmação (non-statement). E ao mesmo tempo estão tirando sarro das pessoas “enterprisey” que, para considerar um produto a sério, precisam pagar por ele e receber uma “chave-secreta” que ninguém mais tem. Fala sério, ninguém suspeitou de um script “make enterprisey”?? Eu falei com o Ninh sobre isso e ele confirmou que ninguém mais tinha descoberto/publicado sobre isso.

A Phusion pegando dicas
com Jim Weinrich

Portanto, a versão 1.0.5 que estava no ar até então, obviamente, não continha o “Enterprise Edition”. Ela foi liberada primeiro para os que doaram e estavam presentes na platéia. Eles haviam prometido liberar a versão 2.0 poucas horas depois da apresentação, mas eles não só não tiveram muito tempo como também a internet no evento estava meio ‘lenta’, vamos dizer. Portanto, os que doaram antecipadamente receberam uma versão em DVD e devem ser os únicos que já puderam testar em produção. Conforme eles explicam no blog deles quem quiser já ainda não tem as gems oficiais mas já pode baixar do github deles.

Durante nossas conversas via IM surgiu a idéia de eu fazer uma aparição surpresa durante a apresentação (um cameo). Eles apresentariam o Passenger, daí abririam para uma sessão falsa de perguntas e respostas, eu levantaria a mão e eles me “escolheriam”. Nesse instante seria revelado o primeiro grande segredo:

Minha pergunta foi algo assim: “mod_rails é legal mas muitos criticam dizendo que o futuro do desenvolvimento web com Ruby requer Rack. O que vocês tem a dizer sobre isso?”

Todo mundo deu risada porque o slide seguinte foi assim:

E a resposta no slide seguinte foi: “Não, Passenger não vai suportar Rack … “, e no terceiro slide: “… porque ele já suporta!”

Poucas pessoas pessoas sabiam disso, incluindo eu e ninguém menos do que Ryan Bates que fez um screencast sobre o suporte a Rack, demonstrando neste vídeo:

Muita gente reclamou disso sobre o “mod_rails”. O próprio Ezra comentou neste post

As far as mod_rails goes… I think they made a huge mistake by not using rack as their interface, so I’d hope they will realize this and add rack support.

Parece que as preces deles foram atendidas. Esta outra discussão mostra como as pessoas assumem coisas sem saber como elas são feitas. O próprio Hongli Lai comentou que suportar Rack seria mais difícil do que Rails. Passenger não é apenas um conector burro de Apache para Rails, ele faz muito mais:

“Rails-specific framework pre-loading logic” is clearly explained in our architectural overview. It explains what it is, the motivation behind it, and how it works.
In a nutshell: it can decrease Rails spawn time by as much as 90%. On a busy web host where spawn time is normally 25 seconds, it can be brought down to 2.5 seconds. Preloading also makes memory sharing between processes possible.

Duas coisas importantes que o Passenger faz é trazer o tempo de startup uma ordem de grandeza para baixo. Isso é relevante porque num shared hosting você quer que processos que não estão sendo usados sejam derrubados para economizar memória, mas quando forem necessário você não quer que seu usuário espere mais de 20 segundos para carregar uma nova instância. O spawner deles consegue diminuir absurdamente esse tempo de loading porque ele sabe que muita coisa entre instâncias é exatamente igual e, portanto, pode ser colocado num cache. O documento de arquitetura deles explica isso em detalhes.

A segunda coisa é copy-on-write, que o Hongli já havia blogado a respeito em seu blog. Essencialmente um mongrel_cluster faz as coisas na força bruta: cada instância mongrel sobe uma cópia do framework Rails e da sua aplicação, duplicando tudo em memória. Ou seja, se você tem memória sobrando, tanto faz, mas normalmente nós queremos economizar o máximo possível.

O Passenger é esperto em relação a isso: ele sobre a primeira instância Ruby/Rails e as seguintes são forks da primeira. Se a primeira consome 50Mb de RAM da segunda em diantes se consome quase zero. Claro, à medida que a aplicação é exercitada, partes da aplicação precisará ser ‘copiada’ em outro espaço de memória isolado para que possa ser ‘sobrescrita’. Na prática, isso pode significar uma economia de pelo menos 1/3 da memória consumida total. Veja este slide sobre memória:

E não é só isso, devido às diversas otimizações que eles fizeram, isso também tornou usar Passenger mais rápido do que a concorrência. Vejam este slide sobre performance:

Ou seja, ele é mais rápido até mesmo do que Nginx + Thin, e mais do que isso: ele consome menos memória e roda mais rápido sobre Apache, que nunca foi um bom exemplo de baixo consumo de memória nem de performance. E ainda mais: diferente de um mongrel_cluster você não precisa limitar a quantidade de processso, não precisa se preocupar em subir uma instância caso ela dê crash por alguma razão, o Passenger faz tudo isso e com o plus de que cada nova instância que ele carrega, sobe com uma ordem de grandeza mais rápido do que a primeira, graças ao spawner.

A estratégia desses garotos foi muito boa: muita gente pediu para que eles lançassem uma versão alpha muito antes do tempo. Porém isso seria burrice , porque daí eles teriam que perder tempo com dúzias de bug reports com coisas que eles já sabiam que teriam que resolver. Daí, em vez de gastar o tempo corrigindo esses bugs, teriam que perder tempo gerenciando as pessoas.

Eles trabalharam com alguns parceiros com a Soocial, iLike, Dreamhost. Para quem usa sites sociais como Facebook já deve conhecer a iLike, que é uma aplicação Rails com mais de 20 milhões de usuários e que contabiliza centenas de milhões de page views mês e, agora, tudo rodando sobre Passenger.

Outra coisa que surgiu literalmente como uma brincadeira via IM acabou virando algo interessante na apresentação. Muitos brasileiros que me acompanham no Twitter viram quando eu lancei uma tirada que é: “A arma secreta do Python contra o Ruby: Leah Culver!” Muita gente entrou na brincadeira, o Fabio Kung não sabia sobre ela e tirou sarro no Twitter também. Foi engraçado :-)

Mas o Ninh Bui, da Phusion, também não sabia! E para os que ainda estão sem entender do que se trata, Leah Culver é praticamente uma lenda viva! Ela é uma jovem programadora de 25 anos e Líder do projeto Pownce de Kevin Rose. Sinceramente, eu nunca vi uma programadora linda como ela. Isso não existe, é praticamente uma Lei dos Programadores: “mulheres bonitas nunca serão programadoras.” Porém, ela programa em Python , e o Pownce é feito em Django.

Portanto, Ninh disse nos slides:

Sobre isso eu quero meus créditos! :-) hehehe. Na realidade eles já pretendiam colocar suporte a WSGI (que é o que o Django usa, por exemplo), mas por causa disso esse suporte ganhou nova prioridade e, em 2 dias, Passenger já suportava WSGI. Ele disse que mandou e-mail pra Leah, mas ainda não teve resposta. Boa sorte!

Claro, Passenger primariamente foi feito para suportar Rails. Diversas inteligências como o spawner, o copy-on-write, dependem exclusivamente do comportamento de dependencies do Rails. Portanto para obter os números dos slides anteriores, considere sempre Rails. Como o Hongli disse, apenas o Rack não é suficiente para ‘adivinhar’ esse tipo de detalhes.

Tanto Rack quanto WSGI ainda vão evoluir nas próximas versões, mas eles fizeram isso para demonstrar a flexibilidade da arquitetura do Passenger. Aliás, o código será finalmente aberto nos próximos dias e qualquer um poderá contribuir, pois será open source. O Hongli mesmo disse que a maior parte do source code é mais comentários e documentação do que propriamente código, portanto vocês não devem ter dificuldades em entender.

Uma das coisas que pode acontecer (ainda é uma possibilidade apenas!) é o Passenger passar a fazer parte do Mac OS X. No Leopard tanto Ruby, Rails e diversas gems já vem pré-instaladas. Mas com o Passenger, o Mac se tornaria o pacote mais simples para se desenvolver em Rails.

Eles voaram para Cupertino logo depois da RailsConf para uma reunião direto na mother-ship! Espero que boas novas apareçam em breve!

Finalmente vocês entenderam porque eu bloguei tão pouco durante a RailsConf: pela metade do evento meu notebook ficou na mão do Ninh. Isso porque ele havia lido que a alfândega americana poderia querer revistar notebooks e não devolver, então ele deixou o mac dele em casa e havia pedido se eu não emprestaria minha máquina a eles.

Eu disse que sim, mas com direito a uma entrevista exclusiva logo em seguida à apresentação. Ainda preciso compilar isso, mas eu gravei um audio podcast e o Carl gravou o vídeo dessa entrevista, que pretendemos liberar em breve.

Nesta foto vocês vêem o Gregg Pollack os entrevistando para este video :

Ninh Bui at Railsconf 2008 from Gregg Pollack on Vimeo.

Foi muito engraçado acompanhar esses garotos durante a RailsConf, eles são muito engraçados e espirituosos. O mais importante, são jovens estudantes de ciências da computação na Holanda, eles pegaram um problema que ninguém resolveu e em vez de blogar bobagens a respeito como “Ruby é uma droga porque o garbage collector deles não deixa suportar copy-on-write” ou “Apache é uma droga porque é pesado” ou “Rails é uma porcaria porque mod_ruby não funciona com ele”, etc eles pegaram todos esses problemas e codificaram uma excelente solução!

O próprio “Ruby Enterprise Edition” na realidade é um binário de Ruby customizado com os patches que modificam o GC e possibilita os ganhos de memória e performance. O instalador torna o processo transparente, copiando tudo num diretório isolado que, caso você não queira mais, pode simplesmente apagar ele fora. O Passenger pode ser configurado para usar seu Ruby padrão ou o “Ruby Enterprise”. Em breve talvez esses patches entrem no trunk do MRI mas isso ainda não aconteceu.

Tudo que eles fizeram segue o Ruby License, por isso mesmo o nome “Enterprise” é só uma brincadeira, tudo que eles fizeram sobre o Ruby precisa voltar à comunidade e é isso que vai acontecer.

Conversando com Michael Koziarski
depois da apresentação da Phusion.

No mesmo dia, no painel de fechamento, o Rails Core Team se juntou para responder perguntas da platéia. Estavam o David Hansson, o Michael Koziarski, Rick Olson e Jeremy Kemper. Durante a sessão aconteceu algo interessante: de repente o Vinicius Telles sumiu do nosso lado e eu escuto alguém falando no microfone que se parece muito com ele!!

Ele basicamente perguntou o que o Core Team achava sobre o Passenger, daí o próprio Koziarski disse que já estava usando em seus próprios sites e que estava muito contente com os ganhos de performance e redução no consumo de memória, dando um testemunho muito positivo. Não preciso dizer que o pessoal da Phusion ficou extremamente feliz por ter recebido elogios diretamente do Rails Core Team numa das apresentações com lotação quase total da platéia. Foi muito legal!

Finalmente, no final, ainda pude capturar um pequeno momento engraçado. Como eu disse antes, quem fez a doação estava presente, levou uma caixa (literalmente uma “caixa”) Enterprise, com camiseta e um DVD com a versão 2.0 do Passenger. E vejam quem estava levando uma caixa para Tim Bray:

Charles e Thomas levando Phusion Enterprise para Tim Bray :-)

Enfim, foi muito legal conhecer esse pessoal todo e acho que a apresentação do Passenger foi de longe a mais divertida da RailsConf. Talvez se não houvesse o MagLev também teria sido a mais importante, mas elas ficaram muito próximas. A diferença: Passenger funciona hoje, em produção!

Em resumo, Avi Bryant foi convidado pela GemStone para levar adiante a idéia que ele próprio previu na RailsConf do ano passado dizendo:

Eu sou do futuro, eu sei como esta história termina. Todas as pessoas dizendo que não se pode implementar uma máquina virtual rápida para Ruby estão erradas. Essa máquina já existe hoje, é chamada GemStone e ela certamente poderia ser adaptada para Ruby. Ela roda Smalltalk, e Ruby essencialmente é Smalltalk, então adaptá-la para rodar Ruby está absolutamente dentro do possível.

Não só está dentro do possível, como efetivamente ela é possível. A apresentação foi dividida entre primeiro Avi demonstrando MagLev rodando na prática e depois Bob Walker , da Gemstone, explicando como as coisas aconteceram.

Avi iniciou o equivalente a um console IRB do Maglev. De lá ele instanciou uma classe pure-Ruby ‘Hat’. Daí abriu um outro Maglev em outro terminal e demonstrou que o chapéu estava lá também, idêntico.

Daí, ele instanciou uma classe ‘Rabbit’ e colocou o coelho dentro do chapéu. Do outro terminal, demonstrou como o coelho ‘apareceu’ no outro chapéu. Ele fez várias pequenas demonstrações desse tipo, com elementos simples de Ruby aparecendo em ambos os ambientes (dois processos independentes com shared-memory transparente). Também demonstrou como esse ambiente suporta Transações ACID. Como em SQL, você pode dar BEGIN, COMMIT, ROLLBACK. Qualquer elemento ‘global’ (definição de classes, variáveis globais, etc) são compartilhadas transacionalmente entre os diferentes processos Maglev.

Em março deste ano, o próprio Avi já dava dicas sobre seu envolvimento com a Gemstone, neste artigo onde ele explica a tecnologia Gemstone para desenvolvedores Ruby on Rails.

Efetivamente, a tecnologia envolve não somente runtimes de Smalltalk que rodam em paralelo (gems), mas um conjunto integrado com uma engine de armazenamento de objetos no backend (stone). Imagine subir 2 mil gems (equivalente a subir vários mongrels) e imagine ter um enorme repositório em backend (equivalente a um massivo banco de dados) e um terceiro player que são memory caches entre os dois.

Agora, o interessante é realmente o repositório de objetos (Stone). Ele é capaz de armazenar 1 trilhão de objetos , ou até 17 Petabytes de dados. E esses não são números de laboratório. É importante lembrar que a Gemstone está no mercado há mais de 20 anos, e a tecnologia foi refinada no mundo Smalltalk por muito tempo. Centenas de grandes clientes, que precisam de “objetos vivos” e ativos usam essa tecnologia, principalmente em mercados como o mundo financeiro.

O conjunto da tecnologia permite levantar quantos processos Maglev quanto se julgar necessário (ou quanto seu parque de máquinas aguentar). Estamos falando de paralelismos da ordem de 2 mil processos rodando em paralelo!

Isso é que se chama escalabilidade. Só isso já seria surpresa o suficiente. Porém, Bob deixou todos perplexos quando demonstrou números de performance (aos pundits, performance não tem absolutamente nada a ver com escalabilidade).

Uma das poucas pessoas que já tinha ‘visto’ o Maglev rodando foi outro amigo meu, Antonio Cangiano e sua reação – colocada no slide – foi “Holy Shit!”

Eles deixaram bem claro que eram números de laboratório, um micro-benchmark, e como todos já deveriam saber, não se pode pegar esses número e clamar nada a respeito. Porém, os slides deixaram todos apavorados. Não estamos falando dos normais “2 ou 3x mais rápido que o MRI”. Estamos falando de 40, 60, até 100 vezes mais rápido que o MRI!

Num dos slides eles mostraram quanto um serviço do tamanho do Twitter consegue processar: cerca de 600 req/s, que é um número respeitável. Um case real de Gemstone supera isso por uma ordem de grandeza: 6 mil transações/seg.

O que o Bob Walker deixou claro desde o início foi que eles estavam trabalhando nisso fazia menos de 100 dias, ou 4 meses. Durante esse período eles conseguiram colocar muito da linguagem e até mesmo das Core Libraries, rodando no Gemstone, mas ainda falta muita coisa para ser 100% compatível. Inclusive ele agradeceu ao pessoal do Rubinius por ter iniciado o projeto RubySpecs, pois é exatamente o que eles vão usar para atingir o nível necessário de compatibilidade.

Tudo que foi demonstrado era uma prova de conceito , um test-bed para a própria Gemstone avaliar se seria realmente realista dizer que Ruby poderia rodar em Gemstone. E pelo que tudo indica, a prova foi um sucesso maior do que qualquer um poderia imaginar. Tudo porque o pessoal da Gemstone estava presente na RailsConf 2007 e viu Avi declamar que isso seria possível.

Charles Nutter parece que ficou bastante abalado com isso. No mesmo instante ele já enviou um Twitter dizendo algo como “eles não deveriam ter mostrado o slide de performance, isso é prematuro.”

Em seguida, rapidamente fez este post em seu blog, que foi bastante criticado. Eu estava sentado na platéia próximo a eles. Vejam esta foto:

Eu não sei se foi apenas eu, mas durante aquela sessão eu senti um “clima” muito sinistro no ar. Seria necessário estar ao vivo lá para entender. Bob Walker tem um tom calmo e aterrorizante em sua voz. A forma como ele descreveu os números, o potencial todo e até a forma como ele pediu aplausos ao pessoal do Rubinius, me deixou com a seguinte impressão por baixo das linhas:

“Obrigado pessoal (Jruby, Rubinius, etc), vocês foram ótimos, seu RubySpec é excelente e nós vamos usá-los. Sinto lhes dizer que é game over para todos vocês já que nosso produto é extremamente superior.”

Claro que isso é opinião minha e não foi isso que ele disse. Mas não pude deixar de notar. Do meu lado esquerdo estavam juntos, o Rails Core Team (dá para ver o rosto do David), o pessoal do JRuby (Charles, Thomas, Ola), na frente deles o pessoal do Rubinius (Evan, Wilson) e outros Railers (como Josh Susser). Eu os observei de perto por um bom tempo, tirei várias fotos deles nesse exato momento e a reação deles não foi do tipo “nossa, que projeto legal!”, eles faziam mais cara de “nossa, estamos acabados!” ou “caramba, o que vamos fazer agora?”

Comentei isso com várias pessoas, e o artigo negativo do Charles meio que confirma essa minha indagação. Ao conversar com outras pessoas, percebi que muitas estão no modo “politicamente correto”, sem criticar o Maglev mas também dando uma ‘ensaboada’ nas respostas. Só o Charles é quem foi mais explícito e, por isso mesmo, será o mais criticado.

O pessoal da Gemstone tem um grande problema nas mãos: “Afirmações extraordinárias exigem provas extraordinárias.” Neste momento, o que eles tem é efetivamente o que o Charles chamou de ‘presentation-ware’, ou seja, bom o suficiente para um demo, mas não para produção. Eles sequer usam o RubySpecs ainda. Porém, eles demonstraram uma aplicação – pequena – Rails rodando sobre Webrick dentro do Gemstone! Isso não é pouca coisa. Quanto tempo levou para o JRuby, Rubinius e IronRuby rodar Rails, mesmo que algumas poucas requests? 4 meses é um tempo recorde, independente de por qual lado você veja isso.

Por coincidência, a apresentação do Avi foi logo em seguida da do pessoal do Rubinius. Sinto dizer que eu não fiquei particularmente impressionando pelo que o Evan e o Wilson tinham a dizer. Eles finalmente mostraram um pouco de Rails rodando sobre Rubinius, mas estamos falando de algumas ordens de grandeza de lentidão ainda. A estratégia deles (e que foi a mesma do JRuby e do IronRuby) é de primeiro ficar o mais compatível possível com o MRI para depois buscar otimização. O caminho do Gemstone foi primeiro ser rápido e depois mostrar compatibilidade. Já explico porque nenhum dos dois está errado.

O pessoal do Rubinius está buscando reimplementar sua VM usando o projeto LLVM em vez de fazer tudo do zero. O LLVM, ou Low Level Virtual Machine, é uma infraestrutura de compilador escrita em C++. É um projeto ambicioso e que deveria levar Rubinius para o próximo degrau. Mas isso ainda está longe.

Eu conversei com o Avi pouco antes da apresentação bombástica. Ele pontuou uma coisa que o Evan disse na sua apresentação. O Rubinius é inspirado no Smalltalk, porém, eles ainda estão, evolutivamente falando, na década de 80. A implementação ainda é ‘ingênua’, assim como o Squeak. E ambas não têm nenhuma das novas tecnologias que estão presentes em máquinas mais avançadas como a Gemstone/S.

E foi exatamente isso que acredito que deixou os implementadores (Charles, Evan, Wilson, etc) mais apreensivos: a Gemstone/S está no mercado há décadas, uma VM otimizada exatamente para rodar linguagens extremamente dinâmicas como Smalltalk. Levou cerca de 2 anos para eles chegarem perto do MRI, e o Maglev já é ordens de grandeza superior. Eles levaram 4 meses apenas para fazer o Maglev, mas a infra-estrutura que a suporta tem 20 anos de idade.

Em seu blog Charles diz o seguinte: implementar Ruby não é tarefa fácil, torná-la compatível significa ter que adicionar um overhead absurdo. Por exemplo, ele diz que para rodar o micro-benchmark no JRuby, ele poderia ‘desligar’ dezenas de overheads que tornam o JRuby mais lento, atingindo 3 ou até 4 vezes mais performance ao custo de deixar o JRuby menos compatível.

Mas eis o ponto crucial nisso: a JVM nunca foi feita para rodar linguagens dinâmicas. A Sun investiu milhares de homens/hora para torná-la especialmente veloz em linguagens estáticas como Java. Classes abertas, meta-programação, lambdas, etc não estão no projeto original e só agora estão sendo atacadas (talvez a partir da JDK 7, que o Charles tem ajudado).

Só existem 2 virtual machines que podem ser consideradas ‘estado-da-arte’, a JVM com seu excelente HotSpot e máquinas robustas como a Gemstone/S. A diferença é que a Gemstone teve 20 anos para tornar sua máquina absolutamente rock-solid e absolutamente refinada para rodar Smalltalk. Mais do que isso, ela foi uma das poucas empresas que teve sucesso em OODB (banco de dados não relacional, de objetos). Mesmo com o overhead de ter um OODB transparente por trás, a Gemstone ainda é altamente veloz. Talvez um pouco mais lenta que a JVM rodando Java nativo.

Depois da apresentação, aconteceu um pequeno happy-hour no Double Tree Hotel, e lá eu tive a oportunidade de conhecer e conversar diretamente com os engenheiros da Gemstone. Antes de mais nada eles me confirmaram o que o Avi já havia dito:

Ruby == Smalltalk

Na prática, eles me disseram que implementaram 3 ou 4 novos bytecodes na virtual machine e é isso. Diferente do JRuby, eles não precisam de um layer para converter uma classe Ruby em uma classe Java. Uma classe Ruby é essencialmente idêntica a uma classe Smalltalk. Portanto não existe overhead de tradução, tecnicamente falando, os números de Smalltalk puro devem ser muito próximas de Ruby puro na mesma VM. Eis o calcanhar de aquiles do JRuby que a Gemstone não precisa ter.

O Monty Williams , da Gemstone, abriu seu Macbook Pro e rodou os micro-benchmarks na minha frente. Chega a ser embaraçoso como o Maglev é veloz comparado ao MRI, o impacto de ver os dois rodando ao mesmo tempo é algo que só pode ser apreciado ao vivo. Com o Antonio disse: “Holy Shit!”.

Mesmo assim, ninguém disse que está tudo perfeito. Agora eles vão retomar o projeto e decidir o que fazer. A Gemstone é uma empresa comercial e precisa, obviamente, ganhar dinheiro para sobreviver. O que eles disseram é o seguinte: a idéia não é tirar dinheiro de desenvolvedores como nós. Haverá uma versão free (as in beer) com uma certa limitação que certamente será suficiente para a maioria dos projetos pequenos/médios. Para quem precisa de tamanho “enterprise” daí sim será cobrado. Não vejo nenhum problema nisso. Produtos de qualidade podem e devem ter seu preço. O Charles também perguntou sobre isso no meio da apresentação e a resposta do Bob Walker foi “bom, segundo me consta o JRuby foi feito sobre uma certa VM fechada que só agora está começando a se tornar aberta, certo?”

Além disso, ainda existe muita coisa a se fazer para rodar Rails perfeitamente. Provavelmente o ActiveRecord precisará ser adaptado ou recodificado. Porque da forma como está, o AR é altamente dependente de SQL. Uma idéia inicial é converter chamadas SQL a chamadas diretas ao OODB deles. Coisas mais complexas como find_by_sql obviamente não daria para suportar. Ainda não se sabe como ter suporte a todos os bancos de dados do mercado (adapters Oracle, SQL Server, etc).

Esse foi um dos pontos mais discutidos durante a sessão de perguntas e respostas, mas o próprio Chad Fowler fez bem em fechar dizendo: “se é para usar o Gemstone, para quê você quer SQL?” ou seja, a Gemstone foi feita para OODB, porque retirar dele esse poder e voltar a usar SQL?

Seguindo essa mesma linha de raciocínio, eu não acredito que o Gemstone precisa ser necessariamente o único. Quem precisa integrar com legado em Java, por exemplo, continuará melhor servido usando JRuby. Quem precisa de 100% de compatibilidade não somente com a linguagem mas com extensões nativas, adapters, etc ainda será melhor servido com MRI. Mas para quem iniciar green-field projects (projetos do zero), poderá ter um boost incrível ao usar Maglev com todo o poder do OODB por trás. Escalabilidade + Performance passam a ser algo trivial.

O bottom-line é o seguinte:

• JRuby ainda precisa de um grande overhead para rodar Ruby. Ainda existem otimizações que podem ser feitas, mas sinceramente não acredito que eles atinjam perto da velocidade da Gemstone sem modificar a própria JVM.

• Rubinius ainda está muito no começo. Em vários sentidos eles estão para recomeçar do zero, usando a LLVM como base. Mas o projeto RubySpecs que saiu da primeira versão é extremamente importante.

• IronRuby cobre uma necessidade no mundo .NET e acredito que não consiga competir de igual para igual com os outros. John Lam gostou muito do Maglev e parece ter sido um dos únicos que não ficou necessariamente abalado, mas que acha bem vindo. Uma das razões é que ele também já foi muito criticado pelo Charles e a equipe do JRuby. Na sua apresentação ele demonstrou Rails rodando sobre IronRuby. Assim como no caso do Rubinius ainda é insipiente e mais uma prova de conceito, mas eles estão avançando bem, considerando o ambiente de trabalho onde estão.

• Maglev ainda é uma prova de conceito. A Gemstone ainda precisa delinear seu business plan. Ninguém teve acesso ao código-fonte e muita gente reclamou disso, mas acho que isso é irrelevante. Lembrem-se, foram míseros 4 meses , onde eles sequer sabiam se seriam capazes de rodar alguma coisa. Agora que foi apresentado ao mundo, eles devem começar a liberar mais informações. Nem ainda sabem quanto vai custar. Vamos aguardar.

Uma outra coisa que notei: o pessoal da Gemstone tinha muitos senhores, idosos, pessoal verdadeiramente sênior. Não no mal sentido: o principal engenheiro deles, acho que o nome era Alan, está na empresa desde o começo. O que isso me demonstra é o seguinte: eles são sabem do que estão falando. Não se trata de um grupo de jovens mavericks fazendo peripécias com código. Estamos falando de gente que não joga para perder, que já tropeçou muitas vezes e que são extremamente técnicos e responsáveis no que dizem. Não é uma startup que nasceu ontem, é uma empresa sólida e lucrativa há décadas.

Só esse fato, para mim, lhes dá o benefício da dúvida. É prematuro mostrar slides de performance? Talvez. Mas eu acho que é prematuro subestimá-los também. O que eles atingiram em tão pouco tempo é incrível. Acredito que nos próximos meses veremos muita coisa interessante vindo deles.

Parabéns, principalmente, ao Avi Bryant. Como eu já disse antes, ele é um role-model para todo bom programador. É um verdadeiro amante de programação. Claro que ele também tem opiniões fortes mas, diferente dos pundits , ele adora tanto Smalltalk quanto Ruby. E, novamente, ao invés de ficar dando indiretas aos ventos “mudei de Ruby para Smalltalk porque acho Ruby lento/incompleto/bla bla bla” Avi pegou o estado da arte do Smalltalk e faz Ruby rodar nele. Grandes artistas agem assim, pequenos insetos gostam de ganhar page views fazendo reclamações nulas ao vento, e programadores que nunca serão bons programadores gostam dessas afirmações nulas. É a vida.

Ps: antes que alguém se engane, não, eu não codifiquei nada do Passenger :-)

Uma pequena batalha ganha na guerra contra o SISTEMA! Como eu reportei no post da semana passada, consegui uma ‘brecha’ no SISTEMA graças ao toque do Vinicius. Fui até Niterói e dei entrada na renovação do meu passaporte que, pelas vias normais, não sairia antes do meio de Junho!

Ontem peguei o ônibus à meia-noite de volta para Niterói, no dia marcado para buscar o passaporte. Detalhe: eles disseram que dois dias antes enviariam um e-mail de confirmação. Claro, esse e-mail nunca chegou. Parece que o SISTEMA está engasgado.

Fui atendido às 7:00 em ponto e às 7:05 saí de lá com meu passaporte! Como eu expliquei antes, nesse horário a conexão de 512kbps ainda não estava saturada no distrito :-)

Pelo menos a viagem foi proveitosa: pude trocar idéias com o Vinicius na Improve It (valeu pela hospitalidade, Vinicius!). Peguei o ônibus de volta para São Paulo ao meio-dia e cheguei por volta das 19:30. Mesmo viajando de leito, é muito cansativo. Na ida eu mal dormi 2 horas, e na volta dei umas cochiladas mal dadas.

Graças às grandes distâncias e ao trânsito de São Paulo, cheguei em casa só por volta das 21h. Um longo dia. Ainda bem que não é rotina. Mas o esforço valeu a pena: agora começa a segunda parte da corrida, arrumar passagens, estadia e tudo mais para a RailsConf!

• O preço da ‘modernidade’

• O preço da ‘modernidade’ - Parte 2

Como vocês devem se lembrar, anunciei alguns meses atrás que pretendia ir para a RailsConf. Meu ingresso já estava até comprado. Mas apareceu um problema: meu visto ainda é válido até 2010, só que o passaporte tinha expirado e eu tinha esquecido disso.

“Sem problemas”, pensei. É só ir na Polícia Federal que isso se resolve em questão de horas. Amigos meus fizeram exatamente isso no fim do ano passado e estão na Europa agora, sem problema algum.

Eu e o Vinicius, depois de termos “dado” nosso sangue pelo Rails! :-)

Ledo engano. E eis que minha saga começa. Aliás, cá estou eu, escrevendo este artigo diretamente do aeroporto do Galeão, no Rio de Janeiro!!

O preço da “modernidade” - Parte 3

No fim de março tentei ir a uma das agências da PF em São Paulo, daquelas que atendem em shopping center. Separei os documentos, paguei a GRU e fui, na inocência. Nem pude entrar. A resposta foi: “agora precisa agendar via internet.”

Ok, tentei agendar pela internet. No sistema (de novo, o temido SISTEMA) não havia nenhuma data disponível. Achei que fosse problema do SISTEMA, como sempre.

Então resolvi ir direto à sede da PF, na Lapa. Cheguei cedinho, peguei uma fila enorme e, depois de umas 3 horas, consegui falar com alguém cujas únicas respostas eram:

• “Se não agendou via internet, pode ir embora.”

• “Vôo de emergência é só se você puder provar que vai morrer amanhã.”

• “Nem adianta tentar, vai embora.”

Ele ainda disse que iam abrir novos dias de agendamento, e que esse era o único jeito. Pessoas com passagens já compradas foram mandadas embora.

Alguns dias depois consegui agendar quando abriram novas datas, coisa que aparentemente acontece toda segunda no fim do dia. Só que os dias disponíveis só começavam em Junho!!

Como a RailsConf é no fim de Maio, não dava. Tentei amigos, contatos, tudo. Nada andou. Eu já estava desistindo da viagem.

Sétima Cavalaria: Dengue!

Passado o mês de Abril inteiro, eu já estava totalmente desencanado. O ingresso da RailsConf já estava cancelado. Eis que na segunda-feira (dia 5) o Vinicius me manda um e-mail com este link que dizia basicamente o seguinte:

A Polícia Federal (PF) de Niterói entrou na campanha de combate à dengue. De 5 a 16 de maio, a corporação estará disponibilizando 100 vagas para a confecção de passaportes, independentemente de agendamento. Aliás, o tempo de espera na fila para ser atendido já chega a dois meses. Para participar, basta ao interessado comparecer ao Hospital Universitário Antônio Pedro, no Centro, doar sangue e pegar a “Declaração de Doador”.

Todo mundo estressado na PF de Niterói,
assim como em todas as PFs do país.

O Vinicius me contou por e-mail que foi na segunda-feira e conseguiu.

Então peguei um ônibus à meia-noite de hoje (dia 7), desembarquei às 7:30 e fui ao Hemocentro do Hospital Universitário. Às 9:00 fui à PF e, depois de mais uma hora de espera, consegui agendar o atendimento para as 15 horas do mesmo dia.

O que descobri nesse período?

• O gargalo em todas as Polícias Federais do país veio da implantação de um “novo” SISTEMA para emitir o novo passaporte digital. E, como era de se esperar, a licitação do governo só consegue trazer LIXO para dentro: o sistema de passaporte é a própria definição de desperdício de dinheiro público.

• Para piorar, a agência da PF de Niterói tem um único link de 512kbps para 60 computadores!! Localizar um passaporte no lote demora cerca de meia hora. O cara estava quase chorando de ter que usar esse sistema. Não é à toa que os policiais atendem todo mundo estressados: é desumano fazer alguém trabalhar num sistema lixo desses, ainda por cima com uma conexão pior que linha discada!!

Eu, conhecendo Niterói. Valeu Vinicius!

O que eu aprendi com isso?

Que para conseguir um passaporte no Brasil agora é preciso, literalmente, dar o sangue!! É a situação mais surreal que eu já vi. Se alguém me contasse, eu não acreditaria. Ainda bem que tirei fotos para provar que não estou louco!

Pelo menos, depois do agendamento na PF, o Vinicius me apresentou várias partes bonitas de Niterói, que, aliás, é uma cidade excelente. Espero voltar com mais tempo para visitar com calma.

Meu vôo sai daqui a pouco, às 19:20, de volta a São Paulo. Dia 15, quinta-feira que vem, preciso peregrinar de novo para cá para buscar o passaporte novo. E preciso chegar antes das 7 da manhã senão, segundo os policiais, posso acabar esperando até 5 horas!! Espero que nada mais dê errado.

Agora é correr atrás para ver se ainda consigo azeitar as coisas e ir à RailsConf. Vai ser uma correria: o evento começa daqui a 3 semanas apenas, no dia 29!!

Ufa!

PS: enquanto eu doava sangue, ainda fui entrevistado por uma repórter da rede Record do Rio. Parece que é para o tal programa do Wagner Montes. Se alguém conseguir assistir, depois me conta como foi :-)

Até entrevista pra TV eu dei hoje!