Quais são as vantagens de se utilizar RUBY?

Ruby, por ser uma linguagem dinâmicamente tipada, lhe dá flexibilidades para desenvolver qualquer tipo de software, não somente web. No geral, você escreve bem menos para alcançar o mesmo resultado, sem perder a legilibilidade no código.

No caso específico das aplicações web, o framework Rails trouxe um conceito interessante que gerou um hype interessante em Ruby. Hoje em dia já existem outras alternativas para desenvolvimento web como por exemplo o Merb.

Na verdade você até ganha legibilidade.

Pessoal pegando a carona deste tópico:

Onde posso utilizar Ruby em um sistema Java web. Especificamente JRuby sem nenhum framework como on Rails.

Usar para web sem nenhum framework te ajudando pra que? Vai reinventar a roda? Tem tanta coisa boa por ai.

anderson.bonavides:

Pessoal pegando a carona deste tópico:

Onde posso utilizar Ruby em um sistema Java web. Especificamente JRuby sem nenhum framework como on Rails.

Como o emerleite disse, isso seria meio que reinventar a roda. No entanto, você poderia utilizar o JRuby em alguma operação específica no ciclo de desenvolvimento do seu sistema, seja numa tarefa do build, ou até mesmo escrevendo testes no RSpec para testar código Java.

Entenda JRuby como um fork de Ruby porém que devido a ser feito em java e rodar encima da JVM te tráz os benefícios da engine e acesso a toda a biblioteca java existente via código ruby.
Já quanto falamos de Java chamar Ruby já entra no esquema de engines de script do java.

Só um adendo: Scala é estaticamente tipada e não possui toda a burocracia/verbsidade do java. A coisa tem mais a ver com a filosofia da linguagem do que com o seu modelo de tipos.

A verdade é que tenho uma monografia que fala de interoperabilidade entre linguagens. Ja em uma outra disciplina tenho um projeto para terminar que é um gerenciador de projeto. Então resolvi mostrar a interoperabilidade entre 2 linguagens como JRuby e Java. Sendo assim não consigo definir bem onde posso utilizar JRuby e nesta altura do campeonato não tenho como mudar acrescentando o framework on Rails.

Você pode obter interoperabilidade entre Ruby e Java através da engine presente em javax.script.* a partir da versão 6 do Java. É possível realizar a integração entre as duas linguagens, mas tem um pequenino “porém”: quando a classe Java depende de algum container feito para o Java EE, não dá pra testar tão facilmente o Rails, já que tem que abrir mão do servidorzinho WEBrick, que vem junto com o framework.

Um outro porém (corro o risco de levar pedrada por essa) é que o Rails é mais forte no LAMP do que no Java EE, e não tem nada a ver com guerra de benchmarks. A razão é que muitas bibliotecas de terceiros do Ruby possuem chamadas nativas a código escrito em C, que, obviamente, não será possível executá-las quando rodado sobre JRuby. Seria possível haver bibliotecas que fizessem chamadas nativas a código Java, mas essas são bem mais raras de se encontrar.

Mas é claro, se você não precisar desses “poréns”, dá pra rodar sobre um servidor Java EE tranqüilo.

Ok leonardo.
Mas a pergunta que quero fazer é em que ponto do sistema eu poderia utilizar JRuby?

É um sistema de gerenciamento de projeto onde a camada de visão eu utilizo JSF e a camada de persistência eu utilizo JPA.
Sei que da para trabalhar muito bem com arquivo, e sei que é possível fazer a troca de JPA para hibernate mudando algumas linhas do persistence.xml, poderia também mudar a camada de visão mas isso ficaria um pouco mais difícil.
Poderia criar também um arquivo de log contendo informações do projeto mas ai ficaria a pergunta pq não fazer com Java?
Bem fora esses pontos não sei onde mais poderia utilizar JRuby em minha aplicação.

Você tem razão. O fato de Ruby ser dinâmicamente tipada até ajuda muito, mas não é o ponto. Me expressei mau no post anterior.
Como não conheço Scala, não posso falar muito sobre essa comparação.

