Semana Groovy 23 – Maratona Groovy e Grails chegando!

Primeiro evento da Maratona Groovy e Grails: panorama!

maratona_groovy_grails

Dia 28/1 às 20 horas (horário de Brasília) ocorrerá o webinar “Panorama Groovy e Grails” no qual farei uma apresentação panorâmica sobre estas duas tecnologias. Você entenderá por que as chamo de pontes e como você pode (e deve) tirar proveito das mesmas!

Para se inscrever, clique neste link: http://institutopangea.org/curso/8-webinar-panorama-groovy-e-grails?a=110

Ah, e por que as chamo de pontes? Já falei sobre isto neste link: http://www.itexto.net/devkico/?p=2025

Canal da itexto no YouTube

logo_freehand

A itexto possuí agora um canal no YouTube no qual publicaremos vídeos sobre as tecnologias que dominamos. Para começar, criamos a série “Dicas de Grails” que expõe aspectos do framework que muitas vezes são ignorados por seus usuários mas que podem tornar sua vida muito mais produtiva.

A partir de fevereiro serão publicados vídeos semanalmente. Para se inscrever, basta clicar neste link: https://www.youtube.com/channel/UCRKpnCLGZCrVEQu9rijqYeQ

Posts

Entrevista de Graeme Rocher sobre a saída da Pivotal – http://jaxenter.com/grails-future-113958.html

Um artigo rápido no site Jaxenter sobre o lançamento da versão 2.4 do Groovy com suporte a desenvolvimento Android – http://jaxenter.com/groovy-2-4-113941.html

“Keep calm & Groovy on!” – Post da Object Partners sobre a saída da Pivotal –  http://www.objectpartners.com/2015/01/23/keep-calm-groovy-on

Groovy Podcast ep. 5 – Com Graeme Rocher e Guillaume Laforge. Novidades sobre a questão da Pivotal e as novidades que virão para o ecossistema Groovy e Grails para 2015 – https://www.youtube.com/watch?v=UgpPy1LvXA0

The Future of Groovy – Peter Ledbrook expõe sua visão sobre o futuro da linguagem Groovy e seu ecossistema. Em breve escreverá sobre Grails. – http://blog.cacoethes.co.uk/groovyandgrails/the-future-of-groovy

(Este papo todo de Pivotal já está ficando chato, não acham? Espero que na próxima edição surjam links melhores para compartilhar com vocês)

Why Gradle – Finalmente outro assunto: Peter Ledbrook falando sobre Gradle. Leitura interessante para quem tem curiosidade sobre este sistema de build – http://blog.cacoethes.co.uk/software/why-gradle

Projetos interessantes baseados em Groovy mas pouco conhecidos

ORMLite – Imagine um ORM implementado em aproximadamente 1000 linhas de Groovy – https://code.google.com/p/ormlite/wiki/API

Gracelets – Facets + Groovy! Já disse o suficiente :) – http://sourceforge.net/projects/gracelets/

Como Groovy nasceu

Post no qual James Strachan (o real criador da linguagem) anuncia Groovy para o mundo. Interessante para entender as razões que levaram à criação da linguagem. – http://radio-weblogs.com/0112098/2003/08/29.html

Lançamento

Groovy Document Builder – criado por Craig Burke, tem como objetivo principal facilitar a geração de documentos nos formatos PDF e Word. Vale à pena ler o anúncio. – http://www.craigburke.com/2015/01/22/groovy-document-builder.html

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

Semana Groovy 22! (histórica!)

Nada melhor que na primeira Semana Groovy de 2015 começarmos com o pé direito e uma série de notícias e novidades que mudarão bastante (e para melhor) a nossa vida. Como verão, não foi por acaso que atrasei tanto a publicação desta edição: estive bastante ocupado com alguns projetos que divulgo agora. :)

Maratona Groovy e Grails pelo Instituto Pangea!

