JSF é o futuro nas empresas?

[Fabio_Kung]

Existe m buzz desde o nício de novmembro na litsa de jvm-languages sobre o JVM Dynamic Languages Metaobject Protocol

Legal, valeu! Vou dar uma olhada. Pior que eu tô na lista e tá com 23424 não lidos…

mas acho que o Hibernate no seu estado atual não se adaptaria ao fato de java.lang.Object não ser o OTO (one true object) de uma linguagem dinâmica.

Aí é um pouco mais fácil. Acho que rolaria se você decorar a sua SessionFactory com uma que faz os objetos dinâmicos se comportarem como o Hibernate espera.

Já pensei bastante sobre isso também. Dá para fazer, mas primeiro precisa sair o tal do dynalang. Faz tempo que tô querendo dar uma mão pra eles com isso, mas tá faltando tempo. Agora no fim do ano quem sabe sai alguma coisa…

[cv1]

Todos os exemplos da 37Signals aos que você citou, possuem poucos usuários e baixa complexidade técnica.

Qual a sua metrica pra complexidade tecnica, e como vc sabe que esses projetos tem complexidade tecnica baixa?

Aliás, não sei o que tem por trás, mas pelo frontend, não vi nada de mais no Oracle Mix.

Ah, voce nao sabe. Hmm…

Já o Mingle exige 1G de memória como pré-rec, pra rodar uma aplicação relativamente simples.

Relativo ao que?

Voce ja usou todas as features do Mingle e disse “porra, esse treco eh relativamente simples! Eu vou fazer um pra mim mesmo, e chamar de MentaTracker! So que o meu vai ocupar 5kb de memoria!” Se sim, favor demonstrar.

[Kenobi]

Qual a sua metrica pra complexidade tecnica, e como vc sabe que esses projetos tem complexidade tecnica baixa?

Aliás, não sei o que tem por trás, mas pelo frontend, não vi nada de mais no Oracle Mix.

Ah, voce nao sabe. Hmm…

Realmente e pelo frontend, realmente não parece muito complexo. Já fiz parte de alguns bem complexos do ponto de vista regras de negócio, como Blue Martini. Não vi , mas você poderia fazer uma pequena explanação, já que fez a proposta.

Ta aí CV , o que o OracleMix tem de diferente de projetos como Twitter, Pownce e por aí vai ? Integração com CRM Oracle para marketing one-to-one, análise de content management e repositório para tal ? Sindicalização desses de acordo com perfil ?Estratégias de advertising para cross-seller nos banners ? Eu não sei o que tem por trás, mas aparentemente pareceu muito simples…exigindo pouco processamento , quase CRUDS e pesquisa indexada.

[quote]

Já o Mingle exige 1G de memória como pré-rec, pra rodar uma aplicação relativamente simples.

Relativo ao que?

Voce já usou todas as features do Mingle e disse “porra, esse treco eh relativamente simples! Eu vou fazer um pra mim mesmo, e chamar de MentaTracker! So que o meu vai ocupar 5kb de memoria!” Se sim, favor demonstrar.[/quote][/quote]

Não preciso, já existe no meio java um exemplo tangível para comparação - Xplanner. Em termos de negócio, pode se prefir o Mingle, pois contempla outras metodologias, como Scrum, mas do ponto de vista técnico são equivalentes e o Xplanner é infinitamente mais leve.

E você acompanha meus posts sobre ferramentas para controle de projetos, eu sempre recomendo o Mingle, até porque tenho um Mac que aguenta com o pé nas costas. Já usei várias features estou tester desde o começo do projeto.

PS: Logo mais verá meu projeto halls no ar , relaxa

[Kenobi]

Eu não confundi em momento algum Domain Model com Mapper e sim fiz uma consideração sobre onde a regra de negócio está e como o pessoal usa normalmente.

[quote=pcalcado]
Eu nao falei que voce confundiu. Voce falou que Rails nao separa Camadas. Voce falou que em Rails as regras ficam no Controller. É mentira, simples assim.[/quote]

Pode ter sio até um equívoco ou um approach para contornar essa deficiência (minha ótica) e não mentira. Acho melhor começar a pensar melhor nos termos que usa, segunda vez que peço para tomar cuidado.

Qualquer profissional com um pouquinho mais de experiência e literatura, sabe que não são construídos com esses frameworks, que é de fato uma solução otimizada, até mesmo pelo fato do tempo que ele está no mercado.

Uma coisa é otimizações para site como o referenciado , ebay, que é uma plataforma. Só para esclarecer, participo do programa de Developers do ebay , conheço bem a arquitetura, até porquê estou tocando um projeto nessa área.

