Não adianta

Já procurei por todo canto
mas não adianta
na melodia de luiz ela não se escondeu
pelo pagode de zeca ela não anda

A vila de martinho vasculhei
pela batida do pandeiro de jackson tentei chamar
onde se meteu, não sei
para tê-la de volta, até a viola de paulinho eu fiz chorar

não adianta
sem ela, emudeceu-se tudo que canta
nem implorando
tudo que gritava, agora anda susurrando
esperando ela voltar…

chora viola de paulinho
canta um pagode, zeca pagodinho
pra ela voltar

eu trago martinho lá da vila
de luiz, canto uma melodia
pra ela voltar

Branco no samba

Resolveu fazer samba
chamou a mulher de preta, morena, minha menina
saiu como malandro
descendo o morro e esbarrando em rima
calça branca, bem feita a bainha
passos leves, como quem tem os pés a meio metro do chão
sorriso fácil, ginga no corpo, apesar da pele cor de algodão

Brigou com a gaita
mas quem chorou foi o cavaco
deu no pandeiro com tanta força
que acordou o pessoal dos barracos

e todo mundo sambou
embora não fosse samba de preto velho,
teve gente que até gostou

e todo mundo sorriu
embora não fosse malandro pra isso
teve mulata casada que por ele perdia o juízo

e todo mundo cantou em coro,
o refrão descompassado
do sambista que não veio do morro.

Errata: Quantificando facilidade de uso

Me expressei mal em relação à métrica do post anterior.

Quando disse:

"eu faço uma comparação simples entre o número de métodos que o programador esperava que houvesse na API e o número de métodos que realmente estão lá."

Eu quis dizer: Eu contabilizo quantos dos métodos presentes no pseudocódigo estão na API. A medida é a API tem X% do que o cara espera. Ou seja, eu pego os métodos que ele gostaria que tivesse na API e vejo quantos deles estão presentes nela.

Quantificando facilidade de uso

Estou fazendo a avaliação de usabilidade de uma API. O método que estou seguindo é o "think aloud protocol for APIs" - um método baseado na avaliação de usabilidade de interfaces gráficas e que foi modificado para APIs.

Em linhas gerais, este método consiste em observar programadores durante o desenvolvimento de algumas tarefas que usam a API. A parte do Think Aloud é feita pelo programador. Ele verbaliza quais as dificuldades que encontra pelo caminho para escrever o código de determinada tarefa. Este método, portanto, suporta a avaliação qualitativa de APIs, pois a observação do comportamento do programador é uma de suas bases.

No entanto, como eu sempre gosto de extrair números das coisas que estou avaliando, acabei bolando uma métrica baseada na seguinte frase:

"It is the comparison between what developers expect and what the API provides that is interesting when evaluating the usability of an API" (Steven Clarck)

O que eu fiz foi pedir para que os programadores, sem conhecer a API, fizessem o pseudocodigo de determinada tarefa. A partir daí eu faço uma comparação simples entre o número de métodos que o programador esperava que houvesse na API e o número de métodos que realmente estão lá.

É uma métrica simples, mas acredito que podem tornar as coisas menos subjetivas.

Dessa maneira, acabo me aproveitando de todo o apoio do protocolo para avaliação subjetiva e ainda crio uma métrica que pode servir como resultado quantitativo.

O que acham?

Como fazer um review

Preciso fazer a revisão de um artigo e achava que tinha idéia de como fazer. Decidi pesquisar sobre o assunto e Tico Meleca me orientou ler um artigo muito interessante que dá diretrizes de como fazer uma revisão. Leia aqui.

Vou relatar algumas dessas dicas, sobretudo as que achei interessante:

#1 - Faça um resumo do artigo
#2 - Faça um ensaio sobre as contribuições do artigo

Comentários específicos

#3 - Inovação. O que há de novo no trabalho? Algum trabalho relacionado foi deixado de lado? O trabalho relacionado invalida o trabalho do artigo?

#4 - Quão bem escrito é o paper? Mais uma vez, o foco aqui parece ser o de indentificar se a escrita está clara. Se o problema é bem delimitado. Em segundo plano, mas também importante, entra detalhes gramaticais.

#5 - Aponte detalhes positivos que te chamou a atenção.

#6 - Aponte detalhes negativos que te chamou a atenção.

#7 - O paper se enquandra na conferência que ele se propõe a ser aceito? Isto é, ele está em conformidade com o CFP?

Por fim, uma conclusão seria interessante. Você pode separar pontos positivos e negativos, mas o mais importante são as recomendações e sugestões que você tem para contribuir com o trabalho sendo avaliado.

Ser revisor de um artigo dá uma certa posição de poder em relação aos autores. Principalmente porque a revisão é anônima. A dica do autor é não abusar desse poder. Não seja irônico, rude ou boa praça. Cuidado com a escrita de críticas e elogios.

Separei uma frase muito abcana que resume o espírito de uma revisão:

"it’s very easy to transform every negative comment into a constructive suggestion"

[]'s

Jazoon!

Eu e o Seu Gosling no Jazoon.

Experimentação

Voltei :) Estou em fase de avaliação do meu mestrado e me deparei com um material do professor Guilherme Travessos da UFRJ. É quase uma dedada no olho de boa parte da galera de Engenharia de Software.

"Experimentação é o centro do processo científico. Somente experimentos verificam as teorias. Somente experimentos podem explorar os fatores críticos e dar luz ao fenômeno novo para que as teorias possam ser formuladas e corrigidas. Experimentação oferece o modo sistemático, disciplinado,computável e controlado para avaliação da atividade humana. Novos métodos, técnicas, linguagens e erramentas não deveriam ser apenas sugeridos, publicados ou apresentados para venda sem experimentação e validação. Portanto, é preciso avaliar novas invenções e sugestões em comparação com as existentes."


Vale a pena lembrar que fiquei cego do olho direito, pois acabo de publicar em uma track chamada New Ideas and Emerging Results :)