Lançado o Play, um novo framework para desenvolvimento web parecido com o rails.
Segue o link: http://www.playframework.org/
[]'s
Novo framework web
B
115 Respostas
A
Gostaria de saber como eles implementaram o padrão ActiveRecord neste framework.
F
Aparentemente é uma boa. Vamos ver se isso esquenta um pouco o mercado… pq ta tenso
R
Com um belo extends Model 
F
hauiaa
arcabouço cheio de marra
do folder dele:
Fix the bug and hit Reload
The Java platform is infamous for its low productivity, mainly due to repeated and tedious compile-package-deploy cycles.
Simple stateless MVC architecture
The Share Nothing architecture is promoted by many Web application frameworks from PHP to Ruby on Rails or Django. As the browser is becoming more and more powerful, it is now easy to use Ajax or offline storage to solve the state problems client-side.
HTTP-to-code mapping
GET /clients/{id} Clients.show
Efficient templating engine
(somente mais uma template engine que promete ser a mais curtinha do mundo)
JPA on steroids
(play.db.jpa.Model um layer supertype pra facilitar sua vida com o JPA)
W
cara, eu quando vejo a palavra framework em java sinto um frio na barriga :?
to me formando na faculdade, e ainda não consegui nada na área de web com java, e toda vez que eu começo estudando um framework vejo 329390248 criticas sobre ele falando pra eu não perder tempo e ir para outro. :shock:
L
cara, eu quando vejo a palavra framework em java sinto um frio na barriga :?
to me formando na faculdade, e ainda não consegui nada na área de web com java, e toda vez que eu começo estudando um framework vejo 329390248 criticas sobre ele falando pra eu não perder tempo e ir para outro. :shock:
Estuda a base (apostilas da Caelum são boas, JEDI também) que pra entender o resto fica beeeeem mais fácil.
E outra: como eu li num tópico há um tempo atrás, “já estava ficando preocupado, já tinha uns 15 minutos que não publicavam um novo framework web pra java”.
A
Gostaria de saber como eles implementaram o padrão ActiveRecord neste framework.
Com um belo extends Model :)
um viva ao “Favor Composition over Inheritance”… hehehe
T
Gostaria de saber como eles implementaram o padrão ActiveRecord neste framework.
Com um belo extends Model :)
um viva ao “Favor Composition over Inheritance”… hehehe
Você poderia então implementar um exemplo de AR favorecendo composição e enviar para eles como sugestão? Poxa, os caras criaram uma plataforma (não é um framework) de desenvolvimento web e você me vem criticar este tipo de detalhe? Eles assim como você conhecem essas regras, e se quebraram, é por que tem um bom motivo. Leia ao menos o FAQ deles que você verá que eles optaram por sair um pouco “das boas regras” que a comunidade prega.
F
cara, eu quando vejo a palavra framework em java sinto um frio na barriga :?
to me formando na faculdade, e ainda não consegui nada na área de web com java, e toda vez que eu começo estudando um framework vejo 329390248 criticas sobre ele falando pra eu não perder tempo e ir para outro. :shock:
Não é bem assim WRYEL.
Veja que a própria especificação JSF vem desse impeto da Sun de que quando as coisas começam a tomar linhas mto adversas ela toma pra si a responsabilidade de criar a sua solução oficial, ha varios outros exemplos disto.
A
Gostaria de saber como eles implementaram o padrão ActiveRecord neste framework.
Com um belo extends Model :)
um viva ao “Favor Composition over Inheritance”… hehehe
Você poderia então implementar um exemplo de AR favorecendo composição e enviar para eles como sugestão? Poxa, os caras criaram uma plataforma (não é um framework) de desenvolvimento web e você me vem criticar este tipo de detalhe? Eles assim como você conhecem essas regras, e se quebraram, é por que tem um bom motivo. Leia ao menos o FAQ deles que você verá que eles optaram por sair um pouco “das boas regras” que a comunidade prega.
Thiago Senna…
Eu não critiquei o projeto deles… achei bacana… e também não sou nenhum defensor das “boas regras” que a comunidades prega…
Achei o projeto muito bacana na verdade…
Não se preocupe… gostei do projeto.
Simplesmente brinquei com que o Rubem Azenha falou.
Você sim que criticou a minha resposta por nada.
T
Ok, então desculpe. Mas pra quem for criticar eu já me adiantei.
S
Gostei do framework mas vamos ver como ele evoluirá.
E
Ok, então desculpe. Mas pra quem for criticar eu já me adiantei.
Hahahah e ai Senna conseguiu terminar o Generator lá? 8)
Relax pessoal mto stress.
Parabens por pessoal do framework, mto bom.
J
Pelo menos nessa imitação do Rails não fizeram a besteira como no Grails de usar o Groovy (obrigatoriamente pra escrever). É mais fácil o Grails, admito, mas é pesado pra caramba, o bicho come memória que dá vontade de chorar.
Vou ver se esse Play melhorou ao menos isso. No vídeo vi que é fácil pegar o uso dele, heeheh.
T
acredito que evoluirá bem. Está previsto para a versão 1.1 suporte para a linguagem Scala. Fora isso também vão incluir a api lambdaj. Entre no site e veja a documentação da versão 1.1.
C
Mais um ?
My God !
F
Gente desculpem a newbisse, mas…
Foi só eu ou vcs tbm acharam que tem muito javascript ali?
C
JADF
T
Gente desculpem a newbisse, mas…
Foi só eu ou vcs tbm acharam que tem muito javascript ali?
JavaScript? Onde, exatamente?
F
Gente desculpem a newbisse, mas…
Foi só eu ou vcs tbm acharam que tem muito javascript ali?JavaScript? Onde, exatamente?
Tu num viu o video no site?
O cara envia todos os request atravez do js
T
Gente desculpem a newbisse, mas…
Foi só eu ou vcs tbm acharam que tem muito javascript ali?JavaScript? Onde, exatamente?
Tu num viu o video no site?
Ali eles usaram JQuery, que se não me engano já é o framework de javascript padrão adotado pelo Play Framework.
No caso do vídeo, foi o desenvolvedor quem optou por usar bastante o JavaScript, já que ele domina bem, ao meu ver. No entanto, o uso do javascript não é mandatório. Vc usa se quiser/precisar.
T
Maneiro. Java on Rails =)
C
Java On Xunxo
Sinceraemente , alguma empresa vai investir em aprender a programar no estilo “play” , com a linguagem de paginas “play” ?
Outra , o demo é uma piada , o cara nem usa uma IDE… como se fosse comum desenvolver em java com notepad…
Se nao integra com uam IDE e nao tem suporte… fica dificil usar em equipe…
Acho que eh “just another java dummy framework”…
J
Java On XunxoSinceraemente , alguma empresa vai investir em aprender a programar no estilo “play” , com a linguagem de paginas “play” ?
Outra , o demo é uma piada , o cara nem usa uma IDE… como se fosse comum desenvolver em java com notepad…
Se nao integra com uam IDE e nao tem suporte… fica dificil usar em equipe…
Acho que eh “just another java dummy framework”…
Ele usa o TextMate pra mostrar como é simples programar nele. Não é aquela bizarrice do JSF que precisa de uma IDE se quiser fazer funcionar um simples e ridículo crud.
C
JSf não é para CRUD…
JSF é tambem para CRUD…
E se vc quer algo no estilo “assistentezinho” , existem dezenas de milhares do genero…
T
Como assim?
No site tem até que vários exemplos - não apenas o do demo.
Sobre programar no notepad (ou TextMate, no caso) também não é problema no caso do play. É questão de gosto 
No caso do play, durante de desenvolvimento o desenvolvedor não precisa se preocupar com compilação. Ele simplesmente edita o código java e o play recompila a classe na hora, dando a impressão de que você está programando em uma linguagem interpretada.
Caso não goste mesmo de Notepad, você pode utilizar os comandos “play eclipsify” ou “play netbeansify” para utilizar sua IDE favorita com auto-complete e tudo mais
Ou não.
M
Pelo menos nessa imitação do Rails não fizeram a besteira como no Grails de usar o Groovy (obrigatoriamente pra escrever). É mais fácil o Grails, admito, mas é pesado pra caramba, o bicho come memória que dá vontade de chorar.
Vou ver se esse Play melhorou ao menos isso. No vídeo vi que é fácil pegar o uso dele, heeheh.
Se não me engano ele usa groovy para templates e python para o build. Parece anos luz a frente de qualquer outra solução Java para web, mesmo estando na versão 1.0.
C
Voce deve estar de zoacao … ANOS LUZ ?: Vc nunca utilizou grails nao ? Por favor…
C
Quanto a parte de redeploy e recompilar… tomcat faz isso “a decadas” , glassfish faz isso “a decadas”…
Rapaziada , acorda.
O glassfish v3 agora faz redeploy em 360ms , sem precisar regerar nada…
R
Dei uma olhada rapida no site e fiquei com uma duvida.
Uma aplicação feita com o play roda somente no seu embedded http server ou roda em qualquer servlet container?
T
Vc não disse agora pouco que faz questão de usar uma IDE descente? Você conseguiu achar uma IDE descente pra utilizar com Grails? Mesmo que tenha achado o suporte a java nas IDE’s hoje está anos luz mais maduro e o play desfruta perfeitamente disso!
C
NetBeans IDE tem suporte total a Grails.
M
Dei uma olhada rapida no site e fiquei com uma duvida.
Uma aplicação feita com o play roda somente no seu embedded http server ou roda em qualquer servlet container?
R
Dei uma olhada rapida no site e fiquei com uma duvida.
Uma aplicação feita com o play roda somente no seu embedded http server ou roda em qualquer servlet container?
legal… vou fazer alguns testes!
F
Não chegaram um pouco tarde demais?
Kd o Mentawai? Ainda existe?
T
Total? A ponto de ser melhor do que o suporte a java? Enfim… todas vezes que busquei suporte a IDE para Groovy não encontrei nenhum que fosse bom o suficiente - nem mesmo o IntelliJ. Acho que suporte total é exagero.
M
Total? A ponto de ser melhor do que o suporte a java?
não entendi o que tem o Netbeans a ver com o topico.
T
Total? A ponto de ser melhor do que o suporte a java?
não entendi o que tem o Netbeans a ver com o topico.
Estavamos comentando sobre o comando “play netbeansify” que torna possível utilizar o play com o netbeans. Inicialmente o netbeans teria muito haver com o tópico, mas a discussão evoluiu a ponto de se tornar desnecessário e virar mais uma “guerrinha de frameworks”. Mal aí. Voltemos ao tópico
C
Total? A ponto de ser melhor do que o suporte a java? Enfim… todas vezes que busquei suporte a IDE para Groovy não encontrei nenhum que fosse bom o suficiente - nem mesmo o IntelliJ. Acho que suporte total é exagero.
Melhor que o suporte a Java e seus “pinduricalhos” não… mas eh muito boa
http://grails.org/NetBeans+Integration
http://docs.codehaus.org/display/GROOVY/NetBeans+Plugin
http://docs.codehaus.org/display/GRAILS/NetBeans+Integration
E
Um tanto quanto interessante esse framework, com a mesma ideologia do ruby on rails vale apena um investimento… nao cheguei a olhar ele com mais detalhes, mas tentar evitar essa forma de template com algo mais nao tão “diferente” pode ser uma općão…
no mais pra quem já conhece a ideologia do 37signals e do proprio rails ( webserver embutido… cobertura 100% de testes… etc… ) … esse parece ser um bom framework!
F
Não chegaram um pouco tarde demais?Kd o Mentawai? Ainda existe?
Existe sim.
E ja tem até integração para usar com o Adobe Flex
T
O Play Framework tem umas features bem interessantes para a versão 1.1. Vocês chegaram a dar uma olhada na documentação? Vejam:
Scala
http://www.playframework.org/documentation/1.1-trunk/scala
LambdaJ
http://www.playframework.org/documentation/1.1-trunk/lambdaj
Vocês acham que adicionar suporte para Scala pode trazer bons benefícios para o projeto?
Vocês utilizariam os recursos do lambdaj, como por exemplo, Closures?
PriceWatcher priceWatcher = new PriceWatcher();
Car.forEach(cars); {
of(priceWatcher).setPrice(var(Car.class));
}
P
Realmente, não é um apenas um “framework web”, é uma plataforma no mesmo estilo do Grails. Sei lá, acho que o Grails ja está aí e tem mais maturidade para quem investe em desenvolvimento orientado a linguagens dinamicas, etc. A fatia do bolo do play! fica para os visionários, por enquanto.
J
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
C
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
E voce acha que um framework que cria tantas camadas de abstracao como os “Rails Styles” o fazem sem memoria ?
Acho que esta na hora de voce comecar a realizar testes e não “ouvir o cara que disse, que um dia…”
O Grails é um exemplo de como vc nao precisa criar uma “plataforma iteira” para conseguir algo descente…
Mas como eu sempre digo… nao precisa cortar os pulsos
R
dar tempo ao tempo 8)
M
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
Sua aplicação web tem quantos usuários pra isso ser um problema?
R
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
Olá
em que embasamento vc diz isso?
J
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
Olá
em que embasamento vc diz isso?
Faz um CRUD e coloca uns profiling pra rodar. Ai vc me diz a diferença. Se não souber fazer isso, lamento.
J
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
E voce acha que um framework que cria tantas camadas de abstracao como os “Rails Styles” o fazem sem memoria ?
Acho que esta na hora de voce comecar a realizar testes e não “ouvir o cara que disse, que um dia…”
O Grails é um exemplo de como vc nao precisa criar uma “plataforma iteira” para conseguir algo descente…
Mas como eu sempre digo… nao precisa cortar os pulsos
Olha, o mesmo exemplo em Rails, com JRuby, até pode ser, o Grails ganha em menos memória. Mas vamos ver se esse ai que lançaram não papa memória como o Grails, ou vai dizer que pra rodar um aplicativo besta agora vou ter que reservar 256MB de memória dedicada só pra começar?
Se for assim, volto pro velho Servlet-JSP, é mais demorado, mas não come memória.
X
O grails não consome muita memória até porque 80%+ é feito em java. O problema do footprint gigante é o groovy coloca 45mb só de ExpandoMetaClasses durante o boot.
@mochuara
Esse problema do footprint inicial alto não interfere muito quando escalando verticalmente. O consumo por thread é bem baixo. É sim um problema serio quando se precisa hospedar em maquinas com pouca memória(menos de 512mb).
E esse play não é bem novo, existe desde 2007/2008 acho. E é até uma prova de conceito legal, usar tudo estatico e stateless. Mas nao parece que vai crescer muito.
Por ser stateless e sem spring, etc o consumo de memória do Play é extremamente baixo.
Grails e SpringRoo(que sim é muito novo) são muito mais maduros, evoluem muito mais rápido e acho que são mais promissores para atrair programadores java.
PS: A melhor ide pra se programar em grails nao é mais o Netbeans, mas o Eclipse com SpringSource Tool Suite, principalmente a versão 2.2.1. Em poucos meses os caras da SpringSource conseguiram ultrapassar o NB e devem ultrapassar até o Intellij logo logo.
J
O grails não consome muita memória até porque 80%+ é feito em java. O problema do footprint gigante é o groovy coloca 45mb só de ExpandoMetaClasses durante o boot.
Durante o boot nada. Fica monitorando 24 horas e você perceberá que um CRUD besta fica alocando memória que o mesmo com até o JSF + Hibernate e Spring não ocorre. E é apenas um CRUD. Quando você começa a manipular o danado, mexer mesmo, a memória vai comendo, sem dó. Depois os objetos demoram mais para serem desalocados. Mais pesado que Grails até hoje que vi só o JRuby com Rails e o Seam.
M
Eu sei que programadores adoram otimizar até o ultimo bit da sua aplicação mas avaliar framework web pelo consumo de memória que é muito mais barato do que tempo de desenvolvimento mostra a falta de visão que alguns, ainda que tecnicamente competentes, têm das reais necessidades enfrentada pelas empresas que precisam colocar uma projeto web no ar.
C
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
E voce acha que um framework que cria tantas camadas de abstracao como os “Rails Styles” o fazem sem memoria ?
Acho que esta na hora de voce comecar a realizar testes e não “ouvir o cara que disse, que um dia…”
O Grails é um exemplo de como vc nao precisa criar uma “plataforma iteira” para conseguir algo descente…
Mas como eu sempre digo… nao precisa cortar os pulsos
Olha, o mesmo exemplo em Rails, com JRuby, até pode ser, o Grails ganha em menos memória. Mas vamos ver se esse ai que lançaram não papa memória como o Grails, ou vai dizer que pra rodar um aplicativo besta agora vou ter que reservar 256MB de memória dedicada só pra começar?
Se for assim, volto pro velho Servlet-JSP, é mais demorado, mas não come memória.
Voce nunca ouviu falar em “pré alocação” ?
“Heap” para voce eh algum tipo de condimento para macarronada ?
Profillers adicionam um overhead gigantesco na execucao , não podem ser utilizados para medir “consumo” de forma burra (crtl+alt+del , ir no processo java e ver quanto ele consome)
E sim , quanto mais abstrair , mais memoria e mais recursos voce vai precisar… isso é FATO…
Se vc quer performance escovando o ultimo bit… entao volte para os cgi-bin escritos em C…
T
Como mudar linguagem e framework não deve ser problema para nós desenvolvedores, simplesmente mude de framework. Se você desaprova o consumo de memória, seja mais um a rejeitar o framework. Com tantas opções de frameworks bons (assim como o próprio Grails) dê a você mesmo o luxo de rejeitá-los por estes detalhes. Utilizar o framework é como se fosse um voto, confirmando de que ele está indo no caminho certo. Prefira aquele que está, no seu ponto de vista, indo para o caminho certo
X
O grails não consome muita memória até porque 80%+ é feito em java. O problema do footprint gigante é o groovy coloca 45mb só de ExpandoMetaClasses durante o boot.
Durante o boot nada. Fica monitorando 24 horas e você perceberá que um CRUD besta fica alocando memória que o mesmo com até o JSF + Hibernate e Spring não ocorre. E é apenas um CRUD. Quando você começa a manipular o danado, mexer mesmo, a memória vai comendo, sem dó. Depois os objetos demoram mais para serem desalocados. Mais pesado que Grails até hoje que vi só o JRuby com Rails e o Seam.
O consumo é maior que uma app em java puro, claro, mas não identifiquei tanto esse problema talvez por estar usando o G1GC.
O problema com do consumo excessivo por um CRUD pode ser devido a um bug na validação. Qual a versão testada?
B
apenas mais um “grao de areia na praia”.
T
kkkk Sotaque de japonês da porra o cara do vídeo…
A
Poxa gostei, eu que já mexi um tempinho com rails achei bem fácil. Espero que isso amadureça
N
Bastante interessante, pretendo utilizar em um projeto futuro por enquanto vou ficar nos estudos e testes e tentar convencer mais gente a testar.
R
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
Olá
em que embasamento vc diz isso?
Faz um CRUD e coloca uns profiling pra rodar. Ai vc me diz a diferença. Se não souber fazer isso, lamento.
Tenho uma aplicação em Grails que faz mais que CRUD e não percebi consumo de memória exacerbado!
R
cara, eu quando vejo a palavra framework em java sinto um frio na barriga :?
to me formando na faculdade, e ainda não consegui nada na área de web com java, e toda vez que eu começo estudando um framework vejo 329390248 criticas sobre ele falando pra eu não perder tempo e ir para outro. :shock:
Bom um framework que se pode considerar de 1ª linha no Java para web é o Hibernate, show de bola usar ele.
Sobre este novo framework, parece legal. Gostei da parte que mostra o trecho do código onde o programador esqueceu o “;”. Não mostra aquela pagina no browser cheia de linhas que a gente tem que ficar catando o erro, hehe.
R
Cgi-bin comia muita memória exatamente por toda execução ser um novo processo alocado. E é possível obter muita performance usando-se apenas Java (claro que tem um preço).
T
Hibernate não é exatamente um framework web, mas tá valendo
J
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
Olá
em que embasamento vc diz isso?
Faz um CRUD e coloca uns profiling pra rodar. Ai vc me diz a diferença. Se não souber fazer isso, lamento.Tenho uma aplicação em Grails que faz mais que CRUD e não percebi consumo de memória exacerbado!
Rs, sério mesmo? Então me ensina a usar porque 1 CRUD aqui comeu mais de 90MB. O mesmo com JSF (ahhh), ficou em 47MB e acrescentando Spring 2.5 e Hibernate ficou em 59MB. Quando fizemos uma parte administrativa de um aplicativo em Grails, porque achei o máximo usá-lo, o pico foi pra mais de 190MB. Um erro fatal que corrigimos no terceiro sprint de modificação, alterando para somente JSF, que caiu para menos de 100MB. Por isso chamo o Grails de “papa memória”.
P
Se vc quer performance escovando o ultimo bit… entao volte para os cgi-bin escritos em C…
Cgi-bin comia muita memória exatamente por toda execução ser um novo processo alocado. E é possível obter muita performance usando-se apenas Java (claro que tem um preço).
Para isso inventaram o fast-cgi
R
“Fantarrrrdigo” rsrrrs
Assim como varios outros que apareceram, Click Framework, Atena Framework, Neo Framework, Etc Framework = D.
Alguém usa algum desses frameworks pra desenvolver algum sistema relativamente grande ??
Eu adoro ver os screencasts, onde rapidamente o autor faz exemplo rsrrs.
Abraços.
K
Java On XunxoSinceraemente , alguma empresa vai investir em aprender a programar no estilo “play” , com a linguagem de paginas “play” ?
Outra , o demo é uma piada , o cara nem usa uma IDE… como se fosse comum desenvolver em java com notepad…
Se nao integra com uam IDE e nao tem suporte… fica dificil usar em equipe…
Acho que eh “just another java dummy framework”…
Apesar de ter o netbeans instalado, utilizo em quase 100% do tempo o VIM, para desenvolver. Na outra parte do tempo brinco com o gEdit.
H
alguem falou em Grails consumir memória excessiva ? desconheço isso .
Não reivente a roda, use Grails.
Herrera
T
Se Grails foi baseado em Rails, não seria Grails uma reinvenção?
R
Se Grails foi baseado em Rails, não seria Grails uma reinvenção?
Acredito que nao, nao existia nda similar de Rails para JAVA.
Sobre o consumo de memoria se um simples CRUD em grails consome em torno de 50mega, acho ate pouco…
S
Não chegaram um pouco tarde demais?Kd o Mentawai? Ainda existe?
Sim, o Mentawai ainda existe com muitos projetos em produção.
Eu gostei desse novo framework. Boa idéia e boa implementação. Na verdade a idéia veio do framework Ramaze (Ruby) que é excelente e na minha opinião mais prazeroso que o Rails. Na verdade são filosofias diferentes (Rails x Ramaze).
O exemplo do Ramaze é exatamente um ToDo list com Sequel.
Na minha opinião, o mais legal de Rails, Ramaze, Sinatra, Sequel, etc. não são os frameworks em si, mas a linguagem Ruby que te proporciona flexibilidade e abstração incomparáveis.
Qualquer coisa em Java poderá ser 10 vezes simplificada em Ruby. PONTO FINAL.
Java tem suas vantagens, mas em matéria de abstração e simplicaidade fica impossível competir com Ruby.
Em breve vou soltar um tutorial sobre Ramaze + Sequel em Ruby. Por enquanto ainda estou me aprimorando…
K
Se vc quer performance escovando o ultimo bit… entao volte para os cgi-bin escritos em C…
Cgi-bin comia muita memória exatamente por toda execução ser um novo processo alocado. E é possível obter muita performance usando-se apenas Java (claro que tem um preço).
Para isso inventaram o fast-cgi ;-)
Incrível, pensei que o pessoal que usa fast-cgi estivesse quase extinto depois do advento de tantas coisas/frameworks/apis que dizem aumentar absurdamente a produtividade no desenvolvimento web e o relativo barateamento do hardware para aguentar tantas camadas de abstração. Bom saber que ainda tem gente tocando as coisas em fast-cgi.
Inté
J
Afinal, um CRUD com GRAILS consome 90MB ou 50MB? Entre um e outro há uma baita diferença (90 é quase o dobro de 50MB). Tem alguém exagerando e/ou configurando alguma coisa errada ai…
E esse “play”, é papa memória? Alguém testou e verificou isso?
L
Olá
JSf não é para CRUD…JSF é tambem para CRUD…
Será que o JSF serve para alguma coisa além de justificar a necessidade de uso de IDE?
Dificilmente eu entraria feliz e convicto de que estão adotando a melhor solução no projeto de uma aplicação web usando JSF.
Só por verificar que o livro que ganhei do Ed Burns tem 833 páginas, já confirmei que as novas versões do JSF estão tão complexas como as anteriores. Típica xaropada inventada pelos maus programadores da Sun.
Na revista Mundo Java deste mês tem um artigo sobre os 10 maus hábitos dos desenvolvedores JSF. Ficou faltando só o principal: usar JSF.
[]s
Luca
F
Não reivente a roda, use Grails.Herrera
O correto seria: Não reivente a roda, use Rails!
Groovy é uma cópia de Ruby e Grails de Rails (até no nome). Não consigo encontrar motivos para utilizar.
E antes que alguém diga: “Grails roda na JVM” eu respondo:
Pra isso existe o JRuby.
Nunca, jamais, ninguém conseguirá atingir, em Java, a produtividade que se consegue em Rails. Simplesmente pq Rails é Ruby e Ruby é absurdamente mais produtivo (e prazerozo) que Java.
De qualquer forma, esse play framework me parece uma excelente alternativa para aumentar os padrões de produtividade quando se desenvolve em Java. Vale a pena ficar de olho.
Aproveito o gancho pra dar a dica: Conheçam o Spring roo. Tem conceitos diferentes mas é também uma boa alternativa para galgar novos patamares de produtividade no desenvolvimento com Java.
J
O correto seria: Não reivente a roda, use Rails!
Groovy é uma cópia de Ruby e Grails de Rails (até no nome). Não consigo encontrar motivos para utilizar.E antes que alguém diga: “Grails roda na JVM” eu respondo:
Pra isso existe o JRuby.Nunca, jamais, ninguém conseguirá atingir, em Java, a produtividade que se consegue em Rails. Simplesmente pq Rails é Ruby e Ruby é absurdamente mais produtivo (e prazerozo) que Java.
De qualquer forma, esse play framework me parece uma excelente alternativa para aumentar os padrões de produtividade quando se desenvolve em Java. Vale a pena ficar de olho.
Aproveito o gancho pra dar a dica: Conheçam o Spring roo. Tem conceitos diferentes mas é também uma boa alternativa para galgar novos patamares de produtividade no desenvolvimento com Java.
Bom, temos Scala. Roda sobre a JVM e nem sei porque não é uma linguagem oficial. Particularmente, acho Scala melhor que Ruby.
R
Se vc quer performance escovando o ultimo bit… entao volte para os cgi-bin escritos em C…
Cgi-bin comia muita memória exatamente por toda execução ser um novo processo alocado. E é possível obter muita performance usando-se apenas Java (claro que tem um preço).
Para isso inventaram o fast-cgi ;-)
O fast-cgi é bem diferente dos CGI-BIN que você sugeriu, ele já mantém bastante coisa pré-alocada. É, pra casos onde a implementação de módulos do servidor web ainda é precária. Como por ex, IIS + PHP via ISAPI. É tão instável que tem o fast-cgi como alternativa mais viável. Pelo Apache, é incrivelmente mais rápido usar o PHP + módulo. E fast-cgi NÃO é uma tendência.
Z
dei uma brincada com ele ontem, gostei bastante do mesmo…muito simples e muito fácil de se trabalhar…chega a ser ridículo até…
faz uns dois anos que eu não trabalho com java…eu fico pensando nesse monte de frameworks e afins que tem por ae…e o quanto de um dia pra noite cada um deles pode ficar completamente atrasado em relação a outro.
[]'s
T
Não reivente a roda, use Grails.Herrera
O correto seria: Não reivente a roda, use Rails!
Groovy é uma cópia de Ruby e Grails de Rails (até no nome). Não consigo encontrar motivos para utilizar.
Humm… sinto muito - mas sou obrigado a discordar. Os desenvolvedores do Grails assim como você não são do tipo que reinventam a roda. Tanto é que eles não fizeram isso. O Grails roda em cima de frameworks já bem estabelecidos como Spring, Sitemesh, Quartz, Hibernate entre outros. Onde é que eles reinventaram a roda? Provavelmente o caminho que tiveram que percorrer para ter um framework like Rails é bem menor do que os esforço feito para criar o Rails do zero. Sendo assim, acho o Grails válido como opção ao Rails.
Você não acha perigoso dizer jamais? Eu não acho muito dificil ser produtivo em java como no Rails. Se você abrir mão de algumas loucuras arquiteturais que todo projeto java tem e escolher uma arquitetura apropriada, dá pra dar um banho de produtividade no Rails. Por exemplo, dependendo do perfil do projeto vc pode usar um bom framework component-based para o java - temos muitas opcoes. E em Rails, vc sugere o que?
Respeito sua resposta, no entanto, a produtividade tá muito mais ligado ao perfil dos desenvolvedores. Há programadores Rails que vão sempre fazer as Actions e as Views do zero, enquanto outros criam scripts ou customizam os templates de geração de código. Produtividade na minha opinião vai muito além de usar os “generate:views e generate:controllers” ou a simplicidade da linguagem.
M
Não seria JRuby uma cópia das linguagens que já nasceram pra JVM?
Ruby como linguagem é legal, mas sua VM é bugada, mas quem se importa, hoje em dia ou vc esta na JVM ou tenta, e nessa questão JRuby ainda é uma promessa e sua performance sofrível, sera que alguem aqui usaria JRuby em produção? Acho que o GUJ tentou e voltou atrás. (poderiam confirmar ou desmentir?)
L
Olá
Surpresa para mim. Pode citar exemplos?
Pelo que sei, os caras mais envolvidos no desenvolvimento do GUJ estão cada vez mais usando também Ruby/Rails. Neste sábado no Devinsampa, o Fabio Kung me contou que na Caelum o Java não foi abandonado mas pélo menos 70% dos seus desenvolvedores são fluentes em Ruby/Rails. E lá também tem gente que manja muito de Scala. Ate brinquei com o Guilherme Silveira (palestrou sobre http://github.com/caelum/restfulie ) que no fim do curso que ele está fazendo na USP de linguagens funcionais, erlang, Scala, etc., sairá o VRaptor para Scala (pura brincadeira mas não duvido nada)
[]s
Luca
F
Reiventaram a roda desenvolvendo um framework que faz exatamente as mesmas coisas que um outro framework já existente.
Se você olhar o código do Rails e o código do Grails vai ver que as coisas não são bem assim.
De qualquer forma, não disse que Grails é ruim nem que não é uma opção válida. Eu disse que não consigo encontrar motivos para utilizá-lo, quando se tem um original muito melhor, muito mais maduro e completo à disposição.
Não é perigosoThiago. Usando Java é impossível atingir o nível de produtividade do Rails. Como eu disse, o Rails não é fantástico apenas pelos geradores e conceitos; Rails é fantástico pq usa Ruby e Ruby é absurdamente mais produtivo que Java.
Não Thiago, não dá! Eu gosto de Java e uso em vários projetos. É uma linguagem excelente, uma plataforma fantástica e tem suas aplicações. Mas dizer que é, ou pode ser, tão produtivo quanto Rails, Django ou qualquer framework que utilize linguagens dinâmicas, é loucura.
Não! JRuby é um port do Ruby para rodar na JVM. JVM é hoje uma plataforma e está aí exatamente pra isso: Possuir linguagens rodando sobre sua arquitetura. Um conceito inspirado na plataforma .NET.
Ruby não é legal, é fantástico. Assim como python, scala, etc…
E quanto à sua VM ser bugada, com que base você afirma isso?
F
Faltaram essas duas:
Por exemplo, dependendo do perfil do projeto vc pode usar um bom framework component-based para o java - temos muitas opcoes. E em Rails, vc sugere o que?
Eu não utilizo component-based em Java por vários motivos que fogem à nossa discussão. De qualquer forma, Rails é altamente desacoplado e configurável e te dá total liberdade de arquitetura (E isso vai melhorar ainda mais no Rails 3, previsto para o início do próximo ano).
Mas se a sua intenção com essa afirmação é deixar claro que existem casos onde adotar Java a despeito de Ruby/Scala/Python é a melhor escolha, concordo contigo! Existem inúmeras situações onde Java seja a melhor opção! Existem inúmeras onde Scala seja a melhor opção! Existem inúmeras situações onde Erlang seja a melhor opção!
A discussão não é essa, amigo. Eu não disse que Java é do inferno e que jamais deve ser utilizado. Eu disse que, usando Java, é impossível ser tão produtivo quando se usa Ruby. Isso é uma verdade indiscutível e não sou eu que estou dizendo. Estude um pouquinho das duas linguagens e comprove por si próprio.
Produtividade na minha opinião vai muito além de usar os “generate:views e generate:controllers” ou a simplicidade da linguagem.
Exatamente Thiago, você está chegando lá! E é exatamente por isso que Rails é fantástico!
Generators, qualquer um com um pouco de tempo livre, pode criar para qualquer linguagem e arquitetura. Rails não é fantástico pelos generators, vai muito além disso.
Este é o problema do “Blog de 15 minutos” que todo mundo lê e pensa que já aprendeu Rails. Quando se tem contato com o Rails no mundo real, você percebe a diferença de usar uma linguagem dinâmica sobre um framework com conceitos tão inovadores.
De qualquer maneira, não queremos começar flamewares aqui, não é mesmo.
Peço perdão se feri o coraçãozinho de alguém quando disse que não encontro motivos para usar Grails. Se você encontrou os seus, então use!
T
Lift, Grails, Play Framework, Pylons, Turbo Gears, Cake PHP … tantos frameworks inspirados ou com idéias parecidas ao Rails onde seus desenvolvedores preferiram reinventar a roda? Rails é ótimo, mas não é a última bolachinha do pacote.
Se você olhar o código do Rails e o código do Grails vai ver que as coisas não são bem assim.
De qualquer forma, não disse que Grails é ruim nem que não é uma opção válida. Eu disse que não consigo encontrar motivos para utilizá-lo, quando se tem um original muito melhor, muito mais maduro e completo à disposição.
A minha colocação se diz respeito ao código utilizado para criar o framework, e não para desenvolver nele. ORM, Controle, Jobs entre outras coisas o grails já reaproveitou de frameworks java bem estabelecidos enquanto no Rails eles tiveram que criar tudo isso. Ou seja, o Grails só se deu ao trabalho de copiar o estilo de desenvolvimento de Rails e não precisou criar nada do zero, como por exemplo, criar seu próprio ORM. É isso que eu quis dizer.
Só por causa da linguagem? Ok, então descordamos
Loucura? Sem exceção? Ok, caso sim, descordamos também.
F
Lift, Grails, Play Framework, Pylons, Turbo Gears, Cake PHP … tantos frameworks inspirados ou com idéias parecidas ao Rails onde seus desenvolvedores preferiram reinventar a roda? Rails é ótimo, mas não é a última bolachinha do pacote.
Não é a última mesmo. É a primeira! As outras são cópias. 8)
Lift é bem legal, vale a pena dar uma olhada. Pylons, só olhei superficialmente, mas me pareceu excelente também. Turbo Gears ainda não tive tempo de estudar. Cake PHP é podre, uma tentativa pífia de fazer em PHP coisas que se faz em Ruby.
A minha colocação se diz respeito ao código utilizado para criar o framework, e não para desenvolver nele.
Eu disse pra você olhar o código do Rails e o código do Grails e não de aplicações desenvolvidas com eles.
SÓ??? É amigo, discordamos.
Discordamos mesmo.
M
OláSurpresa para mim. Pode citar exemplos?
http://opensynapse.net/post/24570619/ruby-memory-leak-regular-expressions-in-class-methods
Estou surpreso de conhecer alguem que nunca tenha ouvido falar de memory leaks no interpretador Ruby!
Pelo que sei, os caras mais envolvidos no desenvolvimento do GUJ estão cada vez mais usando também Ruby/Rails. Neste sábado no Devinsampa, o Fabio Kung me contou que na Caelum o Java não foi abandonado mas pélo menos 70% dos seus desenvolvedores são fluentes em Ruby/Rails. E lá também tem gente que manja muito de Scala. Ate brinquei com o Guilherme Silveira (palestrou sobre http://github.com/caelum/restfulie ) que no fim do curso que ele está fazendo na USP de linguagens funcionais, erlang, Scala, etc., sairá o VRaptor para Scala (pura brincadeira mas não duvido nada)
[]s
Luca
Mas afinal eles usam JRuby no site GUJ ou não? Voce sabe?
T
Eu não utilizo component-based em Java por vários motivos que fogem à nossa discussão. De qualquer forma, Rails é altamente desacoplado e configurável e te dá total liberdade de arquitetura (E isso vai melhorar ainda mais no Rails 3, previsto para o início do próximo ano).
Mas se a sua intenção com essa afirmação é deixar claro que existem casos onde adotar Java a despeito de Ruby/Scala/Python é a melhor escolha, concordo contigo! Existem inúmeras situações onde Java seja a melhor opção! Existem inúmeras onde Scala seja a melhor opção! Existem inúmeras situações onde Erlang seja a melhor opção!
A discussão não é essa, amigo. Eu não disse que Java é do inferno e que jamais deve ser utilizado. Eu disse que, usando Java, é impossível ser tão produtivo quando se usa Ruby. Isso é uma verdade indiscutível e não sou eu que estou dizendo. Estude um pouquinho das duas linguagens e comprove por si próprio.
Ok!
Exatamente Thiago, você está chegando lá! E é exatamente por isso que Rails é fantástico!
Generators, qualquer um com um pouco de tempo livre, pode criar para qualquer linguagem e arquitetura. Rails não é fantástico pelos generators, vai muito além disso.
Sim, é um diferencial no Rails. Só não concordo com a afirmativa de que Rails é mais produtivo pq também posso fazer isso em java. Mas claro, o ambientes de desenvolvimento Rails e Grails é mais encorajador para utilizar essas práticas.
No java existe um mal parecido. Todo mundo aprendeu uma arquitetura de caixinha e não conseguem ou não querem sair dela. É neste momento que o Play é muito bem vindo - ele simplesmente saiu do senso comum - trouxe um ambiente novo para quem ainda sonha em ser produtivo em java
De qualquer maneira, não queremos começar flamewares aqui, não é mesmo.
Peço perdão se feri o coraçãozinho de alguém quando disse que não encontro motivos para usar Grails. Se você encontrou os seus, então use!
Sim, claro!
M
Loucura? Sem exceção? Ok, caso sim, descordamos também.
Concordo que um ambiente dinâmico é fundamental para a produtividade, mas frameworks numa linguagem estática podem simular essa feature (ou até mesmo empregar outras linguagens para o trabalho, que é o caso do framework play que usa linguagens dinâmicas para templates e no build).
F
Há bugs no interpretador Ruby. Assim como há no interpretador Java, python, etc.
Olha esse site que legal: http://bugs.sun.com/
Quando alguém diz que a ferramenta X é “bugada”, entendemos que ela está quebrada e inutilizável. O que não é verdade nem para o interpretador Ruby, nem para a JVM e nem para o interpretador Python.
Aqui está o que eles usam: http://github.com/caelum/guj3-java
edited: correção de link
P
OláJSf não é para CRUD…JSF é tambem para CRUD…
Será que o JSF serve para alguma coisa além de justificar a necessidade de uso de IDE?
Dificilmente eu entraria feliz e convicto de que estão adotando a melhor solução no projeto de uma aplicação web usando JSF.
Só por verificar que o livro que ganhei do Ed Burns tem 833 páginas, já confirmei que as novas versões do JSF estão tão complexas como as anteriores. Típica xaropada inventada pelos maus programadores da Sun.
Na revista Mundo Java deste mês tem um artigo sobre os 10 maus hábitos dos desenvolvedores JSF. Ficou faltando só o principal: usar JSF.
[]s
Luca
Oi Luca, concordo em partes contigo. Mas uma coisa devemos admitir, a componentização E principalmente, os componentes que o JSF oferece não tem comparação com o que temos hoje por aí em termos de facilidade. Por mais que exista alternativas boas, de mercado e open, na grande maioria te obriga a configurar um xml, registrar um filtro ou dois, customizar o CSS, usar uma TAGLIB :twisted: , e por ai vai…
M
http://opensynapse.net/post/24570619/ruby-memory-leak-regular-expressions-in-class-methods
Estou surpreso de conhecer alguem que nunca tenha ouvido falar de memory leaks no interpretador Ruby!
Há bugs no interpretador Ruby. Assim como há no interpretador Java, python, etc.
Olha esse site que legal: http://bugs.sun.com/
Quando alguém diz que a ferramenta X é “bugada”, entendemos que ela está quebrada e inutilizável. O que não é verdade nem para o interpretador Ruby, nem para a JVM e nem para o interpretador Python.
Então vc concorda que ha bugs no interpretador Ruby mas não concorda em dizer que ele esteja bugada? Ok, eu já deveria saber que não se discute com fanáticos em futebol, religião e linguagens de programação.
ps: Voce não apontou nenhum link com memory leak na JVM, só pra constar…
Aqui está o que eles usam: http://github.com/caelum/guj3-java
edited: correção de link
Bom então JRuby no site foi um experimento, parece que eles usam Java mesmo.
F
Loucura? Sem exceção? Ok, caso sim, descordamos também.
Concordo que um ambiente dinâmico é fundamental para a produtividade, mas frameworks numa linguagem estática podem simular essa feature (ou até mesmo empregar outras linguagens para o trabalho, que é o caso do framework play que usa linguagens dinâmicas para templates e no build).
Concordo contigo mochuara, mas veja o que você disse: “… mas frameworks numa linguagem estática podem simular essa feature …” depois disse “… framework play que usa linguagens dinâmicas para templates e …”. Usaram linguagens dinâmicas para aumentar a produtividade! E não poderiam ter tomado uma decisão melhor.
Essa é a grande sacada da JVM que, na minha opinião, é uma das melhores (senão a melhor) escolha de plataforma de desenvolvimento. Pois te dá a liberdade de usar sua excelente arquitetura unida com a produtividade de linguagens dinâmicas.
E só pra deixar claro que não sou xiita: Eu sou perfeitamente crente na possibilidade de, em breve, desenvolverem um framework muito melhor que Rails, usando linguagens dinâmicas e que rode de forma natural sobre a JVM. A única coisa que me deixa chateado é perderem tempo refazendo o Rails em outras linguagens. Este é o cerne do meu ponto de vista aqui.
F
Então vc concorda que ha bugs no interpretador Ruby mas não concorda em dizer que ele esteja bugada? Ok, eu já deveria saber que não se discute com fanáticos em futebol, religião e linguagens de programação.
Não sou fanático amigo. Você é que está agindo como um.
Se formos usar o mesmo conceito podemos dizer que a JVM é bugada também?
Não mesmo, eu postei um link com inúmeros bugs na JVM. E nem por isso digo que ela é bugada e inutilizável, muito pelo contrário! (leia meu post anterior)
Bom então JRuby no site foi um experimento, parece que eles usam Java mesmo.
No Guj eu também não utilizaria.
Já estava pronto quando pensaram em incluir, só por diversão, alguma coisinha de JRuby; Foi concebido e desenvolvido desde o início sobre Java e sua plataforma. JRuby não atende neste caso.
M
Concordo contigo mochuara, mas veja o que você disse: “… mas frameworks numa linguagem estática …” depois disse “… framework play que usa linguagens dinâmicas para templates e …”. Usaram linguagens dinâmicas para aumentar a produtividade! E não poderiam ter tomado uma decisão melhor.
Essa é a grande sacada da JVM que, na minha opinião, é uma das melhores (senão a melhor) escolha de plataforma de desenvolvimento. Pois te dá a liberdade de usar sua excelente arquitetura unida com a produtividade de linguagens dinâmicas.
A maioria dos frameworks Java consegue aumentar produtividade usando mecanismos que dão mais dinamicidade ao desenvolvimento, vide Reflection API, XML, Annotations, AOP, etc… tudo isto sem abrir mão do Java que é estatico.
Por isso concordo que usar logo uma linguagem dinâmica de uma vez é bem melhor do que toda essa confusão que virou o ecossistema Java. Mas acontece que nem todas linguagens dinâmicas rodam bem na atual JVM, e JRuby é uma delas.
M
Pelo visto vc não sabe diferenciar bugs em componentes, bibliotecas, frameworks com bugs na implementação da linguagem. JVM é o estado da arte perto do MRI.
F
Mas acontece que nem todas linguagens dinâmicas rodam bem na atual JVM, e JRuby é uma delas.
Concordo novamente. Por isso opto por usar Ruby e não JRuby. Este é um dos motivos que me deixam a ansiar por um framework inovador, melhor que Rails, que utilize linguagens dinâmicas e que rode sobre a JVM.
F
Não mesmo, eu postei um link com inúmeros bugs na JVM. E nem por isso digo que ela é bugada e inutilizável, muito pelo contrário! (leia meu post anterior)
Pelo visto vc não sabe diferenciar bugs em componentes, bibliotecas, frameworks com bugs na implementação da linguagem. JVM é o estado da arte perto do MRI.
Amigo, você leu quando eu escrevi que a JVM é uma das melhores (se não a melhor) plataforma de desenvolvimento da atualidade?
JVM é uma plataforma excelente, madura e completa. Melhor que .NET, na minha opinião. JVM é totalmente diferente da MRI (inclusive no seu propósito).
Você é que não sabe diferenciar que estamos discutindo linguagem e produtividade e não plataformas.
M
Sim, eu estava falando que Ruby sofre com memory leaks. Não tenho nenhum processo em execução vazando memória com a JVM.
R
Vish mãe, o pau ta quebrando kkkkkkkkkkkkkkkkkkkk :twisted: :twisted: :twisted: :twisted:
L
Olá
Não vejo assim. Apenas gente com opiniões diferentes e isto é muito salutar em qualquer diálogo. Quando todo mundo concorda o papo morre rapidinho.
Quanto a isto Java tem um monte de exemplos. Alguns em casos especialíssimos e raros como o caso que você mostrou. Mas já vi alguns em situações terríveis. Fora os bugs de verdade mesmo que levaram anos pára serem corrigidos.
Mas estes erros não impediram o Java de ser maciçamente adotado e não está impedindo o crescimento de Ruby/Rails.
Minha opinião: não é que Ruby seja tão melhor assim do que Java. É a combinação Ruby/Rails que é MUITO melhor do que Java no que se refere a desenvolvimento de sistemas web. É até covardia comparar JSF+trocentos facesxxx da vida, SEAM e outras baboseiras inventadas por teóricos com o Rails oriundo de prática.
Isto não significa usar 100% de Ruby/Rails. O par Lucene e SOLR ainda não encontraram no bugado Ferret e no Sphinx, similares a altura no mundo Ruby (apesar da extrema facilidade de tratar texto em Ruby dar de 10 a ZERO no Java graças ao seu lado PERL)
E também não se pode comparar a facilidade de resolver problemas usando Ruby em relação ao Java sem lembrar que com Ruby são necessários muito mais testes unitários para compensar a tipagem dinâmica (e a possibilidade de monkey patches). Ruby exige menos linhas de código mas considerando as necessárias linhas de teste a diferença cai um pouquinho.
OBS: Linhas de código a menos siginifica ganho de produtividade porque há menos código para rever (revisão de código é uma das melhores práticas de desenvolvimento ágil)
[]s
Luca
F
Amigo, você leu quando eu escrevi que a JVM é uma das melhores (se não a melhor) plataforma de desenvolvimento da atualidade?JVM é uma plataforma excelente, madura e completa. Melhor que .NET, na minha opinião. JVM é totalmente diferente da MRI (inclusive no seu propósito).
Sim, eu estava falando que Ruby sofre com memory leaks. Não tenho nenhum processo em execução vazando memória com a JVM.
Como estamos discutindo linguagem/produtividade e não plataformas, este será meu último post nessa thread. De qualquer maneira, se memory leaks são seu único argumento pra não usar Ruby, lamento, eu não vejo nisso motivos para abandonar a tecnologia.
Finalizando, seguem algumas referências pra quem estiver interessado no assunto: “Ruby e Memory Leaks”.
http://www.akitaonrails.com/2008/2/22/ruby-e-mem-ria
http://www.akitaonrails.com/2008/1/29/akitaonrails-com-and-god
http://www.mouseoverstudio.com/blog/2009/03/08/ruby-vs-java-e-como-o-coelho-venceu-novamente-a-lebre/
Não rchgonzaga, não está não. Ter pontos de vista diferentes em determinado assunto não é motivo para criar inimigos. Isso seria fanatismo a lá Bin Laden.
Se trabalhássemos no mesmo local, tenho certeza que sairíamos, depois do expediente, pra tomar uma coca-cola e dar boas risadas dessa discussão (ou continuá-la acompanhada de petiscos).
R
Rsrsrsr, calma gente … aqui no forum não tem como eu dar um “ar” de humor, não foi no sentido de briga realmente ok ?
Abraços
N
Sem querer ofender mas… louco é quem afirma com 100% de certeza que é impossivel atingir essa produtividade sem excessão, nunca esteja tão certo de si assista o chaves que ele tem um dito sobre as pessoas que tem total certeza
M
Não Thiago, não dá! Eu gosto de Java e uso em vários projetos. É uma linguagem excelente, uma plataforma fantástica e tem suas aplicações. Mas dizer que é, ou pode ser, tão produtivo quanto Rails, Django ou qualquer framework que utilize linguagens dinâmicas, é loucura.
Sem querer ofender mas… louco é quem afirma com 100% de certeza que é impossivel atingir essa produtividade sem excessão, nunca esteja tão certo de si assista o chaves que ele tem um dito sobre as pessoas que tem total certeza
A unica forma de ser mais produtivo em Java do que numa linguagem dinâmica é não tendo que escrever nenhum código, se tiver que escrever vc tem 100% de chances de ser menos produtivo em Java, principalmente se a linguagem dinâmica roda na JVM e portanto tem acesso a todas as bibliotecas do Java.
T
O problema é 100% de certeza que vocês estão afirmando. Isso não é regra. Isso vai variar dependendo do programador, projeto entre outras coisas. Sei que linguagens dinâmicas em geral são mais produtivas - mas existem muitos outros fatores a serem considerados.
S
Excelente! O cara juntou JQuery, Java e Groovy pra fazer um port do Ramaze pra Java.
Um framework full-stack, moderno, ágil e em Java.
O que me espanta é ver a galera criticando uma iniciativa independente de um cara sozinho que teve a motivação de não só imaginar como conceber esse projeto.
A mesma ladainha de sempre: Pra que outro? Por que tentar inovar se já tem centenas de frameworks?
Quem faz um framework desses faz para agradar a si mesmo, faz pelo prazer de fazer alguma coisa, e não para deixar a comunidade do GUJ contente.
Parabéns para esse francês! Trabalho excelente!
Sugiro a quem criticou dar uma olhada nesse vídeo:
[youtube]http://www.youtube.com/watch?v=1r911KRGwi4[/youtube]
L
Olá
A mesma ladainha de sempre: Pra que outro? Por que tentar inovar se já tem centenas de frameworks?Quem faz um framework desses faz para agradar a si mesmo, faz pelo prazer de fazer alguma coisa, e não para deixar a comunidade do GUJ contente.
Sérgio
Eu mesmo sou testemunha das muitas críticas você sofreu aqui por ter criado um framework. Hoje acho que estão errados todos que o criticaram só pelo fato de você ter tentado uma outra alternativa para uma coisa que já existia.
Reli há pouco tempo um excelente livro que recomendo a todos que se chama The Myths of Innovation do Scoptt Berkun. O livro tenta analisar o processo criativo e as barreiras que se impoem normalmente contra o criador. Uma das barreiras costumeiras é dizer para o cara que isto já existe (a terrível e brochante frase Not Invented Here).
Em empresas comuns sempre que alguém tem uma idéia nova, lá vem a ladainha pondo um monte de impecilhos inclusive a tal síndrome do NIH. Nas empresas mais criativas tipo Google por exemplo, os criadores são incentivados a desenvolver suas idéias mesmo que sejam sobre coisas que já existam. O mundo vem evoluindo a partir de coisas que já existem. E se ninguém tentar, as melhorias virão mais devagar. No livro Founders at Work (série de entrevistas com criadores de startups), o Paul Buchheit, criador do Gmail e do AdSense, diz que no Google por mais louca que seja sua idéia, a primeira reação é de estimular. É provável que quem ouve diga: “Oh, yeah, thatś a good idea”
Hoje em dia dou valor àqueles que como você tentam. É claro que posso até fazer algumas restrições ao seu framework e isto sei que aceitará ou não dependendo se forem pertinentes ou não. Acho totalmente errado criticar alguém como você que toma iniciativas pelo fato de ter tomado iniciativa, por ter tentado criar alguma coisa.
Mesma coisa vale para o autor deste framework. Não sei se será dominante ou se vai mudar o preço do petróleo. Aliás quem faz geralmente nem está preocupado com isto. Tiro o meu chapéu para o cara que fez por ter tentado uma outra alternativa.
[]s
Luca
M
Quanto a fazer algo para agradar a si mesmo e aos outros, não precisam ser opções excludentes.
X
Groovy não é cópia do Ruby. Groovy foi inicialmente inspirado pelo python. Depois teve influencia de muitos outros incluindo Ruby.
Falar que o Grails é uma cópia do Rails é mostrar total desconhecimento do funcionamento interno de rails, grails ou ambos.
Grails copia muito da DSL, da filosofia, o nome :D, mas a implementação é absurdamente diferente. O objetivo do groovy e do grails é deixar o java produtivo não substitui-lo.
Groovy foi feito com o objetivo de ser confortável, produtivo e compativel para programadores Java. JRuby não. Java é muito mais que a Jvm, são as bibliotecas, frameworks, a linguagem, ferramentas, servidores, etc…
De qualquer maneira, o Play var ser totalmente compativel com java e vai ser muito mais rapido que grails, groovy ou jruby por usar muito java estaticamente. O gargalo de produtividade vai ser o java talvez, mas os caras ja estao integrando scala para resolver esse problema. Parece que tem futuro.
N
Excelente! O cara juntou JQuery, Java e Groovy pra fazer um port do Ramaze pra Java.Um framework full-stack, moderno, ágil e em Java.
O que me espanta é ver a galera criticando uma iniciativa independente de um cara sozinho que teve a motivação de não só imaginar como conceber esse projeto.
A mesma ladainha de sempre: Pra que outro? Por que tentar inovar se já tem centenas de frameworks?
Quem faz um framework desses faz para agradar a si mesmo, faz pelo prazer de fazer alguma coisa, e não para deixar a comunidade do GUJ contente.
Parabéns para esse francês! Trabalho excelente!
Sugiro a quem criticou dar uma olhada nesse vídeo:
[youtube]http://www.youtube.com/watch?v=1r911KRGwi4[/youtube]
Concordo em ordem genero e grau, aparentemente algumas pessoas se sentem ofendidas pelo fato de surgirem outras opções a que elas usam.
Parabens ao guillaume bort, trabalho fantastico.
Y
Oi Luca, concordo em partes contigo. Mas uma coisa devemos admitir, a componentização E principalmente, os componentes que o JSF oferece não tem comparação com o que temos hoje por aí em termos de facilidade. Por mais que exista alternativas boas, de mercado e open, na grande maioria te obriga a configurar um xml, registrar um filtro ou dois, customizar o CSS, usar uma TAGLIB :twisted: , e por ai vai…
Eu nao vou te dizer, VRaptor é a solucao porque ainda nao pus ele em producao, to fazendo testes ainda. Mas estou gostando muito da produtividade que ele traz.
Eu posso te dizer que talvez VRaptor seja sua resposta, recomendo muito que pelo menos voce de uma olhada. Eu trabalho com JSF ha uns dois anos e cada dia que passa gosto menos.
Quanto a registrar filtros, css e xml, nem de longe voce escapa disso com JSF.
R
Excelente! O cara juntou JQuery, Java e Groovy pra fazer um port do Ramaze pra Java.Um framework full-stack, moderno, ágil e em Java.
O que me espanta é ver a galera criticando uma iniciativa independente de um cara sozinho que teve a motivação de não só imaginar como conceber esse projeto.
A mesma ladainha de sempre: Pra que outro? Por que tentar inovar se já tem centenas de frameworks?
Quem faz um framework desses faz para agradar a si mesmo, faz pelo prazer de fazer alguma coisa, e não para deixar a comunidade do GUJ contente.
Parabéns para esse francês! Trabalho excelente!
Sugiro a quem criticou dar uma olhada nesse vídeo:
[youtube]http://www.youtube.com/watch?v=1r911KRGwi4[/youtube]
Fantástico esse vídeo…
Falou tudo
(oops… ressucitei um tópico… foi mal)
R
Já que eu ressuscitei o tópico e ele não é tão antigo assim… e não tinha colocado nenhuma opinião, vou colocar aqui o que coloquei em outro fórum…
O link é: http://javafree.uol.com.br/topic-877170-E-o-Playframework.html
Não sei se é permitido links de outros fóruns… de qualquer forma… vou postar o que escrevi lá… segue abaixo:
Vamos aos Play:
A primeira coisa a se notar é que o play é um framework Java. Mas não é um framework JEE. Eu não vejo problema nisso a principio, o que acontece é que ao invés de manter só o framework, o desenvolvedor do play, terá que manter também, uma arquitetura, um servidor, etc. Ainda não sei o que ele usa por baixo dos panos, mas seria bem viavel se utilizasse algo como um Tomcat turbinado.
Eu acho que o JEE hoje, com a utilização de frameworks não tem tanta importância, a não ser para criar um request e response… e fazer a comunicação HTTP. No caso do JSF, por exemplo, request e response praticamente nem existem. O JEE, mesmo com as últimas versões, não oferece grande vantagem já que voce usará é um framework por cima. Até mesmo o JSP tá saindo de linha. E isso se deve ao fato de suas limitações. O pessoal acaba deixando de lado e criando o próprio engine.
Um outro aspecto, que faz grande parte das mágicas, que permitem ao play ser bastante produtivo é a utilização de um Java Agent. Esse java agent, apesar de eu não ter estudado a fundo, deve “tunar” as suas classes em tempo de execução. Fazendo os getters e setters que você não escreveu, implementando os métodos do Model e fazendo o Hot Deploy do seu projeto sem a necessidade de reiniciar o servidor. Um Class Loader especial provavelmente ajuda nesse processo também.
Hoje a maioria dos frameworks utilizam a manipulação de byte codes para facilitar o desenvolvimento. Essa manipulação permite que sejam feitas algumas coisas pelo usuário, que é a tarefa do framework. Antes da proliferação dessa técnica o que acontecia, é que o framework elevava a aplicação a um nível de abstração bem mais alto para poder trabalhar numa cama intermediária entre a JVM e a aplicação. Hoje os frameworks atuam entre o bytecode e a JVM, mantendo a camada de aplicação sobre o Java puro, ao invés de sobre uma camada do framework. Isso facilita bem o desenvolvimento e o aprendizado das ferramentas.
O esquema de redirecionamento também é bastante interessante. Quando você faz por exemplo:
O framework permite que acesse um post com a URL /posts/6 por exemplo. Mas vai além disso… se você utilizar no seu código um redirecionamento tipo
O framework irá ver que Application.show tem um route… e vai renderizar o link como /posts/${post.id} por exemplo. Ou seja, faz a leitura ao contrário também… Isso eu achei bem legal.
A questão de utilizar arquivos de properties grandes, eu não vejo como um problema. Pois apesar de serem grandes, são documentados e você quase não tem que escrever neles… Se quiser alguma configuração apenas descomente alguma linha do arquivo…
A linguagem utilizada nos templates tem bastante poder, utilizando groovy para fazer o evaluation. Oferece uma sintaxe especial para diversos tipos de funcionalidade: # para chamar scripts ou tags, @ para links, etc. Isso torna a leitura do código fácil depois que voce acostuma com os símbolos. O sistema de includes das páginas também é legal, pois permite que sejam utilizados templates dentro de outros…
Os controllers também são bastante simples de se escrever, sem segredo… E oferece também um esquema de validação e mensagens, igualmente simples…
O framework tem uma característica de ser Stateless. Ou seja, você não deve guardar estado nos objetos. Concordo plenamente com isso, não é necessário voce ter milhoes de objetos cada um num escopo para ter uma aplicação bem implementada. Na verdade essa variedade de escopos usadas em alguns frameworks, só causa problemas.
Uma outra feature que estudarei mais profundamente e me interessou, é que a sessão é gravada em cookies. Isso pode ser uma grande vantagem do framework, vou estudar isso melhor futuramente.
Fiz o tutorial do blog… e me pareceu bem estável a ferramenta. Não apresentou erros durante o desenvolvimento. O tutorial é bem explicado, e tem boa documentação.
Vamos dizer assim que é um framework bem redondo.
Algumas críticas:
Injeção de dependencia: Não sei se possui mas não encontrei. Na aplicação de exemplo, não seria realmente necessário. Mas em aplicações grandes voce teria que distribuir o código em services e tal. Apesar de concordar com a natureza stateless, não concordo muito com a natureza static. Nos controllers os métodos são todos static e parece que a ideia é trabalhar assim no framework, se for isso acho que é uma desvantagem bem grande, e deve ser revisto.
Auxilio na view: A linguagem utilizada em templates é bastante poderosa, mas as views são escritas praticamente com HTML. E as tags também são assim. Acaba que é como se voce tivesse tag files do JSP, mas não tenha tags mesmo, com .java e tal.
Sobrescreve o JEE: O play é tudo: framework, servidor, ferramenta. Isso vai tornar mais complicada a adoção e também a evolução do mesmo, já que tem muito código a ser visto. O pacote do play tem 45 Mb. É muita coisa, é claro que por baixo dos panos foram utilizadas outras ferramentas. Mas como a integração é feita pelo play, esse código tem que ser mantido por ele.
Considerações finais:
O Play parece funcionar realmente, foi bastante estável nos testes feitos. O sistema de deploy é excelente. É produtivo e fácil. Apesar de ter todas essas vantagens, e que ele está seguindo a tendência, praticamente todo o framework pode ser substituído por ferramentas que existem no mercado. A grande vantagem do play é que já vem tudo pronto e configurado.
Para ter um framework igual ao play, você pode utilizar por exemplo o Spring. No controller utiliza algo como VRaptor ou Next, que são baseados no Spring MVC. Orientação a aspectos, para fazer os métodos que não são implementados por você como os getters, setters e métodos do Model. E utiliza um template mais poderoso do que o JSP. As queries já são contruidas com JPA mesmo. Aí você já tem um play. Com alguma configuração de class loader e java agent, você consegue o mesmo deploy. A diferença é que nesse caso você estará no Standard, ou seja, usando tomcat, eclipse, plugins, tudo que todo mundo já utiliza. Ao invés de jogar tudo fora e começar do zero.
Não estou criticando o framework e falando que ele é ruim por causa disso. Pelo contrário, acho que ele fez tudo certo, utilizando tendencias de mercado e tudo mais. Só que você começa de uma plataforma nova e isso dificulta bastante a adoção.
Apesar tudo que tem no play, existir no mercado, existe uma grande vantagem do play. Ele já está todo configurado e funcionando, as interfaces já foram testadas e estão estáveis. E não é fácil montar uma arquitetura dessa, gasta muito tempo, testes e código. E não é qualquer programador que consiga fazer uma arquitetura dessas.
A minha crítica em relação ao play é que ele poderia utilizar as coisas que já existem, mesmo que existam limitações, com um pouco de raciocinio, poderia ser feito algo muito semelhante senão igual ao que o play é hoje. E esse é o grande desafio de se desenvolver frameworks, partindo do que já existe, como podemos melhorar? Fazer tudo de novo, é claro que teremos algo melhor. Fazer melhor com a base instalada que é o difícil. Então vejo o play mais como uma proposta de como fazer, do que realmente adotá-lo em larga escala.
Utilizaria o play em algum projeto? Sim.
Mudaria alguma coisa nele? Sim, faria uma camada facilitadora do que já existe, e já configurada, ao invés de criar tudo do zero. Assim a adoção poderia sem bem maior.
No mais gostei da ferramenta, e vou estudar alguns aspectos mais profundamente… Achei bastante válida a iniciativa…
Até mais
Obrigado
PS: Só um comparativo com o Next. O Next hoje possui features, que são implementadas por outros frameworks como o Spring, que o Next inclusive utiliza como base. O caso do Next, é que essas features foram criadas antes de existirem em outros frameworks. A intenção do Next agora, é continuar justamente nessa linha que falei, utilizando features que outros frameworks já implementam. E o Next será apenas uma camada facilitadora, com algumas biliotecas que não são implementadas pelos outros frameworks. Uma configuração mais amigável, sem XML, milhoes de arquivos, etc. Que eu acho que é a linha com mais prosperidade e que possibilitará mais adoção do mercado. As próximas versões serão inclusives modulares e poderão ser utilizadas em projetos que já tem a adoção do Spring por exemplo como um add-on para melhorar a produtividade, ao invés de utilizar o framework inteiro (para quem já usa, essa opção não será descartada de qualquer forma).
B
Ele não utiliza um parser http qualquer, se trata do Apache Mina, que responsa eim!?
http://bazaar.launchpad.net/~play-developers/play/1.1-unstable/annotate/head%3A/framework/src/play/server/Server.java
Isso sim pode se dizer que jamais o ruby vai ter (haahahah)
*adicionado link da implementação
Criado 26 de novembro de 2009
Ultima resposta 7 de abr. de 2010
Respostas 115
Participantes 42