APIs que não mordem.

Desde que comecei a programar em Ruby ou outras linguagens de script, como php, por exemplo, penso sobre como essas linguagens possuem APIs bem simples e diretas de usar. Nada de muitos passos para realizar operações relativamente simples, as interfaces são mais diretas e geralmente invocar um método resolve o problema, ou boa parte dele. Mais ou menos como mostrei em um post anterior que apresenta, em 5 linhas, como fazer um leitor de RSS em Ruby. Nos ultimos dias, depois de ter conversas com Thiago Arrais e com Gandhi sobre esse assunto, resolvi ler (aqui, aqui, aqui e aqui) o que povo tem comentado sobre APIs, apenas para tentar formar uma opinião mais fundamentada. Também tentei ler algumas APIs em Java para fazer algumas operações que considero bastante diretas, como ler um RSS ou fazer o parse de um arquivo YAML.

Enquanto lia, constatei que a comunidade Java realmente cria ótimas APIs, boa parte pode servir como exemplo/estudo para programação e design patterns. Pode-se encontrar ótimo design em APIs como a de Collections ou IO, em um número bastante vasto de projetos open source e por aí vai. Mas, geralmente, as APIs em Java pecam por se utilizarem demais de expressões que se tornaram idiomaticas para a linguagem, ou pecam pelo excesso de zelo para escrever APIs que possam ser expandidas de acordo com a necessidade o que, de fato não as impede de ser simples. Um fato engraçado é como nem sempre as pessoas percebem que criam complicações desnecessarias. Exemplo: esses dias procurava por uma API para fazer o parse de arquivos YAML, se fizesse uma correspondencia direta do formato de um arquivo para a estrutura de uma classe, acharia perfeito. Eis que me deparo com a yaml4j - a YAML Loader/Dumper for Java. For those of us who wish Java were agile. O "agile", deixe-me explicar, fica por conta da discussão entre o formato yaml e xml. O primeiro exemplo da API é simples:

File f = new File(args[0]);
Reader reader = new BufferedReader(new FileReader(f));
Loader loader = new Loader();
loader.load( reader );

Object doc = loader.getDocument();

Claro, não vou colocar os imports e tudo mais, apenas o uso mais direto. Nada demais, certo? Errado! O yaml4j peca por me fazer criar objetos dos quais eu não quero saber, apenas para dar suporte a interface provida, ou melhor para superar a barreira criada pela interface não oferecida. O que eu realmente gostaria de fazer é:

Loader loader = new Loader();
loader.load("C:/my_file.yml");
Object doc = loader.getDocument();

Ou mais direto ainda:

Object doc = Loader.load("C:/my_file.yaml");

É provavel que muita gente diga que aí eu não poderia usar outros tipos de Reades, ou seja lá o que for, para fazer o load do arquivo. Não é verdade, simplesmente. Não o é porque quero apenas uma interface mais direta e não uma mais resumida, por mim o exemplo anterior poderia existir à vontade, mas a API deveria me prover métodos mais diretos. Outros com certeza dirão que, por ser código Java, eu poderia criar uma pequena extensão para a API, parar de reclamar e resolver o problema. Também não é verdade, ao menos para mim, pois estou preocupado em resolver os problemas do meu dominio e não em escrever linhas e mais linhas para dar suporte a API.

O ponto realmente é: se algo tem chance de ser usado com uma freqüência muito grande, vale a pena livrar as classes clientes da tralha, esconder a complexidade e prover uma interface para operações mais diretas. Exatamente assim:

require 'yaml'
doc = YAML::load(File.open('C:/my_file.yml'))

Ou, para ninguém ficar na bronca, para não pensarem que quero ver Java morta e enterrada, um exemplo da APIs que usei (alterei apenas para facilitar a leitura, mas perceba: é um correspondente direto para o código em Ruby):

File file = new File("ReceiptEntry.yml");
Entry entry = Yaml.loadType(file, Entry.class);

Um outro exemplo para mim é o Mentawai, apesar de o último release apresentar bons métodos para facilitar o uso do ActionConfig, poderia prover métodos como addForward, addRedirect, addNull. São consequences muito usados, então, por que não facilitar a vida? O addConsequence continua para permitir consequences customizadas.

Enfim, boa parte dos desenvolvedores Java - outras linguagens também, eu sei - deveria aprender a manter as APIs que desenvolvem tão simples quanto possível, mesmo que isso implique a criação de metodos a mais, um pouco de esperteza vai evitar copy and paste. Isso vale para desenvolvimento de classes que não formam uma API propriamente dita, mas que podem muito bem oferecer uma interface mais amigavel. As APIs nem sempre precisam estar prontas para salvar o mundo, às vezes precisam apenas carregar um arquivo YAML.

valeuz...

Adeus avatares a lá Orkut.

Há algum tempo, um usuario do JavaFree reclamou no forum que o esquema de cores, mais as fotografias, davam a impressão para as pessoas do trabalho de que ele estava perdendo tempo no orkut. Na época eu lembro que pensei imediatamente no Greasemonkey e em como poderia criar um script para remover as tais fotos. Pois é, como eu vivo reclamando da falta de tempo, aproveitei o dia livre - maldita dor de cabeça - para ler sobre o greasemonkey e tentar fazer alguns scripts com utilidade pública.

O primeiro foi para remover as fotografias no forum do JavaFree. O trabalho foi minimo, especialmente depois de colocar um shell e o jsenv entre os meus bookmarks. Incrivel como o povo inventa utilidades para o desenvolvimento web. Mas, fim de papo, quem quiser instalar o script e se livrar dos avatares, vai precisar instalar o Firefox - que? Ainda não usa? Eis mais um bom motivo! - Greasemonkey e depois o script. Absolutamente tranquilo! Para quem já usa o Firefox e o Greasemonkey, clique com o direito aqui e seja mais feliz por não precisar aturar meu avatar.

Update 1: Depois eu tento ver porque ele só remove depois que a pagina carrega.
Update 2: Segundo essa discussão na lista do Greasemonkey, não dá para impedir que as imagens sejam mostradas, porque o script executa apenas depois de toda a arvore DOM ser montada. Enquanto isso, o browser faz as requisições para mostrar as imagens. Verei se há alguma maneira de contornar isso.

valeuz...