Em 2014 ministrei meu primeiro webinar sobre Groovy e Grails pelo Instituto Pangea e a recepção foi simplesmente excelente. Então pensamos: por que não repetir a dose, mas com esteroides? O resultado é a “Maratona Groovy e Grails”. Serão quatro webinares gratuitos nos quais apresentarei diversos aspectos sobre o mundo Groovy.

Dia 28/1 irei apresentar o “Panorama Groovy e Grails“. Vou mostrar por alto o que é Groovy, quais as vantagens da linguagem e o que ela nos trás de novo. Você entenderá por que digo que esta linguagem é uma excelente porta de entrada para quem quer entrar no mundo Java e também por que pode nos tornar melhores programadores. Em seguida, mostrarei o Grails e vocês verão como é trabalhar com este framework.

Dia 4/2 será o evento “O que ganhamos com Groovy?“. Groovy não é só a linguagem de programação por trás do Grails: há todo um ecossistema e oportunidades que apresentarei neste webinar e que, acredito, todos nós devemos tirar máximo proveito.

No dia 10/2 ocorrerá “Grails na prática“: vou construir junto com vocês uma aplicação web Grails do zero. Iremos partir da modelagem da aplicação, passando pela implementação e, finalmente, sua implantação em um servidor de aplicações. É uma experiência muito boa para que vocês conheçam como é o fluxo de trabalho que o framework nos oferece.

Finalmente, no dia 12/2 vamos ter o “Groovy e Grails no mundo real” no qual convido alguns membros da comunidade nacional para contarem suas experiências. É uma excelente oportunidade para ver casos reais de uso: as principais dificuldades e ganhos experimentados por aqueles que usam as tecnologias no seu dia a dia.

Se interessou? No vídeo a seguir falo um pouco mais sobre os eventos!

Treinamentos itexto de Groovy e Grails

logo_freehand

Este é um ano importantíssimo e muito feliz para a itexto: estamos lançando alguns produtos voltados para a comunidade, dos quais os principais neste momento são os treinamentos de Groovy e Grails. Você pode ter uma visão geral sobre o modo como trabalhamos neste link.

Há algumas ementas que propomos, mas você ou sua empresa são livres para customizá-las de acordo com suas necessidades. Seguem os descritivos dos nossos treinamentos Groovy e Grails.

E estão vindo mais novidades por aí. Meu livro já está bem adiantado e deve ser lançado por agora. O que posso adiantar é que, bem: digamos que está com a profundidade que acredito merecermos e seu formato é ágil como Groovy e Grails.

Outra novidade importantíssima que virá são mais melhorias no Grails Brasil: coisas que vocês com certeza vão gostar. Acreditamos muito em comunidades, e há ainda mais coisas por vir. :)

E a Pivotal pulou fora

A notícia da semana foi sem dúvidas o anúncio da Pivotal de que irão parar de financiar os projetos Groovy e Grails a partir do dia 31 de março deste mês. Foi um anúncio que pegou a todos nós de surpresa e, claro, gerou aquele frio na barriga com relação a estas tecnologias. Já adianto pra vocês algo: não é necessário se preocupar, pois Groovy e Grails já existiam bem antes da Pivotal e com certeza continuarão ainda por um bom tempo após esta.

Seguem alguns links sobre o assunto para que vocês saibam melhor o que aconteceu e para onde iremos.

Groovy e Grails sem a Pivotal: e daí? – Meu parecer sobre a situação no qual mostro que este é apenas o modo como o mundo open source funciona. Nada para nos assustar. :)

O anúncio da Pivotal – o post que abalou a Internet esta semana. Reparem um detalhe: a própria Pivotal diz que parou o financiamento por que mais da metade das contribuiçoes aos projetos hoje vêm da comunidade.

O FAQ da Pivotal sobre sua decisão – uma leitura interessante que torna mais clara a postura da empresa.

O anúncio do acontecimento feito pelo Graeme Rocher

