%w(Akita On Rails) * 2.0Sua referência de Ruby on Rails

Existe uma escória na Internet e ela se chama Internet Explorer 6. Ela foi lançada em Agosto de 2001 e representa o aborto gerado pelo fim da Guerra dos Browsers, quando a Microsoft destruiu sem misericórdia a Netscape. A geração do IE 6 representa a Idade Média dos browsers.

Felizmente hoje estamos no início da Renascença dos browsers, com Firefox dominando entre os alternativos, mas com um ecossistema saudável de opções como Safari, Opera, Google Chrome.

Mesmo assim, o fantasma do IE 6 continua a nos assombrar. E o pior: ela se tornou tabu em muitas discussões. Todos sabemos que ela é tão nociva quanto a peste, mas também todos “sabemos” que devemos pagar nosso dízimo a ela, sem mais questões.

I’ve been thinking this through for a while about what are the best tools to develop Ruby and Rails project outside of the Mac. Specially on Windows. Netbeans and Eclipse Aptana are good choices and they are evolving fast, but I always thought of Java based IDE to be heavier than necessary.

I always say that you only need a good text editor and the terminal. But on Windows there is not that many competent editors such as Textmate. Even on the Mac, there are those who don’t want to pay for Textmate.

Railers have recently started to talk about Emacs, including Geoffrey who just released a great Peepcode screencast about it. Personally, I don’t feel like getting used to Emacs. It is just a personal taste thing, but I always preferred Vim.

Faz tempo que venho quebrando a cabeça sobre qual a melhor maneira de se programar com Ruby e Rails fora do ambiente Mac. Principalmente no Windows. O Netbeans e o Eclipse Aptana são boas opções e estão evoluindo rápido, mas eu sempre vou achá-los muito mais pesados do que necessário.

Sempre digo que basta um bom editor de textos e o terminal/linha de comando. Porém, no Windows não há tantos editores competentes como o Textmate. E mesmo no Mac, há quem não queira pagar pelo Textmate também.

Recentemente alguns Railers começaram a se voltar ao Emacs, incluindo Geoffrey, que fez um screencast sobre isso para o Peepcode. Sinceramente, eu ainda não consigo gostar muito do Emacs. É absolutamente questão de gosto pessoal, mas eu sempre preferi o Vim.

Pelo visto, a tradição manda que o último artigo do ano seja uma retrospectiva :-) Portanto, vamos às honras. Este foi um longo ano, definitivamente um dos melhores – e mais atarefados – que eu já passei. No meu blog, apesar disso, foram exatos 247 posts somente no meu blog. Foram 16 palestras (incluindo públicas e particulares) durante o ano todo.

Vamos aos meus posts favoritos do ano, foram vários.

Você tem uma conta Linux em alguma hospedagem compartilhada. Porém, por mais que nos esforcemos, é difícil manter tudo sempre atualizado, ainda mais no mundo Rails onde saem gems novas o tempo todo (por exemplo, o Merb 1.0.7 saiu dia 28 de dezembro e somente 3 dias depois o Yehuda já lançou o 1.0.7.1).

Mesmo assim muita gente quer usar a versão mais recente!

Outro problema: você fez sua aplicação Rails e não configurou corretamente as “config.gem” ou mesmo a variável RAILS_GEM_VERSION. Por alguma razão tem muita gente que comenta essa linha, o que está errado! Isso porque dessa forma sua aplicação sempre vai carregar o Rails mais novo instalado na máquina, se o servidor for atualizado, digamos de Rails 2.2 para Rails 2.3, sua aplicação tem a possibilidade de quebrar! Por alguma razão as pessoas acham que o correto é sempre carregar a versão mais recente. De novo: está errado. Claro subir da versão 1.0.0 para 1.0.1 não deveria ser um problema, mas carregar – sem saber – da versão 1.0 para 2.0, certamente alguma coisa vai quebrar e você só vai saber disso quando alguém entrar na sua aplicação e ela estourar um erro!

Mas existem várias soluções para isso. No Rails, você pode vendorizar todas as Gems dentro do diretório vendor/gems usando as tarefas de Rake que já vem com o Rails desde a versão 2.1 (melhoradas na 2.2).