Entao qual o ponto em usar um portal desses na comparacao? Você falou em eBay como parâmetro, não eu.
O eBay não usar soluções de caixinha como falamos aqui (e ser irrelevante nesta discussao por consequencia) é fruto do vlume de acessos e não “ser uma platafomra”. Se fosse por sso Facebook e Flickr não seriam em PHP.

Sim, disse isso porque ele tem um número considerável de acessos e em muitos casos de negócio, precisa persistir sessão, failover de compras, exposição de serviços e manter esses nesse ambiente de cluster por exemplo.

Completamente diferente de um facebook que é stateless. Amazon, é até um exemplo melhor que ebay.

Agora, completamente diferente é para um OracleMix , simples e sem nada demais. Se vc precisar de customização para esse tipo de aplicação, mostra que sua plataforma não está madura e sim em fase de desenvolvimento.

[quote=pcalcado]
O cv não te respondeu isso? De qualquer modo como vou saber que Grails não va precisar de uma mudancinha para aguentar minha aplicação? Cadê os cases"[/quote]

Espero poder publicar em breve Adianto que fiz uns pequenos testes com ferramentas como Mercury Load Runner e JMeeter. Se valer , publico para comparação.

Mais de uma vez trabalhei em projetos (Java) em que tivemos que contatar o fornecedor da aplicação (o figura líder do projeto OpenSource) porque ele não atendia nossa demanda. É o tipo de coisa que acontece frequentemente quando você desenvolve mais que os sitezinhos de intranet que 99% das pessoas estão fazendo o tempo todo.

Acabou de dar minha argumentação. O OracleMix é um sitezinho simples e precisou de ajustes. Está entre contido no percentual de 99% e aí está o problema !

Antes ele fosse atípico, assim sua argumentação seria válida.

Kung, certíssimo. Rails e Grails são equivalentes, o que mata é o “vou usar Grails poque é Java”.

Não é esse motivo e sim porque tem uma “Melhor Integração”, porque faz uso de projetos consistentes como os já citados - Spring, Hibernate, Lucene, Compass, Acegi e por aí vai e se vai usar JRuby, prefiro usar a JVM direto, menos overhead, não transformo tipos de objeto Java para JRuby por exemplo.

Para mim faz sentido Rails se vou usar uma arquitetura LAMP sem Java no meio. Aí concordo em utilizar o framework.

[pcalcado]

Pode ter sio até um equívoco ou um approach para contornar essa deficiência (minha ótica) e não mentira. Acho melhor começar a pensar melhor nos termos que usa, segunda vez que peço para tomar cuidado.

Aham.

Sim, disse isso porque ele tem um número considerável de acessos e em muitos casos de negócio, precisa persistir sessão, failover de compras, exposição de serviços e manter esses nesse ambiente de cluster por exemplo.

Tirando cluster (que não e usado por arqutieturas web escaláveis de verdade) qual o problema do Rails com as outras técnicas?

Completamente diferente de um facebook que é stateless. Amazon, é até um exemplo melhor que ebay.

Seu problema é mantêr o estado de sessão em ambientes qual alto tráfego? Qual o problema do Rails em fazer isso? Aliás você nunca programou pra Facebook né? Dê uma olhada em como ele faz proxing de aplicações e chame isso de simples novamente, por favor.

Espero poder publicar em breve Adianto que fiz uns pequenos testes com ferramentas como Mercury Load Runner e JMeeter. Se valer , publico para comparação.

Estamos esperando ansiosamente. Claro que estamos esperando o novo eBay e funcionalidades (front e back office, número de acessos além da querida “plataforma”), do contrário sua argumentação inicial sobre “complexidade de sites” é simplesmente fora da realidade não só da maioria das pessoas aqui bem como da sua (que surpresa seria…não?)

Mais de uma vez trabalhei em projetos (Java) em que tivemos que contatar o fornecedor da aplicação (o figura líder do projeto OpenSource) porque ele não atendia nossa demanda. É o tipo de coisa que acontece frequentemente quando você desenvolve mais que os sitezinhos de intranet que 99% das pessoas estão fazendo o tempo todo.

Acabou de dar minha argumentação. O OracleMix é um sitezinho simples e precisou de ajustes. Está entre contido no percentual de 99% e aí está o problema !

Antes ele fosse atípico, assim sua argumentação seria válida.

Você acabou de admitir que não sabe nada sobre o Oracle Mix pro CV mas continua afirmando que é uma aplicação simples? Quem disse que o mix é simples? Com base em quê? Com que sistemas ele se conecta? Quais os requisitos de performance?