O anúncio do acontecimento feito pelo Guillaume LaForge

A entrevista que Guillaume LaForge deu ao site InfoQ

A repercussão no Grails Brasil

Um texto interessante no site IntelliGrape: “Groovy and Grails: GR8 without Pivotal

Após ler todos estes posts, acredito que se você sentia algum medo, este deixou de existir. Apenas para lembrar, um exemplo recente: quando a Nokia abandonou o projeto Qt, ele continuou, prosperou, e a Nokia se foi. Esta é a beleza do código aberto e da comunidade: nós definimos o futuro da tecnologia.

Lançamentos importantes

Groovy 2.4 lançado!

Este é um release importantíssimo pois é o primeiro que oferece suporte ao desenvolvimento de aplicações Android. Acredito que será algo tão ou mais revolucionário que o próprio Grails. Você pode ler o anúncio aqui.

Outros lançamentos

Spring Batch 3.0.3

Spring Boot 1.2.1

 Spring Session, um novo projeto da Spring Source que resolve diversos problemas interessantes sobre gestão de sessões e que, na minha opinião, vocês deveriam prestar bastante atenção.

Posts interessantes

Groovy Weekly 54 – Uma edição histórica no site do Guillaume LaForge

Dois posts meus que tiveram uma boa repercussão. “O que é legado?” e “A crescente irrelevância do MongoDB“. O segundo traduzi para o inglês e fiquei espantado com o efeito que teve no exterior!

 

 

Groovy e Grails sem Pivotal: e daí?

groovylogoMinha história com Groovy e Grails é velha e você pode ler aqui. Quando vi ontem o post da Pivotal dizendo que não iriam mais financiar Groovy e Grails não achei que fosse uma notícia boa ou ruim. Para quem acompanha e trabalha com projetos open source (e já possuí alguma maturidade) fica claro que é apenas notícia. Financiadores de projetos open source vêm e vão, mas o que mantém viva a coisa é a comunidade.

Groovy e Grails já existiam bem antes da Pivotal e continuarão a existir depois. Um financiador ajuda bastante mantendo uma equipe focada no desenvolvimento do framework e linguagem, mas se você observar diversos outros projetos open source bem sucedidos notará que nem sempre existe este grande financiador. Normalmente são mantidos pela própria comunidade ou seus criadores originais que fazem dinheiro com consultorias, livros, artigos, etc.

Muitas vezes chegamos até mesmo a pensar que grandes instituições mantém projetos open source mas na prática quem realmente mantém é um grupo pequeno que se dedica ao projeto e que sequer é pago. Basta ver a infinidade de projetos mantidos pela Apache. Alguns exemplos? Wicket, MyFaces,  Apache Commons e a maioria dos projetos Apache. Isto sem mencionar projetos gigantescos que também são mantidos sem a figura do financiador monstruoso, mas sim seus criadores e comunidades. Alguns exemplos? Vaadin, Prime Faces, Ruby on Rails, VRaptor, jQuery, jFreeChart, HighCharts, JUnit . Estes são apenas alguns exemplos, mas se você fizer uma consulta, constatará a mesma coisa: projetos open source evoluem sem um grande mantenedor desde que possuam qualidade.

Mas ninguém usa Grails né?

Bom, no Brasil, apenas no Grails Brasil, temos quase 2100 membros cadastrados hoje. A imagem a seguir é um slide que costumo apresentar em minhas palestras com algumas empresas com as quais tive contato direto ou indireto. Repare: eu tive contato. A realidade é bem mais abrangente.

grails_no_brasil

E fora do Brasil, quem usa isto? De novo, mais um slide com alguns grandes players que usam Grails em seu dia a dia e muitas vezes você sequer se dá conta:

grails_fora_do_brasil

E a lista é pequena. A abrangência é muito maior que isto. Hà alguns sites inclusive que você pode consultar para ver casos de sucesso, como esteeste e este.

