Janeiro de 2010

O Manifesto Ágil é calcado em 4 valores. Não sei quantas eu já repeti isso. Mais do que isso ele é calcado em 12 princípios importantes. Muitos os consideram como os 10 mandamentos. Eu sempre sou contra qualquer coisa dogmatizada, por outro lado se você prefere dogmatizar o Manifesto, nunca pegue apenas uma frase dele em isolado. Se for levar um deles ao pé-da-letra, leve todos ao pé-da-letra, senão seria o mesmo que dogmatizar os 10 mandamentos e dizer “Eu obedeço os 10 mandamentos: eu já cometi adultério, mas não tem importância porque nunca matei ninguém, nunca roubei e não foi com a mulher do vizinho que cometi adultério.”

No dia 27 de Janeiro, a Apple finalmente anunciou o lançamento do seu iPad. Como muitos já descreveram, é basicamente um iPhone com tela 4 vezes maior :-) Não vou repetir o que todo website já descreveu sobre suas funcionalidades. Recomendo muito que se assista o vídeo do keynote para entender melhor do que se trata.

Porém, muitas críticas já apareceram. Gostaria de discutir algumas delas pelo meu ponto de vista :-) Mas não as considere como “certo” ou “errado”, mas como uma forma de raciocinar o possível “por que” de algumas das decisões. Pode parecer mais estranho considerando o artigo que acabei de escrever, mas a idéia não é justificar porque o iPad vai revolucionar o mercado ou coisa parecida, apenas elocubrar sobre algumas características do produto.

Adoro o vídeo Wear Sunscreen, acho que eu vi pela primeira vez em 2003 ou 2004 e ela ficou para mim como um “aviso”, algo a se lembrar de vez em quando. As partes que mais gosto são:

“Tenha cuidado com quais conselhos você aceita, mas seja paciente com quem lhes dá conselhos. Conselho é uma forma de nostalgia, distribuí-lo é uma forma de pescar o passado do lixo, limpá-lo, pintar sobre as partes feias e reciclá-lo por mais do que vale.”

Outra parte importante:

“Talvez você se case, talvez não, talvez você tenha filhos, talvez não, talvez você se divorcie aos 40, talvez você dance a dança da galinha no seu 75o aniversário de casamento. Não importa o que faça, não se parabenize demais ou se critique demais. Suas chances são de 50%, assim como as de todo mundo.”

Só de curiosidade resolvi dar uma olhada no stack de Rack Middlewares no Rails 3 (aliás, acabei de subir mais uma atualização na aplicação demo Third Rail).

Com o comando “rake middleware” você consegue avaliar o stack. No Rails 2.3.5 a ordem é esta:

use Rack::Lock
use ActionController::Failsafe
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActiveRecord::SessionStore
use ActionController::ParamsParser
use Rack::MethodOverride
use Rack::Head
use ActionController::StringCoercion
use Rack::Cache
run ActionController::Dispatcher.new

Esta notícia já é meio velha mas só hoje resolvi brincar com ela. No começo do ano o Remi publicou um artigo muito curioso sobre uma implementação de Sinatra para ASP!

Para quem não sabe, o Sinatra é um micro-framework para desenvolver aplicações Web em Ruby. Vamos dizer que é um irmão mais leve do Ruby on Rails. O insight do Remi foi lembrar que todo mundo usa ASP com VBScript, mas desde que foi criado mais de uma década atrás, ele também já suportava JScript, uma versão de Javascript da Microsoft. Mais do que isso: Javascript pode ser tão flexível, dinâmico e expressivo quanto Ruby.

Portanto ele pensou: “e se eu implementar um framework simples em JScript para rodar em ASP?” Daí ele implementou um subset do Sinatra, inteiro em JScript. E o mais incrível: ficou realmente interessante. O ASP ficou literalmente com uma cara de século XXI.

Obs: Este artigo tem a ver com a prova-de-conceito Cramp Chat Demo disponível no Github.

Existe um caso de uso de aplicações web que é o envio frequente de conteúdo adicional. Por exemplo uma conversa de chat, ou um livestream de feeds, ou até mesmo APIs públicas muito acessadas. O padrão de solução costuma ser um javascript que, em intervalos regulares, faz requisições Ajax a um servidor que retorna o conteúdo adicional a ser acrescentado na página. Isso é um polling.

Outro padrão é manter uma conexão HTTP aberta, recebendo conteúdo continuamente num stream. Para isso temos termos/técnicas guarda-chuva como Comet, Ajax Push, Reverse Ajax, HTTP server push, etc.

As técnicas no cliente variam bastante. Mas os backends não variam muito. Por exemplo, uma aplicação Rails é limitada ao número de conexões simultâneas (ativas exatamente ao mesmo tempo) pelo número de processos carregados. Se tivermos 10 processos Rails de pé, só podemos ter 10 conexões simultâneas. Essa característica é mais importante se o tempo de resposta por conexão for muito alto (e é por isso que sempre falamos em fazer o mínimo possível numa requisição e deferir processamentos mais pesados para tarefas em background, usando tecnologias simples como Delayed Job, Resque, ou se a coisa for mais complexa, servidores de fila e mensagens como RabbitMQ).

Lendo o livro Systems Thinking esbarrei numa história interessante que deu origem ao meu tweet de ontem:

Information < Knowledge < Understanding
Or
What? < How? < Why?