Eu não costumo falar do que não conheço então vamos dar uma olhada no Mingle, que já conheço alguma coisa tanto como observador interno quanto externo. Nem chegando nas funcionalidades (que não são simples) você pode me esclarecer se acredita que uma aplicação vendida como produto, que pode ser instalado em qualquer ambiente, que pode ser vendida como produto ou serviço, que é personalizável ao extremo, que posui uma interface rica baseada em quilos de ajax (seja isso bom ou ruim, eu tenho minhas dúvidas), que possui um verificação de serial number, que possui código ofuscado e etc. é simples?

No mais, nem Mingel nem OracleMix são aplicações de referência de JRuby on Rails.

Se você gosta mais de abacaxi, ótimo. Só não venha falar sobre frutas que não conhece.

[Kenobi]

Espero poder publicar em breve Adianto que fiz uns pequenos testes com ferramentas como Mercury Load Runner e JMeeter. Se valer , publico para comparação.

Estamos esperando ansiosamente. Claro que estamos esperando o novo eBay e funcionalidades (front e back office, número de acessos além da querida “plataforma”), do contrário sua argumentação inicial sobre “complexidade de sites” é simplesmente fora da realidade não só da maioria das pessoas aqui bem como da sua (que surpresa seria…não?)

Will see meu caro padawan… mas adianto, que penso muito mais em regras como mencionei. Sindicalização, One-to-One Marketing utilzando redes neurais, cross-selling, sistemas de tagging utilizando Thesaurus e por aí vai … Estou desenvolvendo há um certo tempo e possui sim mais complexidade do que vc pode imaginar.

Agora se vai ser ou não um sucesso, é outro ponto. Estou pensando em realizar algo que tenho em mente e isso pra mim já valeu… sonho .

Você acabou de admitir que não sabe nada sobre o Oracle Mix pro CV mas continua afirmando que é uma aplicação simples? Quem disse que o mix é simples? Com base em quê? Com que sistemas ele se conecta? Quais os requisitos de performance?

Não, eu fiz um questionamento ao CV sobre o que tem por debaixo da aplicação, para saber se é ou não simples. Disse que “aparentemente”, me parece uma aplicação simples. Completamente diferente.

Coloquei alguns pontos sobre o que eu acho particularmente complexo e ocuparia um certo processamento entre os requests, o que poderia onerar a performance diretamente.

Eu não costumo falar do que não conheço então vamos dar uma olhada no Mingle, que já conheço alguma coisa tanto como observador interno quanto externo. Nem chegando nas funcionalidades (que não são simples) você pode me esclarecer se acredita que uma aplicação vendida como produto, que pode ser instalado em qualquer ambiente, que pode ser vendida como produto ou serviço, que é personalizável ao extremo, que posui uma interface rica baseada em quilos de ajax (seja isso bom ou ruim, eu tenho minhas dúvidas), que possui um verificação de serial number, que possui código ofuscado e etc. é simples?

Ainda não comparou com o Xplanner …Até onde conheço, existem ofuscadores para o ambiente Java que conseguem até mesmo incrementar a performance, otimizando. Aqui não sou especialista, talvez o Louds possa nos dar um help sobre esse processo, mas não seria um argumento para necessitar de tanta máquina, que foi o mencionado sobre o Mingle.

Verificação de Serial Number ? Depende de como vai implementar…Já vi diversos projetos utilizando as mais variadas técnicas e não justificaria esse incremento de requistos de hardware.

No mais, nem Mingel nem OracleMix são aplicações de referência de JRuby on Rails.

O que seria ? BaseCamp ? Existe uma certa onda no OracleMix para tornar o projeto OpenSource. Se isso ocorrer, vamos poder discutir isso de forma coerente, analisando os fontes, vou adorar

Se você gosta mais de abacaxi, ótimo. Só não venha falar sobre frutas que não conhece.

Por isso mesmo, pedi ao cv uma explanação sobre o que tem por debaixo da aplicação, para não ser injusto !

[pcalcado]

O que, seu projeto não segue os critérios baseados no eBay que você mesmo mencionou como miniamente razoáveis? Ah, então essa tecnologia é tosca, não funciona. Melhor ir para EJB 2.1 que é utilizado or todos os grandes bancos e grandes consultorias, e nós sabemos que sso é sinal de qualidade não? Por favor…

Ainda não comparou com o Xplanner …Até onde conheço, existem ofuscadores para o ambiente Java que conseguem até mesmo incrementar a performance, otimizando. Aqui não sou especialista, talvez o Louds possa nos dar um help sobre esse processo, mas não seria um argumento para necessitar de tanta máquina, que foi o mencionado sobre o Mingle.