Sobre o futuro do Grails? Em março sairá a versão 3.0 que será ordens de magnitude superior ao que temos hoje e ainda será compatível com as versões anteriores. Mais do que isto, estão surgindo cursos aqui no Brasil (um é meu) sobre o framework, assim como eventos a partir deste mês.

 

Mas quem usa Groovy?

Groovy é simplesmente a segunda ou terceira (o segundo lugar fica empatado com Scala) linguagem mais usada na JVM: só perde para o Java. Já sabíamos disto em 2010, mas o uso da linguagem vai bem além do uso direto. Basta lembrar a quantidade de projetos que usam Groovy como dependência direta ou indireta. Alguns com dependência direta: Jasper Reports, Spring,  OpenEJB, Tapestry e tantos outros. E indireta, basta buscar em seu repositório Maven.  É uma das linguagens mais difundidas da história graças ao fato de ser fácilmente embarcada.

Isto sem mencionar o que nos espera para o futuro como, por exemplo, desenvolvimento para Android, que será tão revolucionário (ou mais) que o próprio Grails. E há também todo um ecossistema que vale muito à pena ser mencionado aqui: frameworks fascinantes como RatPack, Griffon, Spock, GPars e tantos outros.

Isto sem mencionar o fato de que o mecanismo de build mais popular atualmente e que mais tem crescido é inteiramente baseado em Groovy. Talvez vocês já tenham ouvido falar dele, se chama Gradle e é o novo padrão usado para o desenvolvimento de aplicações Android.

Comunidade Groovy e Grails

Além disto, é interessante lembrar da comunidade Grails. Há diversos grupos de usuários Grails e Groovy pelo mundo além de um ecossistema de plugins que hoje é imenso. E já mencionei os eventos internacionais como Gr8Conf e Greach totalmente dedicados a Groovy e Grails? Isto sem contar a participação massiva em outros eventos como JavaOne ou Devoxx e tantos outros. São tecnologias extremamente reconhecidas, tanto é que o Geeks Choice Awards do ano passado foi para quem? Groovy.

Se duvida do que digo, convido você a participar das diversas mailing lists que existem hoje tanto para Groovy quanto para Grails. Isto sem mencionar a nacional que é o Grails Brasil. Aliás, já adianto: neste mês começo uma série de eventos pelo país voltados a estas tecnologias. Nâo sou idiota a ponto de apostar em algo que não acredito. Aliás, como já disse antes aqui neste blog (versão em inglês), o valor social de Grovy e Grails neste país é imenso.

É tudo uma questão de postura

Eu sei que é assustador você apostar em uma tecnologia e de repente ver o maior financiador pulando fora. Você se questiona se haverá futuro e coisas do gênero, mas quando observa o tamanho e atividade da comunidade e passa a ter uma visão mais profunda do modo como o mundo open source funciona, estes medos somem pois normalmente só se teme o desconhecido.

Minha sugestão é que todos nós vejamos esta saída da Pivotal como uma excelente oportunidade. Convenhamos, ela não era tão boa assim. Em todos estes anos de Pivotal escrevi para eles diversas vezes e nunca fui respondido. Além disto é interessante observar que também mataram os fórums de Spring, Groovy e Grails movendo-os para o StackOverflow.

Se você realmente gosta de Groovy e Grails que tal parar de simplesmente esperar e ficar plantando o medo por aí e passar a retribuir um pouco para a tecnologia que ajuda a pagar suas contas (tal como eu faço)? Se não souber como, aqui estão dois links ensinando a ajudar a equipe Groovy e Grails.

Eu sei que acreditar no fim do mundo é uma idéia tentadora e fácil de ser abraçada, mas também sei como funcionam projetos open source. Apenas para lembrar, falamos a mesma coisa quando a Oracle comprou a Sun, lembram?  Disseram que o Java estava morto, que não evoluiria, etc. Hoje vemos que estaría morto se continuasse na Sun: a linguagem prosperou, o ecossistema aumentou e todos ganhamos com isto.

