| Autor |
Mensagem |
|
|
Polêmicas, polêmicas.
rogelgarcia wrote:Novo framework brasileiro liberado
Acho que toda essa discussão foi motivada por essa frase do Rogel.
Se ele tivesse escrito simplesmente: Framework Neo renomeado para Next, teriam menos criticas a um "novo framework".
As pessoas estão cansadas de novos frameworks web e eu compreendo porque.
Mas no fundo tudo isso foi bom. Foi bom "cutucarem" o Rogel para ele criar um exemplo de app com o Next (o software da padaria), criar o artigo explicando a motivação do framework, etc.
Tenho certeza que agora as coisas estão mais claras para novos usuários ou pessoas que queiram aprender sobre o Next.
Por isso uma pequena polêmica de vez enquando é bom para sair da rotina, chamar atenção para algo, acertar o que estava faltando, etc.
Não sou a favor de criticar sem avaliar o trabalho, mas no fundo quem ganhou com tudo isso foi o Next. Isso que é legal de projetos Open Source - o contato com a comunidade. Até das coisas ruins podemos tirar coisas positivas.
A proposito, já conhecia do Neo (agora Next) a muito tempo e ele realmente é um fw bem antigo.
Todo esse envolvimento com Open Source é bom. Devia fazer mais parte da nossa cultura. Daqui a um tempo o Next pode ser O framework e utilizado por muitos ou o Rogel pode usar toda essa experiência adquirida e contribuir com outros projetos de sucesso, ou mesmo usar no dia a dia.
Sigam em frente.
|
 |