Por que diabos em compararia com xplanner? Além de não estar aqui para vender produto, a última versão do xplanner que usei foi o que? 2003? Não falo do que não conheço, já disse. E mais uma vez você já deixa claro que “não é especialista” (i.e. vai dar um chute) nos poucos requisitos não funcionais do Mingle que citei e ainda assim fala do que não cnhece. Tsc tsc.

O que seria ? BaseCamp ? Existe uma certa onda no OracleMix para tornar o projeto OpenSource. Se isso ocorrer, vamos poder discutir isso de forma coerente, analisando os fontes, vou adorar

Ok, eu paro por aqui. Basecamp é Ruby on Rails, não jRuby on Rails. Existe uma grande diferença entre os dois e enquanto você não conseguir entender isso a única coisa que vai conseguir escrever são seus suitspeak (mais Você S/A que HBR/FastCompany, aliás), especulações sem fundamento e as hipérboles habituais. É querer discutir um tópico avançado com quem não entende(, não quer entender e tem raiva de quem entende) o básico.

Boa sorte no seu projeto.

[Kenobi]

[quote=pcalcado]O que, seu projeto não segue os critérios baseados no eBay que você mesmo mencionou como miniamente razoáveis? Ah, então essa tecnologia é tosca, não funciona. Melhor ir para EJB 2.1 que é utilizado or todos os grandes bancos e grandes consultorias, e nós sabemos que sso é sinal de qualidade não? Por favor…

Ainda não comparou com o Xplanner …Até onde conheço, existem ofuscadores para o ambiente Java que conseguem até mesmo incrementar a performance, otimizando. Aqui não sou especialista, talvez o Louds possa nos dar um help sobre esse processo, mas não seria um argumento para necessitar de tanta máquina, que foi o mencionado sobre o Mingle.

Por que diabos em compararia com xplanner? Além de não estar aqui para vender produto, a última versão do xplanner que usei foi o que? 2003? Não falo do que não conheço, já disse. E mais uma vez você já deixa claro que “não é especialista” (i.e. vai dar um chute) nos poucos requisitos não funcionais do Mingle que citei e ainda assim fala do que não cnhece. Tsc tsc.

O que seria ? BaseCamp ? Existe uma certa onda no OracleMix para tornar o projeto OpenSource. Se isso ocorrer, vamos poder discutir isso de forma coerente, analisando os fontes, vou adorar

Ok, eu paro por aqui. Basecamp é Ruby on Rails, não jRuby on Rails. Existe uma grande diferença entre os dois e enquanto você não conseguir entender isso a única coisa que vai conseguir escrever são seus suitspeak (mais Você S/A que HBR/FastCompany, aliás), especulações sem fundamento e as hipérboles habituais. É querer discutir um tópico avançado com quem não entende(, não quer entender e tem raiva de quem entende) o básico.

Boa sorte no seu projeto.[/quote]

Fim … vc entende pra caramba, estou maravilhado com suas respostas, aliás todas de uma profundidade … tsc ! Parei por aqui, legal vai ser se o OracleMix virar OpenSource. Aí, meu caro, faço questão de reabrir o tópico, com algo tangível em mãos.

Com relação ao meu projeto, will see … embora grande parte dos projetos atuais não se baseiam em arquiteturas ultra-sofisticadas , vide Django utilizando à torto e direito, além de me preocupar com os paradigmas de negócio também quero algo escalável e confiável, pelo menos para segurar o crescimento mínimo.

Se ele crescer, contrato vcs fodões da TW para refactoring

[cv1]

Se ele crescer, contrato vcs fodões da TW para refactoring

Estou prendendo a respiracao ate la.

[louds]

Com relação ao meu projeto, will see … embora grande parte dos projetos atuais não se baseiam em arquiteturas ultra-sofisticadas , vide Django utilizando à torto e direito, além de me preocupar com os paradigmas de negócio também quero algo escalável e confiável, pelo menos para segurar o crescimento mínimo.

Arquiteturas sofisticadas são apenas isso, elas não conferem nenhuma vantagem quanto a escalabilidade, por exemplo. A lingua inglesa, curiosamente, pode explicar sua predileção por elas, no ingles podemos usar fancy ou poch para qualificar aquilo que vem falando. Desculpa te avisar, mas normalmente aquilo que escala melhor são as arquiteturas simples.

Já desenvolvi sistemas que tinham um volume razoavel, sustentam mais de 100 requisições por segundo durante o dia todo e a arquitetura não nem nada JEE’sh nela, pelo contrario, usamos o mais simples possivel - e funciona bem. Pela minha experiência o sistema poderia ter sido escrito em Java, perl, ruby, groovy ou mesmo em bash sem comprometer o resultado.