E também me lembro de um tempo em que Grails mais prosperou e cresceu. Uma época antes da Pivotal e da Spring Source, quando era um projeto pequeno mantido apenas por seus criadores em uma empresa chamada G2One e que tinha uma comunidade muito mais ativa e próxima dos desenvolvedores originais.

Sem a Pivotal voltamos à época da G2One e, sinceramente, vejo isto como uma excelente oportunidade. Há duas posições: você pode prosperar ou ficar falando bobagem por aí. Opto pela primeira.

PS:

Mas se você realmente acha que é fundamental haver um financiador aqui está uma pequena lista de candidatos: Netflix, RedHat, Oracle, Apache (não financiaria, mas sim ofereceria infraestrutura), Atlassian, MercadoLivre e, quem sabe, você e eu.

Posicionamento do Guillaume Laforge sobre Pivotal

Posicionamento do Graeme Rocher sobre Pivotal.

 

Então você é o legado?

O que é legado?

Santo Agostinho, que de santo mesmo tinha muito pouco.

Dica: você sempre encontrará frases divertidas em Santo Agostinho

De uns tempos para cá tenho notado que cada vez mais pessoas falando sobre “software legado”. E sabem o que acho mais interessante? Elas caem em uma situação parecida com a que Santo Agostinho enfrentou ao falar sobre o tempo.

“Que é, pois o tempo? Se ninguém me pergunta, eu sei; se quero explicá-lo a quem me pede, não sei.” – Santo Agostinho

Troque a palavra “tempo” por “sistema/software legado” e faça uma auto crítica. Se eu te perguntar o que é software legado você vai saber me responder de forma clara e imediata? Já falei aqui como lido com legado, mas nunca apontei uma definição para este. Neste post faço isto,  mas antes vou mostrar algumas definições faláciosas.

“Todo software que você escreve depois de um tempo vira legado, assim como todo aquele que não foi escrito por você.”

Esta definição é um contra-senso e dá pra provar com lógica pura, quer ver? Se digo que um software é legado, a palavra “legado” denota uma categoria (ou conjunto) no qual alguns softwares se encaixem e outros não. Legado é adjetivo. Se é adjetivo, diferencia, se diferencia, deve haver algo que não seja legado.

Se tudo é legado, não há diferenciação, portanto não há legado. O software que você está escrevendo não é legado pois ainda não foi para produção e para o cliente sequer existe de fato, então cairia fora desta definição, mas aí entra aquela outra que também é furada.

“Se foi para a produção virou legado!”

Também não se aplica, a primeira versão do seu sistema, a qual você possui completo controle sobre o código fonte e arquitetura, que está brilhando de lindo pode ser chamado de legado? Sabemos que não. É apenas uma variação da primeira definição que mostrei.

“Legado é todo aquele software que precisa ser substituído por ser obsoleto ou não servir mais!”

Também não. Este software não é legado, mas sim inadequado ao contexto em que se encontra. Entra aí o conceito de obsoleto. Em que sentido obsoleto? Regras de negócio que não se aplicam mais? Uma plataforma de desenvolvimento que NINGUÉM no MULTIVERSO conheça?

A história do ambiente de desenvolvimento críptico também é furada. Ok, você pode ter dificuldade em encontrar mão de obra especializada, mas nada além do custo (que nem sempre é tão exorbitante assim quanto nos vendem) impede que você treine ou aprenda aquele ambiente também antes né? (sempre me soa a preguiça)

“Código legado é código sem testes.” – Michael C. Feathers

Sim, eu li o livro

Sim, eu li o livro

Desconfio que esta falação toda em cima de código legado é motivada pelo livro do Michael C. Feathers que o Robert Martin tem divulgado bastante atualmente. Neste livro há uma definição bem interessante: “código legado é código sem testes”.

