Fragmental

Nossa, tanta coisa que nem sei o que postar. Neste tempo que fiquei afastado –quase um mês!- juntei um bando de idéias para postas mas agora falta tempo.

Neste período terminei mais um projeto. Estou alocado no mesmo cliente e temos dezenas de pequenos projetos que fazem parte de um projeto maior que faz parte de um projeto tão gigantesco que toda semana tem uma festa para comemorar que alguém lá em Perth terminou uma parte que você nem sabia que existia. Segunda-feira devo ser movido para outra parte, desta vez é apenas para prestar ajudar um grupo de desenvolvedores do cliente que está com problemas num sistema baseado em mensagens assíncronas. Deve durar até Maio, creio.

Mas não é o trabalho que me tem afastado, pelo menos não é o maior causador. O problema é a minha pesquisa. Eu tenho dedicado boa parte do meu tempo livre a me aprofundar nos assuntos necessários para uma boa compreensão de Language-Oriented Programming e Domain-Specific Languages.

Infelizmente existe duas áreas de Ciência da Computação nas quais eu nunca me interessei muito: linguagens de programação e inteligência artificial. IA é algo que eu ainda não estudo mas para entender DSLs uma das coisas mais importantes é entender como as linguagens são criadas. Isso está me fazendo tentar aprender em um mês o que eu negligenciei por anos, incluindo a leitura capa-a-capa do SCIP. Eu sei um pouco de Common Lisp mas ainda que não soubesse não seria problema, o livro usa Scheme mas você não precisa saber Scheme ara começar a ler –bem no estilo de Bertrand Meyer que ensina Eiffel no seu livro de OO.

Depois disso vem o Concepts, Techniques, and Models of Computer Programming - que é uma recomendação do Rafael- e The Seasoned Schemer. For a as dezenas de papers da ACM que tenho pesquisado.

É trabalhoso, é complicado mas é uma das coisas que me fizeram vir ara a Austrália e mudar de emprego. Na ThoughtWorks eu tenho acesso a um material seleto sobre iniciativas no mundo real destas tecnologias, e acesso à pessoas com um conhecimento sobrenatural sobre este assunto. Apesar de eu adorar fazer parte de um time fixo desenvolvendo um produto e focado em melhoria, trabalhar como consultor me dá mais liberdade para focar no meu interesse atual, que em grande parte é essa pesquisa. Eu trabalho de 9 as 17h no cliente -sem hora extra- levanto da minha mesa e em 15 minutos estou no meu apartamento.

Antes que comecem as especulações entre meus três leitores não, eu não pretendo fazer nada de útil com o resultado da pesquisa. O resultado, na verdade, não importa, para mim importa o que eu aprender no caminho.

Se tudo der errado eu faço uma aplicação em Lisp pro Facebook e fico rico :)

Todo projeto que já participei, dos meus pet-projects até os com equipes imensas, possuem algum nível de tech debt. Sempre a mesma história: não temos tempo para isso agora, na próxima oportunidade corrigimos.

O problema é que em muitos casos o acúmulo de coisas que deixamos pelo meio do caminho é prejudicial à saúde do projeto. Mais que preciosismo de nerds e perfeccionistas, tech debt pode –e geralmente vai- atrasar o andamento do time.

Nos projetos que eu gerencio eu gosto de alocar um orçamento para resolver estes problemas. Durante o planning game eu deixo claro que precisamos resolver problemas enquanto estamos implementando funcionalidades e geralmente aloco alguns pontos na iteração para eles, normalmente algo perto de 20% do trabalho. Normalmente eu aceito que estas histórias técnicas tenham prioridade baixa e no geral tudo ocorre bem.

Se temos uma emergência então eu costumo não ser muito flexível em relação à solução do problema. As histórias técnicas neste caso ganham prioridade máxima dentro da iteração.