Escalabilidade é um treco complicado demais para simplesmente assumir que ela existe por padrão e que se isso for possivel, é desejavel. Qualquer plataforma hoje possui uma escalabilidade vertical razoavel, suficiente para a grande maioria das aplicações enterprise. Falo isso por experiência própria, metade dos sistes do UOL poderiam ser escritos com RoR, rodar em uma máquina só e estariam muito bem.

“Otimization is the root of all Evil”, por um terno no capeta não ajuda a esconder os chifes, o rabo e, principalmente, o cheiro de enxofre.

[saoj]

Já desenvolvi sistemas que tinham um volume razoavel, sustentão mais de 100 requisições por segundo durante o dia todo e a arquitetura não nem nada JEE’sh nela, pelo contrario, usamos o mais simples possivel - e funciona bem. Pela minha experiência o sistema poderia ter sido escrito em Java, perl, ruby, groovy ou mesmo em bash sem comprometer o resultado.

Editado: Vc está provavelmente falando de um sistema web, logo meu post foi viagem, me desculpem…

[Fabio_Kung]

“early optimization is the root of all Evil”

só um adendo, antes que alguém caia em cima disso

[xandroalmeida]

[quote=cv]

[quote=Kenobi]
A questão não é java pra toda obra, e sim Groovy e Grails , utilizando estrutura pré-existente. Você vai continuar com os preceitos do David, mas se baseando num legado sólido.[/quote]

Por “legado solido” vc diz dezenas de milhares de sistemas usando Struts 1.x e EJB 2? Hmm… solido e marrom, ne?[/quote]

CV, você esta sendo radical em sua defesa do Ruby. Não só radical, mas esta despresando o Java para fortalecer seus argumentos em favor do RoR.

Java não é só Struts 1.x e EJB 2, e mesmo assim existem muito bons sistemas em produção usando estas duas tecnologias.

[saoj]

Que EJB (*) e Struts é muito ruim ninguém discute. Quem usou não foi por falta de aviso aqui no GUJ, visto que há milhares de anos muita gente fala que isso não presta. Até foquinhas foram sacrificadas em prol dessa causa.

(*) Ok, EJB3 é aceitável, mas também depois de refazer a coisa do zero 3 vezes já estava na hora de acertar a mão.

Quanto ao RoR eu concordo que a coisa é muito legal e bem feita, mas eu acredito que ainda ficarei com o Java durante um bom tempo. Os meus argumentos são bem parecidos ao desse cara aqui:

http://beust.com/weblog/archives/000382.html

You won’t be reading any Ruby on Rails bashing in this blog post for a simple reason: I love Ruby and I love Ruby on Rails.

Rails is a fantastic framework built on a wonderful language that appealed to me the very first day I started to study it. I think David did a fantastic job in two areas:

* Coming up with innovative ideas that take Web programming to a new level.
* Leveraging the strength of Ruby to achieve his goal.

To tell the truth, the Pick Axe and Agile Web Development with Rails books are the best two technical books I have read these past years. I read quite a few technical books, but none has caught my interest and made me look forward to resuming my reading more than these two books. And to top it all, features such as Headless Applications, as illustrated in this blog post by Mike Clark, clearly show how powerful Rails is.

There is no denying that Ruby on Rails is turning the Web programming world on its head.

Now that this introduction is out of the way, I’d like to take some time to explain why, in spite of all its qualities, Ruby on Rails will never become mainstream.

As you probably guessed, my conviction doesn’t come from technical grounds.

The truth is that there are a lot of forces involved in making a Web framework successful, but before I dive into those, allow me to tell a little side story.

Have you ever come across Smalltalk or Lisp programmers? You know, these people who, no matter what you tell them, will always respond that “Smalltalk did that twenty years ago” or that “Nothing has been invented since Lisp”. They listen to you patiently with an amused light in their eyes and when you’re done talking, they will just shrug away your points and kindly recommend that you read up on a thirty-year old technology that was the last thing they ever learned and that has been dictating every single technical judgment they have offered since then.

I believe that in ten years from now, people will look back at Ruby on Rails and will have the same reaction. I’m not sure what Web frameworks we will have by then, but I’m quite convinced that a lot of the current Ruby on Rails fanatics will have the same kind of attitude: “That’s nice, but Ruby on Rails already did this ten years ago, and better”.

Interestingly, they might even be right. But by then, it won’t matter because despite its technical excellence, Ruby on Rails will still be a niche technology that only experts know about.

So why do I think that Ruby on Rails will never cross the chasm?