Em uma primeira análise é uma boa definição: se o código não tem testes você não sabe explícitamente o que ele faz, logo não há controle sobre ele. Você não sabe se vai quebrá-lo quando for implementar uma nova funcionalidade ou mudança.

O problema desta definição é o escopo: apenas o programador (e talvez o arquiteto). Para o programador código legado é aquele que considera ruim o que, normalmente não passa de uma questão de ego (Fabio Akita tem um texto excelente sobre isto) e ignorância a respeito do contexto que gerou aquele sistema. É simplesmente não ter uma resposta honesta para a pergunta “o sistema deveria ser deste modo por que eu quero ou por que realmente é uma necessidade?”.

(Sobre o livro, bom: me decepcionou pois é mais um livro de refactoring do que sobre arquitetura na minha opinião. Um dia ainda escrevo um review sobre ele. Resumindo: micro demais e macro de menos, mas mesmo assim recomendo a leitura.)

wizardofoz1

Então você é o legado?

O que é um sistema legado?

Sistema legado é aquele cujo controle foi perdido por seus principais stakeholders. – Definição Lobo Weissmanniana

Software legado tem valor e prova disto está no fato de ser usado. Ignorar isto é menosprezar seu cliente e divulgar aos sete ventos sua própria arrogância e cegueira.

Software legado é aquele cujo controle sobre sua evolução foi perdido pelos principais interessados. E ei: o principal interessado não é o programador ou a equipe de desenvolvimento, mas quem o financiou e os usuários finais. Minha diferença em relação a Feathers é o foco: o dele é a equipe de desenvolvimento, o meu o usuário final.

Testes são importantes? Não, são vitais pois garantem a malha de segurança para a equipe de desenvolvimento e tudo o mais que todos nós, desenvolvedores, já estamos cançados de saber. No entanto para quem financia são na prática apenas um dialeto desconhecido. No que diz respeito à proximidade dos testes com o cliente final o mais próximo que iremos ter é o BDD mas, convenhamos, o usuário executivo não se interessa tanto assim por eles quanto se interessa pelo sistema final NO MUNDO REAL.

Quão “antiga” é a plataforma de desenvolvimento também não fazem um sistema legado. Prova disto é a imensidão de sistemas feitos em Ruby on Rails, Grails, Spring, .net e outros feitos às pressas como “MVP” que deixam seus patrocinadores desesperados com uma quantidade imensa de bugs a serem resolvidos e evoluções caríssimas. Em contrapartida, temos um verdadeiro universo de sistemas feitos em COBOL, FORTRAN, DELPHI e VB cujas instituições financeiras possuem completo controle sobre si e não podem ser considerados como legado. A diferença entre um e outro? Controle.

Quando evoluo um sistema legado o objetivo final é simples: devolver o controle a quem interessa. Mas como se perde este controle? De imediato as seguintes causas me vêem à mente:

  • Perda de contato com a equipe responsável pelo desenvolvimento do sistema.
  • Complexidade ingerenciada: você mantém a equipe mas esta perdeu o controle sobre a complexidade do sistema devido a problemas arquiteturais.
  • Perda do próprio conhecimento do sistema decorrente de ausência de documentação ou alta rotatividade dos stakeholders envolvidos na confecção original.
  • Aparente perda de controle: sinistro mas já vi acontecer. Ocorre quando alguém diz que o sistema é ruim apenas para justificar sua reescrita sem apresentar fatos concretos. (muito comum, especialmente quando você está buscando consultorias no mercado para evoluir seu legado)
  • Perda do código fonte.
  • Ou qualquer outra ausência do elo que ligava você à idéia original que gerou aquele sistema.

Entenda: simplesmente refatorar uma base de código não restaura o controle ao stakeholder pois ele nos paga essencialmente para não ter de se preocupar com isto. Para o investidor ter novas funcionalidades ou evoluções e adaptações implementadas em um prazo e custo aceitável, em um todo que seja compreensível, isto sim é ter controle sobre um sistema. ISTO é evoluir um legado, ou melhor, atualizar um sistema.

