| Autor |
Mensagem |
|
|
Alex Basto wrote:
Vi o video, ficou bem interessante !!!! , uma iniciativa legal pra fazer a pessoa entender rapido as reais mudanças da aplicação, por curiosidade a voz como você fez, achei que ficou perfeito junto com a explicação do video !!!!!!!! 
Sim...  A página de How To foi criada justamente para isso. Vou colocar vários vídeos pequenos sobre vários assuntos e novidades. Mas vou deixar para gravar a maior parte dos vídeos mais para frente quando estiver fechando a versão. Mas todos vão ser nesse estilo.
O vídeo foi criado com Adobe Captivate 4, que tem esse recurso de transformar texto em voz. Da um certo trabalho, mas ficou bacana mesmo.
Sobre o VRaptor / Rest funcionaria sim. Sem problemas.
|
 |
|
|
Sobre o nome, não sei. Não estou vendo tantos problemas.
Por enquanto vai ficar esse mesmo mas vou pensar se surgirem novos argumentos.
Até porque existe DB2 on Rails, RadRails, JRails e outros... a maioria tem algo a ver com Ruby, mas o SPIDER também tem em teoria e vai ter na prática.
|
|
|
|
Alex Basto wrote:Posso aliar as funcionalidades do VRaptor 3 ao J2EE Spider, como situações usando a API Restfulie para contexto de URI?
Não entendi 100% da pergunta, mas sim você pode criar um template do VRaptor 3 para a ferramenta e economizar trabalho em novos projetos.
|
|
|
|
A versão 1.0 só vai ser lançada em 2010 como comentei.
Mas quem quiser brincar com a versão de build atual, gravei um vídeo de 2 minutos mostrando como instalar:
http://www.spideronrails.org/cnf/display/PT/How+To
O template que está mais funcional é o de JSF (mas na hora de configurar OpenID e HTTPs ainda  ).
|
|
|
|
Vai funcionar com Ruby on Rails também similar ao que está sendo feito com Django. Mas não na versão 1.0 que deve sair no primeiro quartil de 2010.
Então uma parte do projeto foi "refatorado" sim, mas para funcionar com qualquer coisa =)
O que foi pensado é que o objetivo dos projetos é o mesmo ou muito parecidos. Porém implementados de uma forma diferente.
Enquanto Ruby é um framework web, o Spider é uma ferramenta. Mas o resultado final é ganhar produtividade, configurar o projeto sem muito trabalho, criar os scaffolds, etc... Então o nome parecido foi proposital nesse aspecto. Mas como havia adiantado o objetivo não é competir, o objetivo é agregar idéias e implementações diferentes a mesma solução..., tanto que uma hora o SPIDER pode ser uma ferramenta para o Ruby on Rails basta sobrar um tempinho e criar um template.
Olhando só em função do nome é algo como "Coca Cola" e "Pepsi Cola" (apesar de que esses são concorrentes).
O proprio Grails é um acronimo de Groovy on Rails.
Então em questão de foco do projeto, objetivo, marketing, SPIDER on Rails foi o melhor nome que encontramos.
Acho que no começo pode parecer um pouco estranho (questão de costume), mas seria melhor do que fazer como o Grails e colocar SRails (super rails? kk).
|
|
|
|
Você pode desenvolver algum plug-in no eclipse usando JET mas não compensa. Vai ser muito trabalho para algo que já tem pronto.
Se quer gerar código a partir de modelos usa o RSA como sugeriram ou se for MDA o AndroMDA ou algo assim.
Mas eu particularmente não gosto de geração de código baseado em modelo.
Você não vai fazer uma app toda gerando código. Vai usar geração de código só para CRUDs e configurações de frameworks para ganhar tempo.
Então pra que os modelos? Os modelos são descartáveis nesse caso. Você precisa modelar as regras de negocio, não a parte descartavel. Mas isso são pontos de vista =)
Se quiser gerar código rápido (sem perder tempo com modelos) e baseado em templates (você pode criar o seu) tente essa ferramenta que também é um plug-in para o Eclipse:
http://www.spideronrails.org
|
|
|
|
djemacao wrote:Nenhum gerador de códigos pra mim é ruim, desde que eu entenda o que está ocorrendo e o código seja humanamente compreensivel. É possível? Com absoluta certeza.
Achar que tudo é ruim é ignorar que, como automatizadores que somos de trabalho alheio, não podemos então automatizar o nosso, o que consideraria uma falta imensa de inteligencia.
o Rails é uma prova concreta de automatização de código.
É mais ou menos por isso que o projeto J2EE Spider trocou de nome para SPIDER on Rails.
A forma de fazer as coisas é totalmente diferente do Ruby on Rails e não também não é um framework, mas o objetivo é parecido.
|
|
|
|
LPJava wrote:para mim so tem valor quando é para executar coisas basicas, o qual eu consigo dar manutenção, porem há situacoes que deve ser analisadas como o thingol citou.
Codigo gerado por uma IDE que eu nao entendo nao serve, nem para vc nem para sua equipe.
Totalmente de acordo
Parte disso que comentei no meu texto.
Mas o erro de não ter esse foco / características são da maioria das ferramentas e não da "geração de código". Esse é o ponto.
|
|
|
|
Opa...,
Eu só vi a existencia desse tópico esses dias.
Então preparei esse texto chamado "Mitos sobre geração de código":
http://www.spideronrails.org/cnf/pages/viewpage.action?pageId=5111911
Veja se ajuda a esclarecer o assunto.
Abçs,
|
|
|
|
Para quem não sabe "J2EE Spider" é uma ferramenta baseada no eclipse (plug-in na verdade) que ajuda na criação e configuração de novos projetos. O objetivo é aumentar a produtividade reduzindo desperdício com tarefas repetitivas (configuração de frameworks, etc).
Bom, a notícia é que o projeto "J2EE Spider" foi renomeado para "SPIDER on Rails". Isso está acontecendo para alinhamento do projeto com mudanças que serão lançadas em 2010.
Basicamente o projeto vai expandir e irá suportar outras tecnologias como Django e PHP além é claro de Java.
Então para um correto alinhamento estratégico foi removida a palavra "J2EE" do nome do projeto e criado um novo nome utilizando a palavra "Spider" demonstrando que também houve continuação das idéias iniciais.
A opção por SPIDER on Rails não é uma concorrência ao Ruby on Rails. É apenas um alinhamento com o que a ferramenta faz e será visto daqui para frente.
A URL http://www.j2eespider.org continuará existindo, mas redirecionará para http://www.spideronrails.org
Feliz Natal a todos!
baseado em: http://www.spideronrails.org/cnf/pages/viewpage.action?pageId=5111918
|
|
|
|
Acho que o projeto JSenna está parado.
Tente esse: www.j2eespider.org
Abçs,
|
|
|
|
huhauah
essa perguntas estão engraçadas.
então mais algumas:
O que você faz se você desenvolveu um aplicativo no maker e por algum motivo comercial você não tem mais a licença do maker. Como da manutenção no seu aplicativo? Edita os jar no notepad? =P
Como sabemos todos os software são sujeitos a bugs. O que você faz se você arrastou um diagrama condicional (um "if") para a tela e por alguma combinação de razões o maker não está respeitando a sua condição. Tranquilo porque se o editor der pau você pode inserir o "if" manualmente no código fonte certo?
Se você tiver acesso ao código gerado, mas o Maker criar o código de um jeito que você não quer em relação a padrões de codificação, design patterns, etc... O que você faz? Você pode customizar o maker para ele gerar o código do seu jeito, certo? Afinal você não vai dar manutenção em algo que não entende...
Perguntas a gente pode criar muitas. Já que sabe tudo de Maker, diz ai pra gente as respostas.
|
|
|
|
O povo implica com a M$ porque ela copia coisa dos outros e fala que não copiou (vide C#).
Porque ela sempre cobrou (e caro) por seu produtos.
E porque ela se acha e fala mal dos concorrentes (vide windows x linux e outra brigas).
A google nunca foi mercenária coma a M$ a ponto de cobrar por tudo.
Lança a muitos produtos como Open Source e focados na comunidade e não em empresas ($$).
Disponibilida API para tudo já no lançamento (e não por força do mercado).
E continua inventando coisas inusitadas. Se não for o Go, vai ser o Wave, Street View, GoogleOS ou outra coisa. O importante é não ficar parado só lançando service pack.
Não vejo como o Google pode se transformar na M$. São duas empresas bem diferentes.
|
|
|
|
|
No update manager, aquela opção de upgrade do 9.04 para o 9.10 funciona? Ou vcs estão instalando do zero?
|
|
|
|
Galera...,
Volta e meia tem essas discussões sobre o Maker, WaveMaker, DavidCopperfieldMaker. E aproveitando que o tópico teve reply recente, vou deixar minha opinião.
Eu fico pu*$#%, porque esse tipo de ferramenta só estraga e atrapalha o que conhecemos como "Geração de Código". Mas geração de código não é o que o Maker faz. O que ele faz é "mágica".
Em uma outra oportunidade eu posto aqui o que é Geração de Código.
Como diz o Rodrigo Yoshima:
rodrigoy wrote:
Geração de Código não é para ser necessáriamente ruim. Não confunda geração de código com ferramentas Case de 1980 (que teimam em ressurgir das cinzas).
fonte: http://www.guj.com.br/posts/list/84720.java#452718
Isso é o Maker, uma ferramenta Case de 1980.
Existe um post o Phillip Calçado que eu dei quote/reply e se encaixa aqui. Era em um post que tinha a comparação de um tal de WaveMaker com o J2EE Spider (projeto Open Source):
bruno.braga wrote:
pcalcado wrote:Por favor spearam a discussão software livre x proprietário de geração de código. Tem gente que tem gerador de código proprietário que possui código aberto para seus clientes.
Até onde eu sei a postura do Bruno no J2EE Spider é, com já oi dito aqui, fazer o trabalho repetitivo. Isso significa que se você gerava uma classe e um arquivo em XML em duas horas na mão ele vai gerar a mesma coisa em 15 minutos. No fim das contas da manutenção dá no mesmo (se a ferramenta tiver qualidade, claro). Eu nunca usei o J2EE Spider mas já usei muitas ferramentas para este tipo de coisa.
O problema das coisas como o maker é que eles se propoem a substituir tudo, não só o trabalho repetitivo.
Eu não tinha visto a discussão, mas é exatamente isso que o Calçado comentou.
O código criado pelo J2EE Spider é seu, não da ferramenta. O desenvolvedor tem liberdade para fazer qualquer manutenção quando necessário.
Inclusive sobre a discussão dos bugs, quem quiser pode consertar bugs do template da ferramenta ou dos artefatos gerados sem ficar dependente da ferramenta (só não esqueça de contribuir depois ).
Então resumindo: se chegarem bugs em produção, praticamente posso dizer que a culpa é mais do desenvolvedor que não fez nenhum tipo de teste no seu projeto (teste unitário, teste funcional, etc...) do que da ferramenta. Lembrem-se o código é seu e pode ser criado exatemente do seu jeito se customizar o template da ferramenta.
A parte ruim do wavemaker (pelo que eu vi em um vídeo) são esses pontos:
não é integrado com nenhuma IDE de desenvolvimento (tudo é feito via browser);
ele é quase uma IDE dentro do browser, você tem que sair arrastando as coisas, com não é maduro com o Eclipse / Netbeans não sei se funciona... isso tem que ser levado em consideração... um erro bobo de javascript no core da IDE pode atrapalhar muita coisa;
você tem mais trabalho para montar um projeto do que usando o conceito de templates, porque no wavemaker é necessário criar tudo no drag and drop, ele é quase mais uma IDE do que uma "maker" então parece mais concorrente do Eclipse do que do SPIDER ou ferramenta de geração de código;
não mostrou como fica o código gerado... você é obrigado a manter tudo pelo Wavemaker e ficar escravo dessa ferramenta? E se ela gerar código errado como você vai concertar? E se tiver acesso ao código gerado (parece que não), é possível abrir ele onde? Eclipse? NetBeans?
o wavemaker se propõe a criar uma aplicação com Spring, Hibernate, JAXWS, ACEGI, Dojo e ponto. Você não consegue escolher se quer usar JSF ou Spring MVC ou mesmo struts (não é possível escolher os frameworks). Ou seja você que tem que se adaptar ao wavemaker e não o contrário.
etc, etc...
Fiz só algumas observações sobre o conceito do wavemaker, que não parece muito diferente daquele outro maker da Bahia. Tirando as diferenças visuais e um ou outro detalhe os dois seguem para o mesmo lado.
fonte: http://www.guj.com.br/posts/preList/84720/461357.java#461357
Nesse quote que eu coloquei acima, praticamente é possível trocar WaveMaker (que é outra ferramenta) por Maker. A idéia de ferramenta Case e ferramenta mágica é a mesma.
A diferença é mais que o WaveMaker você edita dentro do browser e o Maker é um client para Windows.
O WaveMaker é algo que eu nunca usaria mas ainda tem uma vantagem sobre o Maker (se é que é possível achar vantagem): ele gera código usando frameworks de mercado como Spring, Hibernate, etc... Mas não adianta muita coisa porque você não pode editar / dar manutenção no código :/
----
A proposito, aproveitando o assunto, eu estava sem tempo e como ainda sou o único contribuidor ativo o projeto J2EE Spider tinha dado uma estacionada em releases, apesar do nightly build ter muita coisa nova.
Mas já tem um mês que estou pegando mais forte com ele e em breve termino a versão que eu estava fazendo, que vai ter muitas surpresas.
http://www.j2eespider.org
Abçs,
|
|
|
|