* First of all, Ruby.

  Again, and at the risk of repeating myself:  I love Ruby.  I truly do.  It's one of the few languages that I have studied these past years that made me go "Yeah!" whenever I read about a feature I didn't know of yet.  I find its syntax and concepts extremely elegant and powerful at the same time.  I don't like everything about it, of course, but Ruby is by far the number two language in my toolbox behind Java, with number three far, far behind.  But it's a complex language that contains a lot of advanced idioms which will be very hard for PHP and Visual Basic programmers to absorb.

  Admittedly, PHP and Visual Basic are cheap targets (we're talking about languages that don't even have name spaces!), but like it or not, they are the Web standard.  Anyone who wants to succeed in the Web arena must have a compelling story to tell to these programmers, something that will convince them to switch to Rails on technical grounds but that will also be an easy sell to their management.  Rails can't succeed without these two conditions, and I am predicting that Ruby -- and Ruby on Rails -- will always remain a tough sell to any organization that contains more than ten people.
   
* Ruby on Rails itself.

  Ruby on Rails is just too advanced.  I'm serious.  It has an incredible amount of slick features involving a lot of magic (both Ruby-related and invented by David himself).  For talented developers, these features are a dream come true...  autowiring of the MVC, scaffolding, defaults over configuration, unit tests (even integration tests now, nice!), you name it.  David hit every single pain point that Web developers (regular developers even) have been facing these past years.  Ruby on Rails in itself is a great example of how to nicely package what we have learned about software development these past five years.

  But it's still a very wide gap for corporate developers to cross.  Sometimes, too much magic is too much magic, and it can definitely be the case that the flow of code is too direct or too clever to be understandable by regular developers.  Developers were able to do the jump from imperative to object-oriented programming, but it was a hard fight.  I don't believe the Web world will ever be ready to embrace the Rails cleverness.
   
* Still no credible IDE.

  All fanatics of dynamic languages are quick to point that they don't need an IDE to use Ruby, Python, Groovy or other.  And they will quickly add that if you need one, you're probably not being rubyic or pythonic enough and that you should probably switch back to your old language and leave the grown ups alone.

  This is nonsense.  Ignore these people, they don't understand how the real world works and how developers think, and they are one of the reasons why so many great technologies never make it to the mainstream.  Don't ever be ashamed to need an IDE or to ask for one.  Of course, there are bad ways to use an IDE (e.g. you want code generated for you) but if you are interested in Ruby on Rails, chances are that you are a decent developer and you know how to leverage an IDE to make you more productive than when using emacs.  Code completion or navigation, debugging, refactoring, project management, source control integration, etc...  there are too many features to list that make you more productive if you use a tool that enables them.
  This is 2006, not 1996.  The programs we are writing and the problems we are solving every day are orders of magnitude harder than back then, and our tools need to keep up with that need.  Emacs is a fine text editor, but it's no longer adequate for modern development.
   
* Fanaticism.

  Regular readers of my blog know how strongly I feel on this topic.  There are exceptions, of course, but the attitude of Ruby on Rails users toward Ruby skeptics or critics has been less than kind.  This is a crowd convinced that it has found the ultimate answer to everything, and they are not afraid to let you know.  I only have a simple advice for these people:  you might be right, but just be humble.  It never hurts.
   
* Crowd of a single mind.

  If you want to write a Web application in Ruby, there is only one solution.  Only one.  Ruby on Rails.

  Ruby on Rails has pretty much nuked the field of Web development in Ruby, and I wonder if it's such a good thing.  For all the flak that Java receives because you can count at least a dozen different Web frameworks, there is something to be said about plurality and the constant chase for something better and different.  Each framework that comes out builds on the strengths of its ancestors while discarding the errors (and committing a few mistakes of its own, of course). The field advances a little bit every time while bowing down to the timeless laws of natural selection.

  I am worried that Ruby on Rails will do to the Ruby world what JUnit did to Java:  a great tool when it came out but which condemned its community to an ice age where no innovation or competition appeared for years.  Whatever the fate of Ruby, I hope its fans will keep an open mind and will constantly challenge the Rails way, for the simple reason that it's always healthy to question what's in place, no matter how good it looks.
   
* Enterprise capabilities and scalability unclear.

  This is an argument that the Rails crowd doesn't take well, and they are quick to point out BaseCamp and other products.  The problem is that by now, there should be other obvious success Rails stories, and not just ones developed by the Rails Society.  Of course, it's a chicken and egg problem:  a lot of companies evaluate Ruby on Rails but will only take the jump if they can find evidence that other companies have done that before them.  And for now, the evidence is scarce at best.

  Granted, Java took a while to rise to the enterprise challenge as well, and it did so despite tremendous initial handicaps such as poor performances and questionable specifications.  I contend that until Rails goes through its own EJB2 debacle, it won't be seen as enterprise ready.
   
