Discussão sobre Testes Unitários

Participo da Lista Dojo Bahia e hoje tivemos uma discussão de altíssimo nível e que considerei muito interessante. A discussão surgiu após um colega perguntar como ele poderia testar os métodos privados de sua classe. Minha opinião é que não se deve testar métodos privados! Mas há pessoas que pensam diferente. Vejam abaixo a transcrição desta conversa, sem a identificação dos nomes. Não coloquei todas mensagens, pois nem todas tocaram no cerne do assunto. Também removi algumas partes das mensagens para não tornar o post muito chato! Você pensa diferente de todos nós? Então, diga qual a sua opinião nos comentários!

Mike começa a conversa com seu ponto de vista, que é parecido com o meu:
Veja bem, você deve fazer teste unitários de métodos de acesso publico e não de privados. Normalmente os métodos private servem de “ajudantes” dos métodos públicos. Se você testar os métodos publicos que tem ligação com o método private você terá testado ele. Mas aí terá um dilema do teste unitário, que deveria testa o método unicamente sem dependência.


Minha vez de opinar:
Métodos privados são “ajudantes de pedreiro”. Você testa se o pedreiro está fazendo tudo certo, o que, em teoria, deveria garantir que o ajudante está fazendo sua parte corretamente. Ou seja, métodos privados não existem para serem testados, apenas os públicos.

Testes unitários testam o comportamento de um objeto e o comportamento de um objeto está exposto por sua interface pública (se é que faz sentido dizer “interface privada”). Se os métodos desta interface pública delegam suas tarefas para métodos privados, para o teste unitário pouco importa.


Nemo pensa diferente de mim e de Mike, perceba:
Permita-me discordar: a qualidade do método privado vai influenciar diretamente na qualidade do objeto como um todo. Não interessa como você fatore a solução do problema. O código é todo seu, ou da equipe.

Quem faz teste unitário não é quem “compra” o objeto mas quem “faz”. Para o dono da obra, realmente o que importa é o trabalho do pedreiro, mas ele, como chefe de sua equipe, vai querer saber se os ajudantes tem capacidade ou não. E nessa analogia, você é o dona da obra e o pedreiro, ao mesmo tempo.


Não concordei com Nemo e resolvi escrever uma Bíblia para mostrar exatamente o que penso:

Entendo seu ponto de vista, mas bato na mesma tecla: conceitualmente, testes unitários não são feitos para testarem métodos privados. Vamos a outra analogia. Não sei se você conhece o Giga de Testes. Trabalhei na Semp Toshiba e lá havia um projeto para criar um hardware que testa hardware (parecido com nossos testes unitários, software que testa software).

A ideia é simples. Você conecta vários fios em uma placa mãe em suas saídas externas: porta usb, saída de vídeo, saída de mouse, saída de teclado… e por aí vai. A partir daí, aperta-se um botão e a Giga realiza todos os testes destas saídas, emitindo sinais e aguardando que os sinais corretos saiam. Perceba que não existe teste da transmissão entre cada transistor da placa mãe. Seria extremamente custoso. E muito desnecessário também. Basta saber se a saída está correta, conforme todas as entradas possíveis, que basta para a Giga de Testes.

Em software, para mim, é a mesma coisa. Para mim, importa testar todas as entradas possíveis de uma interface de um objeto. Se todas as entradas possíveis geram as respostas esperadas, para mim pouco importa o funcionamento interno… se há 200 métodos privados para resolver o problema? Pouco importa, desde que a interface externa me traga o resultado correto.

Testes unitários não existem para garantir que uma classe foi bem projetada, bem escrita. Aí já entram outras disciplinas do desenvolvimento de sistemas. O que defendo é esta diferença básica que não pode ser confundida. Nesta ideia, métodos privados não são “testáveis”. Se há métodos privados desnecessários, testes unitários não devem tratar isto. Se um método privado retorna o resultado errado para um método público que o chama, mas mesmo assim o método público retorna o resultado correto para quem o chama, então o teste unitário deve passar sem problemas e seu objetivo foi concluído com sucesso.

Agora deve-se partir para outras disciplinas que vão verificar se a classe foi bem projetada, se aquele método privado que está lá realmente tem necessidade de existir. Se o retorno errado dele não existe exatamente porque o método privado não precisa existir e coisas abstratas deste tipo. 🙂


