O Criteria é uma API do Hibernate que facilita muito quando precisamos montar uma query complexa com filtros opcionais. Adicionar restrições ou criar joins com esta API é muito mais simples de gerenciar do que concatenando Strings, como faríamos ao trabalhar com SQL puro.

Apesar das vantagens, o Criteria também tem alguns problemas. O último que encontrei foi ao tentar fazer 2 joins entre as mesmas 2 tabelas. No meu caso, eu tinha no banco as tabelas projeto e historico. A segunda tabela é populada através de uma trigger no banco: sempre que o status do projeto muda, a tabela historico registra o status anterior do projeto com data/hora da mudança. Eu precisava fazer uma query que buscasse um projeto com status “iniciado” num determinado período de datas e com status “finalizado” em outro período. Inicialmente, pensei simplesmente em criar 2 joins entre as tabelas, cada um com um alias diferente e filtrando pelas datas específicas:

Criteria criteria = getSession().createCriteria(Projeto.class);

// Primeiro join
criteria.createCriteria("historicoList", "historicoIniciado", Criteria.LEFT_JOIN)
        .add(Restrictions.eq("historicoIniciado.status", Status.INICIADO.value()))
        .add(Restrictions.ge("historicoIniciado.data", dataIniciadoDe))
        .add(Restrictions.le("historicoIniciado.data", dataIniciadoAte));

// Segundo join
criteria.createCriteria("historicoList", "historicoFinalizado", Criteria.LEFT_JOIN)
        .add(Restrictions.eq("historicoFinalizado.status", Status.FINALIZADO.value()))
        .add(Restrictions.ge("historicoFinalizado.data", dataFinalizadoDe))
        .add(Restrictions.le("historicoFinalizado.data", dataFinalizadoAte));

O código acima, apesar de semelhante ao que eu já havia criado para adicionar outros filtros à query de projetos, fazendo joins com outras tabelas, não funcionava. Tentei retirar um dos joins com a tabela historico e funcionou. Ou seja, o problema estava na criação do segundo join com as mesmas tabelas, mesmo utilizando aliases diferentes. Ao pesquisar este problema, descobri que não é um bug. Na verdade, o Criteria não suporta múltiplos joins para a mesma associação.

Sendo assim, a solução que encontrei para este problema foi criar uma subquery para a tabela historico, utilizando um DetachedCriteria:

DetachedCriteria historicoCriteria = DetachedCriteria.forClass(Historico.class, "historicoIniciado")
        .setProjection(Projections.distinct(Projections.property("projeto")))
        .add(Restrictions.eq("historicoIniciado.status", Status.INICIADO.value()));
        .add(Restrictions.ge("historicoIniciado.data", dataIniciadoDe));
        .add(Restrictions.le("historicoIniciado.data", dataIniciadoAte));
criteria.add(Subqueries.propertyIn("id", historicoCriteria));

Desta forma, apenas um dos joins precisa ser substituído por uma subquery. O outro join pode ser mantido sem problemas.


No último dia 14 aconteceu o Dev in Rio (veja vídeos e fotos do evento). Organizado pelo Guilherme Chapiewski e pelo Henrique Bastos, o evento foi um grande sucesso.

Na abertura do evento, Guilherme e Henrique informaram que o evento seria totalmente voltado para os desenvolvedores, destacando a importância de se integrar e reunir as pessoas para troca de experiências. Eles também ressaltaram a importância de se integrar comunidades de diferentes tecnologias, reforçando também a tendência dos desenvolvedores poliglotas.

A primeira palestra foi de Ryan Ozimek, sobre o CMS Joomla. Ryan, que não é desenvolvedor, falou sobre a história deste projeto, destacando a importância da participação da comunidade para o crescimento do Joomla.

Na palestra seguinte, Nico Steppat e Guilherme Silveira, da Caelum, falaram sobre Java como plataforma, e não como linguagem, destacando o suporte a várias linguagens, permitindo que possamos escolher a linguagem mais adequada a cada situação sem perder as vantagens oferecidas pela plataforma.

Após o almoço, Fábio Akita trouxe uma geral sobre o ecossistema Ruby on Rails. Na minha opinião, esta foi a melhor palestra do evento, pois ele soube resumir em pouco tempo uma quantidade enorme de conteúdo. Primeiramente, ele trouxe um histórico da linguagem Ruby, e, através de uma “meta-apresentação”, mostrou um pouco da linguagem e suas principais características, como meta-programação, por exemplo. Depois, falou sobre Rails, destacando algumas de suas principais características e os mais famosos mitos, como “Rails não escala” (link para a apresentação).

Em seguida, Jacob Kaplan-Moss, um dos criadores do Django, falou sobre este framework Python, sua história, evolução e principais características (link para a apresentação).

Na última palestra, Jeff Patton falou sobre metodologias ágeis, mas focando na criação de produtos e interação com o cliente, e não no desenvolvimento em si. Ele trouxe como exemplo o desenvolvimento de um produto real, as dificuldades encontradas e as soluções utilizadas.

Finalmente, foi feita uma espécie de mesa redonda com a maioria dos palestrantes e alguns convidados, como Marcos Tapajós, Sylvestre Mergulhão e Daniel Cukier, entre outros. Vinicius Teles fez o papel de mediador entre os participantes e o público.

Em paralelo às palestras, ocorreram coding dojos de Ruby, Python e Java. Destaque também para a tradução simultânea das palestras (tanto inglês-português quanto português-inglês), serviço que foi bastante elogiado por aqueles que o utilizaram. Também foram sorteados vários brindes no final, como ingressos para o Rails Summit.