anderson.bonavides acho que o que você tem a fazer é aprender Ruby e primeiro entender as suas vantagens/facilidades/etc antes de qualquer coisa.

Aglomerar mais uma tecnologia(seja JRuby ou Engine Script) simplesmente para colocar mais uma siglazinha na assinatura do projeto não é uma coisa interessante, e muito menos prática.

Te indico primeiro aprender e principalmente entender Ruby/JRuby/Scripting, depois ao longo da necessidade você vai saber utilizar e avaliar “custo X beneficio” a tal implantação.

Espero ter ajudado mais do que atrapalhado.

Valeu…

Otimo para desenvolver blogs…

nbluis:

anderson.bonavides acho que o que você tem a fazer é aprender Ruby e primeiro entender as suas vantagens/facilidades/etc antes de qualquer coisa.

Aglomerar mais uma tecnologia(seja JRuby ou Engine Script) simplesmente para colocar mais uma siglazinha na assinatura do projeto não é uma coisa interessante, e muito menos prática.

Te indico primeiro aprender e principalmente entender Ruby/JRuby/Scripting, depois ao longo da necessidade você vai saber utilizar e avaliar “custo X beneficio” a tal implantação.

Espero ter ajudado mais do que atrapalhado.

Valeu…

Na verdade eu já conheço um pouco. Tenho estudado a linguagem mas só não fiz grandes aplicações. Mesmo assim ainda tenho dificuldades em enxergar pontos onde posso trabalhar com a linguagem.

Se você tem as páginas em JSF e o mapeamento em JPA, vejo algumas possibilidades de se colocar Ruby:

1. Usar classes Ruby como managed beans - nesse caso, como os beans são disparados através de EL, é necessário criar um mapeamento EL <-> Ruby (nada complicado, mas é necessário conhecer conceitos avançados do Faces). E é interessante questionar se é vantagem usar Ruby apenas para os mbeans, que são a menor parte do seu sistema. Seria interessante usar também ActiveRecord ou DataMapper do Ruby para as classes de modelo, mas aí você jogaria muita coisa fora feita em Java.

2. Criar uma parte complicada do sistema em Ruby - só há vantagem nisso se essa parte complicada depente fortemente de reflexão ou metaprogramação, do tipo, sei lá, ler um documento texto semi-estruturado e tranformar isso em um objeto cujos atributos e métodos são definidos de acordo com seu conteúdo.

3. Novas funcionalidades em Rails, velhas em Faces - a solução mais fácil de se adicionar Ruby no projeto. Por ser a mais fácil, é a que mais dá dor de cabeça na hora de manter depois. Portanto, evite ao máximo essa alternativa.

Ok Leonardo muito boa sua sujestão.

Fico grato.

Só para acrescentar, a questão de uma liguagem ser dinamicamente tipada pode até ajudar durante o desenvolvimento (o que normalmente acontece). Mas dificulta bastante esforços de reengenharia, principalmente quando a inferência de tipos é necessária.

Não sei o que você entende por “reengenharia”, por que é uma palavra, digamos, “superutilizada” para designar qualquer coisa que tem que ser feita na fase de manutenção. Para mim, reengenharia é uma transformação no software para se adequar a uma mudança de ambiente ou uma mudança no paradigma de negócio. Isso envolve outras variáveis além de simplesmente código, como por exemplo arquitetura ou análise do negócio, cujo esforço é o mesmo independente da linguagem utilizada pelo software.

E é importante ressaltar que são os usuários das linguagens dinâmicas que mais valorizam testes automatizados, coisa que no mundo Java só acontece se o arquiteto ou desenvolvedor for um “alpha-geek”. Pois na maioria dos casos o que vale é aquele waterfall basicão cujos nomes das fases tem o mesmo nome do processo RUP. Ou seja, ter testes automatizados auxiliam quem precisa fazer alterações no código, coisa que, no mundo Ruby, é bem servido.

Leonardo3001:

