NOTA: Para quem não conhece o Metagen, sugiro a leitura do documento Sistemas Dinâmicos Baseados em Metamodelos, disponível na área colaborativa do Merlin.
O que é o Metagen?
O Metagen foi nosso (meu e do D. Moreira) primeiro esforço para criação de um sistema de renderização em runtime de interfaces CRUD, ou seja, as telas de cadastro.
Na prática, a idéia não era muito avançcada; ela apenas colocava ênfase para o fato que não precisávamos muito mais do que algumas heurísticas para criar controles de tela durante o uso do sistema, evitando a geração de código-fonte - coisa que sempre odiamos. A idéia era simples e, essencialmente, ela foi evoluindo aos poucos.
Quando iniciei meus trabalhos de programação de telas de cadastro (ainda em Visual Basic 6), eu havia pegado muitos trechos de código repetitivos (meu ex-colega devia ser fã do Control-C, Control-V...). Logo pensei: pô, vou criar um método utilitário aqui!
O embrião: um método utilitário para carregamento de comboboxes
Lembro como se fosse hoje. O trecho de código utilitário que fiz, nada era além de umas 15 linhas de código que recebiam como parâmetro o nome de uma tabela e de um campo, e montava o comando SQL para preencher uma combox. Esse foi o início do Metagen e, por consequencia, o início do Merlin.
Logo, aquele método foi crescendo: mais parâmetros foram colocados e mais funcionalidades ele suportava, como cláusula WHERE, ORDER BY, concatenação de campos, etc.
Algum tempo depois o método nem retornava mais uma coleção de registros para ser colocado em uma comboxes: ele literalmente retornava a combox, a qual era tão colocada no formulário em tempo de execução.
Isso foi em 2002, se não me engano.
O Metagen
Aquela coisa de retornar controles e colocá-los em formulários em tempo de execução era legal, e logo eu estava criando não só comboxes, mas também textfields, labels, botões, checkboxes e outras coisas.
O tempo passava, e as funcionalidades aumentavam. Lembro ainda do dia que chamei o Moreira para a cozinha do café e disse: cara, consegui fazer o bind de métodos em tempo de execução; acho que agora podemos ter aquilo que queríamos.
O que queríamos (bem, pelo menos eu), era um gerador de telas de cadastro, que me retiresse o fardo de criar aqueles famigerados (acho essa palavra muito legal) artefatos de software todos os dias. Uma nova era estava surgindo.
Baseado em texto
Logo logo, nossos conceitos evoluíram, e de código estático de geração, tínhamos estruturas configuráveis a partir de arquivos INI.
Esses eram (ou deveriam ser) gerados por outro utilitário que importava modelos do erWin (conhecem?) através de uma API muito legal (ahaha, como eu gostava desse tempo)....
Delphi e Kylix
O sucesso pareceia certo. O projeto evoluía e já tínhamos migrado para Delphi e, então, Kylix (lembram?), para rodar no Linux também. Época boa, onde tudo parecia fácil.
Foi mais ou menos naquela época que publicamos o artigo acima e que fizemos algumas apresentações do projeto em alguns eventos na região central do Estado.
JH Santos
A coisa ia de vento em popa, e então decidimos que era hora de abrir uma área de pesquisa - nem era, nem poderia ser um negócio, embora querêssemos que fosse.
Saíamos do trabalho e íamos para lá. Levávamos coca-cola, pizza, cachorro-quente, xis (embora essas duas últimas iguarias não eram apreciadas por mim) e café, muito café. Brincávamos de programar em Delphi e fazíamos testes com diversas coisas.
O local? Bem, era uma sala num prédio da antiga...
Mais um para o fim
Mas queríamos mais. E mais significava que precisávamos ter alcance web.
Porém, nem eu nem o D. manjavam de web, e então abrimos "a jogada" para um outro colega, o J.
Agora tínhamos uma equipe de três bonecos: um centrado, um pirado e outro maluco. Orbitávamos em nossos devaneios e rodávamos para lá e para cá.
Acho que a coisa não foi muito para a frente porque, libertos como estávamos, acabamos mirando em muitos lugares e quando parei de contar, eu estava em 1.200 horas de pesquisas que envolviam desde RMI, Delphi, VB, EJB, Hibernate, JDO, Eclipse, Netbeans e ... pára por aí. Acho que não dá mais.
Isso foi em 2004.
Merlin, o renascimento
Não que três fosse demais. Muito pelo contrário. Até hoje acredito que 3 é o número ideal: 3layer diz alguma coisa?
Visto que a JH não era mais nosso lugar, precisávamos de algo novo para brincar. E fomos para o mundo. O mundo livre.
O projeto Merlin fora criado no JavaNet e as brincadeiras lá continuaram.
2005 foi um ano difícil para mim, mas que teve uma recompensa inigualável. E quem me conhece sabe o motivo. Também nesse ano, a 3Layer Tecnologia teve sua pedra fundamental lançada: ganhamos um CNPJ :)
2006 foi um ano de recuperação e 2007 de preparação.
Agora, em 2008 estamos com uma bagagem sólida de estudos - sim, são praticamente 7 anos lapidando essas coisas de telas de cadastro!
Estamos nos focando em transformar a coisa em algo sério, e ao invés de brincar, revolucionar.
Antes de terminar...
...mostro uma tela de cadastro gerada pelo Metagen:
Isso é o que gerávamos em 2003 com o Metagen. Para cada campo na tela, algo em torno de 11 propriedades no arquivo INI eram necessárias. Tínhamos um fraco, mas funcional, suporte para ligação de regras de negócio e as telas eram 100% livres de erro de programação.
E esse, bem por cima mesmo, foi o começo...
O que é o Metagen?
O Metagen foi nosso (meu e do D. Moreira) primeiro esforço para criação de um sistema de renderização em runtime de interfaces CRUD, ou seja, as telas de cadastro.
Na prática, a idéia não era muito avançcada; ela apenas colocava ênfase para o fato que não precisávamos muito mais do que algumas heurísticas para criar controles de tela durante o uso do sistema, evitando a geração de código-fonte - coisa que sempre odiamos. A idéia era simples e, essencialmente, ela foi evoluindo aos poucos.
Quando iniciei meus trabalhos de programação de telas de cadastro (ainda em Visual Basic 6), eu havia pegado muitos trechos de código repetitivos (meu ex-colega devia ser fã do Control-C, Control-V...). Logo pensei: pô, vou criar um método utilitário aqui!
O embrião: um método utilitário para carregamento de comboboxes
Lembro como se fosse hoje. O trecho de código utilitário que fiz, nada era além de umas 15 linhas de código que recebiam como parâmetro o nome de uma tabela e de um campo, e montava o comando SQL para preencher uma combox. Esse foi o início do Metagen e, por consequencia, o início do Merlin.
Logo, aquele método foi crescendo: mais parâmetros foram colocados e mais funcionalidades ele suportava, como cláusula WHERE, ORDER BY, concatenação de campos, etc.
Algum tempo depois o método nem retornava mais uma coleção de registros para ser colocado em uma comboxes: ele literalmente retornava a combox, a qual era tão colocada no formulário em tempo de execução.
Isso foi em 2002, se não me engano.
O Metagen
Aquela coisa de retornar controles e colocá-los em formulários em tempo de execução era legal, e logo eu estava criando não só comboxes, mas também textfields, labels, botões, checkboxes e outras coisas.
O tempo passava, e as funcionalidades aumentavam. Lembro ainda do dia que chamei o Moreira para a cozinha do café e disse: cara, consegui fazer o bind de métodos em tempo de execução; acho que agora podemos ter aquilo que queríamos.
O que queríamos (bem, pelo menos eu), era um gerador de telas de cadastro, que me retiresse o fardo de criar aqueles famigerados (acho essa palavra muito legal) artefatos de software todos os dias. Uma nova era estava surgindo.
Baseado em texto
Logo logo, nossos conceitos evoluíram, e de código estático de geração, tínhamos estruturas configuráveis a partir de arquivos INI.
Esses eram (ou deveriam ser) gerados por outro utilitário que importava modelos do erWin (conhecem?) através de uma API muito legal (ahaha, como eu gostava desse tempo)....
Delphi e Kylix
O sucesso pareceia certo. O projeto evoluía e já tínhamos migrado para Delphi e, então, Kylix (lembram?), para rodar no Linux também. Época boa, onde tudo parecia fácil.
Foi mais ou menos naquela época que publicamos o artigo acima e que fizemos algumas apresentações do projeto em alguns eventos na região central do Estado.
JH Santos
A coisa ia de vento em popa, e então decidimos que era hora de abrir uma área de pesquisa - nem era, nem poderia ser um negócio, embora querêssemos que fosse.
Saíamos do trabalho e íamos para lá. Levávamos coca-cola, pizza, cachorro-quente, xis (embora essas duas últimas iguarias não eram apreciadas por mim) e café, muito café. Brincávamos de programar em Delphi e fazíamos testes com diversas coisas.
O local? Bem, era uma sala num prédio da antiga...
Mais um para o fim
Mas queríamos mais. E mais significava que precisávamos ter alcance web.
Porém, nem eu nem o D. manjavam de web, e então abrimos "a jogada" para um outro colega, o J.
Agora tínhamos uma equipe de três bonecos: um centrado, um pirado e outro maluco. Orbitávamos em nossos devaneios e rodávamos para lá e para cá.
Acho que a coisa não foi muito para a frente porque, libertos como estávamos, acabamos mirando em muitos lugares e quando parei de contar, eu estava em 1.200 horas de pesquisas que envolviam desde RMI, Delphi, VB, EJB, Hibernate, JDO, Eclipse, Netbeans e ... pára por aí. Acho que não dá mais.
Isso foi em 2004.
Merlin, o renascimento
Não que três fosse demais. Muito pelo contrário. Até hoje acredito que 3 é o número ideal: 3layer diz alguma coisa?
Visto que a JH não era mais nosso lugar, precisávamos de algo novo para brincar. E fomos para o mundo. O mundo livre.
O projeto Merlin fora criado no JavaNet e as brincadeiras lá continuaram.
2005 foi um ano difícil para mim, mas que teve uma recompensa inigualável. E quem me conhece sabe o motivo. Também nesse ano, a 3Layer Tecnologia teve sua pedra fundamental lançada: ganhamos um CNPJ :)
2006 foi um ano de recuperação e 2007 de preparação.
Agora, em 2008 estamos com uma bagagem sólida de estudos - sim, são praticamente 7 anos lapidando essas coisas de telas de cadastro!
Estamos nos focando em transformar a coisa em algo sério, e ao invés de brincar, revolucionar.
Antes de terminar...
...mostro uma tela de cadastro gerada pelo Metagen:
Isso é o que gerávamos em 2003 com o Metagen. Para cada campo na tela, algo em torno de 11 propriedades no arquivo INI eram necessárias. Tínhamos um fraco, mas funcional, suporte para ligação de regras de negócio e as telas eram 100% livres de erro de programação.
E esse, bem por cima mesmo, foi o começo...