Como geralmente o cliente está satisfeito com a velocidade da equipe num processo ágil (se não está temos outro problema) quando sobra –e quase sempre sobra- tempo extra numa iteração geralmente eu preencho com tech debt, e em especial deixo os desenvolvedores priorizarem o que querem fazer. Muitas vezes não dá tempo para fazer homologação destas mudanças durante a iteração vigente e elas acabam indo para produção apenas na iteração posterior, mas é uma boa estratégia.

O que importa é não deixar o tech debt acumular. Se você tem duvidas dos problemas que o acúmulo de histórias técnicas causam basta lembrar a última vez que você entrou em um projeto para dar manutenção em um sistema pré-existente. Eu nunca vi um caso onde o sistema antigo não tenha toneladas de problemas causados por “deixar para depois” mudanças que não eram urgentes mas foram crescendo em urgência com o tempo.

E claro que meu projeto atual não é diferente. Trata-se da conversão de boa parte de um sistema legado em Java para Ruby (não Rails, Ruby). Como todo projeto deste tipo o orçamento não contempla uma reescrita do sistema, apenas uma conversão. Isso quer dizer que se um módulo assovia e chupa cana em Java ele, teoricamente, vai assoviar e chupar cana em Ruby.

O bom de trabalhar em um time ágil é que não é porque no início do projeto não se pensou em melhorar as coisas que isso precisa ser verdade até o fim dele. Após a equipe (desenvolvedores, analistas de negócios e gerente de projetos) percebemos que alguns itens realmente estavam atrapalhando o andamento do projeto. Nossos dias estão cercados de tarefas repetitivas que existem apenas para contornar alguma “gambiarra” que o sistema original tinha e nós estamos reproduzindo de maneira burra. Levamos a questão aos clientes e fizemos entender que se gastarmos alguns pontos nestas tarefas em algumas iterações nossa velocidade irá aumentar, e muito.

Apos conseguirmos 25% dos pontos de uma iteração para histórias técnicas veio a questão: temos dezenas de problemas, o que faremos primeiro? Como é um time grande cada um tem seu ponto de vista sobre o que está errado e o que precisa melhorar, então fizemos da maneira ágil: disciplina e flexibilidade.

Marcamos uma reunião com o time e coletamos em cartões todos os problemas que conseguíssemos pensar. Os cartões foram pregados na parede, divididos entre coisas do dia-a-dia e coisas que realmente indicam a visão que o sistema deve tomar, aspectos arquiteturais.

Depois cada um recebeu 5 votos para distribuir entre os cartões. Quase todas as histórias eram importantes então precisamos limitar o numero de votos para entender o que realmente é critico.

Apos este exercício nós criamos um backlog paralelo para o produto, apenas com histórias técnicas. Este backlog foi estimado e baseado nele o time decide que história técnica entra nos 25% de pontos disponíveis.

Uma das vantagens dessa abordagem já foi percebida. Nosso sistema é um fluxo de operações em sequência. Operações em sequência são uma ótima área para programação procedural e isso fez com que os desenvolvedores originais do sistema seguissem este paradigma.

Claro que quando se mistura uma linguagem orientada a Objetos com código procedural é necessária muita cautela, e a maioria das pessoas acha que para o código ser procedural basta usar atributos públicos nas suas classes. Existem muitas métricas para qualidade de código procedural (a maioria das métricas de código OO são evoluções ou adaptações destas, na verdade) e nosso código não seguia nenhuma.

Aproveitando o nosso orçamento para histórias técnicas nós introduzimos um sistemas de jobs, uma implementação do padrão Chain of Responsibility. Até agora 50% das funções já foram convertidas para o modelo novo e a cada iteração mais são convertidas.

O resultado das ultimas iterações mostra um aumento consistente de 10% na velocidade. Todos os envolvido creditam esta melhoria à mudança e ainda estimamos que quando todo o sistema for convertido para a nova arquitetura teremos por volta de 25% de aumento total.

Existem coisas simples que podem decidir se um projeto vai ser um sucesso ou fracasso. Não esconder sujeira debaixo do tapete é uma delas.