* Lack of support from Internet Providers.

  What's the big deal with this, you ask?  After all, Java is hardly supported by Internet Providers as well.  The big difference is that Java on the server is targeted at the enterprise.  Anyone who wants to run a Java EE application will most likely host their own servers.

  Ruby on Rails is targeting a different population:  the "Web sites in-between", these sites that are not massively scalable but still have more than a few visits per day.  A lot of these people use external hosting, and they won't go very far if Rails is not offered natively and pre-installed for them.  PHP is a no-brainer for them, because it's installed virtually on 99% of Internet Providers.

  Of course, a little bit of .htaccess magic will allow you to run your own Rails application, whether your provider supports it or not, and assuming that they give you that amount of privileges and that you don't need to scale too high, but until Ruby on Rails achieves at least half of the PHP penetration, it will remain inaccessible to most of the population it needs to become mainstream.

Note that I didn’t say anything about poor error reporting, weak internationalization support or Active Record, which are usually the areas where Ruby on Rails is the most criticized. I’m not worried about these because they are simply a symptom of Ruby on Rails’ youth. They will be fixed in time, and I don’t think they will play a big role in Ruby in Rails’ acceptance (or lack thereof).

So there you have it. My prediction on Ruby on Rails in one, lengthy post. I apologize for the size of this article, I usually try to keep my blog entries short and to the point. I hope at least that I achieved the latter.

I’ll conclude on a positive note: I hope I’m wrong. I really, sincerely do. For my next work, I want to have a choice between Java and Ruby, but right now, when in doubt, even I usually end up returning to Java for my personal projects for the reasons listed above.

And as you know, I love it when frameworks and languages compete for my business. But right now, I see no competition.

[louds]

[quote=louds]“early optimization is the root of all Evil”

só um adendo, antes que alguém caia em cima disso[/quote]

Na verdade é “premature otimization is the root of all Evil”.
Doubloe fault.

[rubinelli]

Aquele é um post antigo, e se você ler criticamente, vai ver que os problemas estão sendo endereçados pelas comunidades Ruby/JRuby/Rails ou nunca foram problemas pra começo de conversa:

Ruby é muito difícil: Balela pura. Já reparou como todo mundo entende Ruby, mas estão sempre dizendo “mas os outros…” Cadê os outros?

Ruby on Rails é muito avançado: Bobagem de novo. Rails é uma DSL construída em cima de Ruby. Se você não se importar em saber como “a mágica” funciona, do mesmo jeito que a maioria dos programadores não se preocupa com o lifecycle de componentes num JSF ou Webforms, ou como é feita a injeção de bytecode em Spring, você pode se virar muito bem em Rails.

Faltam IDEs: Faltavam. Free, para Windows, você tem Netbeans 6, Aptana, e Komodo. Precisa mais?

Fanatismo e mentalidade de rebanho: Frameworks como Merb, Camping e Sinatra mostram que nem todo mundo que faz Ruby bebe do mesmo Kool-Aid. Quem não tolera ActiveRecord pode ajudar no projeto DataMapper.

O fantasma da escalabilidade: Estamos pra ver um grande projeto falhar por falhas na escalabilidade do Rails, até porque ele encoraja um modelo “share nothing” que naturalmente escala bem. O mesmo não pode ser dito de outras plataformas. :roll: O que não quer dizer que não estão trabalhando em performance. O que fizeram com JRuby foi simplesmente fantástico, e a versão 1.9 do Ruby, planejada para começo do ano que vem, está com ganhos reais de performance por volta dos 200%.

Hosting Rails: Onde tem consumidor, aparece solução, especialmente num mercado disputado como webhosting. As empresas ainda estão experimentando pra encontrar a melhor forma de disponibilizar Rails, mas se você tem um orçamento de 20 dólares por mês já da pra colocar seu site no ar num VPS de 256MB. Tenta colocar o Glassfish em 256MB!

Enfim, 2007 foi o ano em que o hype abaixou e resultados concretos começaram a aparecer. Eu não sou tão otimista quanto o “Shoes”, mas realmente espero ver Java perder os primeiros projetos “tradicionais” para Rails em 2008.

[saoj]

A questão não é se é fácil ou difícil, até porque isso é relativo. Talvez se for comparado a C++ / Objective C seja fácil mas se for comparado a Java seja difícil. Java é uma linguagem OO BEM fácil, e isso é importante para a produtividade dos meros mortais que estão no mercado de trabalho. Se a oferta de profissionais altamente capazes, que conseguem entender e dominar Ruby de uma hora pra outra fosse grande, tudo bem, mas é sabido que contratar bons profissionais no Brasil e no mundo na área de TI é complicadíssimo para Java, o que se dirá para Ruby.

