Ruby tem conceitos bem mais complexos do que os de Java.
[quote=Maurício Linhares]
O Seam é full stack? Desde quando? O Seam usa JPA ou Hibernate pra persistência, usa JSF pra view (eles vendem que dá pra colocar outras coisas, mas não é simples de se fazer). O Seam é um monte de glue-code pra tornar JSF e EJB factível em aplicações web comuns, uma tarefa tão titânica que deu num framework do tamanho do Seam.[/quote]
Na verdade o que o Seam fez foi tornar a necessidade de frameworks de terceiro praticamente nulas.
Eu to ligado que ele também vende poder utilizar outras coisas na web (com GWT em vez de JSF) mas não sei até onde vale a pena o esforço. Entre outra coisas, o “glue-code” do seam também cai como uma luva, você elimina uma porrada de camadas e sem contar que todo o “stub” que o seam-gen gera pra você acaba economizando um bom tempo em várias coisas
Apesar de muita gente criticar JSF, o Seam também não é um framework que “simplesmente usa JSF”. Ele tornou JSF algo muito melhor do que já era (tá, sou entusiasta de JSF então nem levem em consideração hahaha) como por exemplo a extensão do EL, a unificação de ManagedBean com Seam POJO Components (ou EJB3 Session Bean) e utilização de annotations pra criar validators e converters
Quando eu tinha me referido a Seam e Rails, o que levei em consideração, principalmente, é que da mesma forma que com Rails você não precisa de “mais nada”, o Seam também acaba sendo um framework completo. Não vou dizer que “ah o Seam é tão legal que ele QUASE usa um ActiveRecord” (…) porque não podemos também dizer que tudo que vem do RoR é a silverbullet e tudo que “segue esse caminho” está sendo algo que tende a ser a solução pra fome no mundo.
[quote=djemacao]O incrível que somente a Sun e a Oracle fizeram sites com JRuby e eles rodam legal. Agora, o que está por trás daqueles sites é que são elas. Precisa de servidor que criança não costuma ter pra brincar.
[/quote]
Te passaram FUD. Groovy e JRuby têm performances semelhantes em termos de uso de memória e velocidade de processamento. JRuby só é significativamente mais lento no startup.
O sites que estou desenvolvendo utilizando Seam são os mais complexos que já fiz e por incrivel que pareça são os que estão ficando com a arquitetura mais simples. Mas como não existe País das Maravílhas, aplicar uma estratégia TDD com o Seam não é fácil, exatamente porque o framework é um monstro. Estamos discutindo isso aqui:
http://www.guj.com.br/posts/list/81757.java
Posso mostrar exemplos bem complexos de aplicações Seam, coisas que integram Ajax, Jbpm (com Forks), Mensagens Assincronas e etc… A única coisa que estou esbarrando nele realmente é o TDD.
[quote=rubinelli][quote=djemacao]O incrível que somente a Sun e a Oracle fizeram sites com JRuby e eles rodam legal. Agora, o que está por trás daqueles sites é que são elas. Precisa de servidor que criança não costuma ter pra brincar.
[/quote]
Te passaram FUD. Groovy e JRuby têm performances semelhantes em termos de uso de memória e velocidade de processamento. JRuby só é significativamente mais lento no startup.[/quote]
Me referi na Web, com Rails sendo usado. E o Groovy com Grails sendo usado. Localmente claro que a performance são parecidas, mas o JRuby ainda é mais lento. E não me passaram FUD, testei na minha máquina.
Ruby tem conceitos bem mais complexos do que os de Java.[/quote]
Posso estar enganado, por já conhecer coisas esquisitas como Perl, mas se contar com os inúmeros Patterns que somos obrigados a engolir pra sanar alguma deficiência da linguagem, acho que deveríamos desconsiderar esta avaliação 
.
Alguém saberia me dizer se o Grails é sem turnaround como o Rails?
A grande vantagem do rails, além de funcionar, e bem, é que ele é 1 só. nada de spring, struts, ejb2, ejb3. Os caras trabalham em 1 só coisa o tempo todo, e parecem a apple de tanta facilidade que criam :). A própria metaprogramação suportada pelo ruby faz com que a criação de xml seja uma coisa pra lá de idiota. Pior que isso, usar o ActiveRecord é algo que faz mal a mente. É tão simples fazer relacionamentos, criar um novo modelo, manter seu código, que você enjoa das outras linguagens e soluções existentes no mercado.
Não sou defensor ferrenho do RoR, mas a gente tem muito o que aprender com eles…
Meu medo do RoR é ele sair do nicho que o saoj comentou, aplicações mais simples e que não exigem alta disponibilidade ou processamento distribuído e cair para sistemas pesados de verdade, pq teve um carinha no desenvolvimento lá que gostava RoR e fez.
Pq aí sobra pra dar jeito nesse tipo de projeto, problemas de performance, disponibilidade, etc… e aí quando falamos que tem que refazer os GPs vão dar xiliques…
[quote=otaviofcs]A grande vantagem do rails, além de funcionar, e bem, é que ele é 1 só. nada de spring, struts, ejb2, ejb3. Os caras trabalham em 1 só coisa o tempo todo, e parecem a apple de tanta facilidade que criam :). A própria metaprogramação suportada pelo ruby faz com que a criação de xml seja uma coisa pra lá de idiota. Pior que isso, usar o ActiveRecord é algo que faz mal a mente. É tão simples fazer relacionamentos, criar um novo modelo, manter seu código, que você enjoa das outras linguagens e soluções existentes no mercado.
Não sou defensor ferrenho do RoR, mas a gente tem muito o que aprender com eles…[/quote]
Conheça Grails, ele aprendeu muito com RoR.
[quote=reinaldob]Meu medo do RoR é ele sair do nicho que o saoj comentou, aplicações mais simples e que não exigem alta disponibilidade ou processamento distribuído e cair para sistemas pesados de verdade, pq teve um carinha no desenvolvimento lá que gostava RoR e fez.
Pq aí sobra pra dar jeito nesse tipo de projeto, problemas de performance, disponibilidade, etc… e aí quando falamos que tem que refazer os GPs vão dar xiliques…[/quote]
E escrever a aplicação em Java vai evitar isso?
Incompetência é independente da linguagem ou ferramenta que as pessoas estiverem utilizando. Se eles não sabem nem escolher a tecnologia certa pra escrever a aplicação, vão dançar em qualquer uma das possibilidades, escolher um ou o outro não vai facilitar a vida deles não.
[quote=reinaldob]Meu medo do RoR é ele sair do nicho que o saoj comentou, aplicações mais simples e que não exigem alta disponibilidade ou processamento distribuído e cair para sistemas pesados de verdade, pq teve um carinha no desenvolvimento lá que gostava RoR e fez.
Pq aí sobra pra dar jeito nesse tipo de projeto, problemas de performance, disponibilidade, etc… e aí quando falamos que tem que refazer os GPs vão dar xiliques…[/quote]
Não é só o seu não, é o meu e de muita gente. RoR é lindo, mas em projetos grandes, tem que ser bem testado primeiro. A curto prazo, vejo ele matando de vez (ainda num matou num sei pq?) o PHP.
Não sei, não vejo o pessoal de PHP migrando pra Rails não. Acho que as maiores “viradas” tem sido o pessoal de Java e .Net mesmo.
Acho essa discussão a respeito de EJB e Spring uma grande falta de foco em relação aos problemas reais que acontecem na plataforma Java.Concordo com o Hal Jordan,o grande desafio é a melhoria(ou pelo menos a aplicação!) de processos de desenvolvimento e arquiteturas capazes de digerir mudanças tão rapidamente e independente de ‘novas conjecturas’,de modo que as aplicações atuais não se tornem ‘legadas’,e sim facilmente atualizadas,quando nescessário.
Acredito que a plataforma se encontra num estágio maduro o suficiente para se desenvolver mais ainda e com pequeno risco de perder espaço para Rails,Groovy e semelhantes(tais linguagens tem sim o seu espaço,mas não de uma maneira ampla como Java e sim atacando os pontos fracos de maneira a se tornar um ótimo complemento),desde que haja uma união dos membros da comunidade para os verdadeiros problemas.
Para exemplificar esse aspecto,desenvolvo sistemas corporativos para uma grande empresa de seguros que ainda tem como padrões o uso de EJB 2.1 e Struts 1.1 há pelos 4 anos com uma arquitetura bem rígida e, a meu ver,eficiente.A rigidez nas regras mais o uso de ferramentas apropriadas facilitou a criação de novas ferramentas mais específicas e aplicações a ponto de se tornar uma tarefa simples possibilitando até um desenvolvimento mais ágil(tirando a burocracia!).
Acho que essa aproximação também pode valer para aplicações menores,tiradas as devidas proporções. :shock:
Leozin , vi que fez uma menção ao SpringMVC e para falar de cases do Brasil, eu o utilizo em diversos projetos Web. Até se você der uma vasculhada no guj, vira e mexe eu o urubatan e o Maurício; respondíamos grande parte das dúvidas da galera.
Quanto ao projeto que você disse que ninguém dá importância, ele é a base do controle MVC do Grails. É um framework muitíssimo poderoso e pouco utilizado aqui no Brasil. No Spring 2.5, a metaprogramação o tornou simples, baseado em anotações :-).
Falando em RoR e aplicações distribuídas, queria saber como o pessoal do RoR resolve a questão de separar uma classe de negócio que envolve uma série de objetos de domínio.
Já falei disso uma vez com o Shoes , ele referenciou DDD e o model. Até voltei no livro do Evans e ele mesmo diz para externalizar em classes quando envolve outros objetos de domínio.
Passamos anos tentando ensinar a galera do Service-to-worker à não colocar suas regras nas Actions. E o que vejo no RoR ? Regras de negócio totalmente amarradas, sem possibilidade de migração entre projetos.
O Grails possui a possibilidade de estender essa característica pelo DI do Spring, separando a camada de negócios e a disponibilizando num GigaSpaces por exemplo. Assim, você consegue resolver o problema de aplicação distribuída de forma simples e fácil~.
º~s
Kenobi .
Já que o Ruby é pragmático em tudo, a galera resolveu ser pragmático até nisso. Não que eu ache que isso esteja errado, pois acelera o desenvolvimento e corta a burocracia pela metade, mas no longo prazo não sei não…
Um dos motivos de fazer isso é que se amanhã você quer transformar a sua lógica de negócios em um web services, você pode facilmente. Facilita os testes também. Permite reutilizar a camada de negócios em outros lugares (na prática é raridade!), etc. Acho que organiza e facilita a manutenção como um todo.
Não que essa separação tb não possa ser feita com Ruby, mas parece que não é isso que a galera tem feito por aí… Tb fiz um comentário interessante sobre o problema de escopo de variáveis no Ruby aqui: http://www.guj.com.br/posts/list/15/82037.java
A moda era Struts, nós é que fomos pelo caminho errado
O Spring MVC é muito bom, só é complicado de você pegar de primeira por causa da grande quantidade de actions. Se o cara não ler a documentação direitinho não vai saber pra que serve cada uma e quando usar.
[quote=Kenobi]Falando em RoR e aplicações distribuídas, queria saber como o pessoal do RoR resolve a questão de separar uma classe de negócio que envolve uma série de objetos de domínio.
Já falei disso uma vez com o Shoes , ele referenciou DDD e o model. Até voltei no livro do Evans e ele mesmo diz para externalizar em classes quando envolve outros objetos de domínio.
Passamos anos tentando ensinar a galera do Service-to-worker à não colocar suas regras nas Actions. E o que vejo no RoR ? Regras de negócio totalmente amarradas, sem possibilidade de migração entre projetos.[/quote]
Isso aí é POG de quem está programando as aplicações, o mínimo que se espera de alguém que está fazendo uma aplicação com um framework web baseado em actions é que ele saiba que a action/controller só deve ter lógica de roteamento, ela não deve ter nada de lógica de negócios, a lógica de negócios fica nas entidades e nos serviços.
Kenobi, no RoR a integração é feita com REST. O mesmo controller que manda renderizar HTML manda gerar XML ou JSON. Ainda assim, todos os desenvolvedores experientes são unânimes em condenar controllers gordos e enfatizam que a lógica de negócio deve ficar no modelo, que é facilmente desacoplado do resto do framework.
Falae Kenobi, tudo bem?
Desculpa se eu pareci não mostrar direito o meu ponto de vista, mas quando me refiro a cases do Brasil a gente pode ter como base principal o mercado: Quantas empresas você já viu no NetCarreiras ou na apinfo pedindo Spring MVC? E quantas empresas pedem SpringMVC em sites como monster.com? Se for falar “ah eu e o urubatan usamos” não tem relevância nenhuma, da mesma maneira que se eu dizer que uso Guice.
Mas mesmo assim tu concordou comigo, pelo menos é o que deu a entender:
Gostaria de dizer também que não estou falando mal do SpringMVC, longe disso hehe (não é esse o objetivo!) pra mim é um dos melhores frameworks web, já utilizei e aprovo. Mas ainda o mercado brasileiro não conhece nem sequer Spring, imagina SpringMVC, são poucas empresas que utilizam e “nem tantos” usuários “brincam” ou fazem projetos pessoais com o SpringMVC.
Sim você voltou ao mesmo ponto da minha pergunta. E se você precisa externalizar sua lógica, pois trata diversos models num único processamento. A regra de negócio pode ser embutida num modelo rico DDD, desde que seja intrínseca ao que se refere.
Entendeu a questão ? 