Recentemente terminei meu primeiro projeto na ThoughtWorks. Como de normal com projetos ágeis esse terminou no prazo e com clientes satisfeitos já prontos para a segunda fase, mas teve algo especial. Foi meu primeiro projeto agile white-label.

A ThoughtWorks é uma empresa especializada em boas práticas de gestão de projetos, análise de negócios e desenvolvimento de software. Não é uma empresa especializada em XP ou Scrum ou Crystal ou que quer que seja.

Com tantos especialistas no escritório não é difícil imaginar que se pega o que melhor funciona em uma metodologia e em outra para formar uma metodologia única, adaptada àquela empresa. Como evangeliza Jacobson, o importante não é o processo em si e sim as praticas.

Nossas praticas neste projeto variaram entre XP e Scrum e as desenvolvidas internamente na ThoughtWorks e que não são tão conhecidas ou por um acaso nunca foram publicadas.

Eu notei algumas coisas boas e ruins no processo. Como estou acostumado a seguir um conjunto específico de metodologias foi muito bom não estar preso à uma prática. No Scrum, por exemplo, se você não segue uma pratica pode complicar outras, elas são habilidosamente encadeadas. Como nós criamos o nosso encadeamento não havia tanto problema em mudar as regras no meio do jogo quando víamos que algo não ia dar certo, mas ao mesmo tempo a falta de uma “arquitetura de processo”, uma linha-guia que dita a estratégia, foi sentida.

Outra coisa importante é que eu não tentaria algo parecido com pessoas inexperientes Existe uma tendência nas adoções de agilidade à largar uma ou outra pratica que parecem menos interessantes ou mais trabalhosas. Eu sou completamente a favor de se personalizar a metodologia com o tempo mas sou completamente contra fazer isso durante a adoção inicial –a menos que seja uma ferramenta didática e a prática seja introduzida no decorrer do período. Adaptação de metodologia deve ser fruto de feedback, não se deve retirar algo do processo antes mesmo de tentar para ver as conseqüências. É claro que existem exceções mas as pessoas que criaram e mantêm as metodologias ágeis tiveram um motivo para colocar aquela pratica ali, se você não vê valor nela existe uma grande chance de não entender ara que ela existe. Tudo bem remover a pratica após entender, só não retire do processo algo que você não conhece e pode ser o coração da coisa toda.

Da mesma maneira, customização demais matou o RUP. O RUP é genérico demais e ao mesmo tempo que é tudo não é nada. Eu já trabalhei em mais de uma dezena de projetos que se diziam RUP e a única coisa que eles compartilhavam era uma burocracia infernal.

Seja qual for sua escolha, Srum, XP, Crystal ou White-Label, o que importa para mim são os valores. As praticas são apenas maneiras de se atingir os valores e apesar delas diferirem entre processos ágeis todos eles tem como objetivo –ou deveriam ter- chegar até os valores expressos aqui.

Há uns 4 ou 5 anos eu faço parte do RioJUG (mesmo na Austrália ainda faço parte do grupo) e nos últimos anos viajei e conheci JUG e outros grupos de usuários no país todo.

Acho que existem três grandes padrões para grupos brasileiros. O primeiro é do estilo do RioJUG: uma apresentação à cada X dias com uma palestra. Pouca participação do público, pouco networking. No Rio ainda é mais complicado porque as reuniões vão até tarde e as pessoas mal tem tempo para o lanche no final.

Outro padrões é o de Dojo. Pessoas se reúnem e resolvem um problema com código, aprendendo sobre ferramentas e plataformas no caminho. Muito networking, muita participação mas geralmente o conteúdo só se espalha até todos terem um razoável conhecimento sobre ele,não existe a figura de uma pessoa que apresenta algo muito novo ou experimental. Além disso no Brasil temos poucos notebooks nas mãos das pessoas -apenas gerentes líderes e etc.- o que elitiza os frequentadores.

Outro tipo é quando as pessoa apenas se reúnem para conversar. A comunidade de Software Livre é especialista nisso e geralmente a conversa começa ou termina no bar.

Todos são legais. A comunidade Java brasileira cresceu muito basicamente com este tipo de divulgação. Mas eu, sinceramente, enchi o saco.

