Erros primários que um arquiteto não pode cometer

Assumir o boné de arquiteto em um projeto de software é uma tarefa que requer maturidade, muito além do simples conhecimento técnico, pois boa parte do sucesso de um projeto de software depende de decisões arquitetônicas.

Presto consultoria nessa área há algum tempo, e não foi uma nem duas vezes que vi pessoas cometerem erros primários ao assumirem esse boné - ao ponto de quase levarem projetos à ruina. Baseado nessa experiência, quero citar cinco erros primários que um arquiteto pode cometer ao ignorar:

1- O time de desenvolvimento

Não, desenvolvedores não são como apertadores de porcas e parafusos de linha de produção. Se você ainda acredita no conto de fadas do processo fabril para desenvolvimento de software, sinto lhe dizer que isso não passa de balela. A verdade é que desenvolvimento de software é um processo criativo, mais humano que mecânico.

Assim, é preciso levar em conta que cada time de desenvolvimento é diferente do outro, tendo qualidades e deficiencias que de maneira alguma podem ser ignoradas. Ao contrario disso, devem ser colocadas sobre a mesa e ponderadas antes de quaisquer decisões arquitetônicas. Ignorar isso pode ser a ruina do projeto.

Portanto, não basta somente o “sr arquiteto” dominar as técnicas e tecnologias escolhidas para o projeto. É preciso que todo o time de desenvolvimento também esteja apto a operacionalizar cada decisão com qualidade.

Um bom arquiteto precisa saber trabalhar com o conhecimento e a experiência do time. Precisa constantemente promover a evolução técnica do time, mas também saber abrir mão da última versão daquele framework mais legal de todos, quando o time ainda não está apto a usá-lo e não há tempo hábil para capacitação.

Outra coisa fundamental é tornar o time de desenvolvimento participante nas decisões arquitetônicas do projeto. Isso torna o time mais convicto das decisões e também mais comprometido com a sua operacionalização.

2- O escopo do projeto

Não é incomum ver arquitetos querendo conceber soluções que vão atender os requisitos de hoje e os da próxima década. Isso é péssimo, porque leva a elocubrações sem fim. Além, é claro, do iminente risco de construir uma arquitetura frankenstein.

“Ah! Mas e se daqui a um ou dois anos vocês quiserem que o sistema de pagamento possa também receber pagamentos por moeda estelar? Será que não seria melhor se modelassemos algo mais flexivel?” - ah meu Deus!

Tenha bem claro qual o objetivo do projeto, onde ele começa e onde ele acaba. Não fique aquém, nem vá além.

Ah! E não se esqueça de deixar também o time de desenvolvimento bem ciente desses limites.

3- A compatibilidade

Não estabelecer claramente as versões de sistema operacional, banco de dados, IDE, frameworks e bibliotecas, com as quais o software em desenvolvimento deve ser compativel é roubada. Porque o que funciona na versão 1.0 do framework XPTO, talvez não funcione na versão 2.0. Quem garante? Eu que não me atrevo!

Já enfrentei tantos problemas trabalhando em projetos onde não existia essa prática que até me dá arrepio pensar nisso. Você debuga pra cá, debuga pra lá, e quando vai ver, foi um bendito JAR que foi mudado e ninguém te avisou, ou mesmo se preocupou em saber se quebraria o que você fez. Pior ainda quando isso acontecia no momento da implatação do produto final. Urgh!!!

Agora, como fazer isso de maneira eficiente? Bem, para o caso de bibliotecas e afins, sugiro que você dê uma olhada no Artifactory, ele serve de repositório para o Maven. E para sistema operacional, banco de dados, IDE, e outros elementos de infra, um quadro na parede já resolve bem o problema.

4- O design evolutivo

A chave para o design evolutivo é fazer o mais simples possível e ir refatorando depois, conforme a necessidade. Sim, o estado da arte nunca acontece na primeira implementação; tentar fazer isso pode leva-lo à ruina.

Seja prático. Primeiro tenha algo funcional; depois, evolua.

5- As opções de ferramentas

Como se diz “se você só tem um martelo, tende a enxergar todos os problemas como um prego”. Isso é perigoso, porque te faz desperdiçar tempo e dinheiro - e ainda conceber soluções burras.