Mais ainda, você pode ter seu próprio repositório de Gems (incluindo o comando “Gem” em si) totalmente local no seu diretório home da hospedagem. Por isso eu criei este artigo de Wiki ensinando como fazer isso em qualquer hospedagem Linux que possua acesso via SSH, tenha pelo menos um Ruby pré-instalado e acessível e compiladores (GCC) também acessíveis. Inclusive como instalar o Merb mais novo com todas as suas dependências.

Lembrem-se: as versões das suas Gems são importantes!! Se você controla tudo na sua máquina local e vai colocar num servidor dedicado, onde somente você usa, daí você pode instalar somente as versões que quiser. Mas se for colocar num servidor compartilhado, não há garantias, e é obrigação do desenvolvedor controlar isso.

Recentemente esbarrei no blog post do Paul Gross falando de Mephisto com Phusion Passenger, mais especificamente em como as versões mais recentes do Mephisto passam a gravar cache num diretório chamado “/public/cache/unusednow.com” em vez de gravar diretamente na raíz pública “/public”. Essa mudança aconteceu depois da 0.7.×. Acabei de atualizar meu blog a partir do repositório Git do Mephisto, que deve ser versão 0.8.x unstable.

Opa! Eu não tinha percebido isso. Eu atualizei meu Mephisto faz algum tempo e lembro que antigamente o cache ficava no /public. Isso significa uma coisa: que meu site está inteiro sendo servido dinamicamente o tempo todo! Péssimo para os recursos do servidor.

Existem duas maneiras de se corrigir isso. A primeira é exatamente como o Paul comenta no seu blog (leiam no link acima). Porém isso só é válido se você tem acesso a editar o arquivo de configuração do Apache. Num servidor compartilhado isso Não deve acontecer (e se acontece não é uma boa coisa para a estabilidade do servidor). Além disso, por alguma razão, não consegui fazer funcionar via .htaccess também. O Passenger, desabilita o mod_rewrite porque toda aplicação Rails antiga pré-cria um arquivo .htaccess padrão que mapeia tudo para CGI, o que é obviamente péssimo. Existe como religar isso no Passenger mas também significa que as aplicações que tem esse .htaccess vão começar a subir com CGI, o que não é bom.

Então, em vez de mexer no rewrite. Resolvi entender porque diabos o Mephisto transferiu tudo para esse diretório "/public/cache’. Ao que parece ele tem uma funcionalidade bastante experimental (leia-se: bugada e incompleta) para multi-sites, por isso essa diferença. Como eu não pretendo ter múltiplos sites na mesma aplicação, basta desligar a opção abaixo no arquivo “config/initializer/custom.rb”:

Site.multi_sites_enabled = false # originalmente estava true

Feito isso, não esqueça de fazer “touch tmp/restart.txt” para forçar o reinício do Passenger e pronto! Em testes básicos usando o Firebug do Firefox, a chamada à minha homepage caiu de 5 seg. para 50ms (milissegundos!). Acho que é bem considerável.

E não se esqueça: sempre configure Page Caching nas suas páginas de maior acesso, principalmente na homepage. É razoávelmente simples, precisa entender como ele funciona, mas uma vez entendido e configurado, funciona perfeitamente e dará um aumento de ordens de grandeza em páginas altamente dinâmicas (minha homepage mesmo, tem dezenas de queries que não precisa executar o tempo todo).

Essas últimas semanas foram bastante atarefadas para mim. Mesmo quando estou em casa não estou parado. Estou com várias novas atribuições na Locaweb. O resultado disso é que minha taxa de blogging, podcasting e tudo mais andou caindo. Pelo que soube o Carlos Brando também andou mais carregado que o normal. Mas não se preocupem, em breve voltamos ao ritmo normal.

Mas para não acumular muita coisa, resolvi escrever um artigo com um resumo das últimas semanas, para acabar o ano sem pendências :-) Entao vamos lá.

Vocês devem ter acabado de ver o anúncio: Ruby on Rails e Merb vão se juntar num único projeto. Tanto Matt Aimonetti quanto Yehuda Katz passam a ser parte do Rails Core Team, e a Engine Yard deve colaborar também.

Sinceramente, era algo que eu não esperava tão cedo. Quer dizer, alguma coisa ia acontecer, mas não imaginei que fosse isso e nem que fosse tão cedo.