Hoje estou no escritório da ThoughtWorks em Melbourne, onde estou baseado. Temos aqui o encontro do grupo de usuários de Ruby de Melbourne, que é hospedado aqui no escritório (também teremos aqui o BarCamp Melbourne em Fevereiro). Este grupo tem uma estrutura de reunião bem interessante.

Começa com a eventual apresentação pelo coordenador, bem rápida. Depois, durante vinte minutos, pessoas conversam sobre coisas interessantes que viram, comentários rápidos e indicações de onde achar mais informação. Depois uma apresentação sobre um tema de meia hora. Um intervalo com pizza e refrigerante (oferecidos pela anfitriã) e nos trinta minutos restantes temos lightining talks, palestras muito rápidas -cinco à dez minutos- sobre coisas aleatórias no mundo Ruby/Rails. No fim vai todo mundo para o pub, como bons australianos. Como em Melbourne anoitece às 21h nessa época do ano a noite ainda nem começou.

A palestra principal foi sobre TreeTop mas falamos sobre Faker, benchmarks de servidores web, ImageMagik, a LnuxConf Melbourne que está rolando esses dias e dezenas de outras coisas. Não haviam espectadores, todos eram participantes.

Fazia muito tempo que não tinha uma noite nerd tão agradável.

O Laércio Queiroz me entrevistou sobre DSLs. O resultado você vê no blog dele.

Removendo algumas teias de aranha do blog. Está sendo um tempo bem difícil com todos estes feriados e tudo mais por aqui mas consegui uma brecha razoável neste natal para colocar algumas coisas em dia.

Como vimos nos últimos capítulos estou em um grande cliente num projeto em Ruby. Na verdade o projeto é uma grande plataforma tecnológica onde Java é usado no produto em si e Ruby no grande conjunto de ferramentas que os desenvolvedores criaram. A parte que eu estou trabalhando neste momento (ou para onde irei voltar dia 2 de janeiro) é um sistema que atesta a veracidade de informações.

Não dá para falar muito sobre o projeto em si mas é algo bem interessante. A empresa cliente é membro de um grande conglomerado de empresas tradicionalíssimas que lidam com tecnologia e engenharia em diversas frentes. Essa empresa em específico tem um problema interessante: ela possui uma mina de ouro em dados exclusivos mas seu sistema é completamente ultrapassado. Mesmo com esse problema em forma de legado seu banco de dados é a fonte mais confiável sobre estes dados que se têm na Oceania e estes dados são necessários para praticamente todas as empresas do país, então ela se mantém como player no mercado.

Como sempre acontece nestes novos (30 anos?) tempos boa parte dos seus clientes não está satisfeita com os serviços e está usando meios alternativos para conseguir as informações que precisa sem passar pelo sistema burocrático e antiquado. Mesmo estes meios sendo mais caros e trabalhosos que o sistema legado ainda assim preferem fugir do sistema atual de alguma forma, qualquer que seja.

Há alguns anos a ThoughtWorks entrou nesta empresa para tocar um projeto que está entregando a fase final em algumas semanas. O trabalho foi tão bem aceito que a empresa adotou o estilo agile & lean de administrar as coisas para si, ao andar pelos dois prédios de 7 andares que a empresa ocupa você vai ver dezenas de cartões pregados na parede formando diversos posteres kanban, do pessoal de marketing até o da produção. Para lidar com o domínio de negócio, algo bem específico e pesado, eles formaram várias pequenas equipes, geralmente com cinco pares de desenvolvedores (100% pair programming), um ou dois analistas de negócios, um representante do cliente (client on-site) e alguns analistas de testes.

Como falei a coisa funcionou bem e o projeto onde eu estou é o segundo com participação da ThoughtWorks. Além dos nossos consultores existem diversos funcionários e alguns consultores empregados por outras empresas: É muito engraçado ver gente que trabalha oficialmente para uma empresa de três letrinhas, CMMi nível 23 e meio praticando agile feliz da vida e comentando como este é o primeiro projeto que vê funcionar na vida.

