Edson Yanaga

Programador Profissional #1: Domínio do inglês

noreply@blogger.com (Edson Yanaga) — Tue, 29 May 2012 17:25:00 +0000

Edsger Wybe Dijkstra (1930-2002)

Este post é o primeiro (#1) da série de definições sobre o que considero um programador profissional. Pensei em utilizar o título "Profissional Competente", mas acabei por concluir que seria um pleonasmo. Afinal, se é profissional, é competente. Os outros não competentes usualmente classifico como amadores.

Costumo utilizar uma imagem para representar cada post. Como falamos em profissionalismo, resolvi utilizar a foto de Edsger Wybe Dijkstra, considerado por muitos como o primeiro programador competente. É dele uma de minhas citações favoritas, apresentada quando um pesquisador lhe perguntou sobre qual tópico estudar:

"Only do what only you can do".

Traduzindo literalmente:

"Faça somente o que somente você pode fazer."

A ordem das postagens é aleatória, ditada pela inspiração do momento. Isto não faz desta definição a mais, nem a menos importante.

Sempre disse aos meus alunos e a quem trabalhou comigo que saber inglês em nossa profissão é fundamental. Dominar a língua inglesa não é precondição para estar empregado na área de tecnologia. Afinal, a suposta carência por mão-de-obra é tão grande que até os amadores têm seu lugar. Mas é precondição sim para ser um programador profissional.

Gosto muito de uma frase que o Bruno Souza (o JavaMan) utilizou em uma de suas palestras aqui em Maringá: "Pra você que trabalha na área de tecnologia, português é sua segunda língua (inglês é a primeira)". Recado dado na medida exata de importância.

Os bons livros são todos escritos em inglês. Depois de muito tempo, apenas alguns destes livros são traduzidos (e normalmente a tradução deixa a desejar). Não conseguir ler os bons livros disponíveis já alija qualquer programador de informações importantes e necessárias para tornar-se profissional. O mesmo se aplica a quaisquer artigos, sites e revistas. Alguns teimosos vão contra-argumentar: "mas para estes casos há o Google Translator". Acreditem: não é a mesma coisa.

Ao participar de fóruns de discussão e eventos você possui a oportunidade de dialogar e trocar idéias e informações com pessoas fantásticas. Estas pessoas advém de diversos lugares do mundo, mas certamente todas falam inglês. Entendam uma coisa: inglês é a lingua franca do mundo da tecnologia. É no mínimo "chato" participar de grandes eventos e ficar "de lado" porque "não sabe inglês".

Ler documentação de projetos? Participar de projetos open-source? Trabalhar em equipes geograficamente distribuídas? Conseguir os melhores projetos? Obter os melhores empregos? Para todas estas situações vocês precisarão do inglês.

Para ser um programador profissional é preciso muito estudo e acesso à muita informação. Esta informação está em inglês. Nunca é tarde para aprender. Aliás, antes agora do que mais tarde. Novamente: quem quer acha um meio; quem não quer, acha uma desculpa. Bons estudos.

Nós NÃO precisamos de mais programadores

noreply@blogger.com (Edson Yanaga) — Tue, 22 May 2012 13:31:00 +0000

Não, nós não precisamos de mais programadores.

Parece contraditório, no mínimo. Afinal, é bastante comum ouvirmos autoridades apregoando em discursos e reportagens que o déficit de programadores, no Brasil, é de 70 mil programadores/ano. Nos EUA, em torno de 200 mil programadores/ano. Mas nunca recebi uma explicação de como este número foi calculado.

O "déficit" de programadores no Brasil e no mundo é utilizado como motivação para se investir mais na formação de mais programadores. O investimento é correto. O foco é que está errado.

Novamente, nós não precisamos de mais programadores. Precisamos de programadores melhores. Precisamos de profissionais competentes.

Citarei um trecho de uma entrevista com David Lorge Parns, ACM Fellow:

What is the most often-overlooked risk in software engineering?

Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

Traduzindo literalmente:

Qual é o mais desapercebido dos riscos em engenharia de software?

Programadores incompetentes. Existem estimativas de que o número de programadores necessários nos EUA ultrapassa os 200.000. Estas estimativas são enganosas. Não é um problema de quantidade; nós temos um problema de qualidade. Um mau programador pode facilmente criar dois novos empregos por ano. Contratar mais maus programadores só vai aumentar a percepção de necessidade deles. Se tivéssemos mais bons programadores, e pudéssemos facilmente identificá-los, precisaríamos de menos, não de mais.

Infelizmente encontrar programadores que sejam profissionais competentes é algo raro. Programar não é somente "fazer funcionar". É fazer bem feito. É produzir código testado. É utilizar técnicas e ferramentas adequadas para resolver o problema.

É fácil perceber porque um mau programador cria dois novos empregos por ano. Um mau programador (que é a regra generalizada) produz código mal feito. Um código mal feito precisa de outros dois maus programadores para ser mantido. E assim continuamos numa progressão geométrica.

Vamos atacar o problema correto. Nossa meta deve ser transformar as pessoas com potencial em profissionais competentes e retirar o restante do mercado. E você? De que lado está? De que lado quer ficar?

A fragilidade da nossa infraestrutura de comunicação

noreply@blogger.com (Edson Yanaga) — Thu, 26 Apr 2012 21:55:00 +0000

Ontem, 25/04/2012, foi um dia que espero que continue atípico. Devido a um rompimento de cabos de fibra óptica, os estados do Paraná, Santa Catarina, Rio Grande do Sul e parte de São Paulo ficaram com a conectividade à Internet limitada ou interrompida, além de sem telefone e celular. (Mas, por incrível e irônico que seja, o meu Twitter funcionava...)

Quem conhece um pouco da história da Internet sabe que ela foi preparada para circunstâncias de guerra, permitindo uma comunicação continuada mesmo que vários enlaces e roteadores fossem comprometidos. Se uma parte da rede ficasse indisponível, automaticamente o tráfego seria desviado para uma rota alternativa para chegar ao destino. A qualidade poderia ser afetada, mas a comunicação não seria interrompida.

Tudo muito bacana na teoria, mas evidente que o modelo de continuidade pressupõe a existência de rotas alternativas. Não é o que testemunhamos com o incidente de ontem. Se um único segmento de fibra óptica rompido provocou toda essa indisponibilidade, imagino o quão precária e deficitária é a nossa infraestrutura de comunicações no Brasil.

Suponho que por falta de planejamento ou avareza não havia e não há nenhum enlace de contingência ligando os estados afetados ao restante do mundo. Esta alternativa já é dolorosa o suficiente pra mim. Pois a outra hipótese, a de que havia um enlace alternativo - mas que foi enterrado junto com o enlace principal - é muito pior: o único termo que me vem à cabeça chama-se burrice (mas com o devido respeito aos equinos). Escolho acreditar na primeira alternativa.

Temos realmente que evoluir muito. Pagamos absurdos por conexão à Internet, mas como provado, a qualidade de serviço que recebemos não está à altura do preço.

E pra finalizar: GVT, instale um enlace de contingência passando por outra rota, por favor...

Estabilidade do build utilizando o Maven

noreply@blogger.com (Edson Yanaga) — Fri, 20 Apr 2012 13:32:00 +0000

Maven: A person who has special knowledge or experience; an expert.

O Maven é uma ferramenta de build fantástica. Não é perfeita, pois como estamos cansados já de discutir, não existe esse conceito de ferramenta, linguagem etc perfeito. Contudo eu particularmente considero que 95% das pessoas que reclamam do maven é porque não sabem utilizá-lo. Os outros 5% talvez tenham razão.

Algo que contribui e muito para as reclamações sobre o maven são a infinidade de poms de dependências mal feitos (provavelmente criados pelos 95%). Infelizmente, eles são muito mais comuns do que o tolerável.

Outro problema crítico para qualquer equipe de software é a estabilidade do build. O maven "baixa" as suas dependências através da Internet - por padrão através de repositórios públicos. Se o seu projeto é "novo", sem problemas. As dependências estarão lá. O problema é garantir que estas mesmas dependências estarão presentes daqui a 2, 3, 5 ou 10 anos. O que aconteceria se alguém resolvesse "apagar" aquelas dependências (já que os repositórios são controlados por terceiros, e não por você)? Resultado: build quebrado.

Para nossa sorte há uma categoria de software que resolve os "problemas" do maven acima citados: os gerenciadores de repositório. Nesta categoria enquadram-se o Nexus e o Artifactory. O Nexus é mais antigo, e tenho trabalhado já há um bom tempo com ele. O Artifactory é mais recente e em 2011 ganhou um Duke Award da Oracle. Algumas comparações baseadas na minha experiência:

O Nexus, por ser mais antigo, é mais popular. O ~~repositório central do próprio maven passou a utilizá-lo recentemente~~. O mecanismo de busca do repositório central do maven utiliza-o (Obrigado ao @aldrinleal pela correção!)
O Nexus possui um consumo de memória menor. O heap da minha instalação é de 64MB. No site do Artifactory recomenda-se 300MB.
O Artifactory é transacional. Isso faz com que qualquer atualização dos repositórios seja bem sucedida ou não sucedida. Não há estado inconsistente - que (dizem, não sou testemunha) ocorre com o Nexus (o Nexus utiliza somente arquivos).
O Nexus utiliza somente o sistema de arquivos. O Artifactory precisa de um banco de dados (por ser transacional).
O Nexus armazena cópias repetidas do mesmo arquivo que existem em repositórios diferentes. O Artifactory armazena somente uma e a referencia em repositórios diferentes (menor consumo de espaço).

Ambos funcionam bem. Escolher um ou outro passa a ser uma questão de gosto. O importante é escolher um e utilizá-lo. Mas como estes gerenciadores resolvem o problema do maven?

Se há um pom.xml mal feito num repositório público, você mesmo pode corrigi-lo e fazer o upload no seu Nexus ou Artifactory. Assim, os seus projetos utilizarão o seu pom.xml corrigido. Claro que você pode e deve contribuir sua correção para os autores de um projeto livre, mas se eles irão aceitar suas "correções" depende deles, e não de você.
O Nexus ou o Artifactory realizam o download das suas dependências de repositórios externos e as salvam em seu repositório privado. Desse modo, mesmo que alguém desapareça com o repositório central do maven, ao menos as dependências do seu projeto estarão seguras no seu repositório local, garantindo a estabilidade do seu build.

Conclusão? Qualquer equipe de software consciente que trabalhe com o maven tem que utilizar um gerenciador de repositório. Escolha o seu.

O fim do jornal e a resistência fútil

noreply@blogger.com (Edson Yanaga) — Thu, 19 Apr 2012 21:48:00 +0000

Sim, o jornal morreu. Alguns moribundos ainda andam por aí, mas diminuem à medida em que os últimos amantes dos folhetins impressos também padecem.

Obviamente o título sensacionalista deste post relaciona-se com o papel jornal, e não com o jornalismo. O jornalismo como fonte de informações transformou-se bastante com o fim do papel - não pela sua falta, mas pelo fato de que ignorantes pretensiosos como eu passaram a também produzir informações que pudessem ser lidas por quem se interessasse. E acredite, por mais improvável que seja, há quem se interesse. Imagino que seja o seu caso, estimado leitor.

O modelo de negócios dos jornais nunca foi "vender papel", e sim publicidade e classificados. Hoje em dia o Google costuma abocanhar boa parte das verbas publicitárias e sites de classificados já preenchem um pouco da demanda provocada pelos internautas. A questão é: como manter a receita do negócio sendo que os consumidores de informação estão migrando para mídias digitais? O natural seria tentar criar atrativos para reter os leitores e transferi-los para a mídia digital (antigamente eu falaria Web, mas tablets e smartphones novamente mudaram o panorama).

Um jornal local da cidade de Maringá (onde resido atualmente) resolveu seguir o caminho contrário. Seu conteúdo "impresso" estava disponível em seu portal para quem se interessasse por acessá-lo. Recentemente, provavelmente devido às quedas nas vendas de papel jornal, decidiu por fechar o seu conteúdo online e restringi-lo somente para assinantes. Resultado? Eu simplesmente parei de acessar o portal, pois o pouco conteúdo local produzido que me interessava já não me estava mais disponível. Imagino que outros leitores tenham feito o mesmo e também passaram então a acessar outros sites que disponibilizassem informações locais.

Desse jeito, esses poucos moribundos desaparecerão antes do esperado...

Mais dados sobre a redução dos custos com cloud computing

noreply@blogger.com (Edson Yanaga) — Thu, 29 Mar 2012 19:18:00 +0000

Muitas empresas ainda não enxergam a significativa redução de custo obtida através do uso do cloud computing (computação em nuvem). Além de trocar o CAPEX (Capital Expenditures) - investimento de capital por OPEX (Operational Expenditures) - despesas operacionais, o tamanho do investimento/despesa é muito menor graças ao ganho de escala.

Dados do Uptime Institute informam que um único servidor de 1U durante um ano pode resultar num gasto de US$ 500 em energia elétrica, US$ 500 em licenças de sistema operacional e mais US$ 1500 em custos de manutenção do hardware. Resultado: US$ 2500/ano. Este é um valor que muitos empresários/diretores não calculam quando comparam o modelo on-premise com o cloud computing.

Eu mesmo já migrei todos os meus serviços há mais de 4 anos, e hoje não enxergo outra forma de se utilizar computação. Definitivamente quem não se aproveita disso está ficando pra trás.

Eclipse, OpenJDK 7 e AJDT no MacOSX

noreply@blogger.com (Edson Yanaga) — Sun, 04 Mar 2012 13:34:00 +0000

O lançamento do Java 7 está quase fazendo aniversário e eu ainda não havia me "atualizado" para esta nova versão. Boa parte da culpa estava na não-disponibilidade do OpenJDK 7 para MacOSX, ao menos não na versão estável.

Depois de muito aguardar, acreditei que o OpenJDK estava estável o suficiente para utiliza-lo. Muitos relatos da comunidade Java no mundo colaboraram para esta opinião.

Passo-a-passo da migração:

Instalar o OpenJDK 7 para MacOSX (obtido em http://jdk7.java.net/macportpreview/). Siga as instruções na página.
Atualizar a versão do Java de 1.6 para 1.7 tanto no maven-compiler-plugin quanto no aspectj-maven-plugin (esse último somente se você utilizar de fato o AspectJ) do seu pom.xml (assumindo que você utiliza o maven).
Atualizar a versão do AspectJ para a 1.7.0.M1 (novamente, somente se você utilizar o AspectJ).
Atualizar a versão do AJDT do Eclipse para uma versão que possua suporte ao Java 7. É necessário se você utilizar o JDT Weaving do Eclipse (como é o meu caso). Pra quem gosta de arriscar e quiser utilizar o update site, adicione a URL http://download.eclipse.org/tools/ajdt/37/dev/update. Entretanto, eu recomendo baixar o zip da atualização manualmente para não ter o dissabor de num update futuro as coisas deixarem de funcionar. A versão que eu utilizei e que afirmo que funciona é a http://www.eclipse.org/downloads/download.php?file=/tools/ajdt/37/dev/update/ajdt-e37x-20120302-1100.zip

Encontrei muitos relatos na Internet que mostravam o Java 7 funcionando no Eclipse no MacOSX, mas nenhum relatava a configuração com o AspectJ. Tive que descobrir sozinho. E aproveito e reporto aqui para que outras pessoas não percam o mesmo tempo que eu perdi.

Nota: usuários do Spring Roo certamente utilizam o AspectJ em seus projetos. Usuários do Spring que utilizam a anotação @Configurable provavelmente também.

O que ficou...

noreply@blogger.com (Edson Yanaga) — Sat, 25 Feb 2012 20:38:00 +0000

Há 12 anos estávamos eu e meus amigos de turma nos formando em Ciência da Computação na Universidade Estadual de Maringá (UEM). Em nossa colação de grau tive a honra de ser o orador geral de todos os formandos da formatura conjunta da UEM. No discurso que preparei (do qual lembro de apenas alguns trechos, infelizmente) optei por encerrá-lo adaptando um poema de Fernando Sabino. Nesse clima de nostalgia, recordo-me destas palavras:

"De tudo ficaram três coisas:
A certeza de que estamos apenas começando,
A certeza de que é preciso continuar e
A certeza de que podemos ser interrompidos antes de terminar.
Fazer da interrupção um caminho novo,
Fazer da queda um passo de dança.
Do medo uma escada,
Do sonho uma ponte,
Da procura um encontro.
Fica a promessa do reencontro,
Fica o desejo de boa sorte,
Fica a vontade de que lutes e venças!"

Creio que são boas palavras de inspiração. É o que fica para todos nós...

Crédito da foto ao Paulo Roberto Crestani Júnior.

Utilizando o iptables ou ngninx para responder requisições na porta 80 como usuário não-root

noreply@blogger.com (Edson Yanaga) — Sat, 25 Feb 2012 19:16:00 +0000

Por questões de segurança jamais devemos permitir que serviços num servidor unix sejam executados como root. Isso permitiria que uma falha nesse serviço (e como desenvolvedores sabemos que essas falhas realmente acontecem) comprometesse todo o sistema.

Pelas mesmas restrições de segurança, não é permitido que usuários não-root escutem (realizem o bind de sockets) em portas inferiores à 1024. A questão é: como então executar um serviço (HTTP, no nosso exemplo) na porta 80 como usuário não-root?

Utilizarei o HTTP - que roda na porta 80 - como exemplo, pois provavelmente é o caso de uso mais popular. Imagino que você precise que um Tomcat, um Glassfish ou um JBoss seja executado no seu servidor. Normalmente estes serviços são inicializados na porta 8080. Apresento então duas solução possíveis:

Caso você possua somente um serviço e um domínio, pode utilizar o redirecionamento através do iptables.
Caso você possua vários serviços em portas diferentes e possivelmente vários domínios (virtual hosts) no mesmo servidor, utilize o nginx como proxy. (Sim, é possível fazer o mesmo com o Apache e mod_proxy ou AJP, mas o ngnix provou-se uma solução mais fácil, rápida, prática e com menor consumo de memória).

Exemplo de configuração com o iptables redirecionando as requisições na porta 80 para a 8080:

Loading ....

O REDIRECT de PREROUTING atende as requisições externas, e o REDIRECT de OUTPUT serve para redirecionar as requisições originadas do próprio servidor que estejam direcionadas à porta 80.

Exemplo de configuração com o ngninx atuando como proxy de requisições na porta 80 e redirecionando para a porta 8080:

Loading ....

Com esta configuração do ngnix, basta duplicar as linhas acima com as alterações convenientes e você pode ter dois Tomcats sendo executados no mesmo servidor nas portas 8080 e 8081, por exemplo, e redirecionar o myserver.mydomain.com para a porta 8080 e o myserver2.mydomain.com para a porta 8081. Dois virtual hosts, cada um num Tomcat diferente, no mesmo servidor.

Spring 3.x Profiles e configurações diferentes do log4j

noreply@blogger.com (Edson Yanaga) — Wed, 22 Feb 2012 18:40:00 +0000

Uma das mais aguardadas e bem vindas novas funcionalidades do Spring Framework 3.x são os bean profiles, permitindo que você configure grupos de beans e escolha qual(is) destes grupos você deseja ativar durante o desenvolvimento, produção, teste etc. Outra boa novidade é o Java Configuration, permitindo que você configure os seus contextos do Spring utilizando somente código Java ao invés dos famigerados arquivos XML.

Nem tanto ao céu, nem tanto ao inferno. XML não é algo ruim. Bem usado, é uma ferramenta valiosa. Mas é fácil exagerar também. De antemão já adianto que o refactoring de arquivos de configuração do Spring que utilizam o Java Configuration é bem mais simples.

Algo que me incomodava no log4j era o fato dele ser configurado através de arquivos disponíveis no classpath como log4j.properties ou log4j.xml. Isso tornava trabalhoso o ato de utilizar configurações diferentes para ambientes diferentes (normalmente utilizando o maven para copiar o arquivo escolhido dependendo do profile utilizado).

Nada como a maravilha do software livre. Analisando o código-fonte, vi que utilizar arquivos de configuração do log4j diferentes para ambiente diferentes é mais simples do que eu pensava.

Com a configuração abaixo você pode utilizar dois arquivos de configuração do log4j: um para teste/desenvolvimento que imprima no console, e outro para produção que grave num rolling file e/ou envie notificações através do SNS, por exemplo.

Loading ....

Notificações do log4j através do Amazon SNS

noreply@blogger.com (Edson Yanaga) — Mon, 20 Feb 2012 16:51:00 +0000

Como desenvolvedores e devops muitas vezes precisamos ser notificados de erros que ocorrem nas aplicações para podermos resolvê-los com o mínimo de downtime e transtorno possível aos nosso clientes e usuários.

Estes "erros" (condições anormais de uso) são registrados no sistema através de loggers. Se você desenvolve software e não utiliza logging, então o problema é mais embaixo. Imagino que o seu código simplesmente deixa o stacktrace das exceções "estourar" na cara do usuário. Perdoe-me, mas você não é profissional. Você finge que programa, e o pior: há quem acredite.

A mais popular implementação de logging em Java é o log4j. Normalmente além do logging para arquivo ou console do log4j, alguns desenvolvedores utilizando o SMTPAppender para enviar e-mails de notificação quando algum WARN é registrado na aplicação.

Utilizar o SNS, serviço de notificações da Amazon, é uma alternativa mais eficiente do que enviar e-mails pois:

Permite o baixo acoplamento entre o emissor das notificações (o logger) e seus assinantes (possivelmente os e-mails dos desenvolvedores e devops).
Num ambiente com vários servidores rodando a mesma aplicação seria uma situação comum em caso de erro todas estas instâncias enviarem o mesmo e-mail, lotando a caixa de e-mail dos assinantes das notificações.

Pensando nisso resolvi criar uma biblioteca (enorme: 3 classes por enquanto) que permite utilizar o SNS como Appender do log4j: https://github.com/insula/log4j-sns

Entre outras benesses está o fato dele implementar um "quiet period" padrão de 15 minutos, evitando que você receba mais de uma notificação com o mesmo stacktrace dentro do intervalo de 15 minutos.

Num ambiente de cloud computing com múltiplas instâncias de uma mesma aplicação provavelmente você desejará implementar uma assinatura HTTP para lidar com notificações repetidas ao invés de ficar recebendo o mesmo e-mail de várias instâncias diferentes. Quem sabe não vale a pena criar um serviço e disponibilizá-lo online? Já vejo múltiplas situações em que isso seria útil.

Utilizando o Janrain com o Spring Security 3.1.x

noreply@blogger.com (Edson Yanaga) — Wed, 08 Feb 2012 23:49:00 +0000

Para quem ainda não conhece, o OpenID é um protocolo que permite que você se autentique num site/serviço utilizando as credenciais (normalmente login/senha, mas também poderia ser um certificado digital, por exemplo) de um terceiro confiável.

Esta iniciativa surgiu para tentar eliminar o problema de ter que guardar e lembrar de centenas (ou quase milhares para alguns) de combinações de login e senha diferentes. Assumo também que você, usuário consciente, não utiliza o mesmo login/senha para mais de um serviço. Pois caso positivo, se alguém descobrir a sua combinação - que presumo deva ser trivial - terá acesso a todos os sites e aplicações nos quais você está cadastrado.

Com o OpenID você pode delegar a autenticação da sua aplicação para um provedor de OpenID como o Google, Facebook, Twitter etc. Assim você pode utilizar o sistema de autenticação destes provedores ao invés de criar um próprio.

O Janrain é um serviço que integra vários provedores diferentes de OpenID, permitindo que você desenvolva sua aplicação somente com o Janrain e passe a utilizar vários provedores de OpenID rapidamente.

Para facilitar a vida de quem utiliza a excelente biblioteca de autenticação e autorização spring-security, criei um projeto LGPL que integra o Janrain com o spring-security. De bônus, já vem com componentes JSF2 prontos para usar. Podem conferir em https://github.com/insula/spring-security-janrain

Continuo aqui. E extremamente feliz em estar vivo!

noreply@blogger.com (Edson Yanaga) — Wed, 01 Feb 2012 00:21:00 +0000

Tudo começou com uma "torção" no joelho, há 16 dias - um domingo. Parecia algo mais sério, pois já havia torcido o joelho antes e a dor desta vez foi algo bem maior - comparável ao evento de quebra de tornozelo que tive. Gelo e anti-inflamatório. Agendei uma consulta com um ortopedista renomado em cirurgias do joelho pois desta vez acreditei que teria que opera-lo. A consulta ficou somente para a segunda-feira da próxima semana.

Durante estes oito dias caminhei com muletas e minha panturrilha estava bastante inchada, e dolorida. A sensação de dor parecia com uma cãimbra bem forte; motivo pelo qual tomei muita água de coco e comi várias bananas. A dor passou e com isso concluí erroneamente que tratava-se de cãimbras mesmo.

Já na segunda-feira da semana seguinte, fui ao ortopedista. Tirei um raio-x e nada de fratura. Como o joelho estava bastante dolorido, tive que fazer uma ressonância magnética. Citei as dores e o inchaço na panturrilha ao ortopedista, que prontamente respondeu que não era normal e que talvez devesse ir consultar-me com um angiologista (especialidade que trata do sistema vascular).

Realizei o exame de ressonância magnética, e como o laudo ficaria pronto na quarta-feira, decidi que o esperaria para então decidir o que fazer. Com o laudo na mão, agendei o retorno no ortopedista, que ficou somente para a terça-feira da semana seguinte. Não houve tempo.

No dia seguinte acordei com a panturrilha e o tornozelo bastante inchados. Tentei trabalhar (sentado), mas as dores tornaram-se insuportáveis. Chamei minha esposa, que vendo a situação, imediatamente tomou a atitude de levar-me à emergência do pronto-socorro. Antes disso resolvemos ligar para o ortopedista para tentar obter alguma orientação. Infelizmente ele estava indisponível, em cirurgia. Minha esposa explicou a situação à secretária, que ficou de dar um retorno. Nem cinco minutos depois, o ortopedista já ligava de volta.

Ao explicar minha situação, o ortopedista solicitou que eu fosse com urgência a um angiologista. Como não conhecia nenhum, solicitei uma indicação. Ele me indicou uma clínica com vários angiologistas, e pediu para que eu demandasse uma consulta com urgência, e que informasse que seria a pedido dele. Fui prontamente atendido e percorremos o centro de Maringá numa quinta-feira chuvosa ao meio-dia (o que obviamente demorou mais do que gostaríamos) rumo à clínica.

Chegando na clínica o angiologista me atendeu rapidamente e num exame clínico explicou que talvez não fosse uma trombose (a situação temida), mas mesmo assim solicitou um ecodoppler (ultrassom) de emergência.

Mais uma jornada rumo à outra clínica. Fui rapidamente atendido para o exame. Inicio o exame e o médico radiologista em silêncio e de cara fechada. Finalizado o procedimento, pergunto se havia algo de estranho. É quando ouço a resposta: "Você está com uma trombose grave, vai levar este exame para o seu angiologista agora pois ele vai lhe internar no hospital com urgência."

Estranhei a confirmação da trombose, pois sempre imaginei como doença de mulheres idosas, obesas, diabéticas etc. Enquanto minha esposa levava o exame ao angiologista e eu aguardava dentro do carro, pude procurar no Google através do meu iPhone sobre "trombose venosa profunda". Foi aí que percebi a minha situação: "Ih, f*d*u".

Não sei quantas veias tem-se na perna, mas eu estava com quatro veias (das grandes, suponho) com trombos (coágulos) impedindo a passagem de sangue. Estava tudo coagulado da virilha até o tornozelo. Ou seja, situação gravíssima com risco de morte iminente. Pelo que o Google me alertou, a complicação era a possibilidade de uma embolia pulmonar a qualquer momento. Esta situação costuma ser fatal.

Durante a rápida viagem da clínica até o hospital, minha esposa tentou "distrair-me" falando das sequelas que eu teria na perna graças à trombose. Mas eu já sabia do risco que estava correndo. E pensei (ironicamente): "Que bom, se eu sobreviver, minha perna vai ficar uma b*s*a". Contudo, um problema de cada vez. Primeiro resolvi pensar em viver pra contar a estória; o resto fica pra depois.

Chegando no Hospital Paraná, havia uma lista de internação. Você sabe que o seu caso é grave quando você "fura" a fila e é internado antes de todo mundo. Maravilha...

Mal entrei no quarto e já iniciou a rotina (durante os próximos seis dias) de medicações. Comprimidos, injeções na veia, exames de sangue e heparina sódica (uma injeção extremamente dolorida) ao redor do umbigo. Eu não tinha muita restrições quanto às injeções, mas essa injeção ao redor do umbigo mudou minha opinião...

A boa notícia é que de um dia para o outro, graças à medicação, minha perna desinchou bastante. Quando dei entrada no hospital minha panturrilha estava da largura da coxa, e meu tornozelo estava da largura da panturrilha. Meus dedos estavam todos "unidos". Para critério de comparação: eu costumo calçar um Croc's bem larguinho para ficar confortável. Deve ter pelo menos 2cm de sobra. Meu pé estava tão inchado que não entrava no Croc's.

A medicação leva de 4 a 5 dias para fazer o efeito. Durante este período meu risco de morte continuava alto, mas diminuía à medida em que o tempo passava. Meu médico mesmo relatou: você teve muita sorte. "A sorte te protegeu até agora". Eu provavelmente acredito que foi outra coisa. Mas não deixa de ser muita "sorte" o fato de não ter morrido.

No 5.o dia de internação, quando já esperava ter alta, acordei meio "indisposto". Talvez culpa das bolachinhas amanteigadas que a namorada do meu irmão trouxe para me "alegrar". Mea culpa. Eu adoro doces, e depois de quase uma semana de abstinência eu acabei comendo praticamente a caixa inteira sozinho durante a noite. Relatei minha indisposição à enfermeira, o que bastou para ligarem o "alerta vermelho". Oxigênio e em menos de 5 minutos o médico já estava do meu lado fazendo perguntas e a enfermeira colhendo exames. Alarme falso. O exame mostrou que provavelmente era só uma indisposição estomacal. Nada de embolia.

Fiquei sob "vigilância" dos médicos e enfermeiros durante todos estes dias. Mas sou muito agraciado por poder estar vivo ainda para poder relatar esta estória. Hoje, terça-feira, tive alta. Meu risco de morte já deve estar próximo de somente 1%. Estou bastante cansado, continuo tendo que tomar comprimidos e a injeção dolorida, tenho que usar uma meia cinta-liga de alta compressão, minha perna ainda dói e não posso ficar de pé ou andando por aí. Mas estou extremamente feliz! Um grande agradecimento a todos os amigos que ficaram preocupados. Já deixo também o alerta: se sentirem dores na panturrilha sem muita explicação e um certo inchaço, corram para o angiologista antes que seja tarde! Pra mim, quase foi tarde demais.

Vídeo do Agile Tour 2011: Tirando o código a limpo

noreply@blogger.com (Edson Yanaga) — Fri, 20 Jan 2012 02:06:00 +0000

Obrigado ao Juliano Ribeiro pela gravação, codificação e disponibilização no YouTube!

Realmente acho que tenho que melhorar bastante como palestrante, mas tenham certeza de que a minha intenção sempre é a melhor possível.

Como assinar uma applet ou jar

noreply@blogger.com (Edson Yanaga) — Fri, 20 Jan 2012 01:45:00 +0000

Muitas vezes precisamos assinar o jar de uma applet para que o Security Manager da JVM permita a execução de determinadas ações fora da sandbox. Não é nada difícil, mas pra quem precisa de uma "receita de bolo", apresento duas opções: utilizando a linha de comando ou através do maven.

Através da linha de comando:

Loading ....

Através do maven, gere primeiro a sua keystore com o 1.o comando do gist acima no raiz do seu projeto. Depois pode executar o package normalmente:

Loading ....

Nossa maltratada e querida Língua Portuguesa

noreply@blogger.com (Edson Yanaga) — Sat, 14 Jan 2012 01:36:00 +0000

Gostaria de refletir um pouco sobre um "sofrimento" que me atormenta todos os dias. Sou uma pessoa da área tecnológica, e o aprendizado que tive da nossa língua pátria, o português, resume-se ao conteúdo acumulado até o ensino médio. Creio que isto me coloca no mesmo patamar que boa parte das pessoas.

O meu "tormento" é causado pela enorme (e infelizmente exponencialmente crescente) quantidade de material escrito de forma impressionantemente errada. Isto me faz pensar se o problema está em mim, que primo pela forma correta e "sofro" quando vejo essa infinidade de erros de grafia e concordância; ou se o problema está nos "outros" que tiveram o mesmo nível de educação que eu, e escrevem muito mal. Notem que quando digo "tiveram o mesmo nível de educação que eu" (que não é muito, como já apresentei) já excluo a parcela das pessoas com menor nível de instrução, já que não é razoável cobrar de alguém algo que não lhe foi ensinado.

Já abro aqui uma exceção e digo que considero normal o "internetiquês" utilizado em rápidas conversas e interações. O que me preocupa não são os "vcs", "t+" e "tbm"; mas sim o restante das palavras.

É um consenso que consideramos o nível de educação decrescente nos últimos anos. Mas vejo também pessoas mais velhas escrevendo errado (muitos professores, inclusive). A minha dúvida é: o aprendizado do português tem decaído nos últimos anos? Ou é a Internet que permite que esse enorme contingente de incultos se expresse de modo errado? Pois é possível que as pessoas escrevam realmente mal (desde sempre), mas como antes não era possível elas massificarem esta ignorância, simplesmente não se percebia.

A expressão "nem escrever direito sabe, imagine o resto" tem validade? Escrever errado invalida o argumento de alguém? É necessário escrever corretamente? Ou a forma correta da nossa língua virou item de museu?

Vale uma reflexão? Espero que sim...

A hora e vez do NOSQL (Not Only SQL): Persistência Poliglota

noreply@blogger.com (Edson Yanaga) — Tue, 03 Jan 2012 13:44:00 +0000

A primeira vez que me deparei com o termo NoSQL imaginei que ele se referia a "No SQL": nada de SQL, uma ruptura com o nosso modo relacional de pensar em persistência. Como todo conceito revolucionário, causa muita resistência na maioria das pessoas por trazê-las fora da "zona de conforto".

Uma releitura necessária sobre o assunto me trouxe o acrônimo NOSQL como "Not Only SQL": não somente SQL. Esta sim, uma definição muito mais palatável e apropriada sobre o assunto. O "Not Only" pressupõe a convivência (pacífica, espero) entre tecnologias consolidadas e a inovação. Chamo de inovação, mas vale enfatizar que estas soluções já encontram-se num nível bastante avançado de maturidade.

NOSQL não é a solução para todos os problemas. Mas trouxe à luz da discussão uma máxima da computação que é "utilizar a ferramenta correta para o problema correto". Não consegui rastrear o autor original, mas esta citação é uma de minhas favoritas:

"A good algorithm is like a sharp knife - it does exactly what it is supposed to do with a minimum amount of applied effort. Using the wrong algorithm to solve a problem is trying to cut a steak with a screwdriver: you may eventually get a digestible result, but you will expend considerable more effort than necessary, and the result is unlikely to be aesthetically pleasing."

Ou numa tradução literal:

"Um bom algoritmo é como uma faca afiada - faz exatamente o que deve ser feito com uma quantidade mínima de esforço. Utilizar o algoritmo errado para resolver um problema é como tentar cortar um bife com uma chave de fenda: você eventualmente pode conseguir um resultado digerível, mas vai gastar muito mais esforço do que o necessário, e o resultado não será esteticamente agradável".

Como todo conceito "novo" muita coisa vai mudar antes de se consolidar, mas baseado na minha experiência no assunto, o que eu posso recomendar é:

Se os seus dados são homogêneos, com poucos relacionamentos entre entidades e numa grande quantidade: use um banco de dados. O modelo relacional foi feito pra isso.
Se os seus dados possuem muita variação entre um e outro (o que num banco de dados implicaria em muitas colunas vazias ou em muitos relacionamentos com outras tabelas): use uma base de documentos como o MongoDB.
Se os seus dados possuem muitos relacionamentos com outras entidades (com possível necessidade de geolocalização): use uma base de grafos como o Neo4j.
Se os seus dados são do tipo chave-valor (key-value) e você precisa computar grandes quantidades (voláteis) desses dados com alto desempenho: use uma base de dados chave-valor em memória como o Redis.
Se os seus dados são do tipo chave-valor (key-value) e você precisa persisti-los: use uma base de dados chave-valor persistente como o Riak.

Farei uma menção honrosa para as situações em que você precisa de uma base de dados confiável, de altíssimo desempenho e transacional: use o Prevayler ou o Disruptor para prevalência de objetos.

Vale ressaltar que a persistência poliglota pressupõe a coexistência destas diferentes bases de dados na mesma aplicação. Avalie e considere a utilização de mais de uma base de dados se for adequada ao seu problema. Mas não caia na tentação de "vou usar o XXX porque é bacana". É o mesmo pecado de se utilizar um Design Pattern só porque ele é "bonito". Tem que resolver um problema.

Todo essa excitação ao redor do NOSQL também está relacionada, claro, ao conceito de BigData. Todas estas bases de dados alternativas foram construídas com a premissa de tratar imensos volumes de dados que bancos de dados relacionais não estão preparados para lidar.

Avaliem todas estas novas alternativas e estejam preparados para, no problema certo, utilizarem a base de dados certa. Boa sorte!

O que o sistema de educação da Finlândia pode nos ensinar?

noreply@blogger.com (Edson Yanaga) — Sat, 31 Dec 2011 20:42:00 +0000

Li esta semana um artigo no mínimo intrigante que tenta demonstrar as diferenças entre o sistema educacional americano e o sistema educacional finlandês. Vou listar alguns pontos pois vale a pena a reflexão:

O sistema americano é baseado na "excelência", na competência; o finlandês, na equidade entre os indivíduos.
As melhores escolas americanas são particulares e pagas; todas as escolas finlandesas são públicas e gratuitas (da creche ao doutorado).
O sistema americano é falido, seus alunos obtém resultados no máximo medianos; os finlandeses estão há anos entre os melhores (senão o melhor).
Para os americanos, a competição entre as escolas torna-as melhores; para os finlandeses, o acesso e condições iguais a todos, independente de posição social, financeira ou geográfica, torna a educação melhor.

Todos os tópicos acima podem levar a conclusões diferentes, mas o item que mais me chama a atenção no texto é: os professores e diretores finlandeses são bem pagos, respeitados, prestigiados e lhes são delegadas responsabilidades.

Ultimamente vemos alunos que não podem ser reprovados, e a educação desmoronando no Brasil. Sinceramente creio que o fator que mais influencia o aprendizado dos alunos é a qualidade do professor. Coloque professores excelentes e bem preparados nas salas de aula, e teremos um salto na nossa qualidade de educação.

Veja a decadência no ensino básico brasileiro nas últimas décadas. Não é culpa do feminismo, mas é uma consequência. Há 40, 50 anos, a única profissão que uma mulher inteligente e bem sucedida poderia exercer na sociedade machista era a de professora. Ou isso ou dona-de-casa. Resultado: aquelas eficazes na tentativa de sair do trabalho doméstico representavam em sua boa parte as melhores mentes femininas disponíveis. Professoras de qualidade. Graças a isso tínhamos alunos com um desempenho satisfatório.

Comparemos com a situação atual. Sou professor também, mas perdoem-me os meus colegas atuais: ser professor costuma ser a última opção dos alunos que se formam nas faculdades. Aliás, eu garanto que os melhores alunos não se dedicam à docência. Há uma verdade escondida no rumor "não sabe fazer nada direito, vira professor". O resultado vemos nos jovens que formam-se por aí. E por que isto acontece? Muito trabalho, pouco dinheiro e nada de respeito.

Uma revolução na educação passa pela valorização dos professores. Pensem nisso e ajam.

Software é artesanal, exige criatividade e precisa de tempo!

noreply@blogger.com (Edson Yanaga) — Thu, 22 Dec 2011 20:04:00 +0000

Já tiveram a impressão que todo software que você avalia sempre é mais do mesmo? Frequentemente recebo alguns e-mails divulgando empresas de software da região. Sempre levado pela curiosidade, tento descobrir qual é o segmento em que a empresa atua e como é o software por ela ofertado. Fico pasmo em constatar que são todos iguais. Você olha e imediatamente se decepciona.

Software não é linha de produção. Software não é barraca de pastel, nem carrinho de cachorro-quente. Software exige criatividade. O vídeo acima demonstra de um modo absolutamente ilustrativo o que a pressão do tempo faz com a nossa capacidade criativa. Não me admira que todo software por aí seja igual. Todos são "produzidos" pelo mesmo "processo": cospe qualquer coisa aí que é pra ontem!

Este é um dos argumentos pelos quais as "fábricas de software" são uma falácia. Uma mentira criada por uma indústria. Mas este é assunto para outro post.

Quer um "oceano azul"? Quer um diferencial competitivo? Passemos a trabalhar mais com o cérebro do que com os músculos dos dedos. Comecemos por aí...

Software é muito mais que código

noreply@blogger.com (Edson Yanaga) — Wed, 21 Dec 2011 17:42:00 +0000

Atualmente os clientes e usuários não julgam o software que produzimos baseados em sua qualidade técnica. Realizar adequadamente atividades como levantamento de requisitos, escolha de ferramentas, codificação, gestão de projeto e obtenção de certificações são quesitos absolutamente indiferentes. Até porque na minha percepção isso é commodity.

Os clientes agora baseiam-se na experiência de uso que tinham antes, durante e depois de utilizar o nosso software. Devemos agradecer ou amaldiçoar a Apple pela experiência digital que ela trouxe às nossas vidas, e com ela, a tão comentada consumerização. Fato é que estamos muitíssimo exigentes com o software e os equipamentos que utilizamos. A expressão correta é "raising the bar".

Nós, programadores profissionais, devemos criar aplicações e prestar serviços que os clientes amem. Bem o oposto daquilo que é feito por aí que os clientes xingam. Para atender a este novo cenário temos que nos adequar e encarar que:

Software não é código; ele cria experiência de uso.
Equipes de desenvolvimento não são programadores; são criadores de experiências.
O talento técnico é o alicerce de tudo; mas grandes desenvolvedores devem ser experts em design e no negócio.
Processo não vale nada sem design; você só obtém pelo processo o que você concebeu, então é melhor fazer o design direito.
Software é uma jornada criativa, não um processo industrial como uma linha de produção. Sua metodologia deve maximizar o seu potencial criativo.

E eu não inventei nada disso. Quem percebeu esta realidade foi a Forrester Research.

Manifesto pelo Artesanato de Software

noreply@blogger.com (Edson Yanaga) — Mon, 19 Dec 2011 16:30:00 +0000

"Como aspirantes a Artesãos de Software elevamos o nível do desenvolvimento de software profissional ao praticar e auxiliar outros a aprender o ofício. Através deste trabalho passamos a valorizar:

Não somente software funcionando, mas também software bem feito.
Não somente responder a mudanças, mas também continuamente adicionar valor.
Não somente indivíduos e interações, mas também uma comunidade de profissionais.
Não somente colaboração com o cliente, mas também parcerias produtivas.

Ou seja, na busca pelos itens à esquerda descobrimos que os itens à direita são indispensáveis."

O manifesto original pode ser encontrado aqui: Manifest for Software Craftsmanship.

Não tenho palavras melhores para traduzir o meu sentimento e a minha motivação do que este manifesto. Depois de um período bastante desanimado, lembrei-me dele e me apeguei às suas ideias para renovar meu entusiasmo pela minha profissão: programador e consultor. Hoje sei que sou um defensor do código bem feito.

Vamos utilizar este manifesto para acabar com esta praga de "programadorezinhos" e "consultorezinhos" (sim, no diminutivo - pois são de uma pequenez tremenda) que se multiplicam por aí. Todos podemos ser profissionais. Ou como já disse Napoleão Bonaparte:

"Onde há uma vontade, há um meio".

Configuração do QueryDSL no m2e do eclipse

noreply@blogger.com (Edson Yanaga) — Sat, 17 Dec 2011 19:06:00 +0000

Esta dica é para os adeptos do QueryDSL, uma ferramenta fantástica para a criação de queries type-safe em Java para Hibernate, JPA, SQL, MongoDB etc.

A configuração do QueryDSL no eclipse funcionava sem problemas com a utilização do plugin m2eclipse, que era a integração do eclipse com o maven. Entretanto, com a liberação do m2e, que a partir de agora é o plugin oficial do maven para o Eclipse, o QueryDSL deixou de funcionar apropriadamente. O erro em questão é que o "target/generated-sources/java" que o plugin do QueryDSL gera deixou de ser adicionado aos "Source Folders" do Eclipse.

A solução é mais simples do que aparenta. Basta instalar este plugin que está disponível no github: https://github.com/ilx/m2e-querydsl

Ele configura o m2e para utilizar o QueryDSL corretamente.

Eliminar o débito técnico é uma obrigação, não uma opção

noreply@blogger.com (Edson Yanaga) — Sat, 17 Dec 2011 13:17:00 +0000

Durante a palestra do Klaus no Agile Tour 2011 em Maringá/PR, houve uma pergunta sobre "O que fazer quando o 'chefe' não permite que você 'gaste' um tempo do sprint para fazer a limpeza do código?" Discutiu-se um pouco sobre o assunto no evento, mas o próprio Klaus acabou reconhecendo no final que a conclusão foi uma "não-resposta".

Minha primeira reação à pergunta foi direta: minta. Ainda bem que não faço as coisas por impulso. Mentir quebraria um dos meus princípios fundamentais que é o da "verdade, doa a quem doer" e também o princípio prático do "mentir dá muito trabalho: dizer a verdade é infinitamente mais fácil". Desnecessário dizer que já angariei muita antipatia por causa destas atitudes, porém ninguém poderá jamais me acusar de ser falso.

Fazer "limpeza do código", também conhecido como eliminar o débito técnico não é uma opção. É uma obrigação de todo profissional. Não acredito que o "chefe" deve permitir que você faça ou não. Programadores devem faze-lo, doa a quem doer. Lembram do juramento de Hipócrates? "Não fazer o mal". Um médico não permitiria que um paciente tomasse uma dose de remédio que pudesse mata-lo. Programadores não permitem que o débito técnico aumente para não matar o software.

Se você é um programador, você (e não o seu "chefe") sabe o que é o melhor para o código. Use esse poder.

Se o seu "chefe" é adepto do micro-gerenciamento, provavelmente ele deve ficar olhando o gráfico de burn-down ou calculando a velocidade do sprint para medir a "produtividade" da equipe. O erro fundamental aqui trata-se da visibilidade dos números. Estimativas, velocidade e burn-down são informações da equipe e para a equipe. O "chefe" não deve ficar sabendo destes números. Mas se o seu "chefe" insistir em ficar acompanhando isso e você precisa eliminar o débito técnico, há uma solução simples. No próximo planning poker, dobre o número das cartas. Em cada tarefa, coloque o adicional de 100% para realizar a limpeza necessária. Você não estará mentindo, a velocidade não vai diminuir, o gráfico de burn-down vai continuar bonitinho, o seu "chefe" vai continuar indiferente, e o mais importante, você ficará feliz e satisfeito e o seu código, limpo.

Minha apresentação no Agile Tour 2011: Tirando o código a limpo

noreply@blogger.com (Edson Yanaga) — Wed, 14 Dec 2011 16:46:00 +0000

Tirando o código a limpo

View more presentations from Edson Yanaga

O Agile Tour provavelmente é a maior conferência sobre o tema "agilidade" em todas as suas edições no planeta. Aproveitando o sucesso, neste ano tivemos a primeira edição do evento em Maringá.

Confesso que superou as minhas expectativas. O nível técnico do evento foi muito bom. O público era bastante interessado (e com muitos conhecidos na platéia). Fiquei meio triste com a comunidade de desenvolvedores de Maringá, pois esperava o auditório lotado. Tanta gente reclama que não temos bons eventos na cidade, mas quando temos, não comparecem. Mas eu também sei que a época do ano não foi propícia para grandes públicos. Quem estuda, estava preocupado com as provas. E mesmo quem só trabalha já estava em ritmo de fim de ano: torrando o 13.o salário.

Parabéns ao Alexandre Nodari, Heitor Roriz, Objective (Ramon & CIA) e Klaus Wuestefeld pelas apresentações. Eu também tentei dar a minha humilde contribuição.

Espero que alguém tenha ou possa tirar proveito do código de conduta que eu apresentei. Desculpem-me se me exaltei ou se alguém não gostou de alguns palavrões (mas eu pedi permissão antes). Quem me conhece sabe que eu não sou tão intransigente assim, mas acho que pra dar palestra e transmitir uma mensagem às vezes temos que incorporar alguns personagens.

Mas e aí? Vocês podem se considerar programadores profissionais? Valendo o toba?

Minha apresentação sobre Spring Integration 2.x no JavaOne Brasil 2011

noreply@blogger.com (Edson Yanaga) — Wed, 14 Dec 2011 14:00:00 +0000

Architecting cloud-enabled applications using Spring-Integration 2.x

View more presentations from Edson Yanaga

Como já escrevi anteriormente, uma das minhas grandes ambições era conseguir apresentar uma sessão no JavaOne Brasil. Este ano consegui, e como prometido, posto agora finalmente os slides da minha apresentação no slideshare.

Demorei mais do que deveria pois o slideshare simplesmente ficou mais de 24 horas processando o meu arquivo do Keynote. Passado esse tempo, ele me enviou uma mensagem dizendo que não foi possível completar a conversão, e que eu deveria fazer upload novamente. Converti do Keynote para PDF, e o processo foi finalizado em cerca de 2 minutos.

Infelizmente sem as transições de "Magic Move" do Keynote a visualização das animações fica bastante prejudicada. Espero que seja o suficiente para entender o funcionamento. Pretendo postar alguns vídeos no YouTube para demonstrar melhor os Enterprise Integration Patterns (EIPs) e o Spring Integration 2.x. Fiquem de olho neste blog que teremos novidades no início do ano.

O código-fonte do demo está disponível no github: https://github.com/yanaga/spring-integration-demo