Faz um bom tempo que o Phillip escreveu este post e ele ainda é muito atual. Infelizmente. Sim, infelizmente, porque ainda tem muita gente que se recusa a ter mais do que um martelo em sua caixa de ferramentas.

Trabalho com Java há muito tempo, mas hoje esta não é a única ferramenta em minha caixa. Há tantas ferramentas boas no mercado, porque ignorar isso?

Há ainda muitos outros erros, certamente…

Que tal você registrar alguns nos comentários deste post?

Valeu!

Executar JRuby a partir do Java

Nos últimos tempos tenho dedicado boa parte do meu tempo livre estudando JRuby. Tem sido uma verdadeira diversão!

Com o objetivo de compartilhar um pouco do que tenho aprendido, eis aqui este post…

Quer dizer que o osrevni inverso também é verdade?

Muito se fala da capacidade do JRuby de acessar código Java de maneira tão natural quanto o faz com seu próprio código - o que é definitivamente fantástico. Mas não tenho visto muitos exemplos de código Java acessando código JRuby. Por quê? Não sei dizer. Talvez porque não tenham visto tanta utilidade nisso. Essa não é minha opinião, já que tenho interesse em implementar algumas coisas em JRuby e usar a partir do Java.

Uma das coisas que fiz nesses meus estudos sobre usar JRuby a partir de Java foi testar o compilador jrubyc para gerar .class, mas não cheguei bem onde eu queria - até troque umas palavras com Charles Nutter a respeito -, porque o .class gerado por ele não é do tipo que se pode instanciar e usar diretamente num código Java, dada a natureza totalmente dinâmica de Ruby. Nas palavras do próprio Charles:

The code compiled by jrubyc is not a “normal” Java class[...] This is not a Java class you can instantiate and call methods on directly from Java[...].

Como não desisti, tenho algumas alternativas para compartilhar.

OBS.: Para executar os exemplos apresentados é necessário ter jruby.jar no classpath do seu projeto. Quando escrevi este post estava usando a versão 1.0, porque não havia uma versão mais atual na máquina que eu estava usando. Mas agora já atualizei o código para a versão 1.1.3.

Primeira alternativa: JRuby puramente Ruby

No exemplo abaixo, criou uma classe Ruby comum - sem qualquer recurso específico do JRuby - e, logo após, a carrego, instancio e executo seu método a partir do Java.

matematica_apenas_ruby.rb

class MatematicaApenasRuby
  def soma(a, b)
    a + b
  end
end

MatematicaApenasRubyTest.java

public class MatematicaApenasRubyTest {
    public static void main(String args[]) throws Exception {
        List pathsLoad = new ArrayList();
        pathsLoad.add("/Workspace/Ruby/IntegracaoJava/lib/");

        Ruby rubyRuntime = JavaEmbedUtils.initialize(pathsLoad);
        rubyRuntime.getLoadService().load("matematica_apenas_ruby.rb", false);

        Object mat_ruby = rubyRuntime.evalScriptlet("MatematicaApenasRuby.new");
        Integer res_ruby = (Integer)JavaEmbedUtils.invokeMethod(rubyRuntime, mat_ruby, "soma", new Integer[] {3, 2}, Integer.class);

        System.out.println("Soma 3 + 2 invocando diretamente JRuby: " + res_ruby);
    }
}

O que esse código Java faz é bem simples, ele:

1- Inicializa um ambiente de runtime para Ruby, indicando onde estão os arquivos .rb;
2- Executa o script de criação da classe MatematicaApenasRuby;
3- Executa o script de instanciação da classe MatematicaApenasRuby;
4- E, por fim, invoca o método soma passando dois parametros.

Que tal, acho simples? Pois muito bem, continuemos…

Segunda alternativa: JRuby implementando Java

Neste segundo exemplo, o que eu faço é criar uma classe JRuby que estende uma classes Java abstrata, o que facilita ainda mais na hora de usar a partir do Java. Vejamos como fica.

matematica_impl_java.rb

require 'java'