(Sabe aquele sistema que “não serve mais” ou é “obsoleto”? Quando é verdade, você tem controle sobre ele, pois sabe que não mais se aplica. Por isto não considero legado. Nestas situações há consciência de que deve haver um descarte. O máximo de descontrole que pode haver neste caso são pessoas que ainda o usam.)

Concluindo

É sempre a questão de uma boa definição. Claro que outras definições existem e podem até ser melhor que a minha, no entanto o que observo é que raríssimas vezes vejo a palavra chave fundamental, controle, ser aplicada. Se você domina um sistema, não há problema, você sabe como ele pode e deve evoluir. De resto, é o mito do legado como bem descrito no blog do Fabio Akita que citei acima.

PS: uma definição alternativa poderia ser “o que separa o desenvolvedor infantil do aduto”, mas achei que poderia soar um pouco agressiva.

mongodb_irrelevante

A crescente irrelevância do MongoDB

Minha relação com MongoDB se divide em duas fases que, acredito, são o normal entre diversos usuários deste produto: deslumbramento e realidade. Neste post exponho a terceira fase que estou experimentando: irrelevância.

Deslumbramento

deslumbramento

Tive uma sorte imensa em meu primeiro contato com o MongoDB: o usei em uma arquitetura de persistência poliglota na qual ele cuidava dos casos nos quais os atributos de algumas entidades variavam bastante. Foi uma experiência muito bem sucedida: o que variava demais ficava no MongoDB e o restante em uma base de dados relacional.

Na época fiquei maravilhado com o desempenho do MongoDB e com a facilidade de instalação e configuração. Além disto a sintaxe das consultas me parecia bastante atraente naquele momento (Javascript!).  O ganho que vi na época (e ainda vejo) na emergência do MongoDB (que provavelmente foi o principal responsável pela popularização das soluções NoSQL) foi o fato de ter nos acordado para um erro tão comum que nem o considerávamos como tal: nem todas as estruturas de dados deveriam ser armazenadas em tabelas. De repente todos nós, desenvolvedores, percebemos que havíamos transformado o universo em tabelas e aquilo não era bom.

Aí segue aquela fase de experimentações em que você se maravilha com o que consegue fazer com a nova ferramenta. Surgirão milhares de posts na Internet relatando experiências legais e isto acaba alimentando o próprio deslumbramento que temos com a nova ferramenta.

Realidade

realidade_mongodb

Conforme o tempo foi passando vi a emergência de tecnologias como MEAN, extremamente interessantes mas que muitas vezes levavam aqueles que a adotavam (em estado de deslumbramento) a repetir nosso erro com a adoção do modelo relacional: MongoDB como solução universal para todos os problemas de persistência.

Vi também alguns projetos em Java adotando MongoDB como única solução e pagando um altíssimo preço. Ficou claro que em diversas situações o MongoDB estava deixando de ser uma solução para se tornar um problema (e dos grandes). As razões eram óbvias, mas o hype acabava por cegar diversas pessoas alguns aspectos fundamentais:

  • O modelo relacional é e continuará relevante por eras: se você precisa de relacionamentos, MongoDB não é seu amigo. E não se engane: redundância de dados sob a forma de documentos embarcados não é uma solução, mas sim um problema disfarçado de solução na maior parte das vezes. Integridade referencial é importante: não está aí há quase quatro décadas por modismo.

    (não acredite no papo furado de que por ser muito diferente é bom e você está com uma mentalidade atrasada)

    (implementar na mão integridade referencial é uma experiência MUITO triste)

  • MongoDB não possuía controle transacional ENTRE documentos: ok, você obtém um desempenho excelente ao não ter um ACID completo, mas quando precisa lidar com mais de um documento em uma mesma unidade de processamento ACID faz MUITA falta.
  • Ainda não há uma longa tradição na manutenção de bancos de dados baseados em documentos, então ainda não há boas práticas comprovadas pelo tempo, mas sim declaradas por um ou outro que se auto proclama “autoridade no assunto”.

    (suspeite dos “gurus”)

  • O argumento de desempenho fantástico do MongoDB é falacioso se você não souber de antemão qual o desempenho que seu projeto precisa. Ter o mais rápido não equivale a ter a melhor solução.