Nemo agora me entendeu:
Acho que o problema de entendimento foi este: minha concepção de teste unitário não é a sua. Você considerou o objeto como a unidade, mas há quem, como eu, considere até métodos como importantes o suficiente para serem testados. Na minha opinião, os testes têm que me ajudar em todo meu código


Oba! Mais gente na conversa:
Como foi citado aqui, quem decide a menor unidade a ser testada é a equipe, ao depender do projeto em relação a custos x
benefícios. E eu vejo de forma clara que se você não testar o teste privado de forma independente, o seu código está sujeito à falhas.

Normalmente quando desenvolvemos uma classe, temos em mente, principalmente, os conceitos de coesão e acoplamento. Então criamos internamente métodos que auxiliem os métodos públicos. Por conta da reutilização de código, um método privado pode ser usado por vários outros e se esse conter um condicional, o seu fluxo vai ser diferente em cada contexto. Dessa forma, você vai precisar garantir em cada método público que você venha, que ele teste todas as possibilidades do teste privado. E isso deixa os testes espalhados, dificultando o controle e trazendo, muitas vezes, duplicação de teste, pois muitas vezes você precisa efetuar alguns testes antes para então testar o fluxo diferente ou então pela complexidade de se verificar em todos os pontos o que já foi e o que não foi testado. E quanto melhor é o seu código, pior para testar, uma vez que para diminuir o tamanho dos métodos e distribuir responsabilidades, você acaba criando método privado chamado por um método privado que é chamado por outro privado.

Se o seu sistema é pequeno, isso é até fácil de controlar, mas a medida que ele for crescendo, essa tarefa vai se tornando mais complicada. E no momento de uma possível manutenção, ai que “o bicho pega”.


Olha eu, chatão, de novo:

Aí estamos com o mesmo problema que ocorre com a Giga de Testes. É preciso testar a corrente que passa de um transistor para outro? Ou, para a venda do equipamento, o importante é que a resposta a um clique no mouse tenha o retorno correto, mesmo que por vias “tortas”? Por questões de custos e viabilidade, é melhor garantir que a resposta é correta. Depois outra disciplina da engenharia tratará da qualidade.

O teste UNITÁRIO é para garantir que uma UNIDADE trabalha da forma como ela foi especificada. Se você tem um método somar2mais2(), deve existir um teste que garanta que o retorno é apenas 4. Se internamente este método chama outros cinco privados, pouco importa para o teste unitário. Os métodos privados existem para auxiliar os públicos a concluírem um trabalho que é seu.

Normalmente, eu crio toda a lógica do meu método sem separar em privados. Faço os testes e garanto que está tudo correto (eu sei, nada de TDD aqui, né! Foi mal!). Depois, usando a ideia de baby steps, eu refatoro meu método dividindo-o, se necessário, em métodos privados. Volto a testar para ver se continua funcionando. Mais uma vez refatoro para melhorar a qualidade do código. Novamente faço testes e por aí vai.

Porventura, mais tarde eu crio um novo método. Percebo que posso repassar uma parte do seu código para um método privado que já existe. Mas preciso mudar um pouco o comportamento deste método… e mudo! Caso esta mudança tenha criado algum problema, ela será apontada nos testes já escritos para os métodos públicos que o usam. Caso não, ótimo! Pronto, só preciso disto.

O funcionamento do meu objeto está garantido. Quem usá-lo, pode ficar tranquilo que a resposta continuará sendo a mesma, mesmo que o método privado tenha sido alterado ou que dezenas de outros tenham sido criados. Para quem usa o objeto, o que importa é a resposta que ele dá, e não o que ele faz para dar a resposta e testes unitários existem para isto. Se foi mal implementado, aí são outros 500! Aí estamos falando de Qualidade e testes unitários não podem e não precisam garantir qualidade, mas garantir que o comportamento de um objeto está conforme sua especificação. Somar2Mais2 nunca poderia retornar 5, e o teste unitário deve garantir apenas isto.

Meu Primeiro Jogo

