sexta-feira, 16 de julho de 2010

A proposito, uma tela simples

Eu no (otimo) La Fiamma, no segundo Red... abri o Eclipse so para rodar isso...




Coisiboa ;)

quinta-feira, 15 de julho de 2010

Snapshots, a saida para o controle do passado?

O uso de configurações históricas no Merlin é a base de toda a sua capacidade de renderização.

Depois de muitas pesquisas, acredito que um termo melhor para isso é chamar a coisa de Configuração por Contexto. E, de forma geral, ela é usada junto à Configuração por Exceção, e ambas cooperam para um modelo altamente eficiente no reuso de informações.

Porém, quando falamos em histórico, ou melhor, em contexto, o problema é que ele pode mudar constantemente. Vou dar um exemplo:

Supomos que temos um campo String Nome no sistema S4. Sem contexto algum, e sem nenhuma anotação atrelada, isso produz uma tela de cadastro com um controle de tela simples do tipo texto. Nada demais. Digamos que esse sistema S4 foi feito hoje, 15/Jul/2010.

Agora, se inserimos no contexto do Merlin, informações de um sistema S1, mais antigo, desenvolvido lá pelo ano de 2007 (sei lá, talvez a empresa adquiriu outra empresa, e lá no servidor de aplicação um aplicativo mais antigo foi deployado junto, e o classpath do Merlin localizou esses metadados antigos...).

Nesse caso, se existir alguma classe nesse sistema antigo, que satisfaça as condições de localização espacial do Merlin, por exemplo, uma anotação @Length(40) sobre um camo Nome do tipo String, então, bingo, o contexto acaba de ser mudado, pois o Merlin calcula os pesos (ou melhor, as distâncias) de cada informação, e sugere então que, o campo String Nome do sistema S4 também deva reusar a informação @Length(40). Óbvio, pois sendo S4 mais novo (mais recente) do que S1 (que foi feito lá em 2007), esperamos que as informações históricas sejam reusadas no sistema mais atual S4.

Qual o problema nesse caso?

O problema se resume ao fato que, a cada alteração no contexto, os sistemas podem sofrer alterações de comportamento (nesse caso, o sistema S1) e isso não é nada bom, pois nenhum usuário gostaria de, a cada vez que abrisse uma tela, essa tivesse um comportamento e aparência diferentes...

Bem, e para resolver isso?

Abaixo, copio o algoritmo que bolei ontem a noite antes de ir dormir as 2:48 AM:

1) Se tem um Snapshot, então usa ele e fim.
2) Se tem uma configuração direta (uma anotação atrelada), então usa ela e fim. (Isso é Configuração por Exceção).
3) Ler todo conteúdo do contexto, tanto o passado (sistemas mais antigos) quando o futuro (sistemas mais novos).
4) Calcular as métricas (as distâncias de cada anotação).
5) Escolher a anotação de distância (na verdade, isso é uma função direta que envolve tempo e espaço - falarei mais em outro momento) mais próxima.
6) Produzir um Snapshot com essas distâncias e salvar num meio físico recuperável na próxima renderização.
7) Renderizar o conteúdo da tela de cadastro.
8) Monitorar alterações (se ativado esse comportamento).
9) Fim.

Usando essa lógica de processamento, resolvemos a situação do exemplo acima, e várias outras situações até (bem mais complexas que eu imaginei). Isso porque, quando o sistema S1 entra no contexto, e esse é alterado por essa entrada, o Merlin já tem um Snapshot com tudo o que ele precisa. E assim, se o sistema S4 for renderizado inúmeras vezes, isso não é impactado pelas nuances das alterações do contexto provocadas pelo sistema S1, ou mesmo outros sistemas S2 e S3 mais antigos; ou mesmo ainda sistemas mais novos como S5, S6, etc.

Sei

Sei que tudo isso parece uma loucura, mas aqui no meu minúsculo e limitado cérebro, essas coisas se encaixam e produzem até uma aura sobre o caminho que tenho pela frente até realmente o Merlin tornar-se algo factível.

T+