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

Pessoal, sei que qualquer um que não fale mal da ferramenta é tachado de “funcionário da empresa”, porisso relutei em me cadastrar (nunca tive senha do guj porque não desenvolvo em java).

Estou analisando a compra do maker (não me decide) e todas as opiniões são importantes para minha decisão. Liguei ontem para a softwell e falei com um vendedor (manoel) e o mesmo me informou que a softwell está lançando 3 versões do maker. uma standart, uma profissional e a atual(enterprise, acho). O que ele me colocou é que a softwell agora estaria de olho também nos pequenos (inclusive free-lance) e a versão mais barata estaria saindo por 2900, que foi capada e só trabalha com banco free e outras limitações. Ficaram de enviar um e-mail com a proposta e a matriz de funcuinalidades.

Gostaria de saber se alguém já tem alguma informação/opinião sobre essa versão menor ?

Grato.

Você já sabe o que quer que essa ferramenta faça por você? Se for gerar um software de qualidade esqueça, ta provado que isso não funciona. Se quer economizar com programadores, da uma lida nisso aqui. Para economizar, tente algo como SCRUM.

[quote=Luca]
2) Sucesso de que?[/quote]
Deve ser de marketing… não vejo outra possibilidade.

[quote=Schuenemann][quote=Luca]
2) Sucesso de que?[/quote]
Deve ser de marketing… não vejo outra possibilidade.[/quote]´

Maker ainda não é referencia como framework nem nada considerando tecnicamente o produto e o modelo de negócio também foi incapaz de tirar proveito de uma estrategia open source.

Quem vai querer investir sua grana nisso?

O grande problema do Maker nao é o produto em si, é o marketing’. O marketing da empresa tem a cara de pau de dizer que programar com fluxogramas é evolução e diferencial, que você não tem que escrever código, que o maker possui os mesmos conceitos que intentional programming e que o maker traz algum diferencial comparado com outras ferramentas que fazem a mesma coisa. Nada disso é verdade. O maker não apresenta nada de novo e ainda é uma involução em conceitos simples como modelagem de sistemas, modularidade, controle de versões, testes, agilidade, visualização… sinceramente não consigo pensar em uma área onde o maker não tenha andado para trás.

O maker e seus concorrentes têm lugar mas não é nem na metade dos lugares onde o fornecedor vende.

Bom, conforme o amigo e companheiro de trabalho victorwss comentou, nós assistimos a uma apresentação do Maker.

Muito do que eu pensava sobre a ferramenta tomou novos rumos, embora eu não seja a favor do seu uso em projeto que exigem a habilidade de bons profissionais e não alguem que sabe fazer if else e pronto.

Acredito no Maker como um complemento e não como uma solução!

Conforme o combinado, também fiz minha análise particular do Maker. Enfoquei alguns pontos e instiguei outros para que possamos analisar isso tudo não só do lado técnico, mas também do lado empresarial e comercial.

espero que ajude! O post sobre a análise está no meu blog. (o endereço do blog está na minha assinatura desse fórum ou aqui http://zakim.blogspot.com/.)

obrigado!

O maker (pelo visto em marketing e nos post do GUJ) não traz NADA de novo. Programação arrasta-e-clica, fluxograma… isso existe no mercado há décadas e seu uso como GPL sempre foi restrito aos programas que antes eram feitos no Excel ou Access, notadamente programas onde fazer tudo de novo é sempre mais barato que refatorar.

Por favor, produtividade não significa apenas criar algo, significa criar algo minimamente aceitável. Um programador consegue fazer um sistema em uma linguagem como JSP/ASP/PHP em um dia mas o custo de manter esse sistema é muito alto. Iniciativas reais de melhoria na área de produtividade (MDA, DSLs, Intentional Programming, XLR…) pregam produtividade com qualidade exatamente porque sabemos, após décadas experimentando essas ferramentas, que elas não entregam sistemas com qualidade aceitável.

Comparar desenvolvimento de software com corte de cana é, no mínimo, uma piada. E bem infeliz.

Dizer que ele não é um erador de código é uma meia-verdade, ele Não gera código editável mas a menos que ele compile para bytecodes ele gera o código que vai ser executado pelo tal servidor. Me parece que dizer que o servidor (webrun) é uma JVM é a mesma coisa que dizer que o WebLoic é uma JVM porque vem com o JRockit.

A piada é bem infeliz mesmo! Foi a forma que eu encontrei para instigar a comparação entre vinho e água por exemplo! Ambos não tem ligações e cada uma tem seu papel, mas são ingeridas pelas mesmas pessoas!
A ligação que abordei foi automatização e produtividade com qualidade!

E quando digo em produtividade! O minimo aceitavel está incluso no pacote!

Concordo, mas acho que o que ele quis dizer no final foi que a máquina produz muito mais rápido, mas com qualidade inferior.

EDIT: No entanto não concordo com o Zakim em um ponto (ou então entendi errado ou ele se expressou mal): A substituição dos cortadores de cana por máquinas, a maioria acredita ser uma evolução (talvez não os próprios cortadores). Mas, não vejo como trocar programadores por “desenhadores de fluxogramas” seja evolução.

[quote=pcalcado]
Dizer que ele não é um erador de código é uma meia-verdade, ele Não gera código editável mas a menos que ele compile para bytecodes ele gera o código que vai ser executado pelo tal servidor. Me parece que dizer que o servidor (webrun) é uma JVM é a mesma coisa que dizer que o WebLoic é uma JVM porque vem com o JRockit.[/quote]

Sim, os fluxogramas e árvores de expressão são serializados no BD em algum formato qualquer que serve como código. Mas aqui vem em primeiro lugar: O que você entende por gerador de código? Eu acho que gerador de código é uma ferramenta que cospe código escrito em alguma linguagem de programação, e para rodar bastaria mandar o código para o compilador e depois executar. Esse não é o caso do maker que interpreta diretamente os fluxogramas e árvores de expressão.

EDIT: Também não considero ferramentas que cospem bytecodes ou códigos em linguagem assembly como geradores de código: Isso são compiladores.

Quanto a questão do webrun ser uma JVM, isso está errado sim. Retire o J e daí vai ficar certo, ele é uma máquina virtual para o maker.

Justamente. No caso o Maker, a parte que não concorda são os desenvolvedores em geral (cortadores de cana) e a maioria que concorda, são empresários que não querem ver mais nada alem de resultados e acreditam que isso possa ser uma evolução! Isso não quer dizer que os empresários estejam corretos.

Eu e o victorwss vimos isso de perto!

Favor usar esse dinheiro p/ pagar a passagem, hospedagem, comida, e salário de um líder de desenvolvimento, Mestre Yoda em desenvolvimento ágil para ensinar para a equipe da empresa durante um mês os O quês, Por quês e Comos do TDD e outras metodologias que valem a pena.

A comparação entre automatizar o corte de cana e autmoatizar software é extremamente infeliz. Software é trabalho criativo, não braçal e repetitivo. O Make rnão automatiza software, automatiza CRUD básico.

Eu não sei da experiência de vocês mas eu nunca vi programador chorando porque vai perder emprego com uma coisa dessa, o que eu vejo é programador que já está cansado de ter que consertar sistemas feitos com algo igualzinho o Maker nas últimas décadas. Em 2003 eu fui contratado para fazer exatamente isso. Um sistema todo construído com fluxograma -só que Orientado a Objetos- e ninguém precisava escrever código, ele mesmo gerava e fazia o deploy do binário. A sorte é que ao contrário do Maker ele gerava código em java (apesar de que o programador não devia alterar este código, era apenas um modelo executável) e quando o sistema passou a exigir duas semanas para implementar mudanças bobas e a empresa viu a besteira que tinha feito chamou programadores de verdade (pagando uma grana para uma consultoria, claro). Resultado? Cada fluxogramazinho do sistema gerava um EJB e o sistema tinha tantos EJBs (2.0) que o deployment descriptor travava o Eclipse. Solução? Mega-refactoring que dura até hoje. Resultado final? Alguns milhões de dólares (o fornecedor da ferramenta era canadense) jogados pela janela.

Imagino em quanto tempo teremos dúvidas no GUJ de gente perguntando como se faz para fazer engenharia reversa nos bancos de dados do fluxograma do Maker.

[quote=victorwss]

[quote=pcalcado]
Dizer que ele não é um erador de código é uma meia-verdade, ele Não gera código editável mas a menos que ele compile para bytecodes ele gera o código que vai ser executado pelo tal servidor. Me parece que dizer que o servidor (webrun) é uma JVM é a mesma coisa que dizer que o WebLoic é uma JVM porque vem com o JRockit.[/quote]

Sim, os fluxogramas e árvores de expressão são serializados no BD em algum formato qualquer que serve como código. Mas aqui vem em primeiro lugar: O que você entende por gerador de código? Eu acho que gerador de código é uma ferramenta que cospe código escrito em alguma linguagem de programação, e para rodar bastaria mandar o código para o compilador e depois executar. Esse não é o caso do maker que interpreta diretamente os fluxogramas e árvores de expressão.

EDIT: Também não considero ferramentas que cospem bytecodes ou códigos em linguagem assembly como geradores de código: Isso são compiladores.

Quanto a questão do webrun ser uma JVM, isso está errado sim. Retire o J e daí vai ficar certo, ele é uma máquina virtual para o maker.[/quote]

Pelo que você mesmo falou ele não é uma máquina virtual, ele é um interpretador apenas, e de programação procedural. Trabalho de fim de semestre em qualquer faculdade que se preze, ou mesmo o conteúdo de um bom livro sobre o tema. Na verdade, se não me engano até no livro do Deitel tem ume xercício para fazer um interpretador…

[quote=Bruno Laturner]…

Favor usar esse dinheiro p/ pagar a passagem, hospedagem, comida, e salário de um líder de desenvolvimento, Mestre Yoda em desenvolvimento ágil para ensinar para a equipe da empresa durante um mês os O quês, Por quês e Comos do TDD e outras metodologias que valem a pena.[/quote]

Concordo em número, grau e gênero. :slight_smile:

[quote=liberali][quote=Bruno Laturner]…

Favor usar esse dinheiro p/ pagar a passagem, hospedagem, comida, e salário de um líder de desenvolvimento, Mestre Yoda em desenvolvimento ágil para ensinar para a equipe da empresa durante um mês os O quês, Por quês e Comos do TDD e outras metodologias que valem a pena.[/quote]

Concordo em número, grau e gênero. :slight_smile: [/quote]

Ah, favor também chamar a gente pra empresa qdo isso ocorrer :wink:

Assim como o JVM é uma máquina virtual que interpreta bytecodes, o webrun é uma máquina virtual que interpreta os fluxogramas do maker. E sim, criar uma máquina virtual não é algo difícil, o difícil é otimizar uma VM.

pCalçado.

Você ja entendeu o contexto da discussão! Seus questionamentos só são entendidos por pessoas do nosso ramo!
A idéia do artigo é passar algo sobre o Maker e não sobre a minha ou sua experiencia no mercado! Você tem toda razão quando diz que meus questionamentos obre o corte de cana foram infelizes, mas querendo ou não, eles são singelos e possibilitam o entendimento de todos!

Nao. Um interpretador é algo diferente de uma máquina virtual, uma máquina virtual cria um modelo computacional em si só, ele vai se preocupar com gerenciamento de recursos, processos e demais. Se o Maker roda na JVM ele delega isso para a JVM, se a JVM interpreta bytecodes (o que não é exatamente verdade já que ela também os compila e gerencia sua execução pelo processador) ou não é uma outra discussão, nada impede que uma VM seja um interpretador.

Pelo sue raciocínio JRuby seria uma máquina virtual que executa sobre a JVM e se você usar algo como HPricot vai acabar com uma áquina virtual que executa numa máquina virtual que executa numa máquina virtual. Tanto JRuby quanto HPricot são apenas interpretadores que rodam sobre uma máquina virtual chamada JVM.

Nao. Um interpretador é algo diferente de uma máquina virtual, uma máquina virtual cria um modelo computacional em si só, ele vai se preocupar com gerenciamento de recursos, processos e demais. Se o Maker roda na JVM ele delega isso para a JVM, se a JVM interpreta bytecodes (o que não é exatamente verdade já que ela também os compila e gerencia sua execução pelo processador) ou não é uma outra discussão, nada impede que uma VM seja um interpretador.

Pelo sue raciocínio JRuby seria uma máquina virtual que executa sobre a JVM e se você usar algo como HPricot vai acabar com uma áquina virtual que executa numa máquina virtual que executa numa máquina virtual. Tanto JRuby quanto HPricot são apenas interpretadores que rodam sobre uma máquina virtual chamada JVM.[/quote]

Por esta visão, então eu não sei se ele seria apenas um interpretador mesmo ou se seria uma VM com um interpretador.

Você levantou um detalhe interessante aí. Eu não sei se o webrun roda em cima da JVM ou não. Há várias classes java no webrun, e sem dúvida ele depende da JVM, mas eu não sei se ele vive dentro da JVM ou se ele apenas a utiliza.

Aí que está, se quem ler isso não possuir o mínimo conhecimento sobre desenvolvimento de software vai entender que automatizar a criação de software é algo tão simples quanto criar uma máquina de colher cana. A menos que isso tenha sido uma piada sarcástica sobre como o Maker possui uma filosofia simplória a comparação é danosa e sem sentido.