GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Maker! Galinha dos ovos de Ouro? Ou não?


#1

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][b]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.[/b][/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.


#2

Bem na minha opiniao durante a apresentação do maker 80% das perguntas feitas o vendedor nao sabia responder, mais desses 80%, 90% do que não sabia se existia era resolvido apenas ligando para a empresa q eles implementavam, por isso a apresentação se resumiu em perguntas do estilo, maker faz isso? Ainda nao mais liga lah na empresa que o pessoal implementa. O apresentador que é o representante do maker aki na regiao centro oeste nao sabia muito dos detalhes tecnicos do software pois como ele mesmo informou so teve 4 aulas do maker,no caso 4 aulas de treinamento a nivel de desenvolvedor de sistemas. Ai eu me pergunto como um empresa dessas me concede a concessão de uma região a uma pessoa que teve 4 aulas a nivel de usuario e nem o treinamento de representação fez??? Isto para mim é muita vontade de vender.


#3

"Para consultorias de 3 letras que estão se lixando para o que estão entregando, o maker é ótimo também"

Isso resume tudo.
Enqto existirem sistemas de grande porte, e com varias tecnologias envolvidas, nao ficarei "com medo de perder meu emprego" como ja foi citado aki nesse forum.

O dia que tudo se resumir a CRUD, ai sim... passo a trabalhar com maker.


#4

Não generalize as coisas! Com apenas 4 aulas e uma ótima apresentação, o representante foi eficaz e mudou a visão de todos nós extremitas CONTRA_MAKER_POR_FALTA_DE_INFORMAÇÃO. (a própria empresa acaba criando isso por não liberar uma versão trial a comunidade e ficar escondendo o jogo).

E a propósito, ainda sou contra porém, não mais extremista. Devo tirar o chapeu para a ferramenta!

Minha análise sobre o Maker http://zakim.blogspot.com/


#5

A qualidade do Maker já foi debatida várias vezes aqui no GUJ.

http://www.guj.com.br/posts/list/91010.java
http://www.guj.com.br/posts/list/76773.java
http://www.guj.com.br/posts/list/78806.java
http://www.guj.com.br/posts/list/66566.java

Minha resposta pra isso é: NÃO, pois essas ferramentas tentam subestimar a capacidade de um programador, o que já foi provado que não funciona.


#6

Eu nao fiz uma critica ao vendedor, o cara ta certo tentando ganhar o troco dele, eu penso na empresa que sai liberando concessoes de venda sem se preocupar com dar um treinamento de qualidade para isto. Ao meu ver isso e muito vontade de vender o maker.

Nao conheço nenhuma grande empresa que venda um produto serio que nomeie vendedor sem requer algum tipo de treinamento.
Se alguem conhece favor postar ai.


#7

KKKKK. sabe o que e mais engraçado? que o cara que deu a palestra p vcs sobre o Maker tinha tido um treinamento de 4 dias e nao sabia responder ate ai tudo bem coitadinho, no meu caso eu fiz um curso de 3 dias com uma pessoa que DESENVOLVEU o maker e ela tbm não sabia responder 70% das perguntas.......tudo que perguntava era enviado a "SOFTWELL" para eles corrigirem.....o maker ta usando tudo e todos para se auto corrigir...

Eu aposto o que quiserem que o Maker nao dura mais 1 ano....

O MAKER E OTIMO PARA BANCAS DE JORNAIS, LOCADORAS E PADARIAS JA OS MERCADINHOS EU ACHO QUE SO SE FOR UM BEM PEQUENINO....

Conheci uns 3 ou 4 caras la da Softwell enhum dos 4 sabiam responder 20% das perguntas....

Fora que e assim ne? Quer algo novo? cria em java ou javascript.....Ué? mas se a ferramenta elimina qualquer coisa que se relacione a digitar codigo vc ainda quer q nos criamos metodos em JAVA?

Obs: Eu tava lembrando do dia do curso de MAKER o cara que tava explicando a cada pergunta ele ficava sem resposta e ficava falando que iria chegar na softwell e iria matar um...coitado acabou matando a softwell inteira pelo jeito ..kkkkkkk

vlw...............


#8

hhuahua para veio matar 1200 pessoas e muita gente, alias, qnd perguntamos se ele realmente foi desenvolvido por 1200 programados o cara falo, q nao a softwell trabalha so com estagiarios.


#9

Sim, pelo que entendi esse é o único propósito de venderem a ferramenta. Não querem vendê-la para ganhar dinheiro e sim para poder melhorá-la. Se não precisassem melhorá-la, não a estariam vendendo. Dinheiro eles já tem bastante ao custo de diversos governos municipais da Bahia.


#10

Fiquei curioso: como chegou a esta conclusão?


#11

Olá

Muito bom seu relato. Obrigado pelo exemplo e pela paciência de escrevê-lo.

Tudo o que falou e que eu não sabia em detalhes, bate com tudo que imaginei a partir da minha longa experiência com o uso deste tipo de ferramenta, que como disse em outro tópico, já comprei várias.

[]s
Luca


#12

Simples. Eles usam o maker em sistemas de centenas de prefeituras, que obviamente pagam milhões a eles. O fato de eles poderem entregar os sistemas mais rápido que qualquer concorrente faz com que eles vençam todas as licitações (talvez se lixando para a qualidade do que foi entregue).

Se eles disponibilizassem o maker baratinho OR open-source OR com versão trial, muita gente o usuaria, inclusive a concorrência, e no final eles acabariam perdendo dinheiro, pois a grana do governo deve ser centenas ou milhares de vezes maior que o ganho com a venda do maker. Por outro lado, se ninguém mais usar o maker além deles mesmos, a ferramenta acabaria estagnada, e eles teriam uma capacidade menor de ampliá-la prematuramente, acabariam só ampliando quando precisassem, o que geraria atraso na entrega de sistemas. Então a solução é vendê-la a um preço astronômico para apenas alguns poucos.

Como vender a um preço astronômico algo de que ninguém tem conhecimento, mesmo que para poucos? Simples: Marketing agressivo.


#13

Interessante você abrir um tópico sobre o Maker para expôr sua opinião séria, já que nos outros você abusou de piadinhas sem-graça enquanto outros tentavam dar suas opiniões.

Um colega de trabalho assistiu a apresentação e se cadastrou no GUJ só para discutir o assunto e contar sua impressão do mesmo (é o que você está fazendo nesse tópico), mas acabou desistindo depois de tanta besteira e insinuações de que ele era programador do software.

Obs: Nós não trabalhamos na Softwell (eu nunca tinha ouvido falar na mesma).


#14

O pessoal do não suporta ver uma ferramenta que eles não gostam fazer sucesso.

PS: Não uso\gosto do Maker. Nunca usei para falar a verdade. Mas acho que o pessoal foi infeliz tanto na hora de defender como atacar o Maker.


#15

Eu ouvi falar por mas linguas que o Dono da softwell e amiguissimo do governo bahiano dai ja da pa sabe algo ne?


#16

Ok, mas agora eu (como qualquer outro) pode usar o meu depoimento para fazer melhores piadinhas sem-graça. E quem quiser defendê-la terá mais argumentos bem como quem quiser atacá-la (ou seja, coloquei lenha na fogueira).

E gente que se cadastra SÓ para defender ou atacar a ferramenta é muito suspeita. Qualquer um pode criar uma conta em 2 minutos para este único propósito, e houve gente que fez isso.

Mas beleza, como disse, tinha certeza que uma bela flamewar se seguiria, e é exatamente o que ocorre!


#17

Olá

1) Pessoal de que?

2) Sucesso de que?

Pode por favor explicar onde acha que alguém neste tópico foi infeliz?

[]s
Luca


#18

Uia isso sim foi um crew bem dado uhauhaua, poha esse Rubem e um faz tudo da computaçao, olha o perfil dele
Profissão: Consultor Borland
Interesses: Java, Arquitetura de software, SCM, Ruby, Agile, Ruby on Rails, Delphi, C#.


#19

Boa, faz sentido :smile:


#20

Aí também já começa teoria da conspiração, não acha? Afinal de contas, uma coisa não implica a outra (caso de fato seja verdade).
Não gostar da ferramenta é uma coisa, apelar pra dizer que rola protecionismo já é apelar :smile:

PS: a propósito, este tipo de afirmação da até processo :smile: