You are currently browsing the archives for the jruby category


Rails Summit Brazil 2008!

Esta foi a melhor notícia que recebi nos últimos tempos: Uma master conferência de Rails Brasuquíssima! OmG! Era tudo que eu queria!

Segundo o Akita:

Confirmei as presenças do próprio David Hansson (somente ele será via video online, ele estará na Europa nesse dia, os outros serão presenciais); o grande Chad Fowler ; os mantenedores do JRuby, Charles Nutter e Thomas Enebo ; diretamente da Holanda, da Phusion teremos Ninh Bui e Hongli Lai ; o mantenedor do RSpec, David Chelimsky ; o criador do Github, Chris Wanstrath ; ninguém menos que Dr. Nic Williams ; o escritor do livro The Rails Way, Obie Fernandez ; também Jay Fields, da ThoughtWorks.

E também muitos grandes Railers brasileiros como Manoel Lemos, da Brasigo ; Carlos Eduardo, da e-Genial ; Fabio Kung, nosso JRuby-man, da Caelum ; o grande Vinicius Teles da Improve it ; George Guimarães do Pagestacker.

A notícia completa está aqui.

JRuby ou Groovy?

Não, não quero começar nenhum flame war em torno de JRuby e Groovy.

O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…

Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?

Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:

Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.

Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).

Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.

Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.

Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.

Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!

Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.

Outro fator primordial que vejo é “comunidade”.

A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.

E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)

E o fim deste pensamento, qual é?

Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!

Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.

Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.

(Valeu Diego, por me fazer pensar um pouco sobre isto.)

Até a próxima!

Falando em Java 2008, eu fui!

Ontem estive no evento Falando em Java 2008, organizado pela Caelum, para trazer lenha à fogueira da tecnologia, e também comemorar seu 4o aniversário. Parabéns!

O evento foi ótimo. Organização, coffe break, brunch, palestras, logística. Tudo esta “nos conformes”.

(Os lanches estavam muuuuito bons, como em todos os treinamentos da Caelum. rsrsrs)

Sobre as palestras, um mais que rápido review:

1- Abertura, Paulo Silveira

Fui muito legal saber dos números da Caelum. Tudo que o Paulo Silveira falou, certamente, foi muito inspirador para todos que estão pensando em começar um negócio, ou mesmo já começaram.

2- Os 7 hábitos dos arquitetos altamente eficazes, Guilherme Silveira

A visão da Caelum para um arquiteto é bem na linha daquilo que eu também acredito, então, foi uma boa palestra para eu ganhar mais embasamento em minhas idéias, sabendo que mais gente (e neste casa, uma pessoa reconhecidamente capaz) pensa como eu penso. Não estou totalmente errado… Uff! =)

Basicamente, a palestra dele colocou o arquiteto no lugar onde ele realmente deve estar: Junto com os desenvolvemores, ajudando no desenvolvimento técnico/profissional deles. É papel do arquiteto estar sempre antenado quanto a tudo quanto é tecnologia que exista por ai. Mas é também papel do arquiteto capacitar (com workshops, coach, pair programming, enfim…) seus desenvolvedores nas tecnologias adotadas num dado projeto que estejam participando.

De que adianta um arquiteto conhecer de mais de uma dada tecnologia, se seu time não conhece, não tem fluência? Adianta se ele capacitar o time. Senão, adianta absolutamente nada. (Porque não adianta um arquiteto decidir por uma dada tecnologia se o time não conhecer essa tecnologia.)

Também é importante que todo arquiteto tenha plena certeza de que NÃO EXISTE A BALA DE PRATA. Entendeu? Não? Vou repetir: NÃO EXISTE A BALA DE PRATA!

Vou falar mais sobre os 7 Hábitos e o papel do arquiteto num próximo post.

3- JAP 2.0, Emmanuel Bernard

Esse cara é o líder da implementação Hibernate da JPA, e também um dos participantes da especificação 2.0 da JPA. Isto além de ser líder do projeto Hibernate Search – que também rendeu palestra.