É interessante ver mais um caso de empresa que muda não para seguir a nova regrinha do jogo mas sim porque precisa mudar. Sei que tem muita gente que discorda de mim mas acho que nos últimos anos as empresas ficaram muito mais maduras com relação ao que adquirem. Há um movimento interessante nas empresas brasileiras que fazem do software seu negócio para retirar terceirizados e colocar sua gente para desenvolver.

Se você perguntar a qualquer analista de mercado ou ler qualquer boa ou má publicação vai ver que isso seria a maior besteira. Ainda que uma empresa como Globo.com, UOL, ig, e etc. dependa do software ela não produz software para viver. Uma empresa deste tipo deveria, segundo a lógica do preto-no-branco, comprar os serviços para uma empresa de desenvolvimento de software. Isso faz sentido e diminui o custo de manter uma equipe de desenvolvimento. O problema é que, como sempre diz minha esposa: economia simplista tende à economia burra.

O modelo funciona no papel e deveria funcionar na vida real mas não funciona. Segundo o pensamento acima quando contratamos uma empresa de software estamos contratando serviços de alguém especializado nisso. Mentira. A grande, grande maioria das empresas que oferecem serviços de consultoria no desenvolvimento não tem a menor idéia do que é desenvolver um software. Seus profissionais são expostos (quando são!) a um treinamento pasteurizado e superficial, os poucos profissionais capacitados destas empresas são por mérito próprio.

Então temos uma equação interessante. Digamos que manter funcionários especializados no desenvolvimento na folha de pagamento custe X. Esse é, por exemplo, o mesmo valor que pagamos à empresa JCN (nome ilustrativo, nem sei se existe uma empresa com esse nome) para alocar seus funcionários na nossa empresa. Se fosse só por isso ia ser um negócio estranho, íamos ter um 0-a-0 no investimento. O problema é que manter um corpo técnico como funcionários da empresa não custa só isso, você precisa investir para que este corpo técnico seja capacitado. Este é o custo que seria evitado contratando os serviços da JCN.

O problema é que após algumas décadas os clientes passaram a perceber que a empresa JCN não investe nada nos seus profissionais. Eles começaram a perceber que a JCN não entende nada de desenvolvimento de software. Alguns clientes não acham que valha a pena fazer algo a este respeito. Continuam na mesma coisa, exigem um certificado CMMi novo e toda vez que fecham um contrato já se preparam para o processo que sem dúvida vai acontecer quando o projeto não for entregue nos termos deste.

Tem outras empresas, no entanto, que não podem ter este prejuízo porque se o software atrasar não vai ser seu gerenciador de estoque que sai do ar, é o seu negócio como um todo, sua fonte de renda. Pelo que já vi na prática essas empresas fazem uma de duas coisas: ou (re-)internalizam o desenvolvimento ou contratam uma empresa realmente capacitada.

A primeira parte é mais cara e trabalhosa, mas pode ser melhor. O cliente adquire uma equipe de desenvolvimento e se preocupa em treiná-los. É preciso que este time entenda como desenvolver software e é por isso que estamos vendo tantos cursos in-company de Scrum, XP e etc. Você já viu consultoria de três letrinhas pagar isso para seus funcionários? Quem está comprando estes treinamentos são os clientes, não os fornecedores. Algo para pensar, não?

No segundo caso o cliente acha uma empresa em que confie para uma parceria. Neste ponto que eu acho que as pequenas consultorias tendem a fazer bastante dinheiro. Um grupo pequeno de desenvolvedores talentosos e motivados pode fazer muito mais do que uma grande corporação de três letrinhas com duzentos funcionários alocados para seu projeto. Palavra de quem já esteve dois dois lados, de quem compra e de quem vende.

