Fragmental

O dia começou bem com uma palestra sobre a arquitetura do eBay. Muita gente cita o site como exemplo de quem migrou de C++ para Java mas não sabe que na verdade o problema, como quase sempre, foi o uso que faziam da plataforma. C++ não é uma linguagem tão interessante para construir aplicações web mas mesmo os back-ends eram extremamente problemáticos, com God Classes de milhares de linhas por todos os lados (coisa muito comum em sistemas em Java, de qualquer forma). A palestra seguinte foi de um dos arquitetos do Microsoft Visual Studio pretensiosamente entitulada ‘Agile Architectures’ que ficou no lugar comum de sempre. Pela descrição do processo utilizado para desenvolver a ferramenta percebe-se que é tudo, menos ágil: times enormes, iterações de meses e meses…

A palestra do Ford (sempre ele) sobre métricas em projetos ágeis foi muito boa. Além de mostrar um pouco de como funciona uma grande empresa que usa os processos com sucesso no dia-a-dia ele reforçou a necessidade de medir e agir sobre métricas como dependência entre módulos, coesão, acoplamento, cobertura de testes e etc.

O último dia foi bem legal, assim como o congresso. Interessante notar como havia um público de idade mais avançada que a média deste tipo de evento o Brasil. Interessante também o interesse dos gringos por agilidade, todos que conversei sempre estavam atrás das palestras com este foco e sempre com o mesmo motivo: estavam ouvindo sobre isso há anos e agora começaram a ver resultados, então querem saber como implantar nas empresas. Caravanas de grandes empresas americanas foram mandadas ao evento para tentar entender como Agile e Ruby especificamente poderiam ajudar suas empresas.

Enquanto isso, no Brasil…

Ainda não vi uma definição sobre o que seria uma linguagem elegante, então lá vai a minha:

Uma linguagem elegante é baseada em primitivas simples e extensíveis e, principalmente, sem muitas exceções.

Segundo esta definição Ruby, Smalltalk e LISP são elegantes. Java é um pouco, C# com suas centenas de exceções (sobrecarregar + é diferente de sobrecarregar [], dentre outras várias exceções) não é.

Uma linguagem elegante é simples e compacta. É de se esperar que não tenha sobrecarga de operadores, mas isso não é verdade. O problema das pessoas com sobrecarga de operadores é porque elas vêem isso como uma quebra da rule of least surprise. Essa regra diz (implora, eu diria) para não surpreendermos nossos usuários modificando o mundo que eles já conhecem para que uma ação traga consequências não esperadas. Por exemplo imagine que você vai modificar um programa como o ls para dar mais performance (uau, você é bom!). Faça o que quiser mas não mude os parâmetros de entrada e saída ou você vai quebrar um zilhão de programas e scripts pelo mundo todo. Caso introduza uma feature nova faça o usuário explicitamente solicitar por ela (passando um flag no estilo ls -lira –my-fancy-new-feature) e mantenha o default como o antigo.

E onde entra sobrecarga de operadores nisso? Lá no seu primeiro curso de programação (ou no seu primeiro livro se você opta pelo caminho mais difícil) deve ter aprendido sobre literais, variáveis, condicionais e… operadores. Operadores são caracteres especiais com uma função bem definida na linguagem, por exemplo o operador de divisão, de resto, de adição…

Em Java, quando você chama:

String texto = "abc".toUpperCase();


É fundamentalmente diferente de quando chama:


int numero = 12 + 24;


Porque um método e um operador são coisas diferentes e você aprendeu a pensar desta forma. Se amanhã eu puder sobrescrever o operador + para que escreva algo na tela você vai se surpreender porque não era isso que o manual da linguagem te disse.

Ainda assim, existem muitas ocasiões onde sobrecarga de operador são mais que convenientes, são semânticos. Imagine o exemplo do nosso BigDecimal:


