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

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

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:

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:

Nossa maltratada e querida Língua Portuguesa

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

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?

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!

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

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:

1. Software não é código; ele cria experiência de uso.
2. Equipes de desenvolvimento não são programadores; são criadores de experiências.
3. O talento técnico é o alicerce de tudo; mas grandes desenvolvedores devem ser experts em design e no negócio.
4. Processo não vale nada sem design; você só obtém pelo processo o que você concebeu, então é melhor fazer o design direito.
5. 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.