[quote=LuksS]Prevayler realmente seria uma boa se tivesse REALMENTE sido concluído de fato, até onde me lembro, não sei se questões como segurança e transações tinham sido implementadas, e se não, então não haveria a mínima possibilidade de utilizar num sistema de grande porte, que exige coisas além do supracitado.
E aproveitando o tema, alguém sabe dos rumos do Prevayler?[/quote]
Sem querer ser chato amigo, mas por favor crie um outro tópico com esse tema pois foge completamente do propósito desse post falar de prevlayer.
Desculpem a crítica, não é pessoal, mas não estamos fugindo da proposta da thread? Daqui a pouco o Luiz terá que refazer a pergunta…
EDIT> já tiveram o trabalho de falar a mesma coisa.
[quote=LuksS]Prevayler realmente seria uma boa se tivesse REALMENTE sido concluído de fato, até onde me lembro, não sei se questões como segurança e transações tinham sido implementadas, e se não, então não haveria a mínima possibilidade de utilizar num sistema de grande porte, que exige coisas além do supracitado.
E aproveitando o tema, alguém sabe dos rumos do Prevayler?[/quote]
Nao morreu por ter terminado e sim pq o criador falava q BD nao prestava q deveriam ser excluidos, pessoas mto revolucionarias nao dao mto certo dentro de grandes corporações, o criador do Prevayler hj ta num projeto de BD OO 
Agora vamos voltar ao: 100% Rails ou JRuby?
ok
[quote=Kenobi]Sempre que vejo a galera falar de frameworks Web,MVC me vêm à cabeça arquitetura desacoplada, orientada à Serviços. Poucos designers projetam sua aplicação para utilizar tal conceito, como em Rails - REST e hoje olhando o cenário das aplicações que são criadas nas empresas, essas questões como Modelo Canônico de dados, são muito superiores à qual linguagem implementar.
Não vejo ninguém falando de ESB Patterns de Integração … só um desabafo… [/quote]
Voltando ao Tópico, não a questão de Deploy é bastante preocupante. Existem uma série de recursos quando usamos um bom application server, desde configuração de regras de SLA, à segurança, pools, configurações de Threads e por aí vai.
JRuby é uma boa opção para desenvolvimento ágil. Do contrário, será necessária uma grande expertise em configurações de infra.
Ótima idéia de deixar a pergunta pública Luiz.
Gerou diversas discussões muito interessantes e levantou alguns pontos muito legais!
Acessos concorrentes é uma expressão muito perigosa Luiz. O que significa acesso concorrente? Em um segundo (req/s)? Em um minuto (req/min)? Em um dia (pageviews)?
Só para termos uma base, consideremos uma das aplicações Rails mais populares (e acessadas). O Twitter recebe cerca de 300 req/s, e isso já é monstruoso na internet. Pouquíssimos de nós vamos precisar lidar com aplicações deste porte.
No twitter, estão usando 120 processos de mongrel divididos em algumas máquinas para aguentar tudo isso. Cada processo mongrel toma de 20-60Mb e quando começa a crescer demais o uso de memória, os processos são reiniciados (já que o gerenciamento de memória da MRI não é lá essas coisas). Na internet tem bastante material de como o twitter vem sendo escalado.
Se eu tivesse a escolha, a quantidade de acessos não iria ser fator determinante para escolher entre MRI ou JRuby. Você conseguiria esse resultado com qualquer um dos dois, com vantagens e desvantagens para cada um dos lados.
Poder usar gems nativos e estar sempre usando todas as coisas mais novas é uma grande vantagem ao se optar pelo caminho MRI, como bem disse o Leonardo3001. Apesar que, pelo menos na minha experiência, não é tão comum você não achar alternativas puro-ruby ou feitas em Java.
Nesse seu caso Luiz, o fator que faria eu escolher entre um e outro seria precisar usar algum gem nativo ou jar. Eu tentaria durante o desenvolvimento não fixar nenhuma escolha, fazer com que a aplicação pudesse rodar tanto no MRI quanto no JRuby. Ao mesmo tempo que gerenciamento de memória fraco (que obriga o uso de watchdogs como o Monit e o God) junto com a falta de um JIT, são desvantagens fortes.
Vantagens fortes do JRuby você mesmo citou. Threads nativas, compartilhamento de coisas entre os runtimes (jndi, pool de conexões, caches, …), garbage collector, jit e principalmente a possibilidade de usar código java existente são vantagens. Tempo de startup, falta de suporte a gems nativos e ciclo de desenvolvimento complicado são desvantagens (os stack traces do jruby são ainda menos informativos que os da MRI tb).
Eu postergaria a decisão o máximo possível. Ótimo se se o deploy puder ser feito em qualquer um dos dois, aí você vai poder fazer mais testes da aplicação real e ter mais base para decidir. Pode até fazer como muitas pessoas estão fazendo: desenvolve com MRI e faz deploy no JRuby, já que os stacktraces da MRI são mais informativos e o tempo de startup é menor. Só fixaria em um dos caminhos se alguma hora não tivesse mais saída e eu precisasse mesmo usar um gem nativo ou código java.
Desculpa, mas como sempre não há uma única resposta para a sua pergunta. Como muitos já disseram, vai depender muito também da experiência da equipe ou da infra que você vai ter. Ainda bem que a resposta para ótimas perguntas como essa é sempre o “decepcionante” depende. Se não fosse assim, nós não seríamos mais necessários! 
Excelente Fábio! 
Bom, vamos deixar esse 1.000 de lado porque me expressei mal mesmo e acabou complicando rs
Minha visão era exatamente na necessidade de muitos processos e consumo alto de memória, acho que vc validou pontos chaves bacanas realmente, como já havia feito na palestra.
O que pensei tambem bate com seu comentário, não da pra prever o que será necessário no desenvolvimento e se não terá “componentes” nativos e terá que recorrer a jars e coisas do “mundo java”.
Quanto ao desenvolvimento, realmente o fato de perder o lado ágil do Rails parece um pouco estranho quando falamos em colocar a aplicação pra rodar com JRuby, essa opção de desenvolver com MRI e depois deployar no JRuby parece uma boa alternativa.
Valeu pela resposta Kung!
Falando nisso, eu estou exatamente com um caso desses
A aplicação é feita basicamente no MRI mas nós rodamos os specs nos dois, mas a implantação é “híbrida”, estamos testando tanto no MRI quanto em JRuby (usando Jetty, com um plugin que eu montei, vai ser publicado daqui a algum tempo), o Jetty tem sido mais confiável que a dobradinha Apache + mongrels e absurdamente mais fácil de configurar, aqui é só rake jetty:start e o troço tá rodando com 4 instâncias no ar sem nenhuma dor de cabeça pra controlar os processos separados. O maior problema do JRuby é o tempo de inicialização das coisas, rodar um spec em JRuby é lento que dói, levantar o servidor demora um bocadinho, então rodar no MRI é mais interessante nesses casos mais pontuais.
E um detalhe MUITO importante que todo mundo esquece, o MRI no Windows é risível, então se você vai fazer deployment de Rails no Windows, não tem nem o que considerar, é JRuby na cabeça
Mesmo se você decidir por usar JRuby no desenvolvimento, não esqueça que agora existe o http://jetty-rails.rubyforge.org, e não perdemos o feedback instantâneo! (= agilidade do rails)
Maurício, seu rake jetty:run parece muito o jetty-rails! Que tal você contribuir lá hein?. Manda MP/email!
Código fonte: http://github.com/fabiokung/jetty-rails/tree/master
Mesmo se você decidir por usar JRuby no desenvolvimento, não esqueça que agora existe o http://jetty-rails.rubyforge.org, e não perdemos o feedback instantâneo! (= agilidade do rails)
Maurício, seu rake jetty:run parece muito o jetty-rails! Que tal você contribuir lá hein?. Manda MP/email!
Código fonte: http://github.com/fabiokung/jetty-rails/tree/master
[/quote]
:lol:
Quando eu vi o jetty-rails já era tarde demais 
Mas a minha idéia é ir no caminho do servidor de produção mesmo, não o de desenvolvimento, tanto que eu uso o script de inicialização do Jetty pra subir o servidor (e um arquivo jetty.xml pra configurar tudo), o plugin na verdade são só uns tasks do Rake que sobem o servidor que vem empacotado no plugin, mas eu vou mexer no Jetty-Rails sim e contribuir com o que eu puder, o negócio é só achar um jeito simples de fazer start-stop-restart no servidor pra poder integrar ele melhor com o Capistrano, foi até por isso que eu resolvi usar o script de inicialização do próprio jetty, já que eles já tinham isso pronto.
certo! entendi! Complementa então…
Mas era uma boa funcionalidade a ser incluida no Warbler ou no próprio jetty-rails. Já andou falando com o Nick Sieger?
Vamos lá, primeiro parabéns ao Kung pela palestra. Tentei lhe achar após a mesma para bater um papo mas parece que todos tiveram a mesma idéia.
Segundo, em outubro do ano passado comecei a fuçar no Ruby on Rails para um projeto interno, rápido e sem frescura. Em uma semana tinha um site no ar com CRUD funcionando, mas estava meio perdido no Ruby e algumas coisas era muito out of path do universo Java.
Foi quando ouvi falar do Grails (Groovy on Rails), e posso dizer que minha vida tomou um outro caminho
O Grails é um rails em Java, que utiliza todo o código escrito pelo pessoal do projeto + Hibernate + Spring + Sitemesh. E o Groovy é muito mais “friendly” do que o Ruby, na minha modesta opinião.
Pra quem for entrar de cabeça nesse mundo recomendo dar uma olhada por aí. Grails é bem legal e é minha escolha.
grails é sim uma ótima opção!
Mas pessoalmente (como me disse o louds uma vez), prefiro mirar na zona de desconforto. Aprender uma linguagem totalmente diferente do que você está acostumado (out-of-path?) te faz abrir mais a cabeça e enfrentar novos paradigmas.
Faz você enxergar as coisas de um ponto de vista totalmente diferente, conhecer novas possibilidades e até te torna um melhor programador na plataforma antiga!
Fábio,
Em primeiro lugar, parabéns pela palestra, foi de um nível muito bom e esclarecedora. Gostei da parte que você “assumiu” os problemas do Ruby.
Agora fiquei com uma dúvida em relação ao GUJ3 ser 7 vezes mais rápido que a versão atual. Você disse que no GUJ3 você esta usando cache. Na implementação em Java com a qual o GUJ3 foi comparada tinha cache?
Na home não tem. Quem faz cache é o JForum, mas no guj3 o JForum continuará o mesmo, no mesmo lugar.
É o que o Lezinho já tinha dito. Ficou mais rápido não por que é Rails ou algum framework Java puro (no fundo o guj3 é Java tb, já que vira tudo bytecode), mas sim por causa do cache. Volta àquela mensagem de que mais importante do que a tecnologia que você usa, é saber aproveitá-la bem, conhecê-la bem.
[quote=Fabio Kung]
Mas pessoalmente (como me disse o louds uma vez), prefiro mirar na zona de desconforto. Aprender uma linguagem totalmente diferente do que você está acostumado (out-of-path?) te faz abrir mais a cabeça e enfrentar novos paradigmas.
Faz você enxergar as coisas de um ponto de vista totalmente diferente, conhecer novas possibilidades e até te torna um melhor programador na plataforma antiga![/quote]
Sim, concordo contigo. O fantástico do Groovy é isso: uma linguagem nova que potencializa o Java, traz novos conceitos e novas opções (como o conceito de clousures) e, o melhor de tudo, por detrás é Java…
Não é esse o grande lance do JRuby, uma nova linguagem, conceitualmente diferente, mas que trás todo o background do Java?
Exato! Essa é sim uma das grandes vantagens.
Eu só fiquei receoso de começar mais um flame groovy vs jruby, que na minha opinião, não leva a nada.
[quote=Fabio Kung]
Eu só fiquei receoso de começar mais um flame groovy vs jruby, que na minha opinião, não leva a nada.[/quote]
Hahahahaha, Flame War é legal. Não leva a nada, mas é legal.
Voltando ao tema, concordamos, isso é bom.
Ola Fabio ,
vc recomendaria algum livro em especial para iniciantes Ruby?