Segundo um email que eu recebi ontem,

O programa do curso abrange as principais novidades da versão 5 da linguagem HTML até o momento e priorizará a apresentação dos novos elementos com o debate em classe da nova semântica. Alguns exercícios serão aplicados com o intuito de demonstrar as novas implementações. Nossa estrutura infelizmente não comporta a formação de diversas turmas do curso de HTML5 que nos permita atender o grande número de solicitações de interessados, inclusive para outras cidades. Por isso faremos uma seleção dos participantes segundo os critérios de compromissos:

• com a replicação do conteúdo do curso;
• com a publicação livre das aplicações geradas;
• com um projeto real de uso do HTML5;
• e com a participação efetiva em uma comunidade dedicada à melhoria da linguagem.

O propósito do W3C Brasil, mais do que treinar no uso da nova versão, é o de organizar uma rede de interlocutores, formadores e multiplicadores preparados para os debates em torno dos padrões web, gerando massa crítica na formulação das novas recomendações.

Mas no mundo de Miguel, isso caiu como uma bomba atômica.

Resumindo: o mecanismo de autenticação usado pelo Job4Dev e pelo SigaSeuTime simplesmente deixaria de funcionar em algumas horas. No caso do SigaSeuTime, isto era uma catástrofe de proporções enormes, já que boa parte do nosso público vem do Twtter. Uma longa noite me aguardava…até que percebemos que Lullis havia falado besteira, e que na verdade o prazo máximo era 31 de junho. Ufa.

Tive então tempo de estudar um pouco o protocolo, e fazer uma implementação usando algumas libs. Por sorte a documentação do próprio Wiki do Twitter é bem interessante. Gostaria de compartilhar alguns pontos aqui.

Basic Auth

OAuth – Idéia básica

Com este protocolo, seria possível permitir que por exemplo o Job4Dev atualizasse a sua timeline, de forma segura e autenticada, sem que eu precisasse guardar a sua senha na minha base de dados. Conveniente!

OAuth – O protocolo

Vou tentar tornar esta descrição a mais simples possível.

OAuth usa um mecanismo de pares de chaves públicas e privadas para gerar assinaturas, permitindo uma identificação inequivoca da origem de cada requisição. Simples demais?

Ok

Vamos supor que o usuário @mgalves queria que o Job4Dev publique vagas na sua timeline, usando um app que algum dia será criado. Este app possui duas chaves, geradas pelo @job4dev: um consumer key e um consumer secret (que como seu nome diz, deve ser guardada de forma secreta). O passo a passo seria mais ou menos o seguinte:

• O app gera uma requisição especial HTTP, usando as duas chaves citadas acima, para obter um token de request temporário.
• Com este token em mãos, o app gera uma requisição HTTP de autorização de acesso para o Twitter. Esta requisição passa como parâmetros o token, o consumer key e uma assinatura gerada a partir de um hash (SHA) de uma string composta pelo token, pelo consumer key e pelo consumer secret key. Portanto, é única, e apenas o app do Job4Dev é capaz de gerar (comprovando assim a procedência da chamada).
• O Twitter já sabe, a partir da assinatura, que quem está pedindo permissão de acesso é o Job4Dev. Falta saber qual usuário irá autorizar o acesso: para isso o site pede que eu, @mgalves, efetue o login e explicitamente autorize o acesso.
• Autorizado o acesso, o Twitter envia para o app um novo par de chaves que serão utilizados para assinar as demais requisições, e que mapeiam de forma única a permissão de acesso do app job4dev aos recursos da conta de @mgalves. Caso eu resolva REVOGAR o acesso, basta invalidar estas novas chaves.

Um ponto importante deve ser ressaltado quanto ao último passo. O retorno do novo par de chaves pode ser feito de duas formas: callback e PIN code. Callback é a forma padrão descrita no protocolo do OAuth, e simplemente consiste em definir um callback HTTP no app que está pedindo acesso, que será chamado pelo provedor (no caso o Twitter) ao final do processo passando as chaves por parâmero POST.

Mas isso apenas funciona se o app em questão for web, e puder responder a uma requisição HTTP. Caso isto não aconteça (como no Tweetdeck por exemplo), o Twitter exibe na tela um código numérico único chamado PIN CODE: o app deve receber este PIN code (copy & paste) e gerar uma nova requisição passando o token, o pin code e a assinatura, cujo retorno é o par de chaves.

E o TweetDeck?

Fucei a documentação do Twitter e achei uma extensão ao protocolo chamada de XAuth, uma pequena variação que permite que as chaves de acesso sejam obtidas através de uma requisição especial contendo username e senha do usuário. Isso evita a necessidade do protocolo definido acima, e funciona bem em casos onde quem vai acessar os recursos é o dono da conta.

Mas segundo o Twitter, para que um app que queira usar este protocolo deve entrar em contato diretamente com eles, explicando a real necessidade.

Tipagem forte, tipagem fraca, tipagem estática, tipagem dinâmica. Existem prós e contras para cada lado, e os defensores de cada campo passam horas e horas tentando provar que o esquema alheio é péssimo. Tendo trabalhado com todos, programando em Java, Python, Javascript e C, chego à conclusão de que é possível ser feliz e produtivo com qualquer uma delas.

Mas nem tudo é perfeito, e em algumas situações, o jardim do vizinho é mais verde…

Sinto falta em alguns momentos de poder tipificar parâmetros de funções em Python, por dois motivos. O primeiro é para evitar que parâmetros de tipos errados sejam passados inadvertidamente: fazer verificação de tipo no início de um método ou função é simples, mas as vezes consome tempo de programação inútil.

O outro que mais me incomoda é que a falta desta tipagem impede que se utilize um recurso muito útil e elegante que é a sobrecarga de método. Basicamente, em Python não é possível criar vários métodos com o mesmo nome e com assinaturas diferentes. O jeito Python de resolver isso é verificando o tipo dentro do método, ou então criando um mecanismo de dispatch, usando os famosos dicionários (que são extremamente eficientes. Ousam dizer por aí que é a implementação mais eficiente que existe….).

Ambas funcionam, mas não são tão elegantes como a solução oferecida pela sobrecarga. Aproveito, pergunto: existe alguma forma mais elegante de se fazer isso em Python?

Fica aqui a minha sugestão. HEY, GUIDO, TIPIFICA OPCIONALMENTE PARÂMETRO DE MÉTODO AÍ!

Sempre fiquei muito intrigado com um fato que recorrentemente eu presenciava: precisava ler um arquivo de “texto puro” mas, quando abria o arquivo, lá estavam vários caracteres esquisitos ou pontos de interrogação ou qualquer coisa que não deveria estar lá. Ou seja, o programa que eu estava usando não conseguia reconhecer adequadamente o charset do arquivo e, quando tentava mostrar os caracteres usando o charset padrão do programa, um punhado de coisa ficava zuada.

Ficava sempre pensando que alguma coisa idiota devia estar acontecendo, afinal de contas, como um programa não conseguia reconhecer um charset? Tantos anos de evolução na computação e uma coisa simples como esta ainda não funcionava direito? Tentava de várias formas bolar uma solução para isso mas, qualquer coisa que eu pensava, não era uma solução que eu achasse viável. Afinal, a maneira mais fácil de identificar um charset seria colocar uma espécia de meta-dado no arquivo, como é (deveria ser) feito com páginas web (mas nem sempre funciona também por falhas nos programas!). E aí o arquivo deixaria de ser um arquivo de “texto puro”.

Enfim, não tinha uma solução para este “problema” e, pelo jeito, via que ninguém mais tinha, afinal o problema continuava existindo. Mas ele continuava me incomodando de tempos em tempos.

Até que li este texto do Joel. E aquietei meu espírito em relação a este problema. O texto inteiro é bom, especialmente a parte final The Single Most Important Fact About Encodings. E o que resume tudo é esta frase: There Ain’t No Such Thing As Plain Text. Ou, numa tradução livre: “Não existe algo como texto puro”.

Ou seja, tudo aquilo que é mostrado pelo programa que abre arquivos de “texto puro” é simplesmente uma abstração. Esqueça os caracteres. Eles são apenas interpretação dos dados reais binários. Qualquer representação dada a eles é apenas resultado de algum processamento por trás que tenta ou não identificar qual foi o charset usado para criar o arquivo.

Por mais óbvio que isso seja e por mais que eu soubesse disso, é engraçado como eu não ligava este simples fato à minha inquietudade em relação ao processamento de arquivos textos pelos programas.