Não sei o que você entende por “reengenharia”, por que é uma palavra, digamos, “superutilizada” para designar qualquer coisa que tem que ser feita na fase de manutenção. Para mim, reengenharia é uma transformação no software para se adequar a uma mudança de ambiente ou uma mudança no paradigma de negócio. Isso envolve outras variáveis além de simplesmente código, como por exemplo arquitetura ou análise do negócio, cujo esforço é o mesmo independente da linguagem utilizada pelo software.

Primeiro, em momento nenhum afirmei que o domínio, que envolve regras de negócio etc e tal, não tem influência em esforços de reengenharia.

Segundo, nesse caso eu classifico reengenharia como manutenção preventiva.

Para esclarecer um pouco mais:

Normalmente atividades de reengenharia envolvem engenharia reversa, que consiste em analisar a documentação, quando disponível, o código fonte, enfim vários artefatos gerados durante o desenvolvimento do software. Após essa análise o propósito de atividades de engenharia reversa é criar representações em um nível mais alto de abstração, como por exemplo: diagramas de classe, seqüência etc. Geralmente, essas atividades de engenharia reversa são mais facilmente realizadas quando o sistema encontra-se implementado em uma linguagem estaticamente tipada (por exemplo, Java). Leonardo3001 quantas ferramentas você conhece que produzem diagramas de classes, a partir de engenharia reversa, de linguagens como Smalltalk, Ruby, etc? Foi isso que eu quis dizer. E afirmo isso por experiência própria, pois, tive que realizar reengenharia de um sistema em Smalltalk para reimplementá-lo em Java, e pode apostar que se a inferência de tipos tivesse sido realizada de maneira mais simples eu necessitaria refatorar menos o código Java.
Abraços.

Reengenharia não é manutenção preventiva. Aliás, manutenção preventiva é uma coisa esquisita por si só, porque só se faz alteração em código se isso traz valor ao negócio do cliente.

Reeengenharia não implica na cópia da estrutura de objetos ou de chamadas a métodos presentes em uma linguagem para a outra, portanto a presença ou não de ferramenta que gera diagramas a partir de código é no mínimo questionável. O que deveria ser feito é fazer a análise baseado nos executáveis, nos fontes, nos documentos, nos casos de testes e nas bases de dados da aplicação atual. E depois, deve-se construir modelos e códigos não se baseando naquilo que foi escrito anteriormente, mas se baseando na análise feita anteriormente. Qualquer coisa diferente disso não é reengenharia propriamente dita.

Ninguém falou em “cópia da estrutura de objetos ou de chamadas a métodos”, niguém mencionou nada disso.
Mencionei a utilização de ferramentas para obtenção de diagramas de classes a partir do código fonte, isso é completamente diferente. Caso não tenha ciência, atividades de reengenharia envolvem atividades de engenharia reversa; se tivesse lido pelo menos uma referência confiável sobre o assunto estaria ciente disso. Atividades de engenharia reversa podem ser apoiadas por ferramentas.

Afinal de contas se você não tem uma representação de alto nível do que será alterado é bem complicado saber onde as alterações devem ser realizadas, e compreender o sistema como um todo. E quando a documentação disponível não está sincronizada com o estado atual do sistema? E os diagramas disponíveis na mesma também não refletem o que se encontra implementado? Vai continuar analisando e confiando cegamente na documentação?

Olha até posso sugerir algumas referências pra ti. Sem pedantismo nenhum, mas meu trabalho de mestrado é nessa área. Acho que sei do que estou falando. Se quiser pode começar por esse aqui: http://www.amazon.com/Oriented-Reengineering-Patterns-Engineering-Programming/dp/[telefone removido]/ref=sr_1_1?ie=UTF8&s=books&qid=[telefone removido]&sr=8-1

Toda a questão começou por “inferência de tipos”, se você acha que é fácil fazer tal coisa em linguagens dinamicamente tipadas poderia publicar bastante. Há vários artigos na IEEE sobre tal assunto… se tiver alguma idéia revolucionária.