Eu sou um cara louco. Tenho plena consciência de minha enfermidade mental. Quero fazer tantas coisas ao mesmo tempo, que acabo viajando em várias ideias que nunca colocarei em prática. E, obviamente, neste exato momento acaba de surgir uma ideia muito, mas muito louca em minha mente. E eu vou encarar a loucura! Aliás, esta ideia sempre esteve em minha mente, como uma voz suave que me lembra o comercial da Garoto: “Compre Battom, Compre Battom, Compre Battom, Compre Battom!”. No meu caso, entretanto, a ideia não é comer chocolate. Aliás, não curto doces. Não combinam com cerveja. A ideia que sempre esteve martelando em minha cabeça é: Faça um Jogo. E juro que já tentei cumprir esta missão. Em vão. Primeiro, tentei criar uma engine de jogos em Java. Trabalho árduo. Criei o projeto no Eclipse, criei as abstrações, li livros sobre o assunto, mas, na hora H… Projeto suspenso devido a outras prioridades (ganhar dinheiro!).

Desta vez, contudo, minha loucura irá para frente e pretendo fazer diferente. Bem diferente, aliás. Primeiro, a ideia de criar uma engine não está mais em cogitação. Existem muitas por aí e agora, com as ideias mais maduras, percebo que fazendo um jogo usando uma engine de terceiros me dará a oportunidade de contribuir com outras pessoas. Outros projetos. E é isto o que pretendo e apoio que todos façam. Segunda questão, eu sempre achei que tinha que fazer o jogo todo para só depois avisar para as pessoas jogarem. Aprendi que a filosofia de baby steps aplica-se a este cenário perfeitamente. Posso ir liberando o jogo à medida em que estou fazendo. Digamos, posso fazer uma fase e lançar a versão 1.0 Beta 2, contemplando mais esta fase.

Agora, a ideia mais louca de todas. O jogo deverá manter um Rank online e à medida em que as fases são liberadas, as pessoas poderão jogar e acumular pontos. E para que acumular pontos? Para ganhar um prêmio, oras bolas. E qual prêmio? Ainda não sei. Mas algo significativo. Tipo um jogo de PS3, um Livro, Camisa Nerd e coisas deste tipo. Outro detalhe importante é que estarei informando passo a passo os detalhes do projeto, como a engine usada, as imagens que irão compor o jogo e as dificuldades e soluções encontradas. Isto vai ao encontro de minha filosofia de vida: compartilhar o conhecimento sempre. E de grátis.

E vamos começar a loucura! Primeiro, a engine escolhida foi a GTGE (Gold T Game Engine). É opensource e está disponibilizada no Google Code. Já rodei uns exemplos. Já li a documentação e gostei. Existem outras opções, mas pretendo iniciar minha aventura com ela. Depois, quem sabe, podemos ir mudando. Segunda questão, a estória do jogo. Eu sempre fui fã de Ultima 7 e Ultima 8 – Pagan. Mas não serei tão pretensioso assim. Mas será um jogo estilo RPG com visão isométrica, onde charadas e mistérios serão resolvidos e que lhe farão acumular pontos para ganhar o tão cobiçado prêmio. 🙂 Não sabe como é uma visão isométrica? Veja a imagem aí embaixo, é do jogo Ultima 8.

Terceira questão: as imagens. Eu sou péssimo designer. Ainda mais para desenhos isométricos… fora de cogitação eu mesmo fazer os gráficos. Roubar imagens de outros jogos… não, muito menos. 🙂 Pagar. Também não. Existem “imagens opensource”? SIM! Há almas caridosas no mundo do design gráfico! Que bom! E vou usar os gráficos destes caras, uma vez que não me importo se você encontrar outro jogo por aí usando os mesmos tiles e sprites que o meu. E um detalhe, não será uma beleza de jogo, tá bom? Será um jogo para saciar meu ímpeto de fazer jogos. E porque os prêmios? Uma forma de chamar a atenção das pessoas para que critiquem, ajudem e joguem! 🙂 E porque logo agora você resolveu tocar esta ideia? Foi quando vi o jogo do Abraão Isvi: Toupety. Fica aí a sugestão e até o próximo capítulo desta odisséia.

Comunidades ou Terceirização ?

Utilizarei meu indicador direito para tocar em um assunto delicado: como vejo a participação e o entendimento de uma boa quantidade de brasileiros, e aí incluo principalmente as empresas brasileiras, com o software livre e suas comunidades. Antes gostaria de reforçar uma diferença conceitual que enxergo, apesar de minha miopia. A visão de comunidade, e a ajuda a esta comunidade em prol de um bem em comum, e uma visão particular sobre um princípio específico que está incluído no software livre, e que citarei nas próximas linhas para tentar que vocês leiam mais um pouco deste (des)interessante post.