Feito isso, com a ajuda do Joel, problema resolvido!

Como não estou com tempo para fazer tudo isso, vou fazer um mix e ver o que acontece. Resumidamente, vou explicar um pequeno problema que eu tenho envolvendo a implementação de um sistema usando o ORM do Django, e gostaria de saber se alguém vê uma solução correta e elegante.

Usando exemplos reais: estou trabalhando em um projeto que visa analisar registros médicos eletrônicos e identificar se certos casos registrados devem ser notificados ao CDC. Mais especificamente, o que eu quero é analisar o registro de vacinas que a pessoa recebeu e verificar se houve alguma reação adversa. Uma reação adversa pode ser identificada por algo comum como febre, ou algo mais complexo como uma hemorragia ou por um exame de laboratório mostrando uma variação em valores de seus componentes (Hemoglobina, Creatina, Sódio, Potássio, etc).

“Falando” OO, o que eu tenho é a classe AdverseEvent, da qual derivam FeverEvent, DiagnosticsEvent e LabResultEvent. Na hora de construir os relatórios, é necessário obter a lista dos eventos e obter também os atributos específicos de cada subclasse. Até aí OO funciona. E antes que the-one-who-can’t-be-named grite “Design Patterns”, eu vou falar que estamos lidando com a implementação de uma Factory: dada uma lista de chaves que identifique uma lista de AdverseEvents, a Factory instancia o objeto adequado a partir da id fornecida.

O “problema”: esses objetos ficam em um banco de dados, e como mapear isso para um banco de dados relacional e fazer uma factory que construa o objeto adequado com uma única consulta?

Vamos ao código. A primeira solução seria uma implementação que tenta ser puramente OO. O código abaixo é parte de um típico módulo de definição dos seus modelos quando usando Django.

class AdverseEventManager(models.Manager):

    def by_id(self, key):
        for klass in [FeverEvent, DiagnosticsEvent, LabResultEvent]
            try:
                obj = klass.objects.get(id=key)
                return obj
            except: pass
        return None

class AdverseEvent(models.Model):
    # Managers
    objects = models.ModelManager()
    manager = AdverseEventManager()

    # Atributos que realmente são de interesse e vão para o BD.
    patient = models.ForeignKey(Demog)
    immunization = models.ForeignKey(Immunization)
    matching_rule_explain = models.CharField(max_length=200)
    category = models.CharField(max_length=20, choices=ADVERSE_EVENT_CATEGORIES)
    created_on = models.DateTimeField(auto_now_add=True)
    last_updated = models.DateTimeField(auto_now=True)



# Classes filhas. NO BD, são mapeadas para tabelas que contém os campos 
# específicos da classe, e referencia a tabela da classe-pai
class FeverEvent(AdverseEvent):
    temperature = models.FloatField('Temperature')
    encounter = models.ForeignKey(Enc)

class DiagnosticsEvent(AdverseEvent):
    encounter = models.ForeignKey(Enc)
    icd9 = models.ForeignKey(Icd9)


class LabResultEvent(AdverseEvent):
    lab_result = models.ForeignKey(Lx)

O Factory method é by_id. Para os que não conhecem Django, ModelManager.get() faz a consulta no banco de dados e retorna um único objeto da classe que o contém, ou a exceção DoesNotExist se não existir objetos com os parâmetros indicados. Como a chave pertence a classe-pai, podemos ter certeza que não há haverá objetos das classes filhos com o mesmo id. Isso permite que encontremos o objeto desejado. O problema com essa solução é que o número de consultas é proporcional ao número de sub-classes

O segundo esquema é “menos OO”. Para desespero de alguns puristas, nós podemos criar um dicionário no módulo que mapeia as sub classes possíveis e a factory faz sempre duas consultas para obter o objeto apropriado.

ADVERSE_EVENT_CLASSES = {'fever':FeverEvent,
                         'diagnostics':DiagnosticsEvent,
                         'lab_result': LabResultEvent
                         }

class AdverseEventManager(models.Manager):  
    def by_id(self, key):
        try:
           ev = AdverseEvent.objects.get(id=key)
           return ADVERSE_EVENT_CLASSES[ev.event_type].objects.get(id=key)
        except:
            return None