Quem está acompanhando deve ter visto a animosidade entre o Rails Core e a Engine Yard. Isso vem de longa data, desde quanto o Ezra começou o projeto Merb com o discurso de que “Rails não era bom o suficiente e por isso ele resolveu fazer um framework próprio”. Desde então a Engine Yard cresceu sendo um hosting especializado em Ruby on Rails, ou seja, o negócio lucrativo deles passou a ser Rails mas o discurso com o Merb não mudou.

Recentemente tivemos várias demonstrações hostis com a discussão das linhas de código que moveu Jeremy Kemper (bitsweat), Yehuda Katz e o próprio DHH. No caso foi a discussão sobre se Merb tinha menos linhas de código que o Rails ou não. Depois foi a discussão sobre modularidade, de que Rails era um monolito.

Além disso, no começo do projeto Rubinius, logo quando o Passenger estava sendo anunciado, o Ezra também anunciou o projeto mod_rubinius, que foi oficialmente morto recentemente e retirado do Github. Ambos os projetos não foram para frente. O Phusion Passenger foi lançado e cumpriu a promessa de resolver o problema de deployment do Rails. Mesmo assim o discurso da EY sempre foi que Passenger não era bom para projetos grandes. O próprio Tom Mornini, CEO da EY, retrucou às provocações do Pratik Naik, depois o Ninh Bui da Phusion também respondeu.

Vocês devem ter notado que depois do lançamento do Merb 1.0, o DHH voltou fortemente à ativa, evangelizando com nunca. Escreveu mais blog posts recentemente do que o ano passado inteiro, atualizou o site oficial do RubyOnRails.org, passou a apoiar publicamente o Passenger. Fora isso, o Rails 2.2 mal saiu e o Rails Core investiu mais tempo na integração com Rack e o Josh Peek lançou o Rails Metal como uma maneira de combater o Merb Bare. Fora alguns patches recentes para tentar melhorar o suporte a Rails Engines, também como forma de combater o Merb Slices.

Frente a tudo isso, conversei com o Matt e em seguida ele escreveu o Merb ♡ Rails numa tentativa de quebrar o gelo. Mas neste ponto as cartas já estavam na mesa. De lá para cá muita coisa aconteceu por baixo dos panos. Resumindo, ontem decidiram que a solução seria juntar os dois projetos. O Merb deve entrar em modo de manutenção e provavelmente a melhores features devem ser mescladas no código-fonte do Rails. Eu especularia que DataMapper poderia passar a ser uma alternativa ao ActiveRecord, o suporte a dependências poderia ser melhorado e o recurso de Slices poderia substituir o antigo Rails Engines.

Tecnicamente isso é uma boa notícia. As vantagens é que os melhores recursos do Merb estarão disponíveis no Rails 3.0 e ainda evitamos uma cisão de comunidades além de fecha a Guerra Fria e entrar num período de trégua. Por outro lado, sabendo um pouco mais do que andou acontecendo, vou segurar minhas fichas até ver como as equipes do Rails Core, do Merb Core e da Engine Yard vão se comportar de agora em diante.

Update:

• Anúncio no blog oficial do Rails
• Anúncio no site oficial do Rails
• Anúncio no blog do Yehuda
• Anúncio no Merbist.com
• Anúncio no blog do Ezra
• Anúncio no blog da Engine Yard
• Anúncio no blog do Carl Lerche
• FAQ no Merbist.com

*Primeiros Desenvolvimentos"

• Bringing Merb’s provides/display into Rails 3
• This Week in Edge Rails

Vou me repetir sobre o que eu já disse em outro artigo, porque muita gente ainda não entendeu: Ruby on Rails não é a salvação que muitos pensam. Isso é bem óbvio, mas o próprio DHH resolveu dizer isso. Assistam a apresentação que ele deu na RailsConf Europe, em Berlim, este ano:

David Heinemeier Hansson’s keynote at RailsConf Europe 2008.

Essa apresentação se chama Legacy Software. Muita gente entra de cabeça em Ruby on Rails acreditando que ele é o Salvador da Pátria. Basta usar Rails que as aplicações serão magicamente perfeitas. Nada feito em Rails se torna “legado”. Legado é Java, PHP, etc.