Vou lhes explicar. A questão é que Richard Stallman e os idealizadores do software livre não condenam, conforme meu minguado conhecimento sobre o assunto, que um software seja copiado, seguindo as regras da licença GPL (ou similares), e modificado. É o fork. O fork não é condenável nesta visão. Ao contrário, é até, de certa forma, motivado. A ideia de comunidade, embora seja no software livre onde mais se destaca na nossa área, enseja um comportamento diferente. Você tem uma necessidade que já é parcialmente atendida por um software sustentado por uma comunidade? Então, não faça um fork. Ajude! Seja agregador. Não seja apenas um cliente do software livre, seja um colaborador. Não faça um fork, pois você poderia estar ajudando a solução atual a se tornar ainda melhor.

Mas, vou voltar mais incisivamente ao assunto do tópico. Uma questão está mais do que clara para mim. Mais até do que Michael Jackson quando lançou o clipe Black and White. Nossas empresas estão pouco se importando para a ideia de comunidades. A verdade é clara e, neste caso, não está lá fora: as comunidades de softwares livre servem apenas como uma forma de terceirizar um serviço do qual a empresa não se vê com competência ou fôlego para fazer. Vou mais além, se há fôlego para fazer, o faz sem ajudar os criadores da ideia inicial, mas criando sua própria solução a partir da ideia dos outros. Fork!

Ainda há outra vertente. As pessoas não ajudam. Elas dizem o que está errado. O que já é algo louvável. Mas, mais louvável ainda é propor a solução. Achar o erro e já levar para os autores do software uma proposta para solucionar o problema é o que chamo de “a essência da colaboração em comunidades de software livre“. Infelizmente, é um mundo distante.

Voltando à questão dos forks: isto é condenável? Não há problemas, se você for considerar a ideia inicial de que um fork é algo normal. Mas, da forma como é feito hoje, é condenável, sim. A colaboração entre os membros de uma comunidade só tende a agregar valor para ambas as partes. A ajuda mútua sempre traz mais benefícios para ambos os lados. Quanto mais mãos e cérebros inteligentes atuando por um objetivo em comum, melhor. Só faça um fork se os autores do projeto inicial forem cabeça dura e não aceitarem ajuda externa. Antes, esvazie todas as alternativas disponíveis para você. Não havendo retorno para seus esforços, então fork neles! Mas deixe isto claro para todos, para que entendam sua motivação e não lhe encarem como um desagregador.

E porque as coisas são assim? Ainda nos falta esta cultura. E isto já vem de longe. Muito longe. O brasileiro sempre usou programas piratas e nunca sentiu vergonha disto. E isto é desde o Pentium 1, ou vai me dizer que sua cópia do Windows Workgroups era original? Oitenta por cento de chances de que não era. E o que pirataria tem a ver com isto tudo? Vou ser sincero, eu só quis deixar um gancho para dizer que as empresas brasileiras atuam como os “Piratas do Software Livre”. Você vai me dizer: seu maluco, que frase sem sentido! É, você tem razão, eu acabei de inventá-la.

E a ideia que quero passar com a frase é a seguinte: quando você usa um “aplicativo pirateado”, você está jogando fora todo esforço daqueles que suaram para lhe entregar uma solução para seus problemas. Não concorda que o software seja pago? Não use. Para mim é simples assim. Quando você não colabora com uma comunidade, se tornando apenas cliente dela, literalmente “vampirizando“, você a destrói em sua essência. É um estaca de madeira no coração desta comunidade.

Este post está enorme e vou finalizá-lo com uma resposta que alguns poderiam me fazer: e porque você ainda continua disponibilizando suas aplicações como software livre já que a maioria só quer se aproveitar disto? Uma mera questão filosófica. Eu acredito no Software Livre. O conhecimento deve ser compartilhado. O que eu aprendi, eu quero compartilhar com os outros. Embora minha visão seja, em alguns momentos, pessimista, isto não quer dizer que eu ficarei parado aguardando passivamente que as coisas mudem. E este post é um passo nesta direção.

Concorda comigo? Sim? Mais ou menos? Deixa seu comentário!

Considerações sobre Workflows

