Um livro cujo título junta Economics (economia) e Scrooge (personagem avarento do conto de Dickens, que também foi homenageado por Carl Barks ao nomear o Tio Patinhas – Uncle Scrooge no original), pode parecer mal-intencionado. Mas não é: o objetivo de Scroogenomics é mostrar que a compra desenfreada de presentes no natal não é exatamente a oitava maravilha para a economia nacional ou global – ao contrário do que o senso comum (compras ⇒ aquecimento econômico) possa sugerir.

†Na minha cabeça, Califórnia é aquele lance descrito pelo Joel Spolsky: todo mundo plugado, surfe, e o verão do amor. A realidade, contudo, é outra: o WiFi nas ruas é escasso (e é difícil conseguir um chip pré-pago com dados), a chuva lembra a garoa paulistana, e me imaginar num calção de banho iniciava uma crise psicológica de hipotermia. Mas os amigos† que nos acolheram tambem ofereceram Wi-Fi, dicas e companhia, viabilizando um passeio por San Francisco (e arredores) em apenas quatro dias – com direito a uma aula do Knuth em pessoa!

Seria um exagero dizer que todo mundo curte um bom livro sobre matemática. Mas não dá para ignorar a popularidade dos que tentam jogar fora a interpretação natural dos números em favor de uma nova ordem que possa emergir do caos aparente. Exemplos incluem o Freakonomics, com a sua investigação baseada em números; o Outliers, que olha para as pessoas e coisas que se destacam; o Free; o The Long Tail e toda uma série de livros cujo tema é a “matemática fora da caixa”.

Nas Redes do Sexo foi mais um daqueles livros “fora da caixa” inseridos entre uma e outra leitura mais próxima do meu cotidiano – uma tática de expansão de horizontes que raramente me decepciona.

O Encontro Ágil 2010 (que merecia seu próprio post) se destacou pelo face-to-face: os open spaces e interações entre participantes foram tão produtivos que a tradicional carência de conectividade sem fio da USP trabalhou a favor. E foi justamente uma dessas interações, o Coding Dojo (saiba o que é um) organizado pelo Bruno Gola (com o forte apoio do Asa) que me inspirou a organizar uma sessão equivalente no Apontador. Segue uma visão geral da experiência:

Preparação

Devido à heterogeneidade do público potencial (e também para levar o ambiente já preparado), era razoável escolher a linguagem com antecedência. Usamos Python por tres motivos: é fácil de aprender na hora para quem nunca viu, o código fica compacto e legível, e a expoisção a uma linguagem nova é um bônus extra (de fato, um dos pontos positivos mais enfatizados na retrospectiva).

A estação de trabalho era o meu Mac do trabalho mesmo, então usei o TextWrangler, um editor básico com sintaxe colorida e que permite alternar facilmente entre o programa e o teste. Deixamos o editor ocupando 2/3 da tela, e o restante dividido entre o console (posicionado estrategicamente para garantir a visibilidade do OK ou FAILED do teste) e o cronômetro – ter as duas coisas na tela dá mais segurança e tranquilidade à dupla.

Eu queria um cronômetro offline – apesar da internet do Apontador ser boa, é sempre bom reduzir riscos. Adorei o Coding Dojo Screenlet, escrito pelo próprio Gola, cuja cor de fundo (vermelho/verde) reflete o status do teste, ajudando a audiência saber quando (não) é apropriado se manifestar, mas ele só existe para Linux. A solução foi o timer do Hora Agora (criado pela Bani), que, aliado à interface minimalista do Chrome, resolveu super bem: o alarme ininterrupto garantia que o piloto, ao sentar no teclado, não esquecesse de reiniciar o timer (usando o parâmetro “?t=05:00″, era só dar reload na página).

Num dojo (e em TDD no geral) é uma boa idéia que, quando viável, o teste seja executado automaticamente sempre que você salva o arquivo. Conseguimos isso graças ao uso de nose + tdaemon (que ainda dá o resultado em popups do Growl), mas tem outras alternativas por aí como o autotest e o watchr. Outra idéia é rodar todo o ambiente do Dojo online, usando o CyberDojo. Opções não faltam: escolha conforme a linguagem, ambiente e gosto – o importante é deixar tudo preparado antes de começar!