class AdverseEvent(models.Model):
    # Managers
    objects = models.ModelManager()
    manager = AdverseEventManager()

    # Atributos que realmente são de interesse e vão para o BD.
    patient = models.ForeignKey(Demog)
    immunization = models.ForeignKey(Immunization)
    matching_rule_explain = models.CharField(max_length=200)
    category = models.CharField(max_length=20, choices=ADVERSE_EVENT_CATEGORIES)
    created_on = models.DateTimeField(auto_now_add=True)
    last_updated = models.DateTimeField(auto_now=True)

    # Adicionamos esse campo para identificar para saber qual é a subclasse 
    event_type = models.CharField(max_length=20, choices=tuple(ADVERSE_EVENT_CLASSES.items()))

Enfim, só estou expondo as duas soluções que eu conheço para lidar com algo trivial. Se alguém tiver alguma idéia diferente, por favor deixe registrado nos comentários.

Com relação a crítica ao ORM: parte da minha bronca são essas incongruências que existem, o ORM não conseguindo fazer uma boa ponte entre o modelo OO e o modelo E-R. É por detalhes assim que estamos começando a ver uma série de projetos de banco de dados não-relacionais, do qual espero falar mais adiante.

Outra coisa interessante: se você perceber, um banco de dados XML não teria esse problema, entretanto parece que ninguém nunca pensou em implementar o BDB-XML como backend para uma datastore.

Por que integrar com o Twitter?

Sendo rápido e objetivo, decidi usar o Twitter por achar que seu design e seu modo de funcionamento se adequavam perfeitamente àquilo que eu estava buscando: a diversificação dos canais de divulgação das vagas. Esta integração foi possível graças ao fato do microblog oferecer uma API bastante bem feita e bem documentada. Junte a isso a minha vontade de brincar com a plataforma, e temos um cenário perfeito!

E a API do Twitter, como funciona?

Ela é baseada em REST, e permite fazer boa parte (se não tudo) do que um usuário humano poderia fazer. Eu explico sucintamente o seu funcionamento no artigo Conversando com o Twitter. A documentação da API pode ser encontrada em http://apiwiki.twitter.com/.

Mas chega de papo, vamos ao design da coisa…

A integração do Job4Dev com o Twitter começou com as seguintes premissas

• Baixo impacto sobre o tempo de resposta do site no momento do cadastro de uma nova vaga
• Garantia de que TODAS as vagas seriam publicadas no Twitter
• Simplicidade da arquitetura

A chave para se conseguir os dois primeiros ítens é o uso de um sistema assíncrono. Ou seja: a ação de gravação de uma nova vaga na base de dados deve notificar o sistema de que uma nova mensagem deve ser enviada ao Twitter, e o envio deve ser executado em background. Isso evita que problemas na rede ou no próprio microblog (bastante comuns na época do desenvolvimento da funcionalidade) afetem o tempo de resposta.

Para garantir que todas os anúncios fossem enviados, deveria existir um mecanismo que persistisse os tweets em caso de problemas de rede, permitindo envio posterior. Finalmente, para garantir a confiabilidade e a simplicidade, decidi usar o máximo de recursos do sistema operacional. Afinal o Linux para mim é o melhor servidor de aplicações que existe!

E como tudo isso foi implementado?

Eu cogitei gerar a mensagem diretamente a partir da base de dados, uma vez que as informações são gravadas em uma tabela. Mas para garantir que uma vaga fosse enviada apenas uma vez, e permitir que uma mensagem fosse reenviada em caso de problemas de comunição, o esquema das tabelas teria que ser modificado para guardar o estado de processamento do canal Twitter.

Para evitar esta modificação, ao meu ver intrusiva, e aplicando a fundo o conceito K.I.S.S, resolvi utilizar o sistema de arquivos: ao submeter uma vaga, o sistema gera um arquivo texto em um diretório específico, contendo a mensagem a ser enviada. Para garantir que não haja conflito, o nome do arquivo é a URL da vaga.

O envio das mensagens é efetuado por uma tarefa em Python lançada pelo CRON, de 15 em 15 minutos. O algoritmo é simples: verifica no diretório apropriado se existem arquivos de mensagens. Caso existam, abre cada um, lê o conteúdo, formata uma mensagem e efetua a requisição de envio para o Twitter. Caso a mensagem seja enviada com sucesso, remove o arquivo. Caso contrário, registra o erro em um arquivo de log e deixa o arquivo no diretório para uma execução futura.

