Tempo passou até que eu voltasse a escrever. E coisas ocorreram nesse meio tempo. E como ocorreram. Mas deixamo-as de lado e vamos falar de assuntos relacionados à...telas de cadastro, claro.
Estou pensando no Merlin para dizer a verdade. E para ser mais exato, no mecanismo de realimentação dele.
O Merlin, brevemente, é um gerador de telas de cadastro baseado em modelos. Em palavras de programador, como eu gosto, ele lê, em tempo de execução e via reflexão, o modelo de dados (as classes POJO) do sistema e, usando uma série de heurísticas e outras regras, ele renderiza (e esse é o termo que acho mais correto) as interfaces de usuário para edição de dados, ou, no jargão dos desenvolvedores, as telas de cadastro. Em suma é isso, mas na prática o negócio é bem complexo. Mas funciona. E como funciona.
Muitas abordagens semelhantes (embora todas essas gerem código - e o Merlin não) tentam fazer coisas parecidas. Mas elas são mais complicadas (e nada práticas). Mas e a realimentação? O Merlin baseia-se em um esquema de realimentação de contexto. Em palavras mais simples, o Merlin considera todo o histórico de desenvolvimento para gerar uma tela de cadastro. Por exemplo, se no sistema S1, você disse que o campo "br.com.minhaEmpresa.sistemaS1.modelo.beans.Usuario.descricao" deve ser renderizado na tela (de cadastro) como "Descrição do usuário", lá no sistema S2, S3...Sn, quando ocorrer algo parecido, o Merlin vai "se lembrar" disso e vai fazer isso automaticamente pra você. Veja a figura abaixo:
Na verdade, o Merlin "se lembra" de tudo. E mais. Ele usa um mecanismo federado para isso. Isso significa que, caso sua empresa (de desenvolvimento de software) tenha filiais espalhadas por cidades, estados ou mesmo em países diferentes, você pode configurar uma federação e o histórico de qualquer um desses lugares será compartilhado entre todos. Mas para isso funcionar, é necessário um compartilhamento de informações muito grande. Na prática, o classpath de todas as aplicações desenvolvidas (S1, S2, S3, Sn) em todas as filiais, deve ser compartilhado. E ai as coisas começam a ficar complicadas. Nesse ponto entram mecanismos de gerência de escrita, de versionamento, de modificação, de atualização do histórico, de propagação de modificações e, óbvio, de segurança. E isso são somente alguns problemas envolvidos.
O Merlin é tema da minha dissertação de mestrado e, a realimentação deve ser um dos capítulos do trabalho. E imagino que será o maior deles (e bem desproporcional, para dizer a verdade). Tenho planos na cabeça de como fazer isso, mas são somente planos. Preciso diagramar, testar e implementar muito antes de tomar uma decisão. Preciso estudar sobre o próprio conceito de federação, sistemas de métricas e estimativas (sim, pois um histórico não é somente uma média aritmética de pontos - a coisa é bem mais complicada. Vou falar disso em outro post), mecanismos de armazenamento e configuração, propagação e técnicas de mensageria, cache e persistência. E isso são somente alguns itens da "famosa" realimentação.
Deve ser por isso que nenhuma outra ferramenta que eu tenha pesquisado até agora implementou isso. Em suma, para dizer a verdade, somente um dos artigos comentou, veja bem somente comentou, que seria interessante o uso de informações históricas a fim de tornar as ferramentas mais pró-ativas. Bem, e tudo isso foi somente um ponto dentro do Merlin, que é um dos meus a fazeres no momento. Que esses próximos 4 meses sejam longos. Bem longos.
Estou pensando no Merlin para dizer a verdade. E para ser mais exato, no mecanismo de realimentação dele.
O Merlin, brevemente, é um gerador de telas de cadastro baseado em modelos. Em palavras de programador, como eu gosto, ele lê, em tempo de execução e via reflexão, o modelo de dados (as classes POJO) do sistema e, usando uma série de heurísticas e outras regras, ele renderiza (e esse é o termo que acho mais correto) as interfaces de usuário para edição de dados, ou, no jargão dos desenvolvedores, as telas de cadastro. Em suma é isso, mas na prática o negócio é bem complexo. Mas funciona. E como funciona.
Muitas abordagens semelhantes (embora todas essas gerem código - e o Merlin não) tentam fazer coisas parecidas. Mas elas são mais complicadas (e nada práticas). Mas e a realimentação? O Merlin baseia-se em um esquema de realimentação de contexto. Em palavras mais simples, o Merlin considera todo o histórico de desenvolvimento para gerar uma tela de cadastro. Por exemplo, se no sistema S1, você disse que o campo "br.com.minhaEmpresa.sistemaS1.modelo.beans.Usuario.descricao" deve ser renderizado na tela (de cadastro) como "Descrição do usuário", lá no sistema S2, S3...Sn, quando ocorrer algo parecido, o Merlin vai "se lembrar" disso e vai fazer isso automaticamente pra você. Veja a figura abaixo:
Na verdade, o Merlin "se lembra" de tudo. E mais. Ele usa um mecanismo federado para isso. Isso significa que, caso sua empresa (de desenvolvimento de software) tenha filiais espalhadas por cidades, estados ou mesmo em países diferentes, você pode configurar uma federação e o histórico de qualquer um desses lugares será compartilhado entre todos. Mas para isso funcionar, é necessário um compartilhamento de informações muito grande. Na prática, o classpath de todas as aplicações desenvolvidas (S1, S2, S3, Sn) em todas as filiais, deve ser compartilhado. E ai as coisas começam a ficar complicadas. Nesse ponto entram mecanismos de gerência de escrita, de versionamento, de modificação, de atualização do histórico, de propagação de modificações e, óbvio, de segurança. E isso são somente alguns problemas envolvidos.
O Merlin é tema da minha dissertação de mestrado e, a realimentação deve ser um dos capítulos do trabalho. E imagino que será o maior deles (e bem desproporcional, para dizer a verdade). Tenho planos na cabeça de como fazer isso, mas são somente planos. Preciso diagramar, testar e implementar muito antes de tomar uma decisão. Preciso estudar sobre o próprio conceito de federação, sistemas de métricas e estimativas (sim, pois um histórico não é somente uma média aritmética de pontos - a coisa é bem mais complicada. Vou falar disso em outro post), mecanismos de armazenamento e configuração, propagação e técnicas de mensageria, cache e persistência. E isso são somente alguns itens da "famosa" realimentação.
Deve ser por isso que nenhuma outra ferramenta que eu tenha pesquisado até agora implementou isso. Em suma, para dizer a verdade, somente um dos artigos comentou, veja bem somente comentou, que seria interessante o uso de informações históricas a fim de tornar as ferramentas mais pró-ativas. Bem, e tudo isso foi somente um ponto dentro do Merlin, que é um dos meus a fazeres no momento. Que esses próximos 4 meses sejam longos. Bem longos.
0 comentários:
Postar um comentário