No final, o balanço do evento foi extremamente positivo, pois conseguiu reunir muita gente, incluindo figuras bastante importantes e conhecidas no desenvolvimento de software. Os organizadores estão de parabéns, pois tudo correu sem qualquer problema aparente, todas as palestras foram muito pontuais e de excelente qualidade. Agora, só resta esperar pelo Dev in Rio 2010! Vale a pena conferir também os posts do Guilherme e do Henrique sobre o evento.


Há alguns anos, era muito comum encontrarmos desenvolvedores que conheciam somente uma linguagem, e por isso intitulavam-se “desenvolvedor Java”, “desenvolvedor Delphi”, “desenvolvedor ASP”, ou qualquer outra linguagem. Eram pessoas que conheciam uma, e somente uma, linguagem de programação, e a defendiam com unhas e dentes em qualquer discussão nos fóruns, frequentemente gerando flame wars.

Esse tipo de desenvolvedor ainda existe, mas é cada vez menos comum, e isto é muito positivo. O livro The Pragmatic Programmer recomenda que aprendamos uma linguagem nova por ano, e, com isso, muitos daqueles desenvolvedores Java ou C# estão aprendendo Ruby, Python ou Erlang. Mesmo que não tenhamos pretensão de trabalhar com estas linguagens, pelo menos a curto ou médio prazo, cada linguagem tem suas particularidades, ajudando a quebrar paradigmas. Quando conhecemos somente uma linguagem, temos uma grande tendência a resolver os problemas sempre da mesma forma, conforme aprendemos e como é feito tradicionalmente com aquela linguagem. Desta forma, a tendência é a estagnação, pois não procuramos outras maneiras de resolver os problemas. A partir do momento em que começamos a estudar outras linguagens, abrimos nossa cabeça e começamos a “pensar fora da caixa”, e percebemos que existem muitas outras maneiras de resolver aquele mesmo problema, muitas delas mais simples e adequadas à situação. Surgem os desenvolvedores poliglotas.

Na época dos desenvolvedores monoglotas (sim, essa palavra existe!) era muito comum vermos discussões do tipo: “que linguagem é melhor, X ou Y?”. A melhor resposta é: depende! Depende da situação, do projeto, da experiência da equipe… Para cada situação, uma linguagem pode ser mais adequada que outra, o que traz uma grande vantagem para os poliglotas, pois, para se tomar esta decisão, é necessário conhecer as linguagens disponíveis. Ao mesmo tempo, se ninguém na equipe tiver experiência com determinada linguagem, seria um grande risco utilizá-la no projeto. É como uma caixa de ferramentas: se eu tiver somente um martelo na minha caixa, como farei para apertar um parafuso? É importante termos o maior número possível de ferramentas disponíveis, e conhecimento sobre cada uma delas, para que possamos escolher a mais adequada em cada situação.

Acompanhando esse comportamento, há atualmente uma forte tendência a plataformas poliglotas, o que também é muito positivo. As plataformas existentes já estão bastante maduras, têm algoritmos eficientes para gerenciamento de memória e Garbage Collection, por exemplo, e são bem conhecidas. Encontram-se nesta categoria as plataformas Java e .NET, que estão continuamente aumentando o número de linguagens suportadas - veja a lista de linguagens suportadas pela JVM e pelo .NET. Com isso, a escolha da linguagem para cada projeto fica muito mais fácil, permitindo, inclusive, projetos poliglotas. Se você trabalha com Java e decide utilizar Ruby no seu projeto, por exemplo, basta adicionar o jar do JRuby.

A conclusão que podemos tirar disso é que um desenvolvedor nunca deve estagnar. Procure sempre estudar e aprender novas coisas, mesmo que não seja nada relacionado com o que você está trabalhando atualmente, pois, mesmo que não venha a trabalhar, isso ajuda a quebrar paradigmas e permite que você se torne um melhor desenvolvedor.


Muitos já devem estar sabendo, mas acho que não custa nada ajudar a divulgar: no dia 14 de setembro ocorrerá aqui no Rio de Janeiro um evento imperdível: o Dev in Rio. Organizado pelo Guilherme Chapiewski e pelo Henrique Bastos, o evento terá palestras sobre Rails, Django, Java, Open Source e metodologias ágeis, contando, inclusive, com palestrantes internacionais. A inscrição custa apenas R$ 65,00, e, pelo sucesso que está fazendo, acho que as vagas vão acabar logo!

Para quem estiver sem grana, vale a pena tentar ganhar ingressos pelo RubyInside ou pela revista TI digital.

Mais informações sobre o Dev in Rio no site e no twitter. Parabéns aos organizadores pela iniciativa!


Há muito tempo eu uso o Google Reader como leitor de feeds. A principal vantagem sobre as demais alternativas para desktop é o fato de não necessitar de instalação, podendo ser acessado diretamente pelo browser.

Outro dia, tentei cadastrar o feed do Twitter no Google Reader, e recebi a seguinte mensagem: “Sorry, an unexpected condition has occurred which is preventing Google Reader from fulfilling the request”. Tentei acessar o feed diretamente no Firefox, e, após solicitação de login e senha, os feeds apareceram normalmente. Após uma rápida pesquisa, descobri que o Google Reader não suporta feeds autenticados, o que é o caso do Twitter.

Uma das alternativas a este problema seria utilizar um leitor de feeds que suporta autenticação, como a extensão NewsFox para Firefox ou algum outro. Porém, para poder continuar utilizando o Google Reader, uma solução é o FreeMyFeed, um serviço que funciona como uma espécie de proxy para feeds autenticados: você informa a URL, o login e a senha do feed que exige autenticação, e ele gera um novo endereço de feed que permite acesso direto, inclusive pelo Google Reader.