|
|
|
bacana =)
|
|
|
|
Tenho um Android também da HTC (HTC Hero) e não tenho nada a reclamar.
O aparelho é excelente.
Sobre instalar programas no cartão SD (que alguem comentou que não é possível), é possível, desde que você tenha acesso root no Android.
Para o HTC Hero eu instalei um ROM customizado pela comunidade para ter acesso root, mas para o Nexus o processo é bem simples.
|
|
|
|
Se o "Meu Projeto" for o projeto do eclipse e "core", "web" e "infra" forem sub-pastas é mto facil gerar nessa estrutura.
Um jeito facil de conseguir isso e mantendo a separação que vc quer é criando o "Meu Projeto" como projeto do eclipse e dentro dele o SPIDER pode gerar o "core", "web" e "infra" como sub-projetos (pastas com o arquivo .project). Depois que a estrutura tiver gerada vc pode dar close no "Meu Projeto" (que é o principal) e import project nos outros 3 pelo eclipse.
Editei para explicar melhor. Estou postando via mobile (android) e antes tinha mais confuso / escrito correndo 
|
|
|
|
Opa,
Então, eu estava dando uma olhada no TextUML e acabei achando o xtext do eclipse antes de ler o forum. O xtext pode ajudar a criar uma DSL para isso. O textUML ja é algo pronto para criar modelos UML. N entendi ainda onde ele pode ajudar, mas depois a gente conversa.
Sobre o exemplo que deu dos artefatos, o que é um projeto no eclipse? "Meu Projeto" ou "core", "web", "infra"?
|
|
|
|
Thiago Senna wrote:então.. eu dei a sugestão da DSL pq eu acho wizards mais complicado. Você poderia manter ambos - os wizards e a DSL. Os wizards por exemplo, poderiam gerar a DSL. Se o desenvolvedor quiser, ele que opte por não usar os wizards e atuar direto na DSL.
Eu sugeri que desse uma olhada no TextUML não é pelo fato de que me interesso por MDD. É que no TextUML já existe uma DSL que representa a UML e talvez valesse a pena reaproveitar ao invés de criar do zero. Valeria muito a pena manter uma DSL onde à partir dela você gera todo o Scaffold da aplicação. Como o seu público alvo são programadores editar as configurações em uma DSL pode ser mais interessante do que editar wizards, é minha sincera opinião 
Ok Thiago. Agora as sugestões / ideias estão começando a tomar forma (não seria MDD, usar o DSL como opção ao wizards, etc), apesar de que eu acho os wizards bem simples e da para clonar as configs de um projeto para o outro.
Vou fazer o seguinte: vou dar uma olha no TextUML e depois a gente conversa para entender melhor o q está sugerindo e ver se é possível de implementar. Se não for atrapalhar nada e só for agregar, tranquilo.
Thiago Senna wrote:
Por exemplo, algo q eu senti falta em alguns projetos por aí é a opção de você gerar código para multi-projetos. Se tenho por exemplo um projeto usando maven com dois subprojetos, como faço pra gerar alguns artefatos no projeto A e outros no projeto B?
A geração do SPIDER e incremental e baseada em assuntos (divididos em abas no wizard).
Vc pode gerar o conteúdo de uma aba em um projeto (ex: layout) e o conteudo de outra em outro projeto (ex: codigo java).
É isso que quer?
|
|
|
|
Alex Basto wrote:Acho que você esta usando um modelo antigo e não entende o que é percebido hoje, algo como Drools usa DSL para implementar regras de negocios.
Não Alex, acho que vc não entendeu. A sugestão era para escrever a DSL em vez de usar os wizards. Não estamos falando de regras de negocio. O assunto regra de negocio está fora do escopo da ferramenta. As regras tem que ser escritas pelos desenvolvedores usando o que eles quiserem - DSL, codigo java puro, patterns, etc...
|
|
|
|
Opa Mauricio,
Usar DSL internamente nos geradores ou ate gerar um projeto que possua DSLs, ok.
O que eu quis dizer é só que eu não sei se o usuário final precisa escrever uma DSL para dizer a ferramenta o que ela deve fazer. A ideia é descomplicar ao máximo a vida do desenvolvedor para que ele se preocupe com o que realmente importa que são as regras de negocio, arquitetura e etc.
Eu tenho muita preocupação em não tirar o foco do que realmente importa em um projeto (regras de negocio e etc). Então eu quero evitar que as pessoas escrevam códigos, comandos ou modelos para gerar algo descartavel (CRUDs). Esse é o objetivo desse projeto. Mas enfim, concordo que podem existir outras soluções 
Vamos ver como as coisas caminham com o tempo. Atualmente a preocupação é essa.
|
|
|
|
Ei Thiago,
Bom, vamos por partes:
Sobre o TextUML eu não conheço. Mas se a sugestão é colocar annotações nas classes para gerar diamagras UML também, isso pode ser feito de forma muito fácil (apesar de que eu não sei qual o valor desses diagramas para CRUDs).
Agora se a sugestão é gerar código a partir de diagramas (ao estilo MDD), isso não está nos planos porque muda totalmente o conceito / foco da ferramenta. Neste caso é melhor utilizar alguma ferramenta MDD que ja tem pronta.
Segue um comparativo entre a geração de código do SPIDER e MDD:
spideronrails.org/cnf/display/docPT/Comparativo
*SPIDER versus MDD*
Algumas ferramentas de geração de código são Model-Driven Development (MDD) e o SPIDER possui outro conceito. Vamos tentar explicar as diferenças:
No SPIDER você não precisa criar diagramas e não tem dependência com a ferramenta se quiser alterar o código. Nós suportamos você a criar o código do seu projeto e após criar os arquivos eles tem como único dono o próprio desenvolvedor. O SPIDER não precisa manter qualquer sincronismo regular com o código. Você pode continuar o seu projeto manualmente, após algumas semanas pode usar o SPIDER novamente, para novos Use Case.
o SPIDER não possui dependência entre o código e a ferramenta, os dois são completamente independentes. Se na metade do projeto você decidir não usar mais o SPIDER, ok. Você pode fazer isso.
Algumas outras ferramentas parecidas tem alguns passos manuais como: muitos "comandos maven", ou entrada de dados usando somente comandos (command line). A abstração do SPIDER é mais elevada e você não precisa "conhecer ou aprender" nada para usar a ferramenta... é muito mais fácil e permite mais features por exemplo: escolher layout (skin) visualmente. Fazer isso em um prompt seria ruim.
As facilidades do SPIDER permitem que você crie projetos muito mais rápido do que com ferramentas MDD ou ferramentas baseadas em comandos.
A qualidade também será boa porque o código gerado é baseado em templates. Você pode usar o seu template com as customizações que quiser.
A documentação e diagrama UML são importantes, mas nós não precisamos delas para configurar o projeto ou criar CRUDs. O SPIDER é mais ágil e consegue criar código (como você quiser) sem usar o conceito de MDD, então você economiza tempo.
Na nossa opinião MDD é importante (por exemplo) para modelar um sistema e criá-lo em várias tecnologias diferentes. Se o seu sistema terá somente uma tecnologia (JEE), MDD não é necessário ou não agrega muitas vantagens. Por isso o SPIDER não é uma ferramenta MDD.
Então o projeto tem um objetivo muito bem definido, e (felizmente ou infelizmente) MDD ou DSL não fazem parte dele. Essas tecnologias são bacanas para alguns casos especificos, mas sinceramente não sei se precisa de tudo isso para configurar um projeto e criar CRUDs. Veja bons exemplos no django e ruby, tudo é feito da maneira mais simples e rápida possível. No SPIDER também sempre foi com esse objetivo, só que tentando ser mais fácil ainda (visualmente), integrado a IDE e sem ter que aprender nenhum comando.
Se está procurando por MDD e DSL, realmente não vai se adaptar (mas não estou dizendo que essas tecnologias são ruins, só que o objetivo é outro).
Abçs,
|
|
|
|
alandasilvaferreira wrote:Em primeiro lugar espero que todos tenham tido um ótimo natal ...
cara achei fantastico o seu artigo citado no link acima realmente muito bom só gostaria de resaltar mais um item, que muitos programadores e arquitetos fazem mal uso dessas ferramentas por falta de experiencia e conseitos mal formados sobre a real utilidade desses softwares, que somente estão ai para dar uma assistencia isso sem contar que em contra partida muitos desses softwares não cumprem nem 30% do que eles vendem ... posso estar me preciptando mas na real, eu acho que a maioria desses caras que produzem esse tipo de software não tem experiencia o suficiente para criar tais tipos de ferramentas ... eu mesmo sou um desses mas pelo menos eu não fico criando porcarias e jogando na internet ...
me desculpem se fui meio grosseiro ou pareci um pouco arrogante mas eu não consigo entender como esses softwares que estão no mercado conseguem ganhar dinheiro com esses produtos ...
Alan, eh o artigo ficou bacana. Sobre as ferramentas tb acho que tem muitas ruins. Por isso criei uma Open Source para que todos possam colaborar e criar algo free melhor do que as pagas.
Na verdade uma vez procurei uma ferramenta nesse estilo e fiquei meio desapontado com a qualidade, nenhuma gerava codigo util, permitia customização ou era facil de usar. Então resolvi começar a fazer uma no tempo livre. No primeiro quartil de 2010 qdo tiver uma release estavel, espero que possa te ajudar com esse problema em comum.
Apesar do parenteses sobre ferramentas, espero ter ajudado a discutir o conceito "geração de código". Ver que se bem entendido o objetivo e bem aplicado pode agregar e não ser um inimigo.
|
|
|
|
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).
|
|
|
|