Conheci Steve McConnell há muitos anos, primeiro com os livros After the Gold Rush e Software Project Survival Guide. Muitos o conhecem mais pelo Code Complete. Ano passado ele escreveu um excelente artigo sobre o assunto Dívida Técnica. Discutindo esse assunto recentemente, resolvi retornar a esse texto e traduzí-lo. Novamente, depois de anos de experiência eu ainda me surpreendo que este é mais um conceito que pouca gente discute e incorre no mesmo erro o tempo todo.

Antes de mais nada, o conceito de “Dívida Técnica”, é uma metáfora para indicar que toda vez que você toma um atalho técnico (o bom e velho “não importa que saia sujo, o importante é lançar o produto rápido!”). Isso não sai de graça. Toda vez que fazemos isso, é como fazer um empréstimo num banco, ou seja, é como assumir uma dívida. E como toda dívida, essa também corre juros e um dia será devidamente cobrada!

Extremistas costumam dizer “paguem tudo à vista, pois cartões de crédito são do mal.” Isso também não é verdade. Empréstimos podem ser bons e importantes. Que comerciante nunca teve um aperto de fluxo de caixa, onde um pequeno empréstimo não lhe deu um fôlego? O problema, como sempre, é o exagero, como o comprador compulsivo que inclusive paga um cartão de crédito com outro cartão de crédito! Muitas empresas agem exatamente assim com software: assumem centenas de dívidas e depois de alguns anos se assustam com o montante acumulado de dívidas a pagar.

E você: assumiu dívidas técnicas recentemente? Está preparado para começar a quitá-las? Segue a tradução do artigo original do Steve:

Depois de vários anos percebo que um grande número de programadores simplesmente não entende o Método Científico. Atualmente discutimos bastante sobre agilidade, sobre como fazer testes, TDD é importante. Em “testes” existe algo que deveria ser óbvio mas parece que não é. Existe um passo que considero muito importante que é a experimentação.

Da mesma forma como muitos usam “falta de tempo” como desculpa para não fazer testes, a mesma desculpa é usada para não testar hipóteses via experimentação (a maioria sequer entende que deveria estar experimentando hipóteses). O que estou falando aqui é sobre criar provas de conceito, “pedaços” do que você quer desenvolver que potencialmente será jogado fora. O “jogar fora” é a parte que deixa os programadores (e os gerentes) arrepiados. “Mas isso é perda de tempo, trabalho jogado fora! Inaceitável!”. Esse pensamento faz as pessoas pensarem que toda linha de código escrito necessariamente precisa estar na aplicação.

Novamente, é o errôneo pensamento que precisamos acertar tudo da primeira vez, a cultura de que tentativa-e-erro é errado. Pois bem, estou aqui dizendo que errado é pensar que sempre vamos acertar da primeira vez. Na maioria dos casos vamos errar todas as primeiras vezes.

Quando estive em São Francisco, uma coisa que conversei com o Matt foi como é difícil conseguir bom material na língua nativa. Ele é francês então também entende isso. Quando uma tecnologia nova sai, alguém escreve um livro em inglês. Só depois que esse livro já fez algum sucesso é que alguma editora nacional resolve comprar os direitos para traduzir. Depois de um longo tempo de tradução e revisão, finalmente sai no mercado … já obsoleto pois a tecnologia anda muito mais rápido do que esse processo moroso.

Pensando nisso, o Matt resolveu criar o projeto Merb-Book. Ele buscou colaboradores e os primeiros convocados foram eu e o Makoto Kuwata, que é rubista do Japão. Outros países se seguiram e ele ainda está procurando mais gente.

Aproveitando: não percam o novo curso de Merb que o grande Satish Talim anunciou hoje para o RubyLearning.org

Update: Como eu disse que ia acontecer, saiu o primeiro contra-ataque contra a EY, direto do pessoal da . Isso foi motivado por um blog post recente do Tom Mornini, CEO da EY.

Faz algumas semanas que temos Rails 2.2. Como já dissemos inúmeras vezes antes, a melhor parte é a Internacionalização. Mas há mais a ser dito.

Uma coisa que nunca teve muita atenção foi a parte de thread-safe. Talvez tenha sido só coincidência, mas é fato que o Merb provavelmente incomodou o Rails Core Team um pouco alguns anos atrás quando ele colocou como meta ser thread-safe. Nunca fez muita diferença porque o Ruby MRI, também como já falamos inúmeras vezes, apenas usa green-threads. Ou seja, não fazia sentido investir muito tempo num recurso que daria pouco retorno.