A história é a seguinte: Havia um projeto de controle de natalidade da Fundação Ford na Índia. Eles estavam frustrados tentando ensinar planejamento familiar e controle de natalidade, sem resultados.

“Indianos são irracionais.”

É o que eles achavam pois:

“Eles sabem que o inimigo número um é a população, e aqui estamos nós ensinando sobre controle, dando os contraceptivos e até mesmo um radio como recompensa. Mas veja o que acontece. Eles voltam pra casa, ligam o rádio, e com música fazem um novo bebê.”

Atualização: 06/01: O objetivo do artigo quando comecei a escrevê-lo foi ser realmente assertivo. Ainda me frustra o fato de pesquisar material atual, blogs, artigos, e nenhum assunto relacionado a Agilidade ir mais a fundo nos princípios. Além disso estou um pouco ansioso com minha própria pesquisa, que sempre ainda parece que faltam pedaços e como não há quase ninguém com quem conversar a respeito, fico mais frustrado ainda. Por isso logo no começo do artigo eu já estava de paciência curta e comecei a abusar da primeira e da terceira pessoa, praticamente num diálogo 1 a 1. Como isso não ajuda o objetivo central do artigo, resolvi limar as partes mais agressivas. Vamos ver se agora ficou mais “digerível” :-)

Ano passado compilei uma lista de livros que eu li na minha busca pela essência do verdadeiro gerenciamento. A diferença é que em vez de passar pelos mais triviais como Peter Druker, eu fui atrás dos princípios da Agilidade.

Existem algumas categorias de gerentes: os que são “ágeis” – no sentido mais amplo da palavra – e os “tradicionais”. O segundo grupo – que tem tendências a não querer mudar nem aprender nada – é triste, ponto final. O primeiro está no caminho certo, mas ainda falta muito. As discussões que eu vejo hoje nas comunidades ágeis, infelizmente, também ainda caem na inércia do “bom senso”, do “senso comum” e acabam sendo superficiais.

Um gerente ágil deveria querer se dedicar muito mais. O próprio Scrum é um exemplo disso. Como eu disse no meu artigo Você não entende nada de Scrum : o Jeff Sutherland e Ken Schwaber realmente pesquisaram há muito tempo os assuntos pertinentes e dão as dicas, embora poucos sigam.

Ainda existem alguns problemas entre o Rails 2.3, o Ruby 1.9 e seu suporte a UTF-8 e a forma como ambos o ERB (Embedded Ruby, a engine padrão para templates que usamos no ActionView) e o adapter de MySQL tratam encoding.

Notei isso quando testei meu próprio blog rodando sobre Ruby 1.9 e ele dá o seguinte erro quando tento carregar a aplicação em algum navegador:

incompatible character encodings: UTF-8 and ASCII-8BIT

O erro aponta justamente para uma linha onde eu puxo dados de um activerecord. Há duas chances para isso: ou o ERB está tratando o encoding errado ou o ActiveRecord está recebendo o dado com encoding errado. No meu caso acho que é o segundo caso.

Se você está há algum tempo acompanhando projetos no Github, as chances são que você tem alguns projetos pessoais e algumas centenas de projetos em observação (quando você clica no botão “watch”) na página de cada projeto no Github. Eu, por exemplo, tenho quase 400 projetos em observação. Claro, muitos deles eu nem mexo. Para variar, todos os projetos estão literalmente jogados num único diretório de projetos. Literalmente, uma bagunça. Hora de arrumar minha casa.

Se você ainda não lê a Wired, deveria. Eu leio esporadicamente mas sempre aparecem artigos muito bons. O do mês passado trás uma série sobre fracasso e sua importância para o sucesso. Num dos artigos (leia a íntegra aqui), fala sobre um dos experimentos de Dunbar (quem nunca ouviu falar dos números de Dunbar ?).

Agora, o que Dunbar tem a ver com conceitos de Emergência, Cross Functional Teams, e outros que comumente discutimos em Agilidade? Ele resolveu estudar como cientistas funcionam (!) No meio do artigo vi este trecho que me chamou a atenção:

Aviso: toda vez que começar uma nova aplicação, garanta que seu banco de dados e sua aplicação estão configurados corretamente para suportar UTF-8! Depois a coisa fica feia. No meu caso, meu blog existe desde 2006, na época eu não prestei atenção nisso e ele ficou por padrão como Latin1 até hoje. Mas hoje aproveitei a limpeza de casa e resolvi consertar isso.

A primeira coisa que fiz foi criar um novo banco de dados mysql vazio. Este é um assunto que tem centenas de posts sobre como proceder, o que eu acabei fazendo foi:

Depois de meses configurando e reconfigurando gems, .bash_profile, etc o ambiente tende a ficar bagunçado. Aproveitando o feriado, resolvi fazer uma limpeza. No meu caso, estou falando do Snow Leopard. Algumas das coisas devem funcionar em distros Linux, mas não é o foco.

O que pretendo fazer é começar a usar o RVM para gerenciar diferentes instalações de Ruby no meu sistema.

Para fechar o ano de 2009 aqui vão duas listas: a primeira é a lista por quantidade de acessos segundo meu Google Analytics, e em seguida a lista dos artigos que eu pessoalmente gostei mais de escrever. Além disso não deixem de ver as coletâneas da RailsConf’09 e do Rails Summit’09.