Novo framework web

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

nofan wrote:

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.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

mochuara wrote: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.

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.

This message was edited 3 times. Last update was at 07/12/2009 23:12:34

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:

Olá

saoj wrote: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

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

saoj wrote:
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.

Quanto a fazer algo para agradar a si mesmo e aos outros, não precisam ser opções excludentes.

This message was edited 1 time. Last update was at 10/12/2009 17:07:37

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

, 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.

JavaChild Membro desde: 09/12/2007 17:03:07 Mensagens: 133 Offline

saoj wrote: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:

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.

JavaEvangelist Membro desde: 07/03/2007 15:58:16 Mensagens: 480 Offline

peerless wrote:
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 , 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.

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1838 Offline

saoj wrote: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:

Fantástico esse vídeo...

Falou tudo

(oops.. ressucitei um tópico.. foi mal)

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1838 Offline

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).

JavaGuru Membro desde: 04/06/2006 13:50:18 Mensagens: 216 Offline

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

Notícias, artigos e o maior fórum brasileiro sobre Java