Ruby On Rails é muito legal mas está anos-luz do Java em termos de penetração nas empresas, profissionais capacitados, projetos open-source, livros, artigos, comunidade, etc. Simplesmente não dá para comparar a posição do Java hoje com a posição do Ruby, mas as pessoas afirmam com naturalidade que RoR agora é a referencia e o resto é coisa do passado. Se esse passado for Struts, JSF, EJB então tudo bem.

A questão é muito simples: Será que os milhares de desenvolvedores Java vão migrar lentamente para o Ruby só para programar no maravilhoso Ruby on Rails ou será que os frameworks Java vão competir com o Ruby on Rails na suposta produtividade e eficiencia?

O meu sentimento é que grande parte do sucesso do Ruby on Rails se deve a coisas como Struts, JSF, EJB, etc.

Perguntei antes e volto a perguntar: O que Ruby On Rails oferece que um framework web em Java não pode oferecer ou implementar? Acho difícil haver alguma coisa tão determinante que não possa ser implementada em Java.

O que o cara do artigo fala com perfeição é que Ruby é uma linguagem fabulosa e RoR é um framework web bem legal, mas por causa disso achar que a linguagem e o framework vão dominar o mundo é muita inocência. Assim como a Apple não dominou o mundo (talvez agora depois de 25 anos consiga), asssim como Smalltalk não dominou o mundo, muita água ainda vai ter que rolar para que o Ruby on Rails ameace um pouquinho só a supremacia do Java no server-side.

[cv1]

Java não é só Struts 1.x e EJB 2, e mesmo assim existem muito bons sistemas em produção usando estas duas tecnologias.

Concordo que Java nao eh soh Struts 1.x e EJB 2.x, e concordo que mesmo assim existem sistemas muito bons escritos nessas duas tecnologias. Mas, assim como existem sistemas muito bons escritos em Perl, eu quero passar o mais longe possivel dessa linguagem justamente pela maioria esmagadora de sistemas escritos nessa linguagem que nao ha perfume suficiente no mundo pra fazer ficar cheirosinho.

Eu tenho 25 anos agora, e eu me preocupo em aprender coisas novas e me livrar das ultrapassadas o quanto antes pq eu nao quero ser um programador de 60 anos que ganha dinheiro limpando as cagadas feitas ha meio seculo atras, como vemos hoje com o pessoal de COBOL e outras 4GL. Pode apostar que Struts e EJB 1.x e 2.x vao ser uma dor de cabeca tao grande quanto.

[cv1]

Simplesmente não dá para comparar a posição do Java hoje com a posição do Ruby, mas as pessoas afirmam com naturalidade que RoR agora é a referencia e o resto é coisa do passado.

Voce nao deve comparar a posicao do Rails hoje com a posicao do J2EE hoje. Compare a posicao do J2EE em 2001, 3 anos depois de comecar pra valer, com o Rails hoje, 3 anos depois de comecar.

Sempre que vc for olhar pra esse tipo de coisa, preste atencao na curva de adocao sobre o tempo decorrido. Recomendo: http://en.wikipedia.org/wiki/Crossing_the_Chasm

O que Ruby On Rails oferece que um framework web em Java não pode oferecer ou implementar?

Ja te respondi isso nessa mesma thread: ActiveRecord e named routes. Nao da pra fazer em Java pq Java nao tem mix-ins, nao tem method_missing e nao tem classes abertas.

Assim como a Apple não dominou o mundo (talvez agora depois de 25 anos consiga), asssim como Smalltalk não dominou o mundo, muita água ainda vai ter que rolar para que o Ruby on Rails ameace um pouquinho só a supremacia do Java no server-side.

E o que te leva a acreditar que Ruby e Rails nunca vao ter o mesmo poder de dominar o mundo que Java e J2EE tiveram? Fazer analogias a Apple e Smalltalk eh facil (ja que os dois sempre foram underdogs celebrados), mas pq nao olhar o que foi extremamente popular, tambem?

[pcalcado]

Ja te respondi isso nessa mesma thread: ActiveRecord e named routes. Nao da pra fazer em Java pq Java nao tem mix-ins, nao tem method_missing e nao tem classes abertas.

Rake, RSpec, gems… Java tem suas vantagems Ruby tem as suas. É só achar o lugar certo de cada (e das outras) e temos um bom lugar para investir.
E o jRuby está aí para ajudar