100% Rails ou JRuby?

JavaTeenager Membro desde: 08/01/2008 10:55:41 Mensagens: 172 Offline

Cara cê desenterrou o Prevayler das profundesas, nossa!

RaulCarlin wrote:Alguém aí por favor me corrija se eu estiver errado...

Alguém lembra do Prevayler?

Pois bem, era uma coisa muito UOW, muito NOSSA, portais sendo feitos com ele, o mundo seria à partir daquele dia PRÉ PREVAYLER e PÓS PREVAYLER, tutoriais, discussões...até que... nunca mais ouvi falar dele... ninguém mais tem dúvida... ué... (se alguém tiver algo a falar sobre tal por favor)

O Prevayler é mto bom, era um projeto de futuro até, mas o criador vira e fala q é pra jogar fora o Banco de dados pra usar tal ferramenta, coisas radicais assim nao viram, pq só agora um monte de empresa ta migrando os sistemas pra Java 1.5 sendo que já tem o 1.6, pq ninguem é radical, pq se der problema ninguem quer se responsabilizar...

Eduardo Bregaida wrote:
O Prevayler é mto bom, era um projeto de futuro até...

É exatamente por isso que não aposto no Ruby AGORA, mas espero que dê certo e que todos que estão apostando nele AGORA tenham sucesso...

É a mesma história do JavaScript, quem diria, que depois de tantos anos, bibliotecas tão poderosas como jQuery e ExtJS pudessem ressucitar algo tão pré-histórico e com tão pouca ambição? Esse é o tchan daquilo que foi falado na primeira palestra, não ter receio de misturar tecnologias, temos tudo pra resolver tudo de n maneiras... basta não ser preconceituoso...

Depois que eu disse pra mim mesmo há anos atrás que seria MCAD de qualquer jeito e logo depois tava cagando e andando pro C# por achar que Java era A minha, nunca mais cuspo pro alto...

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

JavaTeenager Membro desde: 08/01/2008 10:55:41 Mensagens: 172 Offline

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?

LuksS wrote: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?

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.

This message was edited 1 time. Last update was at 19/05/2008 15:32:29

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.

This message was edited 1 time. Last update was at 19/05/2008 15:33:05

LuksS wrote: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?

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?

JavaTeenager Membro desde: 08/01/2008 10:55:41 Mensagens: 172 Offline

ok

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

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!

Luiz Aguiar wrote:Fabio (e demais), hoje se tu fosses criar uma aplicação, com uma média de 1.000 acessos concorrentes, vamos usar esse valor para arredondar apenas, e tu tens a opção de moldar toda a arquitetura/infra para disponibilizar essa aplicação.

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.

Luiz Aguiar wrote:Levando-se em conta os pontos que citou em sua palestra, tanto os fatores de multi-thread, caches, libs javas disponíveis para uso em ambiente jruby, compartilhamento ou não de dados, essas coisas, tu farias essa aplicação num ambiente 100% ruby ou colocaria um container java para rodar essa aplicação em JRuby?

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!

This message was edited 1 time. Last update was at 19/05/2008 18:40:03

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!

This message was edited 1 time. Last update was at 19/05/2008 18:50:37

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

Luiz Aguiar wrote: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.

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! <puxao-de-orelha>Que tal você contribuir lá hein?</puxao-de-orelha>. Manda MP/email!

Código fonte: http://github.com/fabiokung/jetty-rails/tree/master

Fabio Kung wrote:

Luiz Aguiar wrote: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.

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! <puxao-de-orelha>Que tal você contribuir lá hein?</puxao-de-orelha>. Manda MP/email!

Código fonte: http://github.com/fabiokung/jetty-rails/tree/master

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.

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