Os mais curiosos poderão ver o código do módulo Twitter aqui. Este módulo pode ser livremente utilizado para implementação de uma funcionalidade semelhante. Basta passar por parâmetro o nome do diretório, o nome de usuário no microblog e a senha.

Para mim, uma das coisas que mais marcarm a virada do ano no Brasil foi a entrada em vigência da nova ortografia da língua portuguesa falada por aqui. Dizem que isso foi para unificar melhor a língua portuguesa falada em diversos países. Sinceramente, sempre tive dúvida em relação a argumentos como este. Sempre escutei na escola que a língua é um “ser” em constante mutação e evolução causada pelo seu uso pelo povo. Se isso é verdade, até quando a ortografia vai ser comum em todos os países de língua portuguesa? Até os políticos aprovarem outra lei para unificarem novamente as línguas que se mudaram com o tempo? Enfim… não sou especialista neste assunto e este não é um blog sobre línguas. Então vou deixar este assunto de lado um pouco.

Por outro lado, no final do ano, durante as minhas férias, quando em geral eu me afasto consideravelmente dos computadores, uma pessoa próxima e com mais que o dobro da minha idade veio até mim reclamar que o UOL tinha mudado a interface do seu webmail e agora ela estava perdida. A questão é que apesar da idade, esta pessoa que eu conheço é bem interessada em relação à tecnologia de uma forma geral e mexe no computador com certo traquejo. Aliás, a reclamação em relação ao webmail era justamente porque ela usa esta aplicação como ferramenta de trabalho diária. Como eu estava por perto acabei indo ajudá-la com as dúvidas em relação ao novo webmail do UOL. Como eu tenho conta no BOL (que usa o mesmo engine de webmail que o UOL) eu sabia como era a antiga ferramenta. Já era um bom começo, imaginei eu. Mas confesso que, após ver o novo webmail, fiquei frustrado. Eu ainda conseguia utilizá-lo, mas ele tinha ficado mais difícil. Isso tudo para que ele fosse, “finalmente”, Web 2.0! Grande coisa! Mas, vá lá… eu conseguia usá-lo. Mas a pessoa que estava ali do meu lado estava com sérias dificuldades. E com razão! Para se ter uma idéia a lista de contatos era mostrada por ordem alfabética de… e-mail. Ou seja, se eu tivesse cadastrado nos meus contatos alguém com nome Miguel mas que tivesse o e-mail frances@algumlugar.com o nome Miguel aparceria na letra F!!!

Depois de ver isso e outras coisas toscas (tudo em nome da famigerada Web 2.0!) fiquei  pensando na frustração da pessoa que veio me pedir ajuda. Fiquei tentando imaginar como era esta frustração porque, como eu disse, apesar de eu achar difícil, vá lá, eu ainda conseguia usar o webmail.

Depois de refletir durante um tempo eu acabei achando algo que, para mim, parecia ser equivalente àquela sensação de frustração: a tal mudança ortográfica do português.

Talvez o que realmente me incomode e fruste com esta nova ortografia seja a mudança em si. Eu fui alfabetizado e escrevo há mais de 10 anos segundo as normas da velha ortografia (que, diga-se de passagem, valerá até 2012; não misturá-las até lá é que vai ser difícil). Mudanças sempre incomodam e ter que reaprender a escrever vai ser um pouco chato. Mas, sinceramente, nada muito complicado neste caso, eu acho. Mais cedo ou mais tarde vou me acostumar (ainda mais com os corretores ortográficos de hoje em dia ). Mas fico imaginando: se eu já estou achando chato ter que reaprender o português, imagina a geração dos meus pais que está passando por isso pela segunda vez depois que foram alfabetizados. E a dos meus avôs que já passaram por isso três ou quatro vezes? Não sei como isso funciona em outros países, mas acho que estas mudanças políticas no Brasil não fazem muito sentido… ainda mais nesta quantidade. Como será que as pessoas mais velhas se sentem? Talvez já nem estejam se importando mais em aprender direito a nova ortografia se isso não impactar diretamente a vida delas.

