Vish mãe, o pau ta quebrando kkkkkkkkkkkkkkkkkkkk :twisted: :twisted: :twisted: :twisted:
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
[quote=mochuara][quote=Filipe Chagas]
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).
[/quote]
Sim, eu estava falando que Ruby sofre com memory leaks. Não tenho nenhum processo em execução vazando memória com a JVM.[/quote]
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).
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
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 
[quote=nofan][quote]
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.
[/quote]
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 [/quote]
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.
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]
Olá
[quote=saoj]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.[/quote]
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
Quanto a fazer algo para agradar a si mesmo e aos outros, não precisam ser opções excludentes.
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.
[quote=saoj]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]
[/quote]
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.
[quote=peerless]
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…[/quote]
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.
[quote=saoj]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]
[/quote]
Fantástico esse vídeo…
Falou tudo
(oops… ressucitei um tópico… foi mal)
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).
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