Sexta-feira, dia 6, eu e outros dois colegas aqui do GUJ (pintofree e Zakim), vimos uma apresentação sobre o Maker que durou aproximadamente 4 horas. Já temos ciência do flamewar que esta ferramenta causa, por isso vim aqui colocar a minha opinião, e acredito que logo os dois farão o mesmo. [color=red]Embora tenho certeza que este tópico vai desembocar em mais uma flamewar e no final será trancado, pedimos aos moderadores um pouco de paciência para ele não ser trancado antes de umas três páginas talvez. Pedimos a quem for responder para ler com atenção este post na sua íntegra.[/color]
Primeiramente, imaginávamos que o maker fosse um gerador de código (como a maioria aqui imagina). É estranho dizer isso, mas ele não é. Percebi que o maker na verdade corresponde a três coisas: uma IDE, uma linguagem de programação e uma máquina virtual. Tudo extremamente vendor lock-in.
A parte de IDE do maker lembra bastante o delphi e o VB. Você sai arrastando componentes na telinha, define propriedades para eles e cria o código específico e acoplado ao componente. A diferença é que o “código” é feito em fluxogramas.
A softwell diz que estes fluxogramas são a “grande inovação” do maker, mas eu não vi nada de mais nisso. Desenhar o fluxograma é algo significativamente mais lento que escrever código, porém por outro lado a leitura deste tende a ser mais fácil e a curva de aprendizado bem menor.
Em cada ação do fluxograma (equivalente a uma instrução), há uma expressão associada. Essa expressão é montada no gerador de expressões, e tem a forma de uma árvore. Cada nó corresponde a uma função, e o valor retornado pelos nós filhos são parâmetros para o nó pai. Os nós folhas contém expressões literais (números, strings e variáveis) ou funções que não recebem nenhum parâmetro. Criar expressões usando o criador de expressões é algo bem irritante e improdutivo. Escrever as expressões diretamente seria sem dúvida muito mais fácil.
No nível mais baixo das expressões estão as funções built-in do maker (lembra bastante o VB e o delphi isso, não há (ou pelo menos não vimos) organização em classes, namespaces ou qualquer coisa assim). Como válvula de escape é possível codificar alguma função em java, mas a filosofia do maker é contra isso. Essas funções escritas em java são compiladas e executadas on-the-fly, semelhantemente ao que faz o Jasper Reports. Também é possível escrever-se funções em javascript. As funções built-in são bem documentadas, e há uma área para escrever a documentação das suas próprias funções.
O webrun é ao mesmo tempo uma máquina virtual e um container. Ele interpreta diretamente os fluxogramas, sem que haja geração de código, e gera páginas web equivalentes as telinhas feitas com arrastar e soltar componentes. Isso é uma coisa fortemente vendor lock-in, pois se você se você quiser se livrar do webrun, não haverá nada para interpretar os fluxogramas. Isso também destrói praticamente qualquer tentativa de reaproveitar a lógica de negócio fora do maker.
A arquitetura do sistema gerado é típica de um sistema feito em delphi ou em VB. Telinhas de arrastar e soltar com o código em baixo acoplado a cada componente da tela.
O maker não é OO e nem tem a menor pretensão de ser (isto inclusive está no site da softwell), o maker é uma linguagem procedimental.
Junto a parte de IDE do maker há uma ferramenta para administrar banco de dados e criar SQLs. Esta ferramenta lembra bastante o Miscrosoft Access, porém ela é independente de BD. De qualquer forma é possível inserir-se SQLs manualmente também.
Dentre as funções do maker estão coisas como manipulação de XML, webservices, SOAP, stored procedures, triggers, funções no BD, manipulação de arquivos, geração de relatórios, upload e download e outras coisas. No entanto o cara que apresentou não soube dizer se havia suporte a JSON, nem a XML-schemas, nem como o maker trabalha com cookies e nem soube dizer nada sobre concorrência. Também acabamos nos esquecendo de perguntar acerca de gerenciadores de download, segurança contra cross-site scripting, gerenciamento de sessões e testes unitários.
Relativo a concorrência, no entanto há um detalhe importante. Há um agendador de tarefas e com ele é possível obter-se algum grau de multithreading, uma vez que as tarefas executam em paralelo. No entanto, quanto a mecanismos de sincronização, ficou uma lacuna, não soubemos se existe algum ou não.
Transações ocorrem de duas formas, quando inicia-se um fluxo ou quando ele é disparado pela tela. Ao terminar o fluxo ocorre o commit. Se o fluxo for interrompido, ocorre o rollback.
É possível interromper-se fluxos de forma assíncrona ou dar um timeout a eles. Isso pode ser interessante para evitar travamentos ou outros problemas. Mas… Isso não traria ao maker o mesmo problema que Thread.stop trouxe ao java?
Todas as telas têm uma barra de ícones padrão (que pode ser ocultada), semelhante ao que o access gera (no entanto os ícones são mais bonitinhos que o do access). Não é possível alterar-se os ícones, nem mudar a ordem, nem tampouco remover algum deles ou acrescentar outro. Uma possível saída para este problema é ocultar por completo a barra e refazê-la a unha no maker.
O maker tem um sistema de versionamento built-in que lembra um pouco o CVS. Por sinal, se você gosta do CVS, SVN, Mercurial ou qualquer outro sistema de versionamento, esqueça se for usar no maker. Como o maker trabalha com fluxogramas e não gera código nenhum, não há como integrá-los com outras ferramentas de controle de versão. O controle de versão do maker é baseado no banco de dados, onde os fluxogramas são serializados e deserializados em algum formato que ignoro. Não sei como ele lida em caso de conflitos de versões, mas pelo que entendi o suporte a isso deve ser mínimo.
A comunicação entre um componente e outra é feita nos moldes mais tradicionais de gambi-VB: invisible object blackhole. É comum se ter caixas de texto invisíveis trafegando dados entre diferentes telas da aplicação. Outra forma freqüente de fazer uma tela passar dados para outra é usar o banco de dados como intermediário. Por sinal, acessar programaticamente (ou melhor dizendo, fluxogramaticamente) os componentes da tela, para alterar a cor deles, por exemplo, é uma verdadeira luta. Neste ponto o maker é horrível de trabalhar.
O cara que mostrou a ferramenta disse que a softwell prega que estagiários devem fazer o programa por fluxogramas. Se isso for verdade acho que é algo tremendamente absurdo. Isso implica que a reutilização de códigos (ou fluxogramas) é pequena, e que a arquitetura do sistema é o típico Model-view de Delphi/VB. Obviamente, é possível refatorar-se os fluxogramas de forma a obter-se um modelo MVC e prover o máximo de reusabilidade, mas não é qualquer estagiário que faz isso.
O maker 1 foi feito em delphi. O maker 2 foi feito usando-se o maker 1. A softwell deve lançar o maker 3 entre o final de 2009 e o começo de 2011, feito usando-se o maker 2. O maker 2 não roda em linux porque ainda há alguma coisa em delphi no seu interior, no entanto o apresentador disse que o maker 3 será capaz de rodar em linux.
O apresentador também disse que o maker 2 não serve para a criação de portais, e sim para a migração de aplicativos desktop para a web. No entanto, disse que o maker 3 servirá para a criação de portais.
Um grande problema do maker é que ele não tem nenhum tratamento de exceções. Eu testei colocar uma função em java com o código “throw new NullPointerException();” e o bicho foi jogado na cara do usuário sem nenhuma chance de tratá-lo. Um outro caso que eu perguntei é se um webservice lançar um SOAP fault, não há forma de tratar isso. No entanto uma das metas do maker 3 é prover um tratamento de exceções.
O debug é precário. Se resume a colocar uma função no fluxograma semelhante ao comando “stop” do VB. O apresentador deu a desculpa de que com o maker, a necessidade de debug é quase zero, no entanto eu duvido muito disso.
Não há suporte a EJB. Para usar um EJB é necessário fazer-se alguma artimanha como por exemplo funções escritas diretamente em java ou integração com arquivos JAR (que podem ser colocados em uma pasta específica do webrun). Integração com outros frameworks seguem o mesmo caminho.
Apesar do maker não ser um gerador de código, há possibilidade de exportar tudo para java (exportar != gerar). Pelo que entendi isso foi uma exigência do bradesco, e foi implementado meio que a contra-gosto. O código exportado não é nenhuma bola de lama ilegível como muitos esperariam mas também não é o código mais lindo que se possa criar. O código é legível e utiliza generics, cada fluxograma se transforma em um método e cada ação do fluxograma em uma instrução. Não é difícil perceber-se que traduzir um fluxograma (e expressões em forma de árvore) em um código java é uma tarefa relativamente simples (já o inverso não é). Os métodos gerados são todos “public static” e todos têm “throws Exception”. Bem procedimental mesmo. A estrutura dos pacotes não têm nada a ver com a recomendação da Sun. A documentação é legível por um simples motivo: O maker copia e cola a documentação do fluxo no código exportado. No entanto fica uma questão, como é que os “gotos” no fluxograma são traduzidos para java?
Apesar de ser possível exportar o código em java, não é possível importá-lo. Ou seja, não é possível ler ele de volta. É aquele negócio, isso era uma funcionalidade que eles nem queriam que o maker tivesse e fizeram porque foram forçados. No entanto é posível contornar-se essa limitação, pode-se copiar e colar o código em funções feitas “à mão” no maker ou então pode-se colocá-lo em um JAR e disponibilizá-lo ao webrun.
Olhando os JARs e as classes do maker, vê-se que boa parte dele é feita em java, embora ele tenha nascido do delphi. Eu vi dependências em relação ao Jasper Reports, ao Geronimo, ao JBoss e deve haver alguma coisa de JSF lá dentro também. Mas o que predomina são classes proprietárias da softwell.
Do lado mercadológico, o preço é R$ 13850 por PC, e a tendência é que fique mais caro no futuro.
Uma coisa que ele fez questão de dizer foi que a Freire utiliza o maker em 300 prefeituras e foi ela que criou o maker inicialmente para uso próprio. Posteriormente a divisão do maker se separou em uma empresa a parte (a softwell), que ainda é controlada pela Freire. Pensando um pouco, se vê o porque de não existir versão demo do maker e porque ele é tão caro: A Freire ganha milhões e disponibilizar “a galinha dos ovos de ouro” para a concorrência seria dar um tiro no próprio pé, mas por outro lado eles precisam de algum tipo de comunidade usando a ferramenta para que possam melhorá-la para o uso deles mesmo.
No fim o que vimos foi isso: Para quem quer migrar de forma rápida aplicações em cobol, clipper, basic, VB ou delphi para algo mais novo, o maker seria uma boa. Para consultorias de 3 letras que estão se lixando para o que estão entregando, o maker é ótimo também. Para projetos de porte pequeno a médio sem muita importância também é bom (até o dia que eles se tornem grandes, daí fudeu). Mas para coisas grandes de verdade, eu acho que é péssimo. Por outro lado, tive a impressão que o maker 2 ainda é algo incompleto, talvez o maker 3 seja o objetivo real da softwell.