Imagino que o sentimento de algumas pessoas em relação aos sistemas computacionais seja parecido. Apesar de as pessoas se acostumarem com eles e aprenderem a utilizá-los, de uma hora para outra, alguém decide que é necessário pegar um sistema que funciona razoavelmente bem e alterá-lo apenas para seguir as tendências da moda Web 2.0, prejudicando imediatamente um incontável número de pessoas que não estavam assim tão interessadas no modismo. Depois de algum tempo não seria de se estranhar que algumas dessas pessoas “desistissem” de tentar reaprender a utilizar o sistema.

Vejam que não sou contra mudanças! Desde que elas sejam necessárias, bem pensadas, planejadas, e de que venham para melhorar efetivamente a vida das pessoas, facilitando as tarefas. Sou contra mudanças políticas: como me parece ser a mudança ortográfica e como me pareceu ser a alteração do webmail do UOL (para citar só um exemplo na computação).

Por isso caros leitores, a mensagem que eu gostaria de deixar nesta primeira mensagem que escrevo este ano é uma que já foi tratada aqui neste blog outras vezes: quando você estiver desenhando um sistema ou redesenhando uma funcionalidade já existente, pergunte-se sempre se você está tomando decisões que realmente agregam valor e funcionalidade às suas alterações. Fujam das alterações políticas e burocráticas e, se necessário, fuja dos modismos também. Saiba utilizar as ferramentas e as tecnologias com aquilo que elas melhor tem a lhe oferecer e não vire escravo das novas siglas que aparecem o tempo todo.

Motivação e Exemplo

No meu ponto de vista, AOSD não é algo que veio revolucionar o desenvolvimento de software, mas sim um avanço incremental do paradigma de orientação a objetos (OO). Todo bom programador sabe que se deve tentar distribuir as responsabilidades (concerns) do programa em módulos, de forma que cada módulo seja fácil de implementar, entender e reusar. Em C, por exemplo, funções podem ser consideradas módulos. Pra qualquer programa não trivial, você não vai criar somente uma função main(), vai separar a funcionalidade em muitas funções que se chamam pra realizar o objetivo do software. Já OO prega a modularização do software em uma hierarquia de classes e conta com polimorfismo, herança, etc. A motivação de AOSD é que existem algum concerns que entrecortam a hierarquia, ou seja, que mesmo criando essa hierarquia de classes, você não tem como separar dois concerns que deveriam ser separados (para serem melhor implementados, entendidos e reusados).

Pra não ficar somente no abstrato, vamos à um exemplo bem simples, que é utilizado constantemente pra apresentar AOP. Imagine que você tem uma classe que faz o controle do acesso ao banco de dados. O código abaixo é um esboço de como uma classe dessas seria implementada em Java. Você tem um gerente de transações e, em todos os métodos de acesso ao banco de dados, você chama o gerente pra iniciar uma transação e fazer commit se tudo deu certo, ou rollback se deu algum problema. Note que hoje em dia ninguém faria um código assim, já que existem soluções melhores do que ficar escrevendo SQL no seu código (como Hibernate), mas é bem ilustrativo do problema.