class MatematicaImplJava < Java::IntegracaoPoliglota::Matematica
  def soma(a, b)
    a + b
  end
end

Matematica.java

package integracao.poliglota;

public abstract class Matematica {
    public abstract int soma(int a, int b);
}

MatematicaImplJavaTest.java

public class MatematicaImplJavaTest {
    public static void main(String args[]) throws Exception {
        List pathsLoad = new ArrayList();
        pathsLoad.add("/Workspace/Ruby/IntegracaoJava/lib/");

        Ruby rubyRuntime = JavaEmbedUtils.initialize(pathsLoad);
        rubyRuntime.getLoadService().load("matematica_impl_java.rb", false);

        Object mat_impl_java = rubyRuntime.evalScriptlet("MatematicaImplJava.new");
        Matematica matematica = (Matematica)JavaEmbedUtils.rubyToJava(rubyRuntime, (IRubyObject)mat_impl_java, Matematica.class);

        System.out.println("Soma 10 + 2 usando a interface Java: " + matematica.soma(10, 2));
    }
}

E esta alternativa, gostou? Eu gostei bastante. Porque no meu caso, o que eu quero é poder definir uma interface em Java e implementar com JRuby a la Ruby Way e depois usar no Java. É claro que não estou levando em conta o fator “performance”, só estou considerando o fator “alternativa de implemententação”. Só isso.

Mas vamos lá, o que esse código faz?

1- A classe JRuby estende uma classe Java abstrata, como dito antes;
2- A classe que faz o teste, em linhas gerais, faz um cast do objeto JRuby para a classe Java abstrata;
3- E no final das contas, invoca o método da classe Java.

Será que programação poliglota é o futuro?

Se é ou não é, eu não sei. Mas sei que deixei de ser um arquiteto de uma nota só há muito tempo; e estou muito emplogado com JRuby - ele é o melhor dos dois mundos!

E você, o que acha? Deixe um comentário…

Cuidado com suas exceções!

Um tema bastante trivial, mas não pouco importante, são as sempre presentes Exceções. Outro dia desses me deparei novamente com elas – em um dos projetos que presto consultoria [em arquitetura] – e resolvi escrever este post, como uma pequena “dica”, digamos assim, para quem ainda não está totalmente seguro com o tema. Por fim, ele também servirá como complemento ao meu post anterior que aborda o tema transações em EJB3 Session Beans.

Conceituando as coisas

Em Java há dois tipos de exceções:

- Checadas (checked),
- E não checadas (unchecked).

As exceções checadas são identificáveis em tempo de desenvolvimento e, obrigatoriamente, devem ser capturadas (try…catch) e tratadas – seja com uma mensagem “amigável” ao usuário, ou com um algoritmo alternativo, ou seja lá como for. Estas exceções são identificáveis em tempo de desenvolvimento, por isso, são muito uteis na hora de sinalizar que uma “regra de negócio” foi violada – também conhecidas como exceção de aplicação – e, portanto, algo deve ser feito.

Alguns exemplos deste tipo de exceção seriam:

- MaioridadeNaoIdentificavelException
- ValorPagamentoMenorTaxaEmbarqueException
- DataReservaInvalidaException

Já as exceções não checadas normalmente não são identificáveis em tempo de desenvolvimento, por isso são conhecidas como exceções de runtime – e não coincidentemente, são filhas de RuntimeException. Estas exceções geralmente (mas não invariavelmente) denotam erros de sistema que não são recuperáveis.

Exemplos destas exceções na própria API do Java são:

- SecurityException
- NullPointerException
- MissingResourceException

E, como uma prática comum, também é bom notar que exceções não checadas não são declaradas na clausura throws dos métodos os quais podem lançá-las.

Tomando decisões

Quando você entende este conceito fica simples saber quando usar uma ou outra, não? Sim. Quer dizer, sim, mas também, não! Mas por que não? Hammm… Veja só…

IllegalArgumentException denota que um parâmetro inválido foi passado a um método, correto? Sim, é isto que diz a documentação. Bem, neste caso, imagine que você estivesse escrevendo um método de negócio, e neste método você tivesse que consistir os seus parâmetros. Imaginou? Tá. Agora, o que você faria se um dos parâmetros fosse invalido?