No Dia

Após uma rápida introdução ao conceito de dojo e às “regras do jogo” (a Karen recomenda esses dois resumos), compilamos no quadro uma lista ordenada dos participantes – o que evita confusão na hora de trocar a dupla. A lista foi pela ordem em que as pessoas se voluntariaram, mas acho válida também a sugestão do Gola de alternar entre pessoas mais e menos familiarizadas com a tecnologia.

Dojo era novidade para quase todos os presentes, então pareceu razoável começar com um problema introdutório (RandoriKata), e fizemos o RomanNumbers (não por acaso, o mesmo que foi feito no Encontro Ágil). Foi interessante ver como a dinâmica e a técnica de solução de um mesmo problema variam em dojos diferentes.

Conclusão

A retrospectiva foi parte importante da experiência – ajudou a medir o que aprendemos juntos, onde acertamos e onde poderíamos melhorar. E me chamou a atenção ver que, mesmo não sendo o objetivo principal do dojo resolver o problema em si, o pessoal não quis ir pra casa sem ver todos os testes funcionarem. Não tenho dúvidas sobre o impacto positivo que isso terá no dia-a-dia de cada um.

Organizar um dojo não é coisa de outro mundo (gastei mais tempo escrevendo esse post do que preparando) – só é preciso realmente ter um espaço com projetor, comida e interessados. Recomendo reservar entre 1h30 e 2h para a brincadeira, e levar o ambiente pronto, deixando o encontro focado em programar e interagir.

Abrace a simplicidade e ajude as pessoas a seguirem as regras, mas sem pressão. Não perca de vista o aspecto lúdico e não-competitivo do evento, e o resto sai por conta. O pessoal se animou a compartilhar o código e marcar os próximos logo de cara. E o Apontador está considerando promover **dojos abertos para visitantes – interessados, manifestem-se! **

Já tem um tempo que eu queria voltar a ter uma ilustração para dar uma carinha mais simpática ao blog. Eu usava uma caricatura do Serginho (que ilustrava alguns artigos que escrevi para o Último Segundo) que é fantástica, mas retrata um Chester de dez anos, onze quilos e incontáveis cabelos atrás.

A Ila Fox publica todo dia uma ilustração nova no blog dela, e eu sempre curti o estilo. Resolvi então encomendar com ela o mini-Chester que vocês vêem aí embaixo. Curti tanto o resultado que estou usando um corte como avatar no Twitter e em outras redes.

Curtiu? Vai lá na lojinha da Ila e encomende a sua também. Ela é muito atenciosa, eficiente e, acima de tudo, profissional – nem ligou de desenhar o Apple II, mesmo sendo MSXzeira de raiz :-) (essa antítese é meio que o Corinthians x Palmeiras da era 8 bits…)

A maratona de eventos do mês foi concluída com a edição deste ano do Google Developer Day em São Paulo. É um evento bastante concorrido (afinal, é gratuito, bom e ligado ao Google), o que deve tornar a escolha dos participantes um desafio interessante – mesmo para aqueles cuja missão já é meio que organizar/classificar o universo…

Esse ano o processo de inscrição incluiu uma provinha que gerou bastante “mimimi” nas listas e redes sociais: uns questionaram a eficácia de um teste tão básico (e para esses recomendo ler sobre FizzBuzz e programadores que não programam), outros se sentiram injustiçados com a eventual não-convocação. O fato e que ela ajudou: qualquer pessoa que você encontrasse lá esse ano era, em maior ou menor grau, apaixonada por código. Não era bem assim em anos anteriores, e isso fez diferença no café/happy hour. Sabem como é: developers, developers, developers!

A organização também melhorou em todos os aspectos: da alimentação (que já era boa) aos os brindes (incluindo uma camiseta bem bacana) e internet, tudo pareceu funcionar melhor. Tinha mais gente que nos outros anos, e o pessoal xingou muito no twitter esse aspecto. Pessoalmente, achei que acomodaram bem – e que o GDD escala.