BigDecimal a = new BigDecimal("100");
BigDecimal b = new BigDecimal("300");


Some os dois. Ok, você é um programador Java esperto e sabe que vai ter que fazer algo como:


BigDecimal resultado = a.add(b);


Mas disso até me dizer que é melhor que usar ‘+’ é outra história.

Mas e a simplicidade? Não é legal termos um conjunto pequeno de operadores que faz coisas previsíveis e que servem na maioria das vezes? Sim, é! Mas num mundo onde tudo migra para mais expressividade, com Model-Driven Development e Domain-Specific Languages ter este tipo de limitação não é interessante. As melhores linguagens para construir DSLs são as mais flexíveis e por acaso as mais elegantes, que coincidência, não? E como Ruby, que se enquadra nestes dois aspectos, lida com isso?

Simples. Em Ruby não existem operadores, pelo menos não como você está acostumado em Java, operadores são apenas apelidos para métodos. A vantagem disso é que se muda o modelo mental, a partir do momento que você sabe que um operador e um método são a mesma coisa você tem com operadores o mesmo cuidado que tem com métodos. Ao chamar add() do BigDecimal você tem que saber se o método vai retornar o resultado como um objeto separado, se vai modificar os objetos passados como parâmetros, etc. Como você faz isso? Lendo a documentação até se familiarizar com a classe e seu idioma. Após familiarizado você começa a usar sem pensar.

E quando você espera estar lidando com uma classe que sobrescreve um operador e na verdade recebe como parâmetro uma subclasse dela? Sem problemas! Se o autor seguiu os princípios básicos da Orientação a Objetos, que derivam do Design by Contract e o Princípio de Substituição de Liskov a subclasse tem que obedecer o contrato da classe-pai, e se você obedeceu os mesmos princípios não precisa de nada que não esteja no contrato.

Esse tipo de resistência com funcionalidades é o tipo de coisa que se elimina aprendendo várias linguagens e estudando suas motivações. Existem algumas linguagens como as citadas que merecem ser estudas ainda que você nunca as vá utilizar de fato. Elas abrem a sua cabeça.

O Paulo Vasconsellos lá do finito ensaiou sua opinião sobre como código não pode representar a documentação sobre um processo de negócios. O post que originou a conversa é bem fraquinho, mas o ponto é bom.

Basicamente a idéia é que não dá para confiar no código porque ele possui o que Joel Spolsky catalogou como ‘leaks de abstração’ em um dos seus artigos mais citados. ~Tenho que admitir que isso pode ser verdade na maioria dos casos mas apenas porque as pessoas ainda não aprenderam o conceito simples de separação de responsabilidades, e isso é muito pior na cultura .Net que é a do autor do artigo original.

Imagina que temos um processo de negócio automatizado num software OO. A coisa é simples, o clássico e onipresente exemplo de adicionar usuários a um grupo:


void adicionarUsuario(Usuario u, Grupo g){
g.adiciona(u);
}


E como estamos falando de um software OO as regras de negócio estão nos respectivos objetos (grupo e usuario) e não nesse método de serviço. Muito bem, eu consigo gerar uma documentação em fluxograma, UML, o que for desta sequência simples de instruções imperativas. O problema é que software não é simples assim.

Eventualmente nós precisaremos persistir a alteração feita no banco de dados.


void adicionarUsuario(Usuario u, Grupo g){
g.adiciona(u);
repositoriousuarios.atualizar(u);
}


E possivelmente precisamos saber se o usuário logado possui direito a fazer esta alteração, esse é um requisito não-funcional de segurança. Adicionar um log também é útil para auditoria.