a) Lançaria uma IllegalArgumentException
b) Criaria uma exceção própria [checada] para denotar parâmetros inválidos

Sem pensar muito, você ficaria tentado a optar por (a), certo? Creio que sim. Mas esta não seria uma boa opção, se estes parâmetros forem realmente essenciais para o dado método; e se for possível para o código que executa este método tomar uma “decisão de negócio”, se souber que um ou mais parâmetros são inválidos. Neste caso, o melhor é a opção (b). É preciso ficar atento para escolher a melhor opção em cada situação.

Um pouco sobre exceções em EJB3

Todos os métodos de um EJB3 Session Bean lançam uma exceção do tipo EJBException, que é não checada, caso algo de errado aconteça. Isto automaticamente desencadeia um processo de rollback na transação atual, e grava um registro de log no application server para conhecimento do administrador do sistema.

Como fica então se quisermos lançar nossas próprias exceções? É muito simples, mas é também preciso se ater a um detalhe:

“Se a exceção que você lançar for não checada, ela será automaticamente encapsulada por uma EJBException, o que torna o tratamento desta exceção nada fluente na aplicação cliente, uma vez que não será pego de maneira ‘especifica’ pela seu bloco catch. Isto quer dizer que você somente conseguirá capturar uma EJBException, e não uma NaoConseguiEnviarEmailException, por exemplo.”

No caso deste meu cliente, que usa Oracle Application Server, a EJBException encapsula uma OracleRemoteException, que por sua vez encapsulada a exceção que de fato foi lançada. Que beleza, né? Beleza nada, uma praga! rsrsrs

Então, cuidado! Se você estiver trabalhando com EJB3 e quiser lançar uma exceção não checada, não se esqueça que o cliente de seu EJB não saberá (de forma natural, com um simples try…catch) que exceção realmente foi lançada.

Aqui permanece então o que foi dito acima:

- Exceção de negócio, prefira que seja checada,
- E de sistema, prefira que seja não checada, caso realmente não possa trata-la.

Talvez agora você esteja se perguntando: Mas e a transação, como fica? Ela será abortada quando uma exceção checada for lançada?

A resposta é… Não, ela não será abortada. Porque nem sempre uma exceção de negócio requer um rollback de transação. Aliás, também não será registrado qualquer log no application server – porque erros de negócio são irrelevantes a administradores de sistema.

Mas nem tudo esta perdido. EJB3 provê uma anotação para possibilitar que você aborte uma transação caso uma dada exceção checada ocorra.

@javax.ejb.ApplicationException tem um atributo rollback que pode ser definido como true ou false, indicando que a transação deve ser abortada ou não. Assim, basta fazer esta anotação em sua exceção e pronto!

Essa é uma maneira fácil de garantir a atomicidade de sua transação, porque caso ocorra alguma exceção de negócio que de fato viole o acordo da transação, automaticamente, a transação será abortada.

Bom, é isso… Chega de exceções por hoje!

Transacionando EJB3 Session Beans

Um dos requisitos mais importantes em aplicações de software que lidam com modificações de dados persistentes é o controle transacional. O que significa que não podemos simplismente ignorá-lo. Por isso, resolvi escrever este post.

Antes de mais nada, que raios é uma transação?

Uma transação, em linhas gerais, do ponto de vista de negócio, denota uma troca entre duas partes. Por exemplo, numa compra online de livro, você troca uma certa quantia em dinheiro debitada de seu cartão de crédito, por um livro de sua escolha. Ao participar de uma transação de negócio como esta, você procura se certificar de que o valor debitado em seu cartão de crédito é de fato o valor da compra. Caso contrario, há a possibilidade de você estar sendo enganado sem nem mesmo tomar conhecimento - o que não é nada divertido.

Ótimo. Mas onde isso impacta nossos softwares?

Em termos de software, um bom design de seus objetos de negócio não garante que tudo estará bem ao final de um transação. Uma pena. Mas o problema não está no objeto de negócio por si só, ou mesmo no seu processo de negócio. O buraco ainda é um pouquinho mais embaixo.

Em uma aplicação de software, uma transação é bem semelhante ao conceito “toma lá, dá cá” que acabei de apresentar acima, recheado de atividades inter-relacionadas que devem ser completadas em conjunto. A este conjunto de atividades dá-se o nome de unidade de trabalho. (Martin Fowler inclusive catalogou em seu livro Patterns of Enterprise Application Architecture um design pattern que reside nesse campo de transação de negócio chamado Unit Of Work.) Assim, o objetivo final de um transação é executar uma unidade de trabalho, de ponta a ponta, resultando em uma troca 100% confiável. Afinal, ninguém quer comprar gato por lebre, não é mesmo?

Sabendo disso, como podemos garantir esta confiabilidade?

Aqui entra o tal ACID

Quatro características são fundamentais em transações para estas sejam seguras.

1- Atômica, porque uma transação deve executar completamente ou definitivamente não executar. Isso significa que cada trarefa em uma unidade de trabalho deve executar sem qualquer erro, pois se algum erro ocorrer, a transação deve ser abortada e todas alterações revertidas para o estado anterior ao início da transação.

2- Consitente, já que ninguém gostaria de pagar R$ 50,00 no cartão de crédito e, por fim, ao receber a fatura de cobrança, ver que está sendo cobrado R$ 500,00 - e não R$ 50,00. Essa é uma responsabilidade que cabe ao desenvolvedor, que deve consistir cada dado antes de persisti-lo, e ainda, garantir que as tabelas (em caso de banco de dados) estejam preparadas para receber os tais dados.

3- Isolada, porque não é conveniente que os dados estão sendo manipulados por uma transação sejam ao mesmo tempo modificados por outra unidade de trabalho. Imagine que desagradável seria acontecer isso no momento de finalizar uma compra on-line, por exemplo.

4- Durável, uma vez que os dados precisam ser armazenados fisicamente em algum local enquanto a transação está acontecendo, para que não se percam caso o sistema trave.

Daí o acrônimo ACID.

Finalmente, como EJB3 nos permite controlar transações?

EJB3 dá-nos uma maneira muito simples de controlar transações em Session Beans através de uma simples anotação: @javax.ejb.TransactionAttribute.

Você pode aplicar essa anotação tanto em métodos individualmente, quanto na própria classe do bean - o que torna abrangente a todos os métodos. Ou mesmo, se for o caso, você pode aplicar na classe do bean e em seus métodos individualmente, ao mesmo tempo - neste caso, a anotação do método sobrepõem-se à da classe do bean.

@javax.ejb.TransactionAttribute recebe como atributo uma enum TransactionalAttributeType, que tem as seguintes opções:

- MANDATORY, define que o método do bean deve ser parte do escopo de transação do cliente, pois o bean pode não iniciar sua própria transação. Caso o cliente não tenha uma transação iniciada, uma falha ocorrerá e será lançada uma exceção javax.ejb.EJBTransactionRequiredException.

- REQUIRED, significando que o método do bean deve ser invocado no escopo de uma transação. Caso o cliente não houver chamado este método como parte de uma transação, uma nova transação será iniciada. Mas será encerrada ao final da executação deste método.

- REQUIRES_NEW, significa que sempre uma nova transação é iniciada, independente do cliente ter feito a invocação do método do bean em um escopo de transação ou não. O que acontece é que a transação do cliente é suspensa até que o método do bean retorne; e a nova transação, obviamente, só é válida durante a execução do método do bean.

- SUPPORTS, indica que o método do bean pode ser invocado dentro de um escopo de transação ou não. Ele pode, inclusive, interagir com outros beans que não estão inseridos em um escopo de transação.

- NOT_SUPPORTED, suspende a transação até que o método do bean termine a sua execução. Isso faz com que a transação não seja propagada a qualquer outro método de bean que este invoque.

- NEVER, define que um método do bean não pode jamais ser invocado em um escopo de transação. Caso isso aconteça, uma exceção javax.ejb.EJBException será lançada.

Conclusão

Esse modelo de controle transacional é bastante simples de se aplicar, mas ao mesmo tempo poderoso. Como ele fica muito fácil definir as unidades de trabalho - ou, escopos de transação - e garantir as características ACID em sua aplicação de software.