A palestra dele foi bem legal, deu para ver que eles estão trabalhando numas coisas interessantes para a JPA 2.0. Vamos esperar que tudo dê certo… =)

Uma das principais idéias da JPA 2.0 é expandir a API de forma a padronizar coisas que JÁ EXISTEM no Hibernate, para que também outras implementações tenham compatibilidade entre si; e cada vez menos teremos que usar recursos específicos do Hibernate.

Que venham esses novos recursos, porque depender de TopLink… é… deixa pra lá…

4- Domain-Driven Desig, Sérgio Lopes

Cara, essa palestra foi muito divertida. Muuuuito engraçada mesmo. Parabéns ao Sérgio pela criatividade!

Em termos de conteúdo, ele não pode se aprofundar muito, por conta do curto tempo para sua palestra. Como já estou trabalhando com DDD [num grande projeto] há pelo menos 10 meses, tinha anseio de ouvir coisas um pouco mais avançadas. Mas tudo que ele passou, de maneira simples e didática, creio que toda a galera conseguiu entender.

Paulôôô, da próxima vez, dá mais tempo pro menino!

5- Hibernate Search, Emmanuel Bernard

Essa me surpreendeu, porque eu não fazia muita idéia do poder dessa API. Caraca! O negócio é muito bom mesmo.

A idéia do Hibernate Search é literalmente GOOGLEAR suas pesquisas ao seu modelo de domínio. O que é isso? É você fazer aquelas pesquisas que o Google faz (por exatidão, por proximidade, por relevância, etc, etc, etc) no modelo de domínio (sim, objetos!) da sua aplicação. Seria uma full textual search em cima de objetos persistentes.

Com certeza vou estudar dar um estudada nessa API.

Ah! Acho que vale dizer que Hibernate Search usa recursos do Apache Lucene.

6- JRuby, Fábio Kung

Esta era a palestra que eu estava mais interessado em ver. Por quê? Motivos óbvios, adoro Ruby. JRuby então, vixi! =)

O Fábio falou principalmente sobre a experiência de estar desenvolvendo o GUJ on Rails, que é a versão 3.0 do GUJ (a maior comunidade Java da América Latina) totalmente desenvolvida com JRuby on Rails. Chapante!

E o benchmark? Esse foi de matar… O GUJ 2.0 (Pure Java) atende 20 requisições por segundo; o GUJ 3.0 (JRuby on Rails) atende 140 requisições por segundo.

Hammm… Alguém ai disse que Ruby é lento? É… A história se repete…

Tinha expectativa de ver uns códigos, o processo de deploy, etc. Mas de qualquer forma, valeu bastante a palestra. (Se eu já estava doido para colocar alguma coisa Rails no ar, agora estou completamente maluko!)

Bom, depois dessa palestra tive que ir embora, pois tinha um outro compromisso inadiável.

Agora, fora as palestras que foram muito legais, o evento também serviu pro famoso network, ou troca de idéia, ou o que você queira chamar.

Conheci pessoas novas, como o Tony, que trabalha num time Scrum na Abril; o Guilherme Chapiewski, que é ScrumMaster/Tech Lead na Globo.com. E também reencontrei uns caras que não via há um tempo, como o Fábio Akita.

Enfim, valeu de mais o evento!

Mais uma vez, Caelum: Parabéns!

Fui…

Falando em Java 2008

Dia 18 de Maio acontece a 2ª edição do Falando em Java, evento promovido pela Caelum.

Esse ano, entre outras “atrações”, o evento traz [dos EUA] Emmanuel Bernard, líder da implementação JPA do Hibernate e membro do time de especificação da JPA 2.0. Sem dúvida alguma, uma palestra imperdível.

Além desse figura, outras também muito tarimbadas da comunidade brasileira: Paulo e Guilherme Silveira, Alexandre Magno, Fábio Kung, entre outros.

Com certeza, eu vou!

A gente se vê por lá…