O meu cliente atual está indo para a primeira opção. Para chegar lá ele tem que enfrentar dois problemas: 1) é caro e 2) se os dois projetos não saírem até o meio do ano não precisa mais continuar a contratar gente porque a oportunidade vai ser perdida. Neste cenário o que eles fazem é contratar consultores que eles confiem para atuar junto aos seus funcionários e desenvolver o software. Os consultores, mesmo os das empresas de três letrinhas, são minuciosamente entrevistados num processo que lembra o próprio processo seletivo da ThoughtWorks.

Após este tempinho lá e medindo com minha experiência passada eu acredito que estejam no caminho certo. Eles possuem equipes com profissionais muito acima da média a um custo razoável. Estes profissionais estão entregando os projetos e ao mesmo tempo construindo a cara dos departamentos de desenvolvimento. Quando os projetos encerrarem acho que 1/3 do número de pessoas vai ser necessário para manutenção e demais desenvolvimento, como é o aproximado número de consultores não deve haver problema. Os times pequenos já são rearranjados diariamente mesmo.

Claro que o processo de achar consultores é difícil e requer investimento. Seguir este plano é bem mais difícil que fazer uma ligação do tipo: “Alô, é da JCN? Me manda 300 programadores Java, por favor? 30 minutos? Obrigado”. Eu não diria que é uma solução para todos, sequer para a maioria, já falamos um pouco sobre isso aqui.

O que eu digo a respeito da situação na maioria das empresas que está com problemas no desenvolvimento (e qual não está?) é: façam algo. Após tanto tempo comprando dos mesmos fornecedores e recebendo porcaria em troca porque você continua com eles? Após tanto tempo desenvolvendo software ruimd esta forma porqu você continua fazendo isso?

Seja lá o que fizer, faça algo. Só, por favor, não compre soluções de caixinha. Certificados, ferramentas, cursos, livros, vudu… nada disso vai adiantar, pelo menos não sozinho. Descubra a motivação das coisas e veja se aquele eu fornecedor (ou se o produto que ofereces) que diz que faz a práticas X e Y e por iso tem o certificado Z sabe, ao menos, porque ele deveria fazer aquilo.

Lendo os ThoughtBlogs hoje achei uma ótima apresentação feita por John Johnston. A idéia é introduzir os conceitos de agilidade no ponto de vista de um analista de negócios.

Estava pensando sobre o texto que escrevi ontem sobre modelos de negócio afetados por escolhas tecnológicas e acho que posso ter confundido alguém. Minha idéia não é dizer que modelo de negócio não é importante, pelo contrário este é a coisa mais importante numa empresa, apenas atentei para o fato de que as escolhas tecnológicas afetam o modelo de negócios. O caso de exemplo era sobre uma empresa com ótimo modelo e tecnologia não adequada.

Na verdade, provavelmente a tecnologia existente há alguns anos é mais que suficiente para modelar de excelente maneira qualquer domínio. O problema é que ainda somos (como indústria) amadores no desenvolvimento de software.

Veja por exemplo meu primeiro dia no projeto novo. Uma das maiores empresas da Austrália precisa migrar milhões de dados sobre seus clientes do sistema legado para o novo. Eu cheguei no meio do projeto e minha primeira tarefa é atuar no sistema que faz uma checagem ara ver se os dados foram mirados corretamente. Moleza.

Até a hora do almoço meu par e eu tínhamos escrito todo o script Ruby que conecta com o servidor do sistema legado, obtém o resultado da consulta desejada como HTML, faz parsing dele com o hpricot, armazena num banco de dados utilizando ActiveRecord, chaa os scrits e comparação, faz caching em disco e retorna um resultado em XML. Tudo isso rodando numa task do rake e testado com RSpec. Moleza.

O difícil foi fazer os scripts de comparação. A tecnologia já oferece mais que suficiente para criar este mecanismo, já fizemos uma arquitetura baseada no padrão Chain of Responsibility que vai validar todos os casos mas e entender as regras do negócio?

Sempre vai ter aquele que diz “ora, tá tudo documentado em caso de uso, diagrama de domínio e etc.’. Já tive o desprazer de trabalhar em diversos projetos que acreditavam que isso é verdade e invariavelmente o resultado era que o novato só ficava produtivo depois de um mês e pouco.

