MAKER eu testei usei e ODIEI

Assuntos Gerais
#1

Galera a algum tempo saiu aqui no forum uma discução sobre uma nova ferramenta chamada Maker que era totalmente voltada a fluxos e gerava codigo em Java porem o programador não colocava a mão em uma linha de código.

Gostaria de dizer que trabalhei em uma empresa que comprou esta ferramenta, ganhamos um curso que NINGUEM APRENDEU NADA, uma equipe totalmente despreparada e desqualificada, fora isso tudo o que tentavamos construir DAVA bug e o pior que eram bugs como “ERRO: PASSEI POR AQUI” ou seja o cara que programou a ferramenta esqueceu de comentar aquela famosa linha que usamos para debug…

Resumindo e pessimo e medonho pelo menos ate o momento pode ate ser que melhorem muito mas É PESSIMO ATE ENTÃO

Tenho o certificado do curso deles e digo NÃO VALE R$ 0,01, so não joguei fora pq tenho guardado uma prova de que passei por uma porcaria de treinamento e trabalhei comum lixo de ferramenta…

PARABENS A TODOS AQUELES QUE TENTARAM AVISAR ANTES DE QUE MUITOS COMPRASSEM…

#2

nossa, tinha nego aqui no fórum dizendo que isso ae era a solução para a fome e a pobreza mundial

mas pelo jeito é bem ruinzinho mesmo =/ agora o tal “PASSEI POR AQUI” é muito looser hehe

#3

Sua experiência é válida.
Hehe, parabéns você conseguiu se libertar das drogas.

#4

Sem entrar no mérito se é bom ou ruim a ferramenta, o que me chamou atenção desde o início foi o modelo de negócios adotado pela empresa.

Num mundo onde existem dezenas de alternativas open-source gratuitas, entrar com um sistema novo e fechado cobrando 7 mil reais me parece totalmente inviável. Ou talvez eu ainda tenha muito a aprender sobre marketing e o mundo dos negócios…

#5

Eu acredito em papai noel e coelho da pascoa mas nao acredito em programa “gerador” de codigo que nao precisa de programador :slight_smile:

#6

Existem empresas como a CPM que fazem uso do Maker e conversando com uma pessoa da CPM, a mesma me disse que a ferramenta funciona.
Após investimento de algumas empresas no produto, o fabricante melhorou o produto e faz alguns softwares, não é a bala de prata, mas de acordo com essa pessoa,serve para fazer muita coisa mesmo, não apenas CRUDs, relato de uma pessoa que já teve experi~encia com o Maker, e não teria necessidade de mentir, pois não tenho porque comprar software.
Claro, isso é apenas uma opnião que eu ouvi, não necessariamente quer dizer que é verdade absoluta e que o Maker é o pancadão, pode ser que para a necessidade do usuário, o Maker atendeu epor isso ele tem uma boa visão da ferramenta.

#7

Pelo preço do MAKER era p ele construir ate predios de 95 andares, e não ficar corrigindo erros conforme o usuario testa…

ELE USOU OS CLIENTES COMO PLANO DE TESTE?

Na boa a ferramenta e um coco…

#8

Não disse isso…

#9

realmente e um dos que diziam q ele era a salvação do mundo e este TeiTei…
que ironia né TeiTei…

#10

Também tive a oportunidade de conhecer a ferramenta (cancelaram o uso aqui na empresa antes que todos os programadores fossem embora).

Seguinte, os caras venderam a propaganda de que gerava código java (.ear e .war) e que poderiam ser abertos a qualquer momento.

Ele realmente gera, porém tem que levar com ele um tipo de “interpretador”, chamado WebRun que vai junto no pacote, responsável por intermediar a aplicação com o container/servidor no qual foi feito o deploy.

Ou seja, gera um arquivo Gigantesco, além do que não se pode alterar coisas do tipo. ícones horríveis, mensagens de erro em java para o usuário final, tamanho das telas de aviso, etc…

Qualquer alteração que queira fazer, tem que alterar um arquivo .CSS e rezar para que o componente sofra a alteração (geralmente sempre o que você quer mudar dá pau).

Mas a propaganda não era “sem mexer em código”!?!

Ou seja, se você quiser ficar “amarrado” à ícones feios, aplicações extremamente pesadas, inflexibilidade de alteração de componentes (não existe evento para o botão além do click), entre outras limitações, beleza… é a ferramenta ideial (fora o preço absurdo).

Bom, passado o pesadelo, segue minha humilde opinião.

Att,
Lucas.

#11

Eu elogiei a ferramenta mas nao conhecia ainda…HJ n diria o mesmo…

USAR MAKER = REGREDIR.

#12

Você poderia postar uns screenshots destes ícones e/ou de algumas destas mensagens em java indo direto para o usuário? Gostaria de dar upload na desciclopédia. :twisted:

#13

Você poderia postar uns screenshots destes ícones e/ou de algumas destas mensagens em java indo direto para o usuário? Gostaria de dar upload na desciclopédia. :twisted: [/quote]

Acho que isso é perigoso, envolve questões judiciais, não???

#14

Atualmente trabalho numa empresa onde 90% dos projetos são desenvolvidos usando uma ferramenta chamada GeneXus.

Somente o projeto que estou ainda não utiliza desta ferramente para desenvolver, mas a intenção é que em breve o sistema seja todo migrado.

Ao entrar na empresa é ministrado um treinamento á respeito do GeneXus, no meu caso participei para conhecer, mesmo que de imediato não vou utilizá-la.

Sempre fui bastante consciente em relação ás minhas ferramentas de trabalho, com bons argumentos para justificar a escolha entre uma e outra, mas confesso que estou bastante pensativo nestes últimos dias á respeito deste tipo de ferramenta.

Tenho que confessar, que por exemplo no caso do Genexus fiquei impressionado com a produtividade que ela te oferece e principalmente pela facilidade em transformar teu aplicação em Multiplataforma, multibanco, etc. ( Ela gera Java, .NET, VB, etc… Com bancos SQL Server, Oracle, PostgreeSQL, mySQL, etc, tudo sem vc mexer nada em código nativo da linguagem escolhida )

Todos sabemos, que no desenvolvimento de software a linguagem de programação pouco importa para o cliente em muitos casos, exceto casos onde o próprio cliente irá dar manutenção posterior. Justamente por este fato penso que uma ferramente deste tipo poder ser uma solução excelente para software houses ou qualquer empresa que não quer passar por todo tipo de problema que sabemos que enfrentam as empresas de desenvolvimento de software, como por exemplo:

1-Falta de pessoal capacitado nas tecnologias mais modernas
2-Atraso na entrega dos projetos
3-Alto custo de capacitação
4-Acompanhamento do avanço tecnológico

Eu como programador ainda reluto muito em aceitar este tipo de conceito, mas tenho que admitir que fico sem ter como questionar quando converso á respeito com algum desenvolvedor Genexus, pois de fato a solução tem atendido a empresa de uma forma surpreendente.

Ou seja, para o cliente o importante são as regras de negócio, não a tecnologia utilizada.
As vezes penso que nossa profissão tende á se distanciar um pouco do perfil técnico e ir buscar um conhecimento mais amplo, aplicando tecnologia ás necessidades e não enchergando tecnologia como produto fim.

Bom pessoal, desculpem o texto longo, mas o que eu pretendo é coletar opiniões sinceras sobre isto pois por muitas vezes ficamos sem saber qual tecnologia aprender, pra que lado o mercado estará daqui algum tempo, sendo que com uma ferramenta destas essa preocupação é repassada aos desenvolvedores da própria ferramenta.

#15

Sinceramente? Isso de ferramenta geradora é uma utopia q no final acaba sobrando para os pobres programadores q tem que dar manutenção.

Junta-se a vontade das grandes empresas de baixar o custo contratando secretarias no lugar de programadores e empresas oportunistas que vendem algo que não resolve o negócio da empresa, mas que até a empresa descobrir isto, já perdeu milhões.

#16

[quote=aleck]Sinceramente? Isso de ferramenta geradora é uma utopia q no final acaba sobrando para os pobres programadores q tem que dar manutenção.

Junta-se a vontade das grandes empresas de baixar o custo contratando secretarias no lugar de programadores e empresas oportunistas que vendem algo que não resolve o negócio da empresa, mas que até a empresa descobrir isto, já perdeu milhões.

[/quote]

A resposta que eu estou procurando é justamente onde que geralmente este tipo de ferramenta não resolve o negócio da empresa.

O que eu vejo aqui por exemplo são 90% dos sistemas desenvolvidos e vendidos para grandes clientes, todos vendidos já há bastante tempo e todos desenvolvidos neste tipo de ferramenta.

Quero que entendam que estou questionanando pois realmente é uma curiosidade minha e que não sou a favor ainda deste tipo de ferramenta, mas uma vez que estou percebendo que as soluções são desenvolvidas “com a mesma qualidade” mas com produtividade muito maior, posso estar mudando de idéia.

#17

eu acho meio suspeito tudo o que é feito um marcketing mto forte…

quando falo marcketing mto forte (na minha “LEIGA” concepção), me refiro a promessas gigantescas, onde se ouve mais de agilidade mais de 50 vezes maior, da pra fazer de tudo, falta caracteristicas tecnicas mesmo quando se apresenta para tecnicos… quando eu vejo coisa assim eu ja deduzo que a coisa por baixo dos panos (em caso de sowftware, no processamento por tras da interface) é no minimo precario…

da pra se perceber tb esse tipo de marketing que muita coisa nestes textos/falas são feitas como se fosse um leigo falando…

claro que isso é uma opinião pessoal, de repente uma cisma minha…

#18

Perfeito, Gustavo, mas lembre-se que essa ‘lei’ te um corolário: o cliente também não quer saber se você usou a ferramenta errada e por isso para fazer algo bobo como trocar os ícones vai levar vinte anos.

Muitas pessoas repetem ‘no silver bullet’ e citam Fred Brooks mas não entendem o que ele escreveu:

Maker, Genexus, etc. são apenas implementações de um conceito extremamente antigo que já falhou miseravelmente diversas vezes. Semana que vem vai surgir outra ferramenta como essa, com um marketing ainda mais agressivo, mas não adianta. Para que o nível de abstração seja elevado não basta automatizar uma tarefa, você tem que mudar paradigmas e é aí que odas essas ferramentas pecam.

Quanto à ëu falei com a empresa XYZ e ela usa e falou que é legal"a primeira coisa a pensar é que este tipod e consultoria usa qualquer ferramenta. A CPM, por exemplo, possui um centro de treinamento em COBOL e restou serviço pro anos com BC4J e UIX. Para a empresa era ótimo porque era o que o cliente exigia.

#19

Por coincidência, ontem estive com dois representantes do Maker e, juntamente com outros dois desenvolvedores, pudemos avaliar a ferramenta.

Bem, segue aqui a impressão que tive da ferramenta:

Do ponto de vista gerencial, esta foi a minha impressão:

  1. Processo de compra.
    O software custa R$ 13.000,00 a licença, e você não tem direito a uma versão de demonstração para poder experimentar o produto antes de comprar.
    Se quiser, você pode até mesmo fazer um curso (pago) no fornecedor para conhecer a ferramenta, poder avaliá-la, etc.
    Se quiser, a empresa também lhe ajuda a criar um projeto piloto com o Maker. Nos dois casos, óbvio, são pagos e todo o processo de desenvolvimento é feito NO fornecedor, e não na própria empresa.
    Consequência: não há como fazer uma análise imparcial do software sem a influência do mesmo.
    Aí me pergunto: COMO pagar R$ 13.000,00 em algo se é avaliado DESTA maneira?
    (Detalhe: antes só vendiam lotes de 8 licenças. Pelo que os representantes contaram, só AGORA é possível comprar apenas uma licença individual. Imagine: antes, o maker na realidade custava R$ 104.000!!!)

  2. Vendor lock-in
    O Maker, apesar de gerar código “aberto”, é totalmente proprietário. Não temos acesso ao seu código fonte. Quando perguntei sobre qual seria o roadmap do produto, os vendedores simplesmente não souberam me responder. E outra: como saber se a Softwell de fato vai durar tanto tempo assim se nem o roadmap do produto eu conheço? Gerar código Java ou C# ou XML não quer dizer que se trate de uma ferramenta aberta.
    Vendor lock-in? To fora!

  3. Ausência de comunidade
    A comunidade de usuários do sistema é minúscula se comparada com as comunidades de desenvolvedores Java ou mesmo .net, PHP, Ruby, Groovy, etc. Você fica 100% nas mãos da Softwell.

  4. Argumento de venda
    O argumento principal de venda consistiu no velho argumento segundo o qual mão de obra é difícil de conseguir, e que com o Maker uma pessoa menos capacitada conseguiria construir sistemas. É exposto como é problemático o processo de desenvolvimento de softwares, e como o Maker consegue aumentar 3942786234876234876 vezes a produtividade do desenvolvedor.
    Resumindo: com o Maker até um idiota pode desenvolver sistemas como um desenvolvedor mega experiente!

Do ponto de vista técnico, também vi alguns problemas.

  1. O ponto forte do sistema consiste em um ambiente de desenvolvimento 100% visual. Tudo é feito a partir de fluxogramas. Lindo, só tem um problema:nos exemplos expostos, se eu quiser fazer algo simples como
   if (nome.equals("qualquer coisa"))
    {
      // faça isto
    }
   else
    {
      // faça aquilo
    }

necessitava de tantos cliques e arrastes de mouse, que o argumento da produtividade simplesmente ia pro saco. Pode-se criar novos procedimentos no Maker, mas para quem já sabe programar, com certeza achará o processo muito mais complicado do que simplesmente digitar o código na sua linguagem de escolha.
Claro, o fato de ser um fluxograma nos fornece uma visão macro do código melhor, porém este ganho não compensa tanto assim.

  1. Arquitetura do sistema gerado: ao perguntar sobre as entidades, simplesmente não souberam me responder a pergunta. Resumindo: não há entidades, estas consistem nas tabelas presentes no banco de dados. Aliás, o Maker é basicamente programação orientada a banco de dados pelo que pude ver na demonstração. Não é OO, e a camada de visualização fica misturada à de negócio. A distinção entre as camadas de visualização, controle e negócio não é, de maneira alguma (pelo menos com base na demonstração) nítida.

  2. Programação OO é ignorada. O código é gerado em Java e C#, porém o processo de desenvolvimento do Maker é procedural. Todos os diagramas são procedurais. Em momento algum (pelo menos na demonstração que vimos), foi criada uma classe de entidade (ou mesmo uma entidade qualquer). Tudo é relacionado diretamente com o banco de dados. Para quem já trabalha com OO, o Maker pode ser visto como retrocesso.

  3. A ferramenta é de mão única. O código gerado pelo Maker em Java ou C#, se alterado, não pode ser lido de volta pela ferramenta, ou seja, o desenvolvedor fica PRESO ao Maker. Claro, você pode pegar o código gerado e, a partir dele, criar sua própria aplicação, porém esqueça os “maravilhosos recursos” do Maker caso queira aplicá-los no seu código customizado.

  4. Reaproveitamento de código legado: quase zero. Neste ponto da demonstração, foi até engraçado. Sugeriram que, como o Maker é ultra produtivo, que eu simplesmente reescrevesse o meu código utilizando o seu gerenciador de fluxogramas. É possível também mapear funções e procedimentos (reparem, FUNÇÕES E PROCEDIMENTOS, não classes) no Maker para que ele possa acessá-las, mas este trabalho simplesmente não compensa pelo preço e maneira como é apresentada a ferramenta.
    Teve de alterar seu código Java legado? Ok, basta alterar o mapeamento do Maker! (Uhu! Quanta “produtividade”!)

Agora, a ferramenta é uma merda total? Claro que não, só é mal direcionada. É nítido que é fruto de MUITO trabalho. O preço é absurdo, a maneira como é comercializada, cretina e o público visado, errado. Desenvolvedores experientes não irão optar por esta ferramenta. O tal ganho de produtividade do Maker nós já temos com frameworks como Ruby on Rails ou o Grails, e, detalhe: ainda temos uma ferramenta REALMENTE aberta e com custo/benefício REAL.

No entanto, para pessoas sem experiência alguma com desenvolvimento, e que precisem de um cadastro simples (REALMENTE simples) ou coisa semelhante, o Maker já se aplica. Só que, com este preço, compensa MUITO mais utilizar algo como o Access por exemplo, ou mesmo o Kit 5 que, apesar de todas as críticas, se aplicado a este público, oferece um custo benefício ordens de magnitude superior. Se o Maker custasse algo em torno de uns R$ 500,00, e fosse voltado para o leigo, aí sim, talvez tivesse algum futuro real. Da maneira como se encontra, o custo/benefício é zero, diria até se tratar de garantia de prejuízo.

#20

Simplesmente a melhor opinião que eu já li neste fórum sobre o Maker até agora. Não porque prova que a ferramenta é ruim, mas sim pelo embasamento em fatos provindos da convivência com o produto.