O primeiro projeto em que participei no Serpro, assim que fui aprovado no concurso em 2006, era um super Workflow. Documentos que precisavam ser criados, revisados, aprovados, enviados para parecer e outras dezenas de situações. Fora as milhares de regras para definir quem vai executar uma determinada tarefa no documento. E o que dizer da quantidade de perfis e papeis? Era, e ainda é, pois ainda está em desenvolvimento, um mega sistema de Workflow. Até então, eu nunca havia sequer notado a existência de Workflows. E também já havia feito sistemas similares como, por exemplo, um sistema de comércio online e um sistema de notícias. Observando cuidadosamente, percebe-se que estes sistemas tem aspectos em comum: entidades que mudam de situação, pessoas que devem executar tarefas, e-mails que devem ser enviados, sistemas externos que devem ser acionados, etc.

A partir deste momento, fiquei de olhos mais atentos aos sistemas em que eu participava ou ajudava, sempre notando que muitos tinham características de Workflow, mas a equipe pouco percebia este detalhe importante. Para muitos, Workflow é algo mais relacionado aos negócios da empresa em que trabalha e a automatização destes negócios. Parece algo distante. Uma tecnologia meio alienígena e que vai complicar mais do que ajudar em seu projeto. Para piorar, ainda há uma sopa de letrinhas e conceitos que confudem ainda mais o cidadão: BPM, SOA, EBP, Orquestração de Serviços, Coreografia entre Serviços, entre outros.

De fato, a visão de que Workflow está relacionado às questões macro da empresa, envolvendo automatização do seu fluxo de trabalho, é verdadeira, mas, isto é só uma vertente. Não pretendo tocar neste assunto, pelo menos não agora. O que me interessa agora são os desenvolvedores de sistemas, aqueles caras que ouvem as necessidades de seu cliente e que precisam tomar a melhor decisão sobre como desenvolver o sistema do dito cujo. Imagine Arthur Dent, o Analista de Sistemas, ouvindo Ford Prefect, o cliente, dizendo para ele:

– Então, o José recebe a notificação de compra e tem que repassar pro seu gerente.
– Sim, continue… – diz o analista.
– Aí o gerente aprova e repassa pra Carla do almoxarifado ver se tem estoque – diz o cliente, imaginando que já disse tudo e que o sistema já pode começar a ser feito.
– Certo, e a Carla faz o quê?
– Ah sim, já ia esquecendo. Ela aí diz pro financeiro que está certo, que é pra creditar o cliente.

O Analista de Sistemas certamente pensou em Casos de Uso. E o projetista? Imaginou usar Java com Spring, persistir com Hibernate em um banco de dados Oracle com uma arquitetura em três camadas na Web, usando Java Server Faces (JSF). E eles estão errados? Sim! E também não! O que eu defendo é que se pode ganhar bastante em produtividade quando se utiliza uma metodologia diferenciada para projetar e implementar sistemas desta natureza. Mas, para isto, é necessário fortalecer nas pessoas as ideias (conceitos) sobre Workflows. Antes de mais nada, o Arthur Dent precisa ter o feeling, aquela sensação estranha em suas espinhas, algo que lhe diz: eu já vi isto antes! É um Workflow, cara!

“Sim, sabichão, então me indique o caminho das pedras!” Perdoe-me, pois eu não tenho a resposta exata para você. Não agora. Mas, eu estou escrevendo um artigo para o ConSerpro, um Congresso para os empregados do Serpro, sobre este problema e pretendo chegar a algo mais concreto. Percebo no Serpro que as equipes de desenvolvimento perdem a oportunidade de usarem técnicas específicas de projeto e programação para sistemas de Workflow. Não digo apenas usar uma engine de Workflow. Mas, como eu posso ganhar em produtividade quando eu sei que meu sistema é absolutamente um Workflow? Devo usar qual engine de Workflow e de que forma? Qual linguagem de definição de processos devo usar? Pronto. Escolhi a Engine e a linguagem de processos, agora como eu documento este fluxo?

As perguntas são muitas. As respostas, poucas. E as coisas pioram quando percebemos que a padronização na área de Workflows não é grandes coisas. Não é incomum ver engines de Workflow que não conversam entre si: um fluxo definido para rodar em uma, não roda, nem à base de marretadas, em outra. As APIs são absolutamente diferentes também! Agora, imagine tudo isto em uma empresa onde trabalham mais de 1000 desenvolvedores e com centenas de sistemas que poderiam usufruir das facilidades que um mero mecanismo de Workflow pode lhe proporcionar.

Contudo, infelizmente, a realidade não é esta. O que vemos são dezenas de diagramas de projeto e documentos de arquitetura que poderiam ser abstraídos favorecendo uma visão mais generalizada. Vemos centenas de linhas de código, como esta aqui:

public class RegraDeNegocioWorkflowSemNecessidade {
   public void aprovar(Documento documento) {
       if ( documento.getSituacao().getId().equals(SITUACAO_AAPROVAR) ) {
           // Enviar e-mail para o gerente.
           // Atualizar o banco de dados com a situação nova.
          // Chamar um Webservice e aguardar a resposta.
          // Processar a resposta do Webservice e decidir se o fluxo vai pra Aprovado ou Reprovado.
          // Enviar e-mail pro cliente dizendo a situação!
          // Fechar a transação.
          E aqui vai um monte de IF THEN ELSE WHILE FOR...
       }
   }
}

E isto tudo poderia ser descartado! E seu programador poderia ter poupado dezenas de linhas de código, pois todos estes tratamentos podem ser feitos com poucas linhas e uma boa engine ajudando! E você? Concorda comigo? Não? Então, deixe seu comentário!

EncomendaZ na Mídia

Opa! É com grande felicidade que anuncio que o EncomendaZ foi publicado em dois sítios de downloads de aplicativos. O primeiro em que o aplicativo apareceu foi o Baixaki.

O segundo sítio a publicar foi o Zigg. E não é o primeiro aplicativo meu que o Zigg publica. O VeículoZ também está lá! O link para download no Zigg é http://ziggi.uol.com.br/downloads/encomendaz. Só tenho muito a agradecer aos dois sites. Muito obrigado pela confiança. Ao Baixaki e o velho amigo Francis. E ao Ziggi que publicou em tempo recorde, sem burocracia excessiva.

Fica aqui apenas um ponto negativo: Superdownloads. Infelizmente o processo lá é super burocrático. Demora demais para publicar seu aplicativo, quase 2 meses. E ainda há regrar super rígidas o que praticamente lhe desanima em enviar aplicativos para lá.

Atualização em 18/06/2010

E o Superdownloads me surpreendeu. Acabei de receber um e-mail informando a inclusão do EncomendaZ lá. O que eu tinha escrito acima estava baseado na experiência que tive ao tentar incluir a biblioteca Alfred para download lá. Já espero 1 mês e alguns dias a avaliação deles se é possível ou não incluir a biblioteca. Sem respostas. Mas, desta vez, eles foram eficientes. O EncomendaZ aguardou muito pouco e já apareceu lá. Obrigado ao Superdownloads! Link para o aplicativo lá http://www.superdownloads.com.br/download/43/encomendaz/.

Interessante que após a publicação nos dois sites, os downloads já começaram a aumentar rapidamente! Espero que as pessoas que baixaram contribuam e ajudem os programadores de aplicativos livre a continuarem criando aplicativos. As vezes, um e-mail agradecendo já enche monstruosamente o ego do programador. Viu? Não precisa muito. 🙂

Atualização!
E acabei de receber um e-mail do Baixatudo me informando que acabaram de incluir o EncomendaZ lá também. Que legal. Eu conhecia o site e até tentei enviar ele para lá, mas não achei um link para isto. Mas eles mesmos resolveram incluir! Muito obrigado! Ah, o link para o download lá é: http://www.baixatudo.com.br/encomendaz

Rastreador de Encomendas (EncomendaZ)

Quinta-feira de folga. Sexta também não fui trabalhar. Noite em branco com dor de barriga. Durante a quinta, nada de cerveja ou comidas exóticas. Sem vontade de ler livros. Resolvi: vou fazer alguma coisa em Swing/Java para aprender alguma coisa desse troço. E fiz. Precisei de algumas horas de Copy+Paste de códigos na Internet, um pouquinho de ajuda do Alfred e tcham tcham tcham…

Senhores, apresento-lhes o EncomendaZ. Um aplicativo que se conecta ao sítio dos Correios e acompanha o andamento de suas encomendas. É programa para paranóico que vive comprando coisas no Mercado Livre e tem tanto código de rastreamento para acompanhar que se perde. Pronto, agora você cadastra tudo lá no EncomendaZ que ele gerencia.

