terça-feira, julho 24, 2007

Mudei de casa

Ahá, e vc pensou que esse blog havia morrido, não era? Pois morreu mesmo. Esse é apenas um post para informar o endereço do meu novo blog:

http://marcospereira.wordpress.com/

Para aqueles que usam algum agregador de feeds, o novo endereço é:

http://marcospereira.wordpress.com/feed/

valeuz...

quinta-feira, abril 06, 2006

XP, Seu nogueira e algumas lendas.

Como eu disse num post já bem antigo aqui do blastemica, o povo de computação sempre dá um jeito de ligar acontecimentos a algo relacionado a... ora bolas, computação. Foi o sentimento que tive ao ler esse divertido, lendário e, como sempre, interessante post do Thiago Arrais. Não poderia deixar de fazer uma menção aqui.

valeuz...

quarta-feira, março 22, 2006

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...

terça-feira, março 21, 2006

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...

domingo, janeiro 29, 2006

Plugins, tags e extensões

Uma das maneiras recentes mais legais de se catalogar informação é usar tags que podem ser livremente criadas pelos usuários (exemplos: aqui, aqui, aqui e aqui). Tags são um dos destaques, a meu ver, um dos mais interessantes, do que se convencionou chamar de web 2.0. Antes, o que havia era um conjunto de categorias (exemplos aqui e aqui), na maior parte das vezes hierárquicas, criadas por algum administrador da vida e vc precisava, mesmo a contragosto, usar algum ponto da hierarquia. Com tags não. Agora vc categoriza, ou melhor rotula, a informação de acordo com a sua percepção sobre ela. E o melhor, pode compartilhar da percepção que as outras pessoas têm, tanto as que coincidem com as suas quanto as que não. Enfim, tags são um desenvolvimento porque agora as pessoas podem criar as classificações segundo as suas necessidades e vontades.

Vejo isso em arquiteturas que permitem o uso de plugins/extensões também. Agora eu não uso apenas software exatamente como ele vem - out-of-the-box - posso eu mesmo criar extensões de acordo com necessidades bastante particulares. Dos softwares que já usei, um dos primeiros, ao menos que eu me lembre, com esse tipo de funcionalidade era o Winamp. Agora, para mim, um dos melhores exemplos é o Firefox, o tal browser que incomoda a liderança menos folgada do Internet Explorer. E das tantas - e úteis - extensões para o Firefox, uma que me chama a atenção ainda mais é o Greasemonkey porque leva adiante o conceito de extensão. Vejo o Greasemonkey praticamente como uma extensão que permite criar extensões.

É uma daquelas sacadas bem geniais e, como boa parte das idéias geniais, se baseia em um conceito simples: que tal alterar as paginas que vc usa com freqüência? Colocar os links que vc mais usa e não aparecem de imediato, botões para ações comuns, remover partes da pagina que vc não usa, mudar o tamanho das letras, remover propagandas inconvenientes, enfim, o que fazer fica a seu critério. Isso tudo com scripts escritos em JavaScript (se vc for um programador, clique aqui), o bom conceito de se manter compatível com o que já existe. O tal do Greasemonkey é bom ao ponto de mudar minha visão preconceituosa sobre JavaScript - depois de Ruby a linguagem que mais desperta minha curiosidade, para ir alem de apenas validar formularios ou outras funcionalidades mais simples. Mas isso é outra história, preciso criar coragem para começar a escrever um post sobre APIs para daqui a pouco.

valeuz...

sexta-feira, dezembro 30, 2005

Adeus ano velho...

Feliz 2006! Sim eu sei que ainda não chegou, mas ninguém espera que eu vá bloggar durante a virada de ano, então, antes de viajar para Pipa - estou com preguiça de procurar algo no google para linkar, se vira! - ficam os votos para um ano melhor do que 2005, para todos vocês três, meus caros leitores.

Espero uma boa festa em Pipa, até porque, veja bem, apesar de nunca ter ido lá, nem ser lá, nem ir para ficar, sempre me falam bem, então as expectativas são as melhores possiveis. Blog novamente apenas lá para o dia 4 de janeiro de 2006 quando volto a falar sobre qualidade de código, sobre Ruby ou qualquer outra lombra/lenda/mito que atraia meu interesse.

valeuz...

quarta-feira, dezembro 28, 2005

Ruby no tempo livre.

Eu falei de Ruby apenas uma vez no blog até agora, na verdade, não diretamente de Ruby, e não escrevi nada mais do que algumas linhas embasbacadas por um video do RoR. De lá para cá, no tempo livre, parei para estudar um pouco sobre a linguagem e sempre fica aquela impressão de "não pode ser, só isso?" ou "hum, interessante". Esses dias enquanto fuçava no repositorio remoto do gem em busca de alguma biblioteca para rss - sei lá porque rss, oras - encontrei o Simple-RSS (para instalar gem install simple-rss), e convenhamos, o "simple" no nome é bem justificado. Para testar, resolvi ler o rss dos novos posts no forum do JavaFree. Nada de muito complicado, apenas acessar o rss, iterar sobre as entradas e mostrar os titulos dos posts. O código, gigantesco, 5 linhas, um absurdo, ficou assim:
require 'rubygems'
require 'simple-rss'
require 'open-uri'
rss = SimpleRSS.parse open('http://www.javafree.org/javabb/rss/newPosts.jbb')
rss.channel.entries.each {|e| puts e.title}
Nem quero imaginar como fazer um leitor RSS em Java. De qualquer modo, claro, uma ajudinha das closures, ausentes em Java, não fazem mal a ninguém. Por fim, nada de RoR, por enquanto, já que quero aprender Ruby para valer e depois sim usar o framework com alguns "add-ons". Os planos são fazer uma serie de exemplos simples e praticos até me sentir à vontade com a sintaxe. A proposito, acho que um livro não vai fazer mal.

valeuz...