public class DB {
    TransactionManager manager = ...;

public void storeUser(User u) {
    manager.start();
    try {
        // write some sql code storing u into the DB
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}
public void storeAccount(Account a) {
    manager.start();
    try {
        // write some sql code storing a into the DB
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}
...


}

public interface TransactionalTask {
    public void execute();
}
public class TransactionManager {
    TransactionManager manager = ...;

public void executeInTransaction(TransactionalTask task) {
    manager.start();
    try {
        task.execute();
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}
...


}
public class DB {
    public void storeUser(User u) {
        manager.executeInTransaction(new TransactionalTask() {
            public void execute() {
                // write some sql code storing u into the DB
            }
        });
    }
    ...
}

public aspect TransactionManagerAspect {
    TransactionManager manager = ...;

around(Object o) : execution(public void DB.*(..)) && args(o) {
    manager.start();
    try {
        proceed(o);
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}


}

public class DB {

public void storeUser(User u) {
    // write some sql code storing u into the DB
}
public void storeAccount(Account a) {
    // write some sql code storing a into the DB
}
...


}

Esse exemplo mostra a parte dinâmica da história, isto é, como usar aspectos pra “interceptar” alguns pontos da execução de um programa e inserir (ou remover) funcionalidade (código) nesses pontos. Mas AOSD também trata da parte estática ou “estrutural” da coisa. Por exemplo, imagine que no nosso exemplo nós quiséssemos inserir um controle de concorrência bem primitivo, pra garantir que ninguém modificou o User no tempo entre eu buscar no banco e salvar. Pra isso, eu poderia adicionar um campo na classe User com um contador que é incrementado sempre que ele for salvo no banco. Desta forma, na hora de salvar, eu confiro se o valor do contador no objeto que recebi é o mesmo do banco de dados. Se não for, significa que alguém alterou o objeto e eu recebi um objeto inconsistente. Novamente, o problema é que esse campo não faz parte do concern persistência ou modelo de dados. Portanto, não faria sentido eu declarar o contador na classe User. Pra resolver esse problema, AspectJ usa intertype declarations, que permitem a declaracão de campos e métodos em outras classes. Por exemplo, o código abaixo declara e inicializa um campo counter na classe User, removendo dela o concern tratamento de concorrência.

public aspect ConcurrencyManagerAspect {
    long User.counter = 0;
    ...
}

Quando eu estava descrevendo o exemplo eu me referi à alguns conceitos de AOSD. Mas acho importante deixar um pouco mais explícito, então seguem algumas definições.

Existem alguns eventos que acontecem durante a execução de um programa que são interessantes de serem interceptados. Esses pontos são chamados join points. Nós vimos que a execução de um método é um ponto interessante quando o objetivo é substituir o método ou introduzir funcionalidade antes ou depois do método. Outros join points, por exemplo, são a chamada de um método (não confundir com a execução), a leitura ou escrita de um campo, ou a inicialização estática de uma classe. Mas esses join points são eventos concretos que acontecem em tempo de execução. Pointcuts são um jeito de especificar de forma abstrata (por exemplo, com regular expressions) quais join points você quer interceptar. AspectJ oferece pointcuts primitivos pros join points mais importantes (como execution, call, get, etc) e outros pointcuts usados pra identificar os objetos envolvidos nos eventos e ligá-los a variáveis. No nosso exemplo, args foi usado pra pegar uma referência ao objeto passado como parâmetro ao método. Outros pointcuts importantes são target (e.g., o objeto que é o destino de uma chamada de método) e this (e.g., o objeto que faz a chamada).

Quando um join point acontece em runtime e ele faz match com um pointcut, então se executa o advice relativo ao pointcut (se tiver algum). Nós vimos como um advice do tipo around funciona. AspectJ também tem advices before e after (que pode ser after throwing ou after returning), que servem pra introduzir código antes ou depois do join point. Intertype declarations também são disponibilizadas por AspectJ pra introduzir novos campos métodos em outras classes, como vimos no exemplo.

Um aspecto é então um módulo usado pra encapsular todas essas construções, do mesmo jeito que uma classe encapsula métodos e campos. O objetivo principal de um aspecto é de modularizar um interesse (concern) que não faz parte da decomposição normal da hierarquia de classes. Esses concerns são chamados de crosscutting concerns, porque eles entrecortam a hierarquia. A implementação de um concern é dita espalhada (scattered) quando ela não está localizada, e entrelaçada (tangled) quando ela está misturada com outros concerns.

Pra quem tiver interesse, o AspectJ Programming Guide é um excelente tutorial com bons exemplos e referências pros diversos tipos de pointcuts, além de explicar alguns problemas que você pode encontrar quando não tiver muita experiência com aspectos.

Discussão

No texto acima eu tratei AOSD e AOP quase como sinônimos, mas eu quero enfatizar que são distintos. Orientação a aspectos surgiu como AOP, pois trazia soluções pra problemas diretamente ligados ao código, como no exemplo sobre controle de transações. Contudo, percebeu-se que seria interessante elevar o nível de abstração e que crosscutting concerns podiam também ser encontrados em design, arquitetura, análise de requisitos, etc. Então AOSD trata não só da programação, mas também de todo o conjunto de metodologias, processos, etc, ligados ao desenvolvimento de software usando a idéia de que crosscutting concerns devem ser tratados como “first class citizens”.

Na minha experiência, AOP como encontrada em AspectJ é utilizada quase que exclusivamente em círculos acadêmicos. Existem algumas empresas que adotam AspectJ para alguns projetos, mas a linguagem está longe de ser adotada em larga escala. Porém, alguns conceitos de AOP são muito usados em alguns frameworks e application servers como Spring e JBoss. Spring, por exemplo, tem o conceito de interceptors, que nada mais são do que pointcuts e advice, mas menos poderosos (não permitem interceptar join points de pouca granularidade, como getters, se não me engano).

Eu acredito que existem atualmente dois grandes impedimentos pra se usar AOP em larga escala. Primeiro é a tecnologia do compilador. Hoje em dia ninguém aceita trabalhar com um compilador que não seja incremental. Quando você usa Eclipse e faz uma alteração no código, o JDT só compila o necessário. O similar para AspectJ, AJDT, tenta fazer o mesmo. Porém, a tarefa é muito mais difícil, pois uma pequena mudança tem que ser verificada perante todos os pointcuts do seu sistema, pois de repente o que você mudou pode agora ser interceptado pelo pointcut. Assim, apesar de ter uma performance relativamente boa, trabalhar com AspectJ usando AJDT não é tao agradável quanto trabalhar com Java usando JDT.

Segundo, AOSD não vai acabar com todos os seus problemas. É difícil pros programadores entenderem os conceitos e leva tempo pra comunidade desenvolver design patterns e entender o que tirar de melhor do paradigma. Pointcuts são atualmente regular expressions, então eles são frágeis e qualquer mudança de nome de um método pode fazer um pointcut não mais interceptar aquele método, e você não tem como perceber que isso aconteceu. Suporte de boas ferramentas é então essencial. Além disso, eu tenho dúvidas de que aspectos sejam bons pra modularizar concerns heterogêneos como “logging”, que foi sempre um dos principais exemplos. O problema é que cada instância de logging é muito específica pro contexto, então não faz sentido você remover todas as chamadas de log e encapsular em um advice, pois o advice teria que ser diferente pra cada ponto que ele interceptasse. Controle de transações é homogêneo, pois o advice sempre faz a mesma coisa, então é um exemplo mais apropriado. Existem estudos que apontam que Mixin Layers são melhores pra concerns heterogêneos como logging, mas isso seria assunto para um outro post.

========================== Nota no dia 5/11

Conversando com o Miguel eu acabei percebendo algo que talvez não tenha ficado muito claro. AspectJ é uma extensão de Java e precisa de um compilador especial que compila as classes como se fossem Java e depois analisa os aspectos do sistema e faz diretamente as modificações no código (ou introduz testes de tempo de execução quando não tem como verificar estaticamente o resultado). Esse último passo, “introduzir os aspectos”, é chamado weaving.

Existem duas alternativas principais de compiladores pra AspectJ. O ajc é parte do AJDT, que é uma extensão do JDT do Eclipse. Como o JDT, o AJDT contém editor, compilador, debugger, e tudo o mais, implementados em plugins pro Eclipse. O principal objetivo do projeto é que a compilação seja rápida pra que você tenha a mesma experiencia que programando em Java, ou seja, ele tenta ser incremental e o código do compilador em si é otimizado (leia-se, não-facilmente extensível).

A outra alternativa é o abc (Aspect Bench Compiler), que é um compilador acadêmico cujo objetivo principal é ser extensível pra que se possa fazer pesquisa com linguagens de programação, otimização de código, análise estática, etc. Dessa forma, compilar um sistema grande com abc, principalmente usando as otimizações disponíveis, é bem demorado. O ideal é programar usando o AJDT e usar o abc pra gerar o bytecode de produção, já que ele é bem mais otimizado que o gerado pelo ajc.

Além disso, AspectJ não é a única linguagem orientada à aspectos derivada de Java. No site da aosd.net, por exemplo, tem uma lista com alguns sistemas (derivados ou não de Java) e algumas ferramentas orientadas a aspectos.

O processo é simples: faça upload ou passe a URL da imagem que deseja analisar, verifique se os caracteres que ele detectou estão corretos e pronto. O resultado é exibido na forma de uma lista de textos em diversas fontes, e o sistema permite a comparação das fontes obtidas com a sua fonte original mostrando a sua imagem sempre no centro da tela.

Utilizei a ferramenta para tentar descobrir as fontes utilizadas pelo Raphael para fazer o logo do job4dev (ele perdeu o arquivo PSD original…), e o resultado obtido está abaixo:

A fonte ATCapone-Light parece a correta!