Esta é a fase na qual você passa a saber de forma clara onde a ferramenta pode ou não ser usada.

Irrelevância

k7tape

Confesso que não esperava por este estado na minha experiência com o MongoDB, mas ele ocorreu de uma forma tão natural que um belo dia acordei e percebi que não iria mais adotá-lo como solução. Repare: considero irrelevante o produto MongoDB, não o modelo de persistência baseado em documentos. Esta irrelevância se manifestou para mim em dois momentos.

Primeiro momento: TokuMX

tokutek

Algumas das limitações do MongoDB atrapalhavam bastante meu trabalho. Dentre estas, a principal era o fato de não haver transações quando manipulamos mais de um documento em uma mesma unidade de processamento. Buscando alternativas encontrei o TokuMX: um fork do MongoDB que era atraente pelas seguintes razões:

  • Me possibilitava ter transações entre múltiplos documentos em uma mesma unidade de processamento.
  • Ordens de magnitude mais rápido que o MongoDB.
  • Consome uma quantidade de espaço de armazenamento significativamente menor ( isto pude comprovar na prática) .
  • 100% compatível com o MongoDB: basta substituir minha instância do MongoDB pelo TokuMX que meus clientes sequer perceberiam a mudança e já teriam os ganhos acima.

A partir deste momento TokuMX tomou o lugar do MongoDB em meus projetos. Claro que ele não era uma solução perfeita. Algumas de suas limitações poderiam ser bastante chatas:

  • Não há uma distribuição do TokuMX para Windows.
  • As bibliotecas Java usadas para lidar com MongoDB não tiram ainda proveito do suporte transacional do TokuMX. Spring Data não oferece suporte e os drivers que usei também não.  Apesar disto, é possível tirar proveito desta funcionalidade através do envio de comandos ao SGBD, mas não é uma solução tãããão elegante quanto deveria ser.

No entanto a irrelevância do MongoDB neste momento é temporária. Nada impede que surja uma nova versão que supere o TokuMX.

Segunda fase: PostgreSQL

Postgresql_logo

Este foi o prego no caixão. O PostgreSQL desde a versão 9.2 já oferece suporte ao tipo de dados JSON e JSONB em suas tabelas. É uma solução interessante pois mescla em um mesmo SGBD os modelos de persistência baseado em documentos e relacional. Tudo isto dentro de uma arquitetura de anos cuja qualidade já está pra lá de comprovada.

O único ponto que o MongoDB mantinha neste caso era seu desempenho. Era, pois em 2014 a versão 9.4 do PostgreSQL superou (e muito) o desempenho do MongoDB. Duvida? Aqui está o link. Não sei ainda como o PostgreSQL se compara ao TokuMX, mas o simples fato de poder usar um único SGBD ao invés de dois já é uma vantagem bastante interessante para mim. Some a isto o fato de ter o ACID completo e acessível de uma forma simples, PostgreSQL acaba de tomar o lugar do TokuMX.

Concluindo

Se você comparar o MongoDB com as alternativas do mercado, verá que a maior parte da sua relevância se foi. Não o considero um produto ruim, mas sim inferior aos desdobramentos que vieram na sequência (TokuMX e PostgreSQL 9.4). Se há soluções superiores e com um custo mais interessante, o que posso fazer agora é apenas aguardar para ver como o MongoDB evoluirá em 2015 e além.