Hoje, no meu primeiro dia no projeto novo, já consegui ser produtivo e implementar boa parte de uma história. A mágica não está no Ruby, não está no Mac, não está no Java nem no SOA. Está em uma palavrinha que eu coloquei no texto lá no início e talvez tenha assado despercebida:

Até a hora do almoço meu par e eu tínhamos escrito todo o script[…]

Na chegada eu fui recebido com uma visão geral do sistema, seus objetivos e arquitetura. Em uma hora eu estava programando uma parte importante e para me mantêr dentro do domínio havia ma pessoa com anos de experiência na casa pareando comigo. Acredito que amanhã pela manhã tenhamos completado a user story que estávamos implementando.

A tecnologia vai continuar evoluindo e nos levando para luares fantásticos mas o que a maioria das empresas precisa é de uma faxina no modo de pensar das pessoas, tanto do alto quanto do baixo escalão.

Desde que cheguei aqui na ThoughtWorks as coisas têm sido bem calmas. O primeiro dia eu fui recebido pelas pessoas e recebi meu infame MacBook Pro (eu pude escolher entre um Mac ou PC antes de vr pra Austrália, BAs pegam um MacBook comum, Devs pegam um MacBook Pro 2.2Ghz/2GB). Depois de ser resresentado ao Lotus Notes (essa porcaria que eu não usava desde 2005) eu fui para a beach.

Na ThoughtWorks, ‘beach’é quando você não está alocado em nenhum projeto. Você vai ao escritório todo dia com seu notebook e senta na “main desk”, uma graaaaaande mesa sem lugares marcados. O escritório possui tudo que você iria querer: coca-cola, sucos, frutas frescas, cereais, chocolates e doces em geral, água, café grátis (a TW tem um contrato com uma empresa tipo Starbucks), wii e… cerveja.

Na beach você faz basicamete o que quiser. A maioria das pessoas está sempre procurando sistemas para fazer e testar novos conhecimentos, a dupla Alex & Alex que costumam sentar próximos a mim arrumaram uns requisitos com a menina do RH para criar um sistema e treinar Rails. Um outro que é desenvolvedor .Net está fazendo um feed reader em GWT. Todo mundo conversa bastante e socializa, tem uma galera que, como eu, não era usuário de Mac e ficamos batendo a cabeça e chorando as pitangas juntos.

Durante meu tempo na beach eu aproveitei para brincar com o Antlr. No Fragmental.tw eu já falei uma vez que estou implementando um esquema de conectar DSLs via um barramento, eu tenho uma linguagem pronta e preciso das outras para continuar. Ainda não consigo fazer minha linguagem ser aceita pela gramática mas tá indo bem…

Outra coisa legal no escritório é que temos almoços corporativos. Serve para trazer pro escritório o pessoal que está alocado nos clientes pela cidade, ao contrário de consultorias que conheço por aí não é porque você está alocado que você não se relaciona mais com a TW, você simplesmnte é um TWer alocado. Esses almoços são dentro do escritório, aqui em Melbourne são terças e sextas. Hoje tivemos sushi.

E ontem houve também um dos eventos típicos: pelo menos uma vez por mês a TW fecha um bar ou pub e reúne todo mundo da empresa e alguns “clientes selecionados”(pessoas que trabalham nos clientes e possuem o espírito “cool”da TW).

Hoje foi meu último dia na beach, vou ser alocado em um projeto a partir de segunda. O legal é que o prédio do cliente é vizinho ao apartamento onde estou morando, literalmente à cinco minutos andando de casa.

Apos trinta horas de cansativa viagem cheguei a Melbourne sexta-feira passada. A cidade eh linda, o povo amigavel.

Estou no finzinho do meu segundo dia na ThoughtWorks, no escritorio de Melbourne por enquanto. Ontem eu ganhei meu MacBook Pro (e isso explica porque este post nao tem acentos, nao sei usar isso direito) e ainda estou matando o backlog de uma semana sem computador decente. Mais em breve.