A esperança do Ezra e da EngineYard era criar um framework thread-safe em Ruby e ao mesmo tempo uma nova implementação de Ruby que também fosse thread-safe. Daí o motivo de adquirir o projeto Rubinius. Foi nessa época em que o Ezra falava de mod_rubinius. Porém, infelizmente o Evan ainda não conseguiu evoluir muito e recentemente, devido à crise econômica, a EY foi obrigada a dissolver a equipe do Rubinius. O sonho do “turtles all the way” ficou para depois.

Por outro lado, um desenvolvimento que o Rails Core ignorou foi o JRuby. No começo esse projeto ainda era lento, mas o Charles, Tom, Ola, Nick, e muitos mais da comunidade Java/Ruby foram extremamente rápidos. Do 1.0 ao 1.1.5 foram poucos meses e a performance sempre aumentou muito. Com a diferença de poder contar com a JVM, que lhe dá um garbage collection geracional, suporte a threads nativa, Strings UTF-16 e muito mais de graça.

Nesse cenário, sim, um framework thread-safe faz bastante diferença! E o Merb seria o framework mais completo e thread-safe. Por isso fez sentido o Rails Core também correr atrás disso, motivado pelo Merb estar se aproximando de lançar sua versão 1.0.

Mais do que isso, o lançamento do Merb 1.0 fez o DHH entrar em modo de evangelização. Foi quando ele começou sua série de posts de Mitos Rails. Até então ele praticamente não blogava e nem twitava, agora ele twita todos os dias. A EY também sempre atacou o Passenger. Mais explicitamente, em suas palestras recentes o Ezra diz que o Passenger só é bom para pequenos projetos. E o CTO da EY, o Tom Mornini disse muito mais contra o Passenger. Por isso, a 37signals e o próprio DHH passaram a apoiar bem explicitamente o Phusion Passenger como a melhor maneira de deployment.

Isso porque a EY, até agora, sempre vendou serviços de Rails mas evangelizou que a única maneira de escalar muito seria com nginx + mongrel + merb. O DHH está disposto a vender que a melhor opção é apache + passenger + rails. O desenvolvimento do Rails 2.3 já está evoluindo bem rápido. Em pouco tempo eles adicionaram o plugin Rg que dá templates: uma resposta aos Merb Stacks. E também começou um movimento em torno de melhorar a plugin Engines: outra resposta ao Merb Slices. Outra coisa que o Rails 2.3 está perseguindo – e o Merb também – é lazy loading. Na hora que li isso imaginei que fosse quebrar pois o Ruby não sendo thread-safe por natureza, a metaprogramação também não é. Nesse caso o auto loading de classes on demand facilmente poderia quebrar em 2 threads o que foi confirmado nessa discussão. Isso ainda vai evoluir, mas não sei o quanto isso é realmente eficiente.

No mundo Unix isso não faz muita diferença. O Windows (e isso não é um fanboyismo, apenas um fato) que tem o ineficiente CreateProcess mas não tem o equivalente a Fork e muito menos a copy-on-write. Com essas capacidades básicas um processo Unix pode criar uma cópia de si (fork) mesmo consumindo quase nada de recursos se a memória alocada interna for sempre constante (copy-on-write): que é o que o Ruby Enterprise Edition faz para economizar RAM. Aliás, ambos REE e Passenger tiveram novas versões lançadas recentemente, ambas apoiadas pela 37signals.

O Merb tem um suporte nativo a controlar clusters de processos Mongrel, de forma parecida como o Passenger faz com Rails, mas com a diferença que ele não é um módulo de Apache e ainda precisa configurar proxy reverso de HTTP manualmente. Além disso o Merb ainda não tem suporte a filas e monitores de CPU e Ram como o Passenger já tem.

Neste exato momento o clima está quente. Muitas coisas estão acontecendo nos bastidores que infelizmente poucos vão ficar sabendo. Mas o Rails deve dar uma boa acelerada neste momento por causa disso e algumas notícias interessantes vão começar a aparecer muito em breve.