O conteúdo era, como se esperava, um grande showcase de tecnologias Google. Como recém-convertido a Android (e vindo do ADL Bootcamp), fiquei empolgado com a ênfase dada à plataforma – que não sucumbiu à miopia das operadoras, como eu temia no meu primeiro contato, em 2007. De qualquer forma, com três palestras simultâneas divididas em quatro trilhas (Android, Cloud, APIs e Chrome/HTML5), era difícil achar um horário em que nada interessasse (só deixei de ver dois blocos, para fins de socialização e uma merecida soneca nos pufes).

As palestras eram mais abrangentes que profundas (ao menos as que eu vi) – o que, para autodidatas, é um fantástico “mapa da mina” sobre o que explorar no universo de tecnologias que o Google disponibiliza. Em particular gostei de ver novamente o p@ falando sobre AppEngine e outros tópicos, e o Ryan Boyd destrinchando OAuth e OpenID. O que deu menos certo, a meu ver, foi a participação de empresas que usam as APIs do Google: a intenção de levar “gente que faz” para mostrar seus cases foi boa, mas rolou desde constrangimento de ex-funcionário até palestra tomada pelo “jabá”.

Mas essas coisas acontecem, e nem de longe tiram o brilho do evento. Pelo contrário, esse mesmo espírito de abertura conduziu ao fechamento do evento com apresentação dos GTUGs (Google Technology User Groups) do Brasil (onde o Paulo Fernandes do SP-GTUG sorteou vários brindes) e ao happy hour, no qual Googlers e civis papearam bastante. Em resumo, o casamento entre tecnologia e fator humano tornou o evento um sucesso, que espero ver novamente em 2011.

Um complemento bacana a participar da PythonBrasil foi estar na RubyConf Brasil 2010. O evento sucede os Rails Summit, e na mesma tradição desses tem a LocaWeb como organizador, mas com empresas como a Gonow (onde o Akita, pioneiro do Rails no Brasil, trabalha atualmente) e a Caelum (que vem expandindo sua posição já consolidada no mundo Java para os novos fronts do desenvolvimento) aparecendo em destaque.

Apesar da internet ter deixado a desejar (em particular no primeiro dia), o evento contou com estrutura ótima: comeu-se bem (não teve almoço, mas estávamos sobre um shopping center), o espaço foi suficiente (não tão grande quanto o dos anteriores, segundo os veteranos, mas coube todo mundo) e o local era de facílimo acesso.

As palestras focaram muito em aplicação das tecnologias que se consolidaram no mundo do Ruby nos últimos tempos. Eu, que andava um pouco afastado da tecnologia, curti muito a abordagem. Houve um espaço para “desconferências”, que funcionaram bem, mas eram um pouco formais demais, talvez desestimulando quem tivesse um recado mais curto para passar.

Como sempre, o lado social é importante. Houve um happy hour no Bar Opção (no qual fiquei pouco tempo, o cansaço dos eventos anteriores já se acumulava) e a impressão que ficou ao conversar com as pessoas é que as empresas estão ficando mais receptivas ao uso de linguagens dinâmicas – possivelmente um movimento em sintonia com a crescente adoção de práticas ágeis na gestão do desenvolvimento de software.

Toda essa vibração em torno de Ruby on Rails me faz ver que é questão de tempo até que apareçam as primeiras aplicações Ruby on Rails usando a Apontador API. Ela ainda não dispõe de biblioteca oficial para esse ambiente, mas com módulos como RestClient e oauth-plugin, creio que os rubistas não terão grandes dificuldades (e se estiverem, estamos lá para ajudar).

Quase como um “esquenta” para o GDD, o Google marcou na véspera (e no mesmo local) o Android Developer Lab Bootcamp, cuja proposta foi ocupar metade do dia com um “bootstrap” da tecnologia, no qual desenvolvedores participaram de:

• Uma apresentação rápida sobre Android (na qual ganhei um bonequinho de vinil respondendo a uma pergunta);
• Uma demonstração na qual cada participante reproduziu¹ em seu micro o passo-a-passo da construção de um aplicativo;
• Um desafio: adicionar um feature ao aplicativo em um intervalo de tempo reduzido. Os poucos que conseguiram ganharam camisetas, e participaram do sorteio de um Lego Mindstorms.

¹ O método utilizado foi uma aplicativo template†, no qual o código dos features era “des-comentado” a cada passo (procure por “Step 0″). Parece bobo, mas na prática essa técnica alia o hands-on com a agilidade de algo pronto – gostei.