Mas se você não usa EJB3, tudo bem também, não há problema, fico te devendo um post sobre controle transacional com Spring Framework. =)

Até a próxima!

Por um Java mais efetivo!

Tempo atrás participei da primeira turma do treinamento de Arquitetura e Design de Projetos Java da Caelum, com “o cara”, Paulo Silveira - ele me diz que não é “o cara”, mas tô ligado que ele é sim.

Quem me conhece sabe que estou envolvido com Java desde meados de 97, versão JDK 1.1.8, quando tive que fazer um trabalho escolar - do curso de processamento de dados - e comprei o livro Aprenda Java em 24h. Então, cheguei ao treinamento com minhas expectativas lá em cima.

Felizmente, não me decepcionei. Não mesmo. O treinamento foi excelente, altíssimo nível sob todos os aspectos!

Não foi um treinamento de arquitetura de caixinha. Pelo contrario, foi um treinamento amplo e completo, abordando temas bem interessantes, como: Linguagens dinamicamente tipadas, REST, manipulação de bytecodes, AJAX, JSON, interfaces fluêntes, proxy dinânico, DSLs, e um monte de outras coisas legais. Tudo com muita propriedade e sobriedade de quem conhece do assunto.

Este é um treinamento que indico tanto a arquitetos e desenvolvedores experientes, quanto a quem apenas quer praticar um Java mais efetivo.

Sabe por que digo isso? Porque a grande sacada está na comunicação. A apostila é muito boa, mas o resultado das discuções e troca de idéias são infinitamente melhores. Isso é o que me motiva a participar de um treinamento.

Aliás, já que falei em praticar um Java mais efetivo, leia este post do Paulo.

Nested Classes: Use com consciência

Há situações em que precisamos de nested classes, seja para agrupar logicamente classes que apenas fazem sentido num determinado local, ou mesmo para melhorar o encapsulamento. A API Java padrão está repleta de bons exemplos. Mas é preciso algum cuidado para não fazer mal uso delas.

O que é uma nested class?

De maneira bem simples e direta, uma nested class é uma classe membro de outra classe - conhecida como enclosing class.

Java dispõe de dois tipos de nested classes:

1. Static Nested Classes, que são classes sintaticamente residentes em outra classe, mas que usa esta apenas como namespace.

Este tipo de nested class não tem acesso a membros de instância de sua enclosing class.

A sintax para instanciar este tipo de nested class é bem trivial:

StaticNestedClass obj = new EnclosingClass.StaticNestedClass();

2. Non-static Nested Classes ou Inner Classes, que além de residir sintaticamente em outra classe, também tem acesso a membros de instância desta - pois sua instância resite na instância de sua enclosing class.

Este tipo de nested class tem uma sintax bem exótica de instanciação, mas até que intuitiva, quando você entende o conceito de inner class. Veja:

InnerClass obj = objEnclosingClass.new InnerClass();

Por que intuitiva? Porque uma vez que uma instância de inner class está diretamente associada a uma instância de sua enclosing class - e só pode existir nela -, nada mais natural do que criar esta instância a partir da instância de sua enclosing class.

Por motivos óbvios, inner classes consomem mais tempo de processamento e memória que static nested classes.

Quando usar uma ou outra?

Sabendo quais são os tipos de nested classes possíveis no Java - estáticas e não estáticas - e suas naturezas, podemos ter uma idéia clara de quando usar uma ou outra.

• Se sua nested class precisa de acesso a membros de sua enclosing class, opte por inner class;
• Caso contrário, se o que você precisa, na verdade, é apenas de um namespace, opter por static nested class.

Simples, não?

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á…

Projeto Da Vinci Machine

A Sun caminha a passos cada vez mais largos em direção à consolidação da Plataforma Java como tecnologia de base para multiplas linguagens de programação, tal como a plataforma .Net da Microsoft. Assunto que abordei em um de meus posts recentemente.

Mais um grande esforço neste sentido é o projeto Da Vinci Machine, que visa facilitar a implementação de outras linguagens para a JVM.

New York Times/IDG: Sun’s Da Vinci Machine Broadens JVM Coverage.