Como eu disse alguns dias atrás, o Ruby on Rails foi escolhido pelo voto popular (via revista Info Exame e pelo site deles) como a melhor plataforma de desenvolvimento do ano. As outras opções foram Adobe Air e Django. Foi uma disputa cabeça-a-cabeça porque o Rails ganhou do Air por apenas 1% :-) Foi 41% vs 40%!!

Ruby on Rails cresceu bastante em 2008, ao ponto em que finalmente muitas empresas já estão usando e outras estão pensando seriamente em usar. Muitos programadores já estão aprendendo e agora é hora de não perder tempo! Vejam a premiação da Locaweb e do Rails abaixo:

Prêmio Info 2008 – Locaweb from Fabio Akita on Vimeo.

Além disso, cruzei com o pessoal do Mozilla Brasil por lá também já que o Firefox ganhou pelo segundo ano seguido. Então aqui vai um vídeo com eles também :-)

Prêmio Info 2008 – Firefox from Fabio Akita on Vimeo.

Curiosidade: sabiam que no mundo o Firefox tem 20% de market share de browsers, mas no Brasil já alcançamos 30% !?

Parabéns ao Ruby on Rails, ao Firefox e às comunidades Open Source!

Conheci o Matt Aimonetti durante a QCon (veja no artigo dele). Ele faz parte da equipe principal do Merb e é o principal evangelizador. Conversamos muito, nos tornamos bons amigos e vamos colaborar em divulgar mais o Merb como uma boa alternativa de framework web em Ruby. Acompanhe o Matt (e este blog, claro), ele vai anunciar algumas novidades interessantes em breve.

Para explicar: o framework Merb foi criado por Ezra Zygmuntowicz. Depois o trabalho de mantenedor passou para Yehuda Katz, que já ajudava no projeto DataMapper também. Ezra e Yehuda são da Engine Yard, mas essa empresa não é dona nem dita o futuro do Merb. Trata-se de um projeto open source como qualquer outro e tem vida própria.

Recentemente iniciou-se uma animosidade implícita entre as equipes do Rails e do Merb. Quem acompanha de perto sabia que uma pequena Guerra Fria estava se armando (e foi um dos meus objetivos tentar apaziguar isso durante minhas entrevistas na QCon). Hoje o Matt blogou um cessar-fogo. Vou traduzir o post dele.

O Githubber Scott Chacon fez um grande artigo/site explicando porque Git é melhor do que X (Subversion, Perforce, Mercurial, Bazaar).

Como eu achei o artigo muito bem feito, resolvi traduzí-lo para português (pra variar :-). Então leiam e distribuam para seus amigos, colegas de trabalho e chefes:

http://akitaonrails.com/porquegitehmelhor/

Update: O Scott fez um post no blog do Github sobre a tradução. Ele puxou do meu repositório e colocou no seu site principal:

http://pt.whygitisbetterthanx.com/

Yesterday I wrote a detailed summary of everything I’ve done in the year of 2008 and I think it is important to translate it into English so everybody else outside of Brazil can see how we’ve been evolving.

This was a very busy year. I was always a quiet guy. On the other hand I always hated routine, I always hated do only the things everybody else were doing. I’ve changed perspectives several times. On the late 80’s I’ve toyed with DOS and standalone local systems. On the early 90’s it was client-server. Mid-90’s multimedia, CD-ROMs, publicity agencies. Late 90’s it was the first Internet wave. Early XXI century, enterprisey, SAP, Java. 3 years ago my Ruby on Rails journey began, first the portuguese book, then the blog, then throwing out the enterprise world for freelancing in Rails. This year, Locaweb, Rails Summit.

By 2006, right after I taught myself Rails, it was obvious that this was a worthwhile path. But, back then there was no market for Ruby in Brazil. Some people that started before me were already giving up. I had 2 options: try outside of Brazil or create a new market from scratch here. Obviously, I chose the less easy path. Fortunately more and more people joined and the community grew fast.

And before I go on, the good news! Next week, December, 3rd, Ruby on Rails will receive the “Info Award 2008” for software development, and I will be there on the behalf of David Hansson. For those of you who are not from Brazil, the “Info Exame” magazine is “the” single largest IT magazing in Brazil. So you can imagine that this is an important award and a big win for the entire Ruby community. This is a key milestone and I congratulate the efforts of the entire community for it.