2008 December

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 al...

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 já saiu 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 ...

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...

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 ...

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 Phusion. 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 ...

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 aprendend...

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....