Tem utilidade? Sei lá, deve ter. E lembra o que eu já disse? Eu gosto de fazer coisas inúteis também. Só pra aprender alguma coisa mesmo. E, obviamente, depois eu disponibilizo o código fonte da brincadeira pra todo mundo ver. E o deste programa está logo aqui: http://encomendaz.googlecode.com/.

Veja uma tela do programa logo abaixo. Repare no Look and Feel do Nimbus. Achei estilo e botei como padrão. Agora a parte engraçada? Ah, para ver vai ter que baixar o programa e olhar na aba de Doações! 🙂

Quer baixar? Clique aqui. Achou um bug? Cadastre um Issue clicando aqui. Gostou? Deixe um comentário me elogiando, meu ego agradece! 🙂 Não gostou? Então, deixe um comentário e diga o que pode ser feito para melhorar!

AuctionX – Informações do Mercado Livre

Fale sério pra mim! Você já fez um sistema, biblioteca, ou algo que o valha, que não tem a mínima ideia se é útil? 🙂 Estou neste dilema. Na falta do que fazer numa noite dessas, resolvi brincar com o Mercado Livre, Java, XML e Maven.

E no que deu isso? Nasceu o AuctionX. Uma biblioteca pra você fazer consultas aos produtos vendidos no Mercado Livre. E aí? Tem utilidade isso? Sei lá, oras! Só sei que eu fiz e tá legal.

Pra usar é bem simples. A API eu fiz com o Hibernate em mente, logo, você verá algumas semelhanças com a classe Criteria deles. Vamos começar com os exemplos. Você quer pesquisar “iphones” vendidos apenas por vendedores certificados (Gold, Platinum):

	Search search = AuctionXService.createSearch("ML");
	Collection<Auction> auctions = search
				.addRestriction(Restriction.onlyCertifiedSellers())
				.search("iphone");

Certo. Legal. Agora você quer pesquisar por “iphones” que não estão em leilão, mas em venda direta. E também que os vendedores sejam da Bahia e mais, que os produtos sejam apenas novos!

	Search search = AuctionXService.createSearch("ML");
	Collection<Auction> auctions = search
			.addRestriction(Restriction.onlyCertifiedSellers())
			.addRestriction(Restriction.buyNow())
			.addRestriction(Restriction.location("BAHIA"))
			.addRestriction(Restriction.onlyNewProducts())
			.search("iphone");

Onde está o projeto? No lugar de sempre: Google Code! http://code.google.com/p/auctionx/. Tá completo? Não. Ainda falta implementar a ordenação do resultado. Mas vai ser rapidinho! 🙂 Vá lá, tou só esperando você me chamar de maluco e coisa de quem não tem o que fazer.

Futuro do Alfred


Conforme informei no post anterior, tive uma boa recepção dos desenvolvedores que viram a notícia no BR-Linux e enviaram suas críticas e sugestões sobre o Alfred. Alguns criticaram a forma como a biblioteca foi programada, usando apenas métodos estáticos.

Cabe a mim explicar o motivo desta escolha. Não foi por desconhecer Orientação a Objetos, aliás, eu adoto este paradigma de programação a mais de 5 anos, seja programando em Java, C++ ou C#.

A adoção de métodos estáticos é devido à própria natureza da biblioteca. Eu diria que está relacionado à filosofia que eu pensei inicialmente para este projeto. A ideia inicial era ter uma biblioteca super simplificada. Não imaginei que sua utilização fosse com Composição de objetos ou herança.

Por exemplo, a ideia era que você não usasse a classe Telefone como um atributo de alguma classe, mas que se você precisasse, pontualmente, de uma formatação de telefone, usasse um método bastante simples de ser adotado.

Claro, em um mundo O.O. isto pode parecer estranho, mas admito que fui influenciado pelo projeto do Aurélio, o Funções ZZ. A filosofia por trás é a KISS: Keep It Simple and Stupid. E a forma mais simples que achei para a biblioteca foi esta.

E você? Concorda? Acha que a biblioteca deveria seguir outro rumo e adotar um modelo mais orientado a objetos? Dê sua sugestão, a biblioteca seguirá o rumo que a maioria achar melhor.