Uma pequena confusão foi causada pelo fato de o site do evento pedir para baixar as ferramentas, mas não para instalar as mesmas previamente. Algumas pessoas mal conseguiram concluir a configuração do ambiente, outras tantas perderam momentos preciosos da apresentação nesse processo de configuração. Mas no final deu tudo certo, e eu, recém-convertido ao Android, já estou com idéias envolvendo a migração de antigos projetos J2ME para a nova plataforma…

Desagradável mesmo foi o gaiato que se aproveitou do surgimento do FireSheep (que permite a pessoas sem conhecimento técnico capturar cookies de autenticação de sites como o Twitter) e da ausência de criptografia da rede Wi-Fi do evento (não que só isso seja garantia de segurança total, mas a falta dela viabiliza a coisa). Eu normalmente sou paranóico quando estou em redes públicas, mas acreditava que num evento desses o pessoal estaria mais focado em programar do que em brincar de “ráquer”. De qualquer forma, o Sheepsafe parece uma alternativa bacana para heavy users de redes públicas minimizarem esse tipo de inconveniente.

Finalmente, vale mencionar que quem ganhou o prêmio foi uma dupla, composta pelos meus amigos na foto: Lucas Uyezu e Karen Zamlutti – esta última também colega de IME/USP e integrante do time do Apontador. Detalhe: eles mal se conheciam, e trabalharam em par por iniciativa e inclinação natural a metodologias ágeis. Fica a lição.

Estive na PythonBrasil[6], isto é, no “6º Encontro Brasileiro da Comunidade Python”, que rolou em Curitiba entre 21 e 23 de Outubro. Por conta da aula na UNESP, só pude chegar na sexta (22), mas ainda assim deu pra aproveitar bastante.

Alguém tuitou que este foi um encontro orientado a pessoas, e é verdade: todos lá estavam muito acessíveis – sem deixar de lado o perfeccionismo e profundidade no conteúdo, os palestrantes estabeleceram um diálogo muito positvo com todos os presentes, dentro e fora das palestras.

Uma das marcas da comunidade Python é receber bem todos os interessados, e este aspecto foi contemplado pela ilustre presença do Fabio Akita (@AkitaOnRails), que, à exemplo do que fez no QCon, mostrou onde a comunidade Ruby/Rails acertou e errou ao longo dos anos, deixando lições inestimáveis para os pythonistas que souberam enxergar além das diferenças.

Outro destaque foi o Pedro Valente (@pedrovalente), o elo perdido entre o jornalismo e o desenvolvimento de software. Ele agitou o #freecep nos open spaces e apresentou a versão python-ativada da sua consagrada exposição sobre extração de dados públicos “na marra” – que deixava uma dica para que eu fizesse (mais) uma lightning talk sobre o Cruzalinhas.

Eu achava que o assunto já tinha sido abordado o suficiente (falei dele no FISL 11 e no QCon), mas dado que a palestra original do Pedro Valente foi justamente o que me inspirou a criar o site, achei que não faria mal em complementar a apresentação dele (mesmo sem ter ensaiado ou feito slides próprios para a ocasião). Mas ver o pessoal abraçando à idéia de que serviços públicos implicam em dados públicos já valeu: o @botobr está tentando reproduzir o lance em Curitiba, o @jbochi abriu o fonte do Tô a Pé, entre outros.

De qualquer forma, eu estava no evento como palestrante: fui falar da Apontador API, a iniciativa do Apontador em abrir suas APIs (um assunto que merece seu próprio post, a seu tempo). Fiquei muito satisfeito com a resposta do público: não foram passivos, fazendo perguntas contundentes (acerca da qualidade, da relevância e do posicionamento do produto diante de alternativas) e dando sugestões muito coerentes (que já dispararam ações lá dentro). Audiência qualificada é tudo!

Os slides estão disponíveis no SlideShare (e abaixo), e incluem incluem exemplos básicos de uso da biblioteca Python (cujo código-fonte é livre e também pode ser obtido no github). Ficam os meus agradecimentos à organização pela oportunidade, ao público pela receptividade e a todos os participantes por um excelente evento!