void adicionarUsuario(Usuario modificador, Usuario modificado, Grupo g){
if(podeAlteraroutrosUsuarios(modificador){
g.adiciona(modificado);
repositoriousuarios.atualizar(modificado);
logger.info("Alterou");
}
else{
throw new IllegalQualquerCoisaException();
logger.error("Tentou alterar");
}
}


E isso pode piorar ainda mais. Agora utilize o código acima como documentação de negócios por favor. Mostre ao seu cliente e peça para ele tentar te explicar. não dá, né? E por quê? Porque cada uma destas coisas são conceitos ortogonais, que deviam ser implementados por técnicas de AOP e não embolados no meio do código de negócio.

Domain Driven Design possui a modelagem de negócios no código como sua essência. Um dos pontos que mais causam dúvidas, por exemplo, é o da diferença entre Repositórios eDataMappers (DAOs no mundo Java EE). A diferença é que eu coloco um repositório num diagrama de negócios (ainda que chame de outra coisa) mas não coloco um DataMapper . E por quê? Porque a responsabilidade de um Repositório é referente à objetos que mapeiam o negócio enquanto a responsabilidade de umDataMapper é transformar objetos em tabelas (ou coisa do gênero) e objetos ou tabelas não são conceitos de negócio. Assim ainda que um DataMapper implemente um Repositório eles são tratados sob pontos de vista bem diferentes para análise de sistemas.

No passado nós tínhamos uma discrepância enorme entre os modelos de negócio e o modelo físico do software. Há mais de vinte anos que não há motivo para esta diferença existir, exceto uma cultura dominante. O problema, como sempre, está nas pessoas.

Model-Driven Development, conjunto de idéias que Domain-Driven Design faz parte, é exatamente sobre isso. Por enquanto nós ainda precisamos educar os desenvolvedores para que usem as ferramentas de maneira correta, num futuro próximo eu espero que Domain Specific Languages poupem este trabalho na maioria dos casos.

Ontem eu terminei o dia assistindo a palestra sobre Rails de Neal Ford, da ThoughWorks. O tema em si não era novidade mas eu queria ver a reação da platéia, que foi como esperado: exatamente como a platéia brasileira que é apresentada ao framework. A diferença é que os americanos (e indianos, e japoneses, e suecos, e demais presentes…) já passaram da fase do ‘ouvir falar’ que o Brasil está vivendo e estão na fase de ver os impactos.

Ford também abriu meu dia de hoje com sua palestra sobre DSLs em linguagens estáticas. Ótima apresentação focando nas diferenças entre APIs, Human interfaces, DSLs Internas e externas e mostrando exemplos em Java, Groovy e Ruby.

Depois desta eu não perderia por nada a apresentação do Uncle Bob. Infelizmente foi apenas a mesma apresentação que já assiti algumas vezes, que basicamente traduz o ótimo livro do martin. Claro que apesar do conteúdo já ser conhecido a presença de espírito do apresentador faz tudo valer a pena. no meio da apresentação as imagens sumiram dos slides e o tio Bob teve que desenhar todas novamente num flip chart, não sem emendar comentários hilários sobre a origem e utilidade de cada uma. O bashing também era um ponto de sentar de rir, começando pelo já batido bashing do Netbeans (”só existem duas IDEs para Java: Eclipse e Netbeans, e por um acaso o Eclipse é gratuito”) passando pelo bashing da massa de programadores C++ sobre usas ferramentas e plataformas (”se alguém disser que compila um sistema C++ de gente grande em menos de duas horas é mentira”). Afinal, você ia discutir sobre C++ com o cara?

Uncle Bob se juntou á Scott Ambler, figurinha conhecida dos brasileiros, e Elliotte Rusty para falar sobre TDD. O painel recebeu várias perguntas da platéia e, como o próprio Uncle Bob deixou claro, era engraçado como as perguntas são há quase vinte anos.

Minha tarde terminou com Dean Wampler falando sobre AOP em Ruby. Eu acreditava que seria uma palestra bem básica mas me surpreendi, Wampler falou sobre como a metaprogramação de Ruby não substitui AOp com exemplos tirados de frameworks famosos como Rails e decorreu sobre as propostas da área, inclusive as novidade do Ruby 1.9. Infelizmente a platéia não estava preparada, apenas uns 5 eram programadores Ruby de fato.

Para aqueles que mostraram sua solidariedade pela minha perda do lollapalooza informo que pelo menos comprei o Live at the Gorge, que eu nem vi pelo Brasil. Imperdível.

Após a palestra xarope sobre pseudo-Domain Models foi a hora do almoço com direito à keynote de Ivar Jacobson. Se você acompanha a Dr. Dobbs sabe que o cara -um dos pais da UML e do RUP- está cansado de processos e foi sobre isso sua palestra. Eu estava esperando para comentar sobre a série de artigos aqui em algum momento, pelo visto vai ser agora.

Imagine uma empresa que constrói sistemas. Agora imagina que ela só domina Struts e Hibernate como ferramentas. Todos os projetos, se exceção, são feitos nestas duas plataformas, e pior: os desenvolvedores só usam o que leram em tutoriais na Internet, ninguém sabe de fato utilizar as próprias ferramentas. Além de usar a dupla para implementar aplicações tão pequenas quanto um “fale conosco” (quem nunca viu uma aplicação que nem SGBD acessava e tinha os JARs do Hibernate no classpath?) a empresa usa mal e porcamente as ferramentas quando precisa de fato, simplesmente porque usar ou implantar não significa usar corretamente.

É assim que Jacobson vê a implantação de projetos nas empresas, e disso que ele está cansado. “Ninguém lê livros sobre processos”, ele exclama e isso embasa toda a minha série de posts sobre “pare de se enganar: você NÃO usa RUP”.

O que Ivar propõe é o foco no uso de práticas que fazem sentido. Vê-lo falar (e sacanear o Scott Ambler, na primeira fila, ocasionalmente) fazia transparecer a sabedoria que décadas tentando enfiar conhecimento na cabeça dos outros traz e as consequências que se chega. Recomendo os artigos, vamos focar no tema em outra ocasião.

Logo depois parti para um talk de Juha-Pekka Tolvanen com título “Creating a Domain-Specific Modeling Language: Hands-On”. propaganda da MetaCase apenas, que eu considero um bom case de DSL mas não gosto da ferramenta. Acho que as pessoas precisam aprender que RAD não deu certo para sistemas de verdade e não dará para definição de DSLs, que são programas em si. Que saudades da sabedoria do Jacobson! Bom, fiquei na sessão para recarregar a bateria do meu notebook de qualquer forma…

Manhã morna no evento. Primeiro uma palestra bem legal com James Hobart entitulada “Designing Usable Web 2.0 Applications” onde ele delineou alguns dos “Design Patterns” (eu chamaria de “Interaction Patterns”) e alguns divertidos exercícios de usabilidade derivados destes. Bem legal.

A segunda foi “Domain Models and Requirements that Span Projects”, de Petter Graf.. Decepcionante. Os slides prometiam bastante mas a apresentação se mostrou uma sequência de conceitos do século passado sobre Domain Model gordos e sobre como derivar requisitos do domínio, geralmente ignorando que o sistema mapeia apenas uma parte pequena do domínio e um foco enorme em ferramentas, sejam CASE ou Mind Maps. Para piorar no final rola um pequeno comentário de como a arquitetura de Entity Beans 2.x mapeia o conceito apresentado muito bem. Já viram o tamanho do problema, né? Medo das pessoas que assistiram esta palestra, muito medo… Os slides desta apresentação estão online. Cuidado com eles! Tome como anti-exemplo!

Eu bato nesta tecla frequentemente, mas nunca deixo de ficar espantado em como as pessoas conseguem fazer a associação completamente errada ao tentar adequar a posição de desenvolvedor de software em algum lugar. Existe uma pressão social para que enquadremos esta profissão em algum critério, preferencialmente apenas estendendo uma já existente. Eu não tenho nada contra a princípio, na verdade deixo sempre bem claro que na minha visão desenvolvimento de software é uma engenharia, uma ciência destinada a resolver problemas.

Eis que aí mora o perigo. Ao associar a profissão com engenharia logo se vê gente que tenta adequar tudo a esta área, como se houvesse apenas uma maneira de fazer engenharia. O maior problema, entretanto, é que o desenvolvimento de uma solução em software é diferente do da maioria das engenharias (talvez não da química… preciso pesquisar sobre isso). Numa engenharia tradicional (civil,agrónoma, sanitária…) geralmente você precisa entregar um projeto que vai ser executado por outros profissionais, quase sempre profissionais que não possuem o grau de engenheiro, ou seja: não saberiam resolver os problemas por si só. A implementação do projeto tem que seguir o plano minuciosamente, primeiro porque a mão-de-obra teoricamente não possui conhecimento suficiente para tomar decisão em caso de dúvida e em segundo lugar porque um projeto deste geralmente é algo big bang. Você não consegue construir meia ponte, deixar uns carros passarem por uma semana e ajustar o projeto. precisa construir a ponte toda, do início ao fim, de uma só vez e seja lá o que Zahl quiser.

Bem, detesto ser estraga-prazeres de tantos mas não é assim que software funciona. Há muito tempo que descobriram que a melhor maneira de produzir software é de maneira iterativa e incremental. Este é o princípio básico de RUP, Scrum e XP, só para citar algumas metodologias/processos de desenvolvimento. Nestes processos sabe-se muito bem que o nível de acerto em um projeto BDUF, que segue o modelo dos engenheiros do parágrafo anterior, é passo certo para o fracasso. Ok, mentira minha, certo não é. Eu conheço algumas poucas empresas, de ramos muito específicos (geralmente gente que lida com regulamentação governamental pesada) que consegue levar este modelo. Aliás, sabe qual é esse modelo onde você produz uma especificação antes e escreve código depois? Waterfall, ou Cascata.

Eu me lembro em algum momento de 2002 tendo uma aula na faculdade sobre este modelo. O professor, uma pessoa com curriculum bem razoável e instrutor certificado IBM para RUP, ou algo assim, desenhou o velho diagrama espiralado no quadro e escreveu embaixo uma lista copiada da apostila sobre vantagens e desvantagens dos dois modelos. Em seguida ele começaria a descrever o modelo iterativo incremental desta maneira:

Primeiro, é feita a análise do problema. A análise é, certamente, a parte mais importante de todo o processo. Neste momento são identificados os problemas, os atores, os casos de uso e tudo mais que é necessário para chegarmos na próxima etapa, o projeto do sistemas.

Na fase de projeto os projetistas pegam o trabalho do analista -que deve ser completo o suficiente para que o projetista faça seu trabalho sem ter que esclarecer qualquer dúvida- e criam o modelo da solução para aquele problema, criando diagramas de interação entre as classes e seus estados.

Logo em seguida os codificadores pegam este projeto e escrevem software. O sistema assim está entregue. Notem que um sistema feito desta forma divide corretamente as responsabilidades e gera código de qualidade e bem documentado. Nenhum programador ninja sai escrevendo código por aí sem que antes tudo seja validado pelo analista, projetista e arquiteto do sistema.

Naquela época eu sentia que havia algo errado mas não sabia dizer o que era. Apesar dele não ter explicado direito o tal espiral se isso era diferente do waterfall esta descrição não fazia sentido. Ele descreveu o processo de waterfall, com uma única peculiaridade de atribuir papéis aos participantes. Ele estava errado, não tinha entendido nem mesmo o que era modelo iterativo incremental, muito menos o RUP no qual se certificara.

Quem olha o gráfico das baleias corcundas pode realmente ter uma impressão desta, mas eu realmente espero que alguém que seja um instrutor certificado, ou mesmo um instrutor não certificado, saiba que mais importante que a figura é o embasamento literário. Os livros sobre o tema vão te explicar o que aquelas curvas significam e, ao contrário do senso comum, elas não significam fases no seu projeto. Ok, nova mentira, elas significam sim, até são chamadas de phase, mas o meu ponto é que este conceito não é o mesmo que você vai ouvir por aí.

Uma fase no RUP indica apenas um período de tempo com uma dada característica mais marcante. Na fase de Inception, por exemplo, a atividade mais marcante é a de modelar o negócio e trabalhar requisitos. Isso não significa que você não vai coletar e analisar requisitos mais tarde pelo contrário. indica apenas que a maior parte do trabalho naquele tempo é destinada a esta atividade. E por quê? Porque precisamos de modelos de análise completos? Não! Simplesmente porque naquela altura do campeonato não sabemos direito o que vamosconstruir e estamos tentando entender mais ou menos para começarmos a trabalhar.

Em RUP geralmente as funcionalidades com maior risco ou impacto arquitetural serão implementadas primeiro, XP e Scrum possuem uma estratégia que eu considero muito mais inteligente neste aspecto que é trabalhar logo de cara pequenos pedaços que o cliente escolher. No fim das contas o efeito é bem semelhante: começamos a trabalhar no sistema pedaço por pedaço, descobrimos os pontos que precisam ser ajustados, os ajustamos e seguimos em frente: o desenvolvimento iterativo é completamente baseado feedback que uma iteração dá para a equipe. XP e Scrum possuem diversas características mais interessantes que as implementações comuns de RUP para boa parte das pessoas (iterações curtas, planning game, reuniões super-ultra-rápidas diárias…) mas eu diria que estão ganhando tanto terreno e tão rápido pelas falhas nas pseudo-implementações de RUP que os instrutores certificados, appraisers CMM/CMMi/MPS.BR/Sigla-de-3+x-letrinhas-que-estiver-na-moda-este-mês e demais membros da fauna de processos de desenvolvimento de software insistem em aplicar. Após alguns anos se enganando o mercado começa a acordar e procura um novo salvador da pátria, nesta armadilha está caindo um conceito que é, na minha opinião, uma evolução pura e simples dos processos existentes (mais foco nas pessoas -em vez de temer o ‘programador ninja’ fazer com que o conhecimento se espalhe por todos- e em resultados palpáveis e obtidos rapidamente, por exemplo), processos estes que nunca foram implantados de fato na maioria das empresas, destas que compraram uma caixinha de pseudo-RUP e ganharam um belo waterfall com zilhões de documentos para preencher todo dia.

E o meu maior medo agora é de estar vendo isso acontecer com processos ágeis. Durante o excelente curso de Certified Scrum Master (onde a certificação é algo simbólico, não quer dizer nada além de que você teve x horas de treinamento, por isso pode tirar da sua assinatura de e-mail, por favor?) ministrado pela Teamware lá no Rio conversamos muito sobre isso no cocktail. Já se pode ver empresas muito conhecidas da comunidade por prometer mundos e fundos, entregar (quando entrega) software de péssima qualidade e aos olhos da cara que de repente viu no Scrum, por exemplo, vantagem competitiva.

Como nós vamos conseguir saber se estas pessoas entenderam o mínimo necessário? Não vamos. Apenas podemos nos preparar para que quando estas figurinhas aparecerem com seus Certified Scrum Master, Certified Rational QualquerCoisa, PMP, CMMi, MPS.BR e tudo mais que couber no cartão de visitas nós possamos fazer uma avaliação real, sem nos basearmos nas baboseiras que sempre são citadas.

Fazer este tipo de avaliação não é difícil. Se você não entende a vantagem competitiva e está apenas curioso pergunte ao fornecedor o que ele te oferece de diferente. Ouça bem o que ele lhe diz, estude. Caso não saiba avaliar contrate um consultor e peça referências em um fórum como o do GUJ (onde temos o maior prazer em rechaçar fornecedores ruins em geral). Peça para fazer uma visita ao ambiente de trabalho, qualquer menção da palavra ‘fábrica’ já é sinal de eliminação do processo seletivo: fábricas são um modelo que não funciona para software (pense numa fábrica de notícias num jornal. Funcionaria? É o mesmo princípio: atividade criativa não se serializa ou controla desta forma) e são o extremo oposto de metodologias ágeis (não necessariamente do RUP, mas mesmo assim a empresa deve perder muitos pontos na avaliação). A empresa tem um portfólio no site, todas têm, então ligue para os clientes anteriores. De surpresa, claro, não avise ao fornecedor ou ele irá te indicar apenas referências que ele sabe o que dirão.

Dá trabalho, mas é melhor gastar um mês fazendo a seleção de um fornecedor decente do que ficar anos e anos se lamentando de um projeto furado.

Estava eu passeando pelo Galeão pensando se meu vôo ia sair apenas atrasado ou se ia ser cancelado (para minha sorte e surpresa ele saiu na hora), dentro da livraria reformada do aeroporto quando encontro um livro que queria muito ler por recomendação do Rodrigo Kumpera “louds”: Você Está louco, de Ricardo Semler. Durante as 12 horas seguintes de baldeações entre 3 aeroportos, cada um num fuso-horário, por 3 horas até chegar em Chicago li o que o tal Semler tinha pra dizer. Desde sempre eu me interesso por leitura de negócios, mas desde sempre eu odeio literatura do tipo Pai Rico, Pai Pobre ou o meu favorito para o ranking de livro mais idiota da história: Quem Mexeu no Meu Queijo (outro dia vi uma variação nova sobre sapos que acham lagoas novas). Por isso eu folheava o livro com bastante receio de ter gasto R$40,00 a toa.

Pois não é que o Semler tem muito a dizer? A idéia básica do livro você pega muito depressa: as idéias ‘loucas’ do autor são apenas aplicações do conceito de ‘power to the people’, tão falado neste mundinho Web 2.0 que estamos inventando e vendendo. É impressionante como quando alguém que pode quer fazer alguma coisa os efeitos são visíveis em pouco tempo, seja em um site de conteúdo colaborativo, em folksonomy, em uma rede de distribuição de conteúdo colaborativa e indestrutível ou mesmo numa fábrica com seus operários.

Uma parte importante, no entanto, é quando Semler explica como fez para que os operários fossem apresentados aos balanços da empresa. Não adiantava mostrar planilhas e gráficos para quem não estava habituado a isso, foi necessário falar a língua do povo.

Não vou estragar o livro, fica a recomendação.

Até agora uma coisa boa e uma coisa ruim:

- Aqui da terra do Tio Sam dá pra ouvir o Pandora, que realmente está me fazendo falta no Brasil. Não pelo conceito de rádio online, porque este existe de monte, mas pela forma como ele trabalha conteúdo relacionado e ainda te explica que associação fez. Minhas pobres rádios quase abandonadas voltaram a ser ouvidas a todo vapor no quarto de hotel.

- Acabo de descobrir que semana que vem começa o lollapalooza, que vai ser encerrado por Pearl Jam. Maldita conferência, por que não podia ser semana que vem? Volto pro Brasil dia primeiro :’(

Estou em Atlanta esperando minha conexão para Chicago onde participarei da conferência Dr. Dobbs Archtiecture & Design World. Entrar no país do Tio Sam não é fácil nunca, mas até que foi tranquilo (tirando o eterno alerta laranja do aeroporto). Definitivamente com essa cara de chicano e cavanhaque sou presa fácil pra ir parar na inspeção…

O que mais me interessa na conferência são as apresentações sobre DSLs, um tema que vai demorar um tempinho para de fato chegar no Brasil.

Bom, durante a semana devo comentar os acontecimentos.