Hespanha

Resolvi escrever este post porque vejo que existe muita confusão, e talvez até mesmo desinformação da comunidade Java quando o assunto são exceções.

Pra esclarecer as dúvidas resolvi ir até uma das maiores fontes de informação sobre boas práticas do Java que existe, o livro Effective Java.

Pra começar, no item 40 do livro é dito “Use Checked Exceptions for recoverable conditions”. Infelizmente eu vejo que em muitos projetos por aí Checked Exceptions viraram padrão e todas as exceções do projeto são deste tipo. Isso é um ERRO que deixa o projeto chatissimo pra manter, porque com isso toda vez que você precisa chamar um método ou você tem que colocar ele dentro de um try/catch, ou senão tem que dar um throws na exceção. Da próxima vez que você precisar lançar uma exceção, por favor, pense por alguns momentos no seguinte: “O cara que pegar essa minha exceção vai poder fazer alguma coisa pra trata-lá?”. Se a sua reposta por NÃO, então você não deve usar uma Checked Exception.

Lidar com exceções em Java não é um assunto fácil, e no próprio livro o Joshua Bloch fala que não existe uma receita de bolo que resolva todos os casos. Mas de toda maneira, parece que um comodismo se instalou nos programadores Java, e ao invez de pensar no cenário, o que se tem feito é lançar uma Checked Exception e pronto, possivelmente incentivado por um pensamento do tipo “Se o cara quiser fazer alguma coisa ele faz, senão ele ignora, pelo menos eu fiz a minha parte”. No item 41 é dito “Avoid unnecessay use of checked exceptions”. É um desprazer trabalhar com uma API ou sistema cheio de checked exceptions.

Checked Exceptions são excelentes quando usadas na hora certa, pois dá poder pra você corrigir algo que deu errado, mas são péssimas se usadas na hora errada!

Eu poderia tentar explicar mais sobre exceções, mas definitivamente é melhor ler o Effective Java, e a Bani traduziu esse capítulo de exceçõe, e disponibilizou no blog dela no seguinte link: http://vanessas.sites.uol.com.br/java/ej6.html . Minha recomendação é: LEIAM! É de graça, é pouca coisa, e com certeza você se tornará um programador melhor depois de ler, e vai pensar melhor antes de sair lançando checked exceptions por aí.

Esse fim de semana eu participei do Yahoo Hack Day Brasil. Foi definitivamente o melhor evento de computação que eu já fui, perfeito, e o melhor de tudo, foi de graça. O objetivo do evento foi construir uma aplicação qualquer usando as APIs que o Yahoo disponibiliza, excelentes APIs, diga-se de passagem.

Eu formei um time com dois amigos do UOL(Rafael e Wandi) e um amigo feito no Rails Summit(Marcos Sousa).

Falando um pouco do nosso projeto, ele consistiu de um site no qual o usuário informava um endereço da cidade de São Paulo, e a partir disso o site retornava dados sobre a criminalidade na região daquele endereço. Pra chegar nisso, a gente fez o seguinte:

1) Recuperamos todos os endereços de delegacias da cidade de São Paulo e pra cada um obtivemos a latitude e a longitude usando a API do Yahoo Maps. Depois salvamos na nossa aplicação essas informações.

2) Dado o endereço do usuário nós usamos a API do Yahoo Maps para obter a latitude e longitude do endereço.

3) Calculamos qual a delegacia mais próxima do endereço informado usando os dados da latitude e longitude que tinhamos na mão.

4) Depois de encontrada a delegacia mais próxima nós vamos em um site de dados da secretaria de segurança da cidade de São Paulo, e usamos a fantástica API YQL para obter os dados daquela delegacia. Os dados no site da secretaria de segurança ficam expostos em uma tabela HTML, então o YQL ajuda muito para filtrar estes dados.

5) Com os dados na mão é só exibir para o usuário o indice de criminalidade naquela região.

Bom, quem quiser conferir o endereço do nosso projeto é:

http://violenciasp.appspot.com

O layout tem algumas falhas, principalmente em browsers no Windows, mas não se esqueçam que é um projeto feito em 24hs. hehehe Quem sabe no futuro a gente de um tapa e melhore o site.

Infelizmente o nosso hack não nos rendeu nenhum prêmio, mas com certeza o aprendizado que o evento proporcionou valeu muito! E pra quem não conhece, eu recomendo muito dar uma olhada nas APIs do Yahoo, especialmente nesse tal de YQL que é show de bola!

Até a próxima!

No semestre passado eu tive a oportunidade de fazer um projeto muito bacana no mestrado. Eu cursei uma matéria chamada Geometria computacional, que como o próprio nome diz, estuda algoritmos clássicos para resolver problemas geométricos. Como projeto final, tivemos que criar um “simulador visual” de um dos problemas geométricos que estudamos. A idéia era implementar o algoritmo força-bruta que resolve o problema e um algoritmo assintoticamente mais rápido, tudo isso de uma forma que o usuário pudesse ver o que o algoritmo está fazendo a cada instante.

Eu e mais um colega de classe resolvemos implementar os algoritmos que resolvem o problema de localizar intersecção de segmentos no plano, ou seja, dado um conjunto de n retas no plano localizar quais delas se intersectam. O Alexis, um ex-aluno do ime-usp, desenvolveu no ano que ele fez essa matéria toda uma interface gráfica bem modular para esse tipo de projeto feita em Python. Como Python é uma linguagem muito massa e seria bem mais simples usar essa interface que ele desenvolveu do que criar uma nossa do zero, resolvemos usar ela para o nosso projeto.

Implementamos um algoritmo conhecido como Shamos & Hoey(SH) que encontra a primeira interseção em um conjunto de n segmentos de reta. Esse algoritmo possui complexidade O(nlgn), e para atingir essa complexidade ele requer uma estrutura de dados que busca um elemento em um conjunto de n elementos em tempo O(lgn). Sendo assim, resolvemos implementar o algoritmo com três sabores: Com Árvore de Busca Binária Balanceada, Árvore de Busca Binária Sem Balanceamento e Skip List. A idéia resumida do algoritmo é analisar todas as retas, mas ao invés de testar a intersecção de cada uma com todas as outras, ele testa apenas a reta logo acima e a logo abaixo da que está sendo analisada, pois obviamente, se estas duas não intersectam a reta, nenhuma outra intersecta, dada uma linha de varredura sobre o eixo x. Além disso, implementamos a versão Força-Bruta que consome tempo O(nˆ2), já que pra cada reta analisada, ele verifica a intersecção com todas as outras.

Segue abaixo alguns screenshots com o resultado final:

No exemplo mostrado, como a árvore de busca não crescia muito, o tempo entre a execução com árvore balanceada e não balanceada foram equivalentes, mas em casos onde a árvore cresce(existem exemplos deste no código) é bem bacana ver a diferença que dá usar uma árvore balanceada. A diferença entre o algoritmo de SH e o Força-Bruta então é gritante. Um programa como esse é legal para abrir os olhos daqueles que não dão valor para Analise de Algoritmos. Se você não acredita o quanto um algoritmo O(nlgn) é melhor que um O(nˆ2), agora você pode ver e comprovar. =)

Coloquei o código no GitHub para caso alguém se interesse por olhar e/ou rodar o programa. Está em http://github.com/luizhespanha/geometry-algorithms-simulation

Como muitos que me conhecem sabem, eu sou um grande fã de campeonatos de programação. Na época da graduação eu participei por 2 anos consecutivos da Maratona de Programação, e hoje em dia, mesmo não podendo mais participar, ainda me divirto resolvendo problemas em sites como: TopCoder, br.spoj.pl e uva.

No próximo ano eu pretendo participar do Google Code Jam pra valer, pra conseguir um resultado honroso. E pra isso, eu estipulei uma meta de resolver um problema por dia útil da semana, ou seja, aproximadamente 20 problemas por mês.

A partir dessa idéia surgiu uma outra de disponibilizar o códigos desses problemas que eu resolver em um repositório. Dessa idéia surgiu o: http://github.com/luizhespanha/maratona-programacao.

A idéia de disponibilizar os códigos não é muito bem vista pela comunidade que gosta destes campeonatos, pois isso acaba tirando a graça do desafio de outras pessoas, porém, o Google Code JAM disponibiliza o código de todos os concorrentes, e eu achei muito bacana, porque mesmo tendo resolvido um problema, eu tive a oportunidade de ver os códigos do ACRush, e ver como ele programa, algo que com certeza vale a pena. Logo, cabe a quem se interessar avaliar se é interessante ou não olhar um código do repositório sem tentar resolver primeiro.

Espero que consiga manter minha meta. Para problemas mais elaborados também pretendo criar um post com algumas explicações.

Até a próxima!

Hoje tive uma surpresa extremamente desagradável. Temos um framework de uma empresa ˜conceituada” que é o responsável pelo core de um sistema crítico que temos aqui na empresa. A empresa responsável lançou recentemente uma nova versão deste framework que possui diversas coisas importantes que estavamos querendo a tempos. Então lá fui eu feliz e contente baixar a nova versão para colocar no projeto. Faço o download e vou ver o README.txt para ver como fazer a migração da versão antiga para a nova versão. Para a minha surpresa leio o seguinte:

“Esta versão é totalmente incompátivel com a versão antiga. Mudamos a API, mudamos as tabelas no banco de dados, ou seja, mudamos tudo. Ah, também não existe nenhuma ferramenta para ajudar na migração”

Ou seja, basicamente um “Dane-se você, se vira se quiser migrar”

Na minha opinião, isso é o cúmulo da falta de respeito com o seu cliente, que usa a sua ferramenta. Tá na hora das empresas entenderem que é uma obrigação manter a compatibilidade entre versões. Eu até entendo que existem mudanças que necessitam quebrar tudo, mas então, nesse caso, a empresa fornecedora deveria ter o dever de prover ferramentas e guias para orientar os clientes em migrações.

Estamos em uma situação delicadissima no projeto. Migrar versões em um projeto que é responsável pelo billing da empresa é sempre um drama. Nessa condições então, onde a empresa fornecedora lavou as mãos então.

Nesse aspecto, eu respeito bastante a Sun e a Oracle. Essas empresas sempre foram bem conservadoras em relação a compatibilidade, e com certeza, é por isso que elas são tão respeitadas e seus produtos atingiram sucesso. Um outro belo exemplo foi a migração de versões do WordPress, eu simplesmente apertei um botão e a ferramenta se atualizou sozinha.

Já essa empresa que faz esse framework que usamos no projeto sempre foi negligente em relação a mudanças de versões. Mesmo em mudanças de versões minors eles conseguem tornar suas ferramentas incompativeis entre versões! Mas enfim, paciência!

Meu objetivo nesse post é conscientizar os programadores a sempre atentarem para esse ponto. Em um momento que a integração entre sistemas, SOA, ganham força a cada dia, é importantíssimo mantermos compatibilidade quando atualizarmos nossos sistemas. Isso inspira confiança para o cliente do seu sistema/framework/API/serviço. É sempre preciso fazer o possivel e o impossível para isso. E no caso que realmente for imprescindível quebrar a compatibilidade, fazer tudo para ajudar o seu cliente e nunca ˜lavar as mãos˜.

Fica aqui meu desabafo!

De férias no trabalho, as vésperas de viajar, sem muito o que fazer, resolvi brincar um pouco com AppleScript. Meu conhecimento anterior
de AppleScript era nulo, nunca não tinha nem visto como era um código feito em AppleScript, e por isso me surpreendi com a facilidade que
é desenvolver um!!

Eu fiz um scriptzinho de algo que eu já queria faz tempo. Eu queria que quando eu ligasse o meu Mac e entrasse no sistema operacional, ele
falasse algumas palavras! Isso “ainda” gera um certo fascínio nas pessoas, principalmente nos usuários leigos, é algo diferente ver um
computador falando! Como a tarefa foi muito fácil e terminei em 5 minutos, resolvi incrementar um pouquinho meu script e adicionar umas
condicionais para o meu Mac falar frases diferentes dependendo do horário!

Pra começar, o Mac vêm com uma ferramenta chamada “Script Editor”. Ela é muito simples e intuitiva, e possui diversos templates de comandos, o que ajuda muito pra aprender a sintaxe. Sem muito esforço e com a ajuda dessa ferramenta eu desenvolvi o script abaixo:
[sourcecode language='java']
if time of (current date) < 43200 then
tell application "Console"
say "Good Morning, Mr Hespanha"
say "Do you want a coffee?"
end tell
else
if time of (current date) < 64800 then
tell application "Console"
say "Good Afternoon, Mr Hespanha"
say "Time to program!"
end tell
else
tell application "Console"
say "Good night, Mr Hespanha"
say "Time to play!!"
end tell
end if
end if
[/sourcecode]
A chamada a função time of(current date) retorna a quantidade de minutos decorridas no dia.

Os demais comandos são auto-explicativos!

Feito isso, foi só salvar o arquivo como "Application Bundle" e colocar ele pra rodar no login do meu usuário. Como diz o grande Aurélio: “Simple == Beautiful”.

Gostei muito da experiência de desenvolver(se é que se pode falar isso) com AppleScript. Quando voltar de férias pretendo me aventurar
mais e tentar fazer umas coisinhas mais elaboradas!

O Aurelio mantém uma página com vários AppleScripts. Quem quiser conhecer, o endereço é: http://www.aurelio.net/soft/

Pra aprender mais sobre AppleScripts, é só dar uma googada que vão aparecer diversos tutoriais e dicas!!

É isso! Abraços e até a próxima!

Certa vez estava numa palestra do Vinicius da Globalcode, e ele disse brincando a seguinte frase: “O JMetter é muito louco! Não sei como alguém faz um negócio tão bom como esse e
distribui gratuitamente.”. Eu diria o mesmo a respeito do Maven. O Maven é uma ferramente fantastica e indispensável para todo projeto Java.

Entre as muitas features do Maven que eu gosto, uma das minhas preferidas é que sempre que você precisa compilar o projeto para gerar os seus ears, jars, sars etc, ele executa automaticamente
todos os testes unitários do projeto, e se algum teste não passar ele não compila o projeto. Acho esse recurso formidável para manter a qualidade do projeto.

Porém, infelizmente existe o parâmetro -Dmaven.test.skip=true, que se você passa ele, os testes não são executados. Agora imagine a seguinte situação: “O sprint está aos 45 do segundo tempo, você
precisa gerar o ear do projeto pra fechar o sprint e mostrar pro Product Owner, dai você manda o Maven compilar o projeto e os testes unitários não passam” O que fazer nesta situação? Taca o “Skip Test”
lá e vamos embora certo?

Ao menos na minha opinião, ERRADISSIMO. Neste caso, é sprint NOT DONE e acabou. O código não está apto para ir para produção, afinal, dizem os mais críticos que código não testado é lixo. Eu não tenho
uma opinião tão rígida, mas concordo que é muito arriscado colocar um código em produção sem testa-lo, ainda mais se você escreveu testes pra esse código, e os testes não estão passando.

Usar -Dmaven.test.skip=true é tentador. Eu mesmo já usei várias vezes, sempre com o pensamento que “Ah, o código tá certo, precisa só arrumar os testes mas depois quando tiver tempo eu faço isso”. Hoje,
com mais maturidade eu vejo que isso é um erro feio, e eu aboli completamente este parâmetro da minha vida. Finjo que ele não existe, e tenho até vontade de recompilar o Maven para arrancar ele de vez, para
não correr riscos de ter recaidas. Hehehe

Fica aqui então o recado deste post, se você não conhecia esse parâmetro macabro, continue sem conhecer, se você conhecia mas não usa, excelente, se você conhecia e ainda usa, esta na hora de mudar
a sua mente, deixar de apelar, e começar a testar o código direito.

Um abraço e até a próxima.

Esse post é apenas para deixar uma referência aqui para o meu blog antigo, para que assim, quem entre pela primeira vez neste novo blog possa ver o que eu já escrevi.

Eu tentei migrar o conteúdo do antigo blog para este novo mas não obtive sucesso. Eu tentei fazer a importação via RSS mas não funcionou. Acho que o UOL não quer colaborar muito com quem quer migrar do servidor de blogs deles para algum outro.

Mas enfim, chega de papo! O endereço do meu antigo blog é:  http://lavh.zip.net