domingo, 19 de agosto de 2012

Redfoot JUG agora no Google Groups



Desde a fundação do Redfoot JUG em 2004 hospedávamos nossa lista de discussão na infraestrutura do java.net. Somos muito gratos por todo o tempo em que pudemos utilizar os serviços da CollabNet e agora do Kenai.

Mas as coisas evoluem, e é certo afirmar que o Google Groups evoluiu bem mais do que o Kenai que nos hospedava até então. Através de uma enquete democrática no nosso grupo, fizemos uma votação pela migração e tivemos 12 votos a favor, e quase 300 abstenções (que são as pessoas que não responderam ao meu e-mail).

Hoje, dia 19/08/2012 adicionei todos os e-mail da lista antiga através de convites no nosso novo grupo de discussão no Google Groups. Confesso que foi uma tarefa bem trabalhosa, pois não há nada que possa automatizar, e tanto no Kenai quanto no Google Groups eu só consigo manipular 10 e-mails de cada vez. O bom disso tudo é que eu estou quase craque em responder captchas, pois acho que foram quase 50 um atrás do outro.

No decorrer desta semana creio que todos os realmente interessados no nosso grupo aceitem os convites e eu possa desativar enfim a antiga lista.

Quem tiver interesse em se inscrever no grupo, pode acessar o grupo em https://groups.google.com/d/forum/redfoot-jug

sábado, 30 de junho de 2012

Validação do CNS (Cartão Nacional de Saúde)


Durante a semana que passou tive que implementar um código para validar o número do CNS (Cartão Nacional de Saúde), que passará a ser obrigatório a todos os brasileiros. O próprio site do SUS apresenta um exemplo em Java (e em outras linguagens).

Utilizei o código de exemplo, mas na minha opinião ele está tão mal feito que isso passou a manhã inteira me atormentando. Fiquei tentando me convencer de que "você tem um prazo para cumprir, o importante é funcionar", mas não consegui. Logo depois do almoço tive que refazê-lo. O relevante é que se você analisar o código para verificar "o que ele deve fazer", ao invés do "como fazer", perceberá que é algo extremamente simples. Passei de 93 linhas para as 15 abaixo.

Código bem-feito:

O projeto que contém este código, os testes e outras benesses está disponível em https://github.com/insula/opes

Para quem tiver curiosidade em saber como é o código original no site do SUS, segue abaixo. Mas cuidado! Pode causar náuseas e vômitos. Se tiver estômago forte, pode seguir adiante...

Código "normal":

[Dica] Normalização de Strings em Java


Dica rápida para quem já passou pela situação de ter que "normalizar" Strings em Java. Por "normalizar" eu defino que é a rotina de se remover todos os caracteres não-ASCII de uma determinada String.

Segue abaixo:

segunda-feira, 18 de junho de 2012

[Dica] Desfazendo o último commit do git

Você acabou de fazer um commit no seu repositório do git, mas esqueceu de alguma coisa, ou resolveu mudar a mensagem do log, ou cometeu um erro e gostaria de desfazê-lo.

Para os impacientes:
git reset --soft HEAD~1
Quem quiser uma explicação de como o comando funciona pode referenciar diretamente em http://stackoverflow.com/questions/927358/git-undo-last-commit

Ou se quiser aproveitar e criar um alias para poder executar simplesmente um git undo:
git config --global alias.undo "reset --soft HEAD~1"

domingo, 17 de junho de 2012

Eclipse fullscreen no MacOSX


Certamente uma das formas de aumentar a sua produtividade é eliminar o máximo possível de distrações no trabalho. Assim você torna mais fácil fazer o que tem que ser feito.

Recentemente passei a utilizar um recurso do MacOSX Lion pouco explorado por mim até então: o modo fullscreen das aplicações. Não tenho nenhuma informação numérica para provar, mas a minha impressão é a de que realmente o modo fullscreen melhora a produtividade. Não tenho mais e-mail, twitter etc aparecendo nos cantos da tela para tirar o meu foco da tela.

Na parte psicológica, parece-me que alivia também a sensação de "sobrecarga de informação". Ajuda a lidar com uma coisa de cada vez.

Para quem considera o Eclipse a sua IDE favorita, descobri um plugin que faz com que ele fique compatível com o modo fullscreen do MacOSX Lion. http://marketplace.eclipse.org/content/full-screen-enabler-eclipse-3637-osx-lion. Nos outros SOs não faz diferença.

Aos felizes usuários do Eclipse no MacOSX, depois me reportem se a produtividade de vocês realmente aumentou ou não.

Dica: utilizem o Cocoa 32 bits. Carbon é um toolkit muito antigo, e 64 bits só pra quem utilizar heaps maiores que 4GB.

Falhas no cloud computing da Amazon no dia 14/06/2012


Muitas pessoas tiveram problemas no dia 14/06/2012 com suas instâncias disponibilizadas no Amazon EC2 na região us-east-1. Com sorte, felizmente, não fui um dos afetados. Mesmo assim tive o interesse de ler o relatório que a Amazon disponibilizou sobre as causas do incidente.

Se errar (e falhar) é humano, então certamente não há uma outra disciplina tão humana quanto a Tecnologia da Informação. Nossa área de atuação possui tantos fatores interligados que torna o improvável muito mais plausível.

Notem a sequência de eventos da falha:
  1. Um cabo de alta tensão que fornecia energia ao datacenter falhou.
  2. Duas subestações de energia desligaram.
  3. Imediatamente os geradores do datacenter foram ligados e o sistema de energia foi trocado sem interrupções.
  4. Após um tempo de operação, um dos geradores superaqueceu graças a um cooler defeituoso, e desligou-se.
  5. Automaticamente todos os equipamentos que estavam ligados àquele gerador tiveram seu circuito de energia trocado para o conjunto de geradores secundário, que também foi ligado de modo imediato.
  6. Infelizmente o disjuntor que ligava o circuito ao conjunto de geradores secundários estava configurado com uma amperagem muito baixa, e desligou no momento da troca.
  7. A partir deste instante os equipamentos conectados àquele gerador ficaram sem energia e foram desligados.
Improvável? Certamente. Isso só evidencia a fragilidade das operações. Se num ambiente de altíssima disponibilidade como o da Amazon uma falha dessas aconteceu, imagine nos pseudo-datacenters ou pseudo-infraestruturas locais que muitas empresas utilizam por aí.

Notem que mesmo com uma falha deste porte, somente uma pequena quantidade de equipamentos ficou sem energia (somente os ligados ao gerador com cooler defeituoso).

Para garantir a continuidade do negócio, é necessário seguir o manual à risca: replicar os dados e o serviço em datacenters em regiões geográficas distintas. Os clientes da Amazon que utilizaram o multi-AZ não foram afetados pela falha.

quinta-feira, 14 de junho de 2012

O preço da felicidade: R$ 12.500/mês


O estudo não é novo (foi publicado em 2010 com dados relativos a 2008 e 2009), mas ainda assim acredito que vale a pena trata-lo. Neste link é possível encontrar uma reportagem a respeito.
"Quem disse que dinheiro não traz felicidade?"
Dois pesquisadores (incluindo um ganhador do prêmio Nobel em economia) de Princeton realizaram um estudo e descobriram quanto custa a felicidade: US$ 75.000 anuais. Convertendo em Reais a uma cotação de R$ 2,00 = US$ 1,00 em Junho/2012, temos que a felicidade custa R$ 150.000,00 anuais ou aproximadamente R$ 12.500,00 por mês.

Como a pesquisa foi realizada nos EUA, há uma margem de erro para os padrões brasileiros, mas podemos acreditar em um valor próximo de R$ 12.500,00 por mês.

Quais são os indicativos da pesquisa? Até uma renda mensal de R$ 12.500,00 quaisquer acréscimos de renda provocam um aumento diretamente proporcional no índice de felicidade das pessoas. Acima deste valor mensal o aumento de renda não influencia mais na felicidade. Outros fatores passam a influenciar a balança, tais como religião, filhos, saúde etc.

Posso ousar em dizer que o dinheiro não traz felicidade, mas certamente a falta dele a leva embora. A falta de dinheiro costuma exacerbar os outros problemas que enfrentamos no cotidiano. Na pior das hipóteses com o dinheiro pode-se comprar excelentes antidepressivos...

Este tópico está relacionado a um outro tema que pretendo tratar em breve: motivação no trabalho. Mais ficará para um próximo post.

Olhando minha situação por uma perspectiva boa, creio que minha felicidade ainda pode crescer muito! Só preciso aumentar a minha renda em boas doses. E você, já conseguiu comprar a sua?

quarta-feira, 13 de junho de 2012

Programador Profissional #2: Arrogância e humildade


Primeiramente definirei as acepções que utilizarei das palavras "arrogância" e "humildade":
Arrogância: (do latim arrogantia). Atitude altaneira; altivez, orgulho.
Humildade: Consciência da própria fraqueza ou situação.
Um programador profissional é arrogante, pois tem consciência do que representa seu trabalho e do que é capaz de fazer. Não há porque sermos modestos neste ponto: programar é provavelmente a atividade intelectual mais difícil de todos as profissões existentes.

Nós, programadores, somos os seres mais poderosos do universo. Nós, programadores, somos capazes de criar ordem a partir do caos. Nós, programadores, somos capazes de enviar passarinhos ao espaço para matar porcos que roubam ovos. E nós temos esse poder pois somos capazes de criar software.

A cura do câncer só será possível pois um programador profissional criará um software que permitirá que isso aconteça. Os limites da idade humana serão rompidos porque um programador profissional criará um software que permitirá que isso aconteça. A fome de todos os habitantes do planeta será extinta porque um programador profissional criará um software que permitirá que haja comida em abundância. Absolutamente nenhuma inovação da produção humana ocorrerá sem que um programador profissional  esteja por trás dela.

E "quanto maior o poder, maior a responsabilidade". Um programador profissional tem consciência e orgulho de seu poder; e o utiliza com responsabilidade.

Um programador profissional não se contenta em fazer "cadastros": ele sabe que pode e se empreende em fazer muito mais.

Mas um programador profissional também tem humildade. Ele sabe que é humano, e que pode e falhará muitas vezes em sua jornada. Admitir seus erros, desculpar-se e corrigi-los faz parte do seu cotidiano.

Um programador profissional não é um chato que precisa proclamar para todas as paredes que "eu sou foda". (Não faltariam exemplos se quisesse cita-los).

Um programador profissional usa o seu conhecimento, sua habilidade e a sua experiência como um relógio de bolso: deixa-o guardado sem exibi-lo, mas oferece e mostra as horas quando necessário ou quando solicitado.

Um programador profissional é humilde como um super-herói: ele dorme com a satisfação de quem tornou o seu mundo um pouquinho melhor, mas contenta-se em permanecer no anonimato...

terça-feira, 12 de junho de 2012

De aprendiz a mestre: os 3 primeiros livros


Frequentemente alguém me indaga com uma frase parecida com "Gostaria de aprender. Quais livros você me recomenda?" Esta semana aconteceu novamente e resolvi deixar aqui registrado para facilitar o acesso a esta informação.

Java continua sendo minha referência, e embora quase todos os conceitos possam ser aplicados provavelmente em qualquer linguagem, os exemplos dos livros são em Java. Os livros que indico abaixo não são livros para se aprender a programar, ou para se aprender Java. São livros que considero fundamentais para alguém tornar-se um programador profissional. Afinal, aprender Java (ou qualquer linguagem) é uma questão de conhecimento da sintaxe e familiaridade. O que buscamos com esta bibliografia são os conceitos fundamentais de código bem-feito.

Estes três livros são suficientes? Certamente que não! A lista de livros é potencialmente infinita. Mas toda jornada se inicia com os primeiros passos. Acredito que com estes três livros a caminhada comece bem. E por que três livros? Pura liberalidade. Geralmente no início da jornada o dinheiro é curto, e a frase que ouvi esta semana foi: "Tenho verba pra comprar três livros. Quais você me indica?" Segue a tríade. São referências que de tempos em tempos você voltará a ler por prazer e necessidade. Boa leitura.

Effective Java, de Joshua Block

Clean Code, de Robert C. Martin (Uncle Bob)

Refactoring, de Martin Fowler

segunda-feira, 11 de junho de 2012

Técnica do espelho: olhe pelos olhos do usuário


Hoje pela manhã gastei uma hora e meia do meu tempo para renovar a minha CNH. Tive a sensatez de preencher a guia pela Internet e já levá-la paga ao posto de atendimento do DETRAN. Isto fez com que eu economizasse no mínimo mais umas 2 horas.

A senha que obtive para cadastrar as digitais e tirar a foto digital foi a de número 47. No painel indicava já o atendimento 23. Levei mais de uma hora para ser chamado, mesmo com 4 atendentes realizando o trabalho simultaneamente. Fazendo umas continhas básicas constatei a média de 10 minutos para cada cadastro. Blasfemei silenciosamente alguns impauperios ao funcionalismo público, somente para depois ter que perdoá-los...

O motivo da lentidão não era o ritmo de trabalho dos atendentes, e sim o software que fazia o registro das digitais. Logo pensei: certamente o responsável (ou os responsáveis) pelo software nunca devem ter passado por esta situação de morosidade. Ou se o fizeram, não olharam com os "olhos do usuário".

Uma das melhores coisas que aprendi na minha vida como profissional de software foi a técnica do espelho. Em tudo o que você faça, sempre olhe pelos olhos de quem usa. No nosso caso, o usuário. Penso sempre assim: se eu tivesse pago pelo software que eu mesmo fiz, xingaria a mãe do programador ou ficaria satisfeito com o resultado (ou numa situação ideal, mais que satisfeito)?

Nunca considere o seu trabalho como finalizado somente porque "está funcionando". Sempre pense como o usuário. Tenha o desejo e o objetivo de surpreender positivamente quem quer que utilize o seu software.

Quando alguém liga ou manda um e-mail reportando um bug, você se irrita? Se o usuário é rude com você, você retruca também de modo grosseiro? Pense bem. Quem é o f**** d* p*** que não está fazendo o trabalho direito? Você (programador) ou o usuário? Se você recebe a enésima ligação reclamando que um usuário não consegue executar tal rotina: o idiota é o usuário ou você que fez algo extremamente não intuitivo?

Faça esse exercício. Se depois de utilizar a técnica do espelho você realmente concluir que o culpado é o outro, aí sim poderá exercitar o seu vocabulário de baixo calão à vontade...

sexta-feira, 8 de junho de 2012

Educação na área de Tecnologia da Informação

É necessário curso superior?

Se você quiser um diploma de um curso da área de Tecnologia da Informação sem realmente ter que saber programar, você consegue. Afinal, educação no fundo tornou-se um negócio, e se você tiver o dinheiro e quiser comprar, alguém irá vendê-lo para você. E não há nada de ilegal nisso. Há um infinidade de cursos em que você pode entrar, passar em todas as disciplinas, e se formar sem nem saber escrever código. Se o curso for muito exigente, muitos reprovam, desistem... E os alunos somem. Negócio é negócio. Você sempre tem que deixar os clientes (ops, alunos) satisfeitos.

Se você quiser um diploma que realmente lhe ensine a programar e que lhe capacite a ser um profissional de sucesso, você também consegue. Em algumas instituições você não se forma se não conseguir demonstrar um bom nível de competência em suas habilidades. Mas infelizmente em boa parte das instituições que consideramos respeitáveis você obtém um nível de competência proporcional ao esforço que você dedica. Como a maioria dos estudantes aplica pouco esforço, já sabemos qual resultado esperar.

Quem me dera saber e ter convicção das soluções para estes problemas. Cada dia mais acredito que o modelo aprendiz-mestre é o mais adequado para formar programadores. Os anos de experiência me mostraram e fizeram acreditar que software é muito menos (quase nada) de engenharia e muito de artesanato.

É necessário um programador profissional para trabalhar em conjunto e ensinar outros aprendizes. Claro que há uma série de conhecimentos básicos e fundamentais que todo programador deve adquirir; mas as técnicas, o espírito e a habilidade de programar e fazer código bem-feito devem ser transmitidas por um mestre.

Sim, há os autodidatas, e estes são imprescindíveis.

O modelo aprendiz-mestre e o conceito de artesanato de software é algo em que pretendo trabalhar e elaborar um projeto nos próximos meses... Quem sabe conseguir aplica-lo em alguma(s) instituição(ões) de ensino da região. Depois reporto os resultados.

terça-feira, 29 de maio de 2012

Programador Profissional #1: Domínio do inglês

Edsger Wybe Dijkstra (1930-2002)
Este post é o primeiro (#1) da série de definições sobre o que considero um programador profissional. Pensei em utilizar o título "Profissional Competente", mas acabei por concluir que seria um pleonasmo. Afinal, se é profissional, é competente. Os outros não competentes usualmente classifico como amadores.

Costumo utilizar uma imagem para representar cada post. Como falamos em profissionalismo, resolvi utilizar a foto de Edsger Wybe Dijkstra, considerado por muitos como o primeiro programador competente. É dele uma de minhas citações favoritas, apresentada quando um pesquisador lhe perguntou sobre qual tópico estudar:
"Only do what only you can do".
Traduzindo literalmente:
"Faça somente o que somente você pode fazer." 
A ordem das postagens é aleatória, ditada pela inspiração do momento. Isto não faz desta definição a mais, nem a menos importante.

Sempre disse aos meus alunos e a quem trabalhou comigo que saber inglês em nossa profissão é fundamental. Dominar a língua inglesa não é precondição para estar empregado na área de tecnologia. Afinal, a suposta carência por mão-de-obra é tão grande que até os amadores têm seu lugar. Mas é precondição sim para ser um programador profissional.

Gosto muito de uma frase que o +Bruno Souza (o JavaMan) utilizou em uma de suas palestras aqui em Maringá: "Pra você que trabalha na área de tecnologia, português é sua segunda língua (inglês é a primeira)". Recado dado na medida exata de importância.

Os bons livros são todos escritos em inglês. Depois de muito tempo, apenas alguns destes livros são traduzidos (e normalmente a tradução deixa a desejar). Não conseguir ler os bons livros disponíveis já alija qualquer programador de informações importantes e necessárias para tornar-se profissional. O mesmo se aplica a quaisquer artigos, sites e revistas. Alguns teimosos vão contra-argumentar: "mas para estes casos há o Google Translator". Acreditem: não é a mesma coisa.

Ao participar de fóruns de discussão e eventos você possui a oportunidade de dialogar e trocar idéias e informações com pessoas fantásticas. Estas pessoas advém de diversos lugares do mundo, mas certamente todas falam inglês. Entendam uma coisa: inglês é a lingua franca do mundo da tecnologia. É no mínimo "chato" participar de grandes eventos e ficar "de lado" porque "não sabe inglês".

Ler documentação de projetos? Participar de projetos open-source? Trabalhar em equipes geograficamente distribuídas? Conseguir os melhores projetos? Obter os melhores empregos? Para todas estas situações vocês precisarão do inglês.

Para ser um programador profissional é preciso muito estudo e acesso à muita informação. Esta informação está em inglês. Nunca é tarde para aprender. Aliás, antes agora do que mais tarde. Novamente: quem quer acha um meio; quem não quer, acha uma desculpa. Bons estudos.

terça-feira, 22 de maio de 2012

Nós NÃO precisamos de mais programadores


Não, nós não precisamos de mais programadores.

Parece contraditório, no mínimo. Afinal, é bastante comum ouvirmos autoridades apregoando em discursos e reportagens que o déficit de programadores, no Brasil, é de 70 mil programadores/ano. Nos EUA, em torno de 200 mil programadores/ano. Mas nunca recebi uma explicação de como este número foi calculado.

O "déficit" de programadores no Brasil e no mundo é utilizado como motivação para se investir mais na formação de mais programadores. O investimento é correto. O foco é que está errado.

Novamente, nós não precisamos de mais programadores. Precisamos de programadores melhores. Precisamos de profissionais competentes.

Citarei um trecho de uma entrevista com David Lorge Parns, ACM Fellow:
What is the most often-overlooked risk in software engineering?
Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.
Traduzindo literalmente:
 Qual é o mais desapercebido dos riscos em engenharia de software?
Programadores incompetentes. Existem estimativas de que o número de programadores necessários nos EUA ultrapassa os 200.000. Estas estimativas são enganosas. Não é um problema de quantidade; nós temos um problema de qualidade. Um mau programador pode facilmente criar dois novos empregos por ano. Contratar mais maus programadores só vai aumentar a percepção de necessidade deles. Se tivéssemos mais bons programadores, e pudéssemos facilmente identificá-los, precisaríamos de menos, não de mais.
Infelizmente encontrar programadores que sejam profissionais competentes é algo raro. Programar não é somente "fazer funcionar". É fazer bem feito. É produzir código testado. É utilizar técnicas e ferramentas adequadas para resolver o problema.

É fácil perceber porque um mau programador cria dois novos empregos por ano. Um mau programador (que é a regra generalizada) produz código mal feito. Um código mal feito precisa de outros dois maus programadores para ser mantido. E assim continuamos numa progressão geométrica.

Vamos atacar o problema correto. Nossa meta deve ser transformar as pessoas com potencial em profissionais competentes e retirar o restante do mercado. E você? De que lado está? De que lado quer ficar?

quinta-feira, 26 de abril de 2012

A fragilidade da nossa infraestrutura de comunicação

Ontem, 25/04/2012, foi um dia que espero que continue atípico. Devido a um rompimento de cabos de fibra óptica, os estados do Paraná, Santa Catarina, Rio Grande do Sul e parte de São Paulo ficaram com a conectividade à Internet limitada ou interrompida, além de sem telefone e celular. (Mas, por incrível e irônico que seja, o meu Twitter funcionava...)

Quem conhece um pouco da história da Internet sabe que ela foi preparada para circunstâncias de guerra, permitindo uma comunicação continuada mesmo que vários enlaces e roteadores fossem comprometidos. Se uma parte da rede ficasse indisponível, automaticamente o tráfego seria desviado para uma rota alternativa para chegar ao destino. A qualidade poderia ser afetada, mas a comunicação não seria interrompida.

Tudo muito bacana na teoria, mas evidente que o modelo de continuidade pressupõe a existência de rotas alternativas. Não é o que testemunhamos com o incidente de ontem. Se um único segmento de fibra óptica rompido provocou toda essa indisponibilidade, imagino o quão precária e deficitária é a nossa infraestrutura de comunicações no Brasil.

Suponho que por falta de planejamento ou avareza não havia e não há nenhum enlace de contingência ligando os estados afetados ao restante do mundo. Esta alternativa já é dolorosa o suficiente pra mim. Pois a outra hipótese, a de que havia um enlace alternativo - mas que foi enterrado junto com o enlace principal - é muito pior: o único termo que me vem à cabeça chama-se burrice (mas com o devido respeito aos equinos). Escolho acreditar na primeira alternativa.

Temos realmente que evoluir muito. Pagamos absurdos por conexão à Internet, mas como provado, a qualidade de serviço que recebemos não está à altura do preço.

E pra finalizar: GVT, instale um enlace de contingência passando por outra rota, por favor...

sexta-feira, 20 de abril de 2012

Estabilidade do build utilizando o Maven

Maven: A person who has special knowledge or experience; an expert.
O Maven é uma ferramenta de build fantástica. Não é perfeita, pois como estamos cansados já de discutir, não existe esse conceito de ferramenta, linguagem etc perfeito. Contudo eu particularmente considero que 95% das pessoas que reclamam do maven é porque não sabem utilizá-lo. Os outros 5% talvez tenham razão.

Algo que contribui e muito para as reclamações sobre o maven são a infinidade de poms de dependências mal feitos (provavelmente criados pelos 95%). Infelizmente, eles são muito mais comuns do que o tolerável.

Outro problema crítico para qualquer equipe de software é a estabilidade do build. O maven "baixa" as suas dependências através da Internet - por padrão através de repositórios públicos. Se o seu projeto é "novo", sem problemas. As dependências estarão lá. O problema é garantir que estas mesmas dependências estarão presentes daqui a 2, 3, 5 ou 10 anos. O que aconteceria se alguém resolvesse "apagar" aquelas dependências (já que os repositórios são controlados por terceiros, e não por você)? Resultado: build quebrado.

Para nossa sorte há uma categoria de software que resolve os "problemas" do maven acima citados: os gerenciadores de repositório. Nesta categoria enquadram-se o Nexus e o Artifactory. O Nexus é mais antigo, e tenho trabalhado já há um bom tempo com ele. O Artifactory é mais recente e em 2011 ganhou um Duke Award da Oracle. Algumas comparações baseadas na minha experiência:
  • O Nexus, por ser mais antigo, é mais popular. O repositório central do próprio maven passou a utilizá-lo recentemente. O mecanismo de busca do repositório central do maven utiliza-o (Obrigado ao @aldrinleal pela correção!)
  • O Nexus possui um consumo de memória menor. O heap da minha instalação é de 64MB. No site do Artifactory recomenda-se 300MB.
  • O Artifactory é transacional. Isso faz com que qualquer atualização dos repositórios seja bem sucedida ou não sucedida. Não há estado inconsistente - que (dizem, não sou testemunha) ocorre com o Nexus (o Nexus utiliza somente arquivos).
  • O Nexus utiliza somente o sistema de arquivos. O Artifactory precisa de um banco de dados (por ser transacional).
  • O Nexus armazena cópias repetidas do mesmo arquivo que existem em repositórios diferentes. O Artifactory armazena somente uma e a referencia em repositórios diferentes (menor consumo de espaço).
Ambos funcionam bem. Escolher um ou outro passa a ser uma questão de gosto. O importante é escolher um e utilizá-lo. Mas como estes gerenciadores resolvem o problema do maven?
  • Se há um pom.xml mal feito num repositório público, você mesmo pode corrigi-lo e fazer o upload no seu Nexus ou Artifactory. Assim, os seus projetos utilizarão o seu pom.xml corrigido. Claro que você pode e deve contribuir sua correção para os autores de um projeto livre, mas se eles irão aceitar suas "correções" depende deles, e não de você.
  • O Nexus ou o Artifactory realizam o download das suas dependências de repositórios externos e as salvam em seu repositório privado. Desse modo, mesmo que alguém desapareça com o repositório central do maven, ao menos as dependências do seu projeto estarão seguras no seu repositório local, garantindo a estabilidade do seu build.
Conclusão? Qualquer equipe de software consciente que trabalhe com o maven tem que utilizar um gerenciador de repositório. Escolha o seu.

quinta-feira, 19 de abril de 2012

O fim do jornal e a resistência fútil


Sim, o jornal morreu. Alguns moribundos ainda andam por aí, mas diminuem à medida em que os últimos amantes dos folhetins impressos também padecem.

Obviamente o título sensacionalista deste post relaciona-se com o papel jornal, e não com o jornalismo. O jornalismo como fonte de informações transformou-se bastante com o fim do papel - não pela sua falta, mas pelo fato de que ignorantes pretensiosos como eu passaram a também produzir informações que pudessem ser lidas por quem se interessasse. E acredite, por mais improvável que seja, há quem se interesse. Imagino que seja o seu caso, estimado leitor.

O modelo de negócios dos jornais nunca foi "vender papel", e sim publicidade e classificados. Hoje em dia o Google costuma abocanhar boa parte das verbas publicitárias e sites de classificados já preenchem um pouco da demanda provocada pelos internautas. A questão é: como manter a receita do negócio sendo que os consumidores de informação estão migrando para mídias digitais? O natural seria tentar criar atrativos para reter os leitores e transferi-los para a mídia digital (antigamente eu falaria Web, mas tablets e smartphones novamente mudaram o panorama).

Um jornal local da cidade de Maringá (onde resido atualmente) resolveu seguir o caminho contrário. Seu conteúdo "impresso" estava disponível em seu portal para quem se interessasse por acessá-lo. Recentemente, provavelmente devido às quedas nas vendas de papel jornal, decidiu por fechar o seu conteúdo online e restringi-lo somente para assinantes. Resultado? Eu simplesmente parei de acessar o portal, pois o pouco conteúdo local produzido que me interessava já não me estava mais disponível. Imagino que outros leitores tenham feito o mesmo e também passaram então a acessar outros sites que disponibilizassem informações locais.

Desse jeito, esses poucos moribundos desaparecerão antes do esperado...

quinta-feira, 29 de março de 2012

Mais dados sobre a redução dos custos com cloud computing


Muitas empresas ainda não enxergam a significativa redução de custo obtida através do uso do cloud computing (computação em nuvem). Além de trocar o CAPEX (Capital Expenditures) - investimento de capital por OPEX (Operational Expenditures) - despesas operacionais, o tamanho do investimento/despesa é muito menor graças ao ganho de escala.

Dados do Uptime Institute informam que um único servidor de 1U durante um ano pode resultar num gasto de US$ 500 em energia elétrica, US$ 500 em licenças de sistema operacional e mais US$ 1500 em custos de manutenção do hardware. Resultado: US$ 2500/ano. Este é um valor que muitos empresários/diretores não calculam quando comparam o modelo on-premise com o cloud computing.

Eu mesmo já migrei todos os meus serviços há mais de 4 anos, e hoje não enxergo outra forma de se utilizar computação. Definitivamente quem não se aproveita disso está ficando pra trás.

domingo, 4 de março de 2012

Eclipse, OpenJDK 7 e AJDT no MacOSX


O lançamento do Java 7 está quase fazendo aniversário e eu ainda não havia me "atualizado" para esta nova versão. Boa parte da culpa estava na não-disponibilidade do OpenJDK 7 para MacOSX, ao menos não na versão estável.

Depois de muito aguardar, acreditei que o OpenJDK estava estável o suficiente para utiliza-lo. Muitos relatos da comunidade Java no mundo colaboraram para esta opinião.

Passo-a-passo da migração:
  1. Instalar o OpenJDK 7 para MacOSX (obtido em http://jdk7.java.net/macportpreview/). Siga as instruções na página.
  2. Atualizar a versão do Java de 1.6 para 1.7 tanto no maven-compiler-plugin quanto no aspectj-maven-plugin (esse último somente se você utilizar de fato  o AspectJ) do seu pom.xml (assumindo que você utiliza o maven).
  3. Atualizar a versão do AspectJ para a 1.7.0.M1 (novamente, somente se você utilizar o AspectJ).
  4. Atualizar a versão do AJDT do Eclipse para uma versão que possua suporte ao Java 7. É necessário se você utilizar o JDT Weaving do Eclipse (como é o meu caso). Pra quem gosta de arriscar e quiser utilizar o update site, adicione a URL http://download.eclipse.org/tools/ajdt/37/dev/update. Entretanto, eu recomendo baixar o zip da atualização manualmente para não ter o dissabor de num update futuro as coisas deixarem de funcionar. A versão que eu utilizei e que afirmo que funciona é a http://www.eclipse.org/downloads/download.php?file=/tools/ajdt/37/dev/update/ajdt-e37x-20120302-1100.zip
Encontrei muitos relatos na Internet que mostravam o Java 7 funcionando no Eclipse no MacOSX, mas nenhum relatava a configuração com o AspectJ. Tive que descobrir sozinho. E aproveito e reporto aqui para que outras pessoas não percam o mesmo tempo que eu perdi.

Nota: usuários do Spring Roo certamente utilizam o AspectJ em seus projetos. Usuários do Spring que utilizam a anotação @Configurable provavelmente também.

sábado, 25 de fevereiro de 2012

O que ficou...


Há 12 anos estávamos eu e meus amigos de turma nos formando em Ciência da Computação na Universidade Estadual de Maringá (UEM). Em nossa colação de grau tive a honra de ser o orador geral de todos os formandos da formatura conjunta da UEM. No discurso que preparei (do qual lembro de apenas alguns trechos, infelizmente) optei por encerrá-lo adaptando um poema de Fernando Sabino. Nesse clima de nostalgia, recordo-me destas palavras:
"De tudo ficaram três coisas: 
A certeza de que estamos apenas começando,
A certeza de que é preciso continuar e
A certeza de que podemos ser interrompidos antes de terminar.
Fazer da interrupção um caminho novo,
Fazer da queda um passo de dança.
Do medo uma escada,
Do sonho uma ponte,
Da procura um encontro.
Fica a promessa do reencontro,
Fica o desejo de boa sorte,
Fica a vontade de que lutes e venças!"
Creio que são boas palavras de inspiração. É o que fica para todos nós...

Crédito da foto ao Paulo Roberto Crestani Júnior.

Utilizando o iptables ou ngninx para responder requisições na porta 80 como usuário não-root


Por questões de segurança jamais devemos permitir que serviços num servidor unix sejam executados como root. Isso permitiria que uma falha nesse serviço (e como desenvolvedores sabemos que essas falhas realmente acontecem) comprometesse todo o sistema.

Pelas mesmas restrições de segurança, não é permitido que usuários não-root escutem (realizem o bind de sockets) em portas inferiores à 1024. A questão é: como então executar um serviço (HTTP, no nosso exemplo) na porta 80 como usuário não-root?

Utilizarei o HTTP - que roda na porta 80 - como exemplo, pois provavelmente é o caso de uso mais popular. Imagino que você precise que um Tomcat, um Glassfish ou um JBoss seja executado no seu servidor. Normalmente estes serviços são inicializados na porta 8080. Apresento então duas solução possíveis:
  1. Caso você possua somente um serviço e um domínio, pode utilizar o redirecionamento através do iptables.
  2. Caso você possua vários serviços em portas diferentes e possivelmente vários domínios (virtual hosts) no mesmo servidor, utilize o nginx como proxy. (Sim, é possível fazer o mesmo com o Apache e mod_proxy ou AJP, mas o ngnix provou-se uma solução mais fácil, rápida, prática e com menor consumo de memória).
Exemplo de configuração com o iptables redirecionando as requisições na porta 80 para a 8080:

O REDIRECT de PREROUTING atende as requisições externas, e o REDIRECT de OUTPUT serve para redirecionar as requisições originadas do próprio servidor que estejam direcionadas à porta 80.

Exemplo de configuração com o ngninx atuando como proxy de requisições na porta 80 e redirecionando para a porta 8080:

Com esta configuração do ngnix, basta duplicar as linhas acima com as alterações convenientes e você pode ter dois Tomcats sendo executados no mesmo servidor nas portas 8080 e 8081, por exemplo, e redirecionar o myserver.mydomain.com para a porta 8080 e o myserver2.mydomain.com para a porta 8081. Dois virtual hosts, cada um num Tomcat diferente, no mesmo servidor.

quarta-feira, 22 de fevereiro de 2012

Spring 3.x Profiles e configurações diferentes do log4j


Uma das mais aguardadas e bem vindas novas funcionalidades do Spring Framework 3.x são os bean profiles, permitindo que você configure grupos de beans e escolha qual(is) destes grupos você deseja ativar durante o desenvolvimento, produção, teste etc. Outra boa novidade é o Java Configuration, permitindo que você configure os seus contextos do Spring utilizando somente código Java ao invés dos famigerados arquivos XML.

Nem tanto ao céu, nem tanto ao inferno. XML não é algo ruim. Bem usado, é uma ferramenta valiosa. Mas é fácil exagerar também. De antemão já adianto que o refactoring de arquivos de configuração do Spring que utilizam o Java Configuration é bem mais simples.

Algo que me incomodava no log4j era o fato dele ser configurado através de arquivos disponíveis no classpath como log4j.properties ou log4j.xml. Isso tornava trabalhoso o ato de utilizar configurações diferentes para ambientes diferentes (normalmente utilizando o maven para copiar o arquivo escolhido dependendo do profile utilizado).

Nada como a maravilha do software livre. Analisando o código-fonte, vi que utilizar arquivos de configuração do log4j diferentes para ambiente diferentes é mais simples do que eu pensava.

Com a configuração abaixo você pode utilizar dois arquivos de configuração do log4j: um para teste/desenvolvimento que imprima no console, e outro para produção que grave num rolling file e/ou envie notificações através do SNS, por exemplo.


segunda-feira, 20 de fevereiro de 2012

Notificações do log4j através do Amazon SNS

Como desenvolvedores e devops muitas vezes precisamos ser notificados de erros que ocorrem nas aplicações para podermos resolvê-los com o mínimo de downtime e transtorno possível aos nosso clientes e usuários.

Estes "erros" (condições anormais de uso) são registrados no sistema através de loggers. Se você desenvolve software e não utiliza logging, então o problema é mais embaixo. Imagino que o seu código simplesmente deixa o stacktrace das exceções "estourar" na cara do usuário. Perdoe-me, mas você não é profissional. Você finge que programa, e o pior: há quem acredite.

A mais popular implementação de logging em Java é o log4j. Normalmente além do logging para arquivo ou console do log4j, alguns desenvolvedores utilizando o SMTPAppender para enviar e-mails de notificação quando algum WARN é registrado na aplicação.

Utilizar o SNS, serviço de notificações da Amazon, é uma alternativa mais eficiente do que enviar e-mails pois:
  • Permite o baixo acoplamento entre o emissor das notificações (o logger) e seus assinantes (possivelmente os e-mails dos desenvolvedores e devops).
  • Num ambiente com vários servidores rodando a mesma aplicação seria uma situação comum em caso de erro todas estas instâncias enviarem o mesmo e-mail, lotando a caixa de e-mail dos assinantes das notificações.

Pensando nisso resolvi criar uma biblioteca (enorme: 3 classes por enquanto) que permite utilizar o SNS como Appender do log4j: https://github.com/insula/log4j-sns

Entre outras benesses está o fato dele implementar um "quiet period" padrão de 15 minutos, evitando que você receba mais de uma notificação com o mesmo stacktrace dentro do intervalo de 15 minutos.

Num ambiente de cloud computing com múltiplas instâncias de uma mesma aplicação provavelmente você desejará implementar uma assinatura HTTP para lidar com notificações repetidas ao invés de ficar recebendo o mesmo e-mail de várias instâncias diferentes. Quem sabe não vale a pena criar um serviço e disponibilizá-lo online? Já vejo múltiplas situações em que isso seria útil.

quarta-feira, 8 de fevereiro de 2012

Utilizando o Janrain com o Spring Security 3.1.x


Para quem ainda não conhece, o OpenID é um protocolo que permite que você se autentique num site/serviço utilizando as credenciais (normalmente login/senha, mas também poderia ser um certificado digital, por exemplo) de um terceiro confiável.

Esta iniciativa surgiu para tentar eliminar o problema de ter que guardar e lembrar de centenas (ou quase milhares para alguns) de combinações de login e senha diferentes. Assumo também que você, usuário consciente, não utiliza o mesmo login/senha para mais de um serviço. Pois caso positivo, se alguém descobrir a sua combinação - que presumo deva ser trivial - terá acesso a todos os sites e aplicações nos quais você está cadastrado.

Com o OpenID você pode delegar a autenticação da sua aplicação para um provedor de OpenID como o Google, Facebook, Twitter etc. Assim você pode utilizar o sistema de autenticação destes provedores ao invés de criar um próprio.

O Janrain é um serviço que integra vários provedores diferentes de OpenID, permitindo que você desenvolva sua aplicação somente com o Janrain e passe a utilizar vários provedores de OpenID rapidamente.

Para facilitar a vida de quem utiliza a excelente biblioteca de autenticação e autorização spring-security, criei um projeto LGPL que integra o Janrain com o spring-security. De bônus, já vem com componentes JSF2 prontos para usar. Podem conferir em https://github.com/insula/spring-security-janrain

terça-feira, 31 de janeiro de 2012

Continuo aqui. E extremamente feliz em estar vivo!


Tudo começou com uma "torção" no joelho, há 16 dias - um domingo. Parecia algo mais sério, pois já havia torcido o joelho antes e a dor desta vez foi algo bem maior - comparável ao evento de quebra de tornozelo que tive. Gelo e anti-inflamatório. Agendei uma consulta com um ortopedista renomado em cirurgias do joelho pois desta vez acreditei que teria que opera-lo. A consulta ficou somente para a segunda-feira da próxima semana.

Durante estes oito dias caminhei com muletas e minha panturrilha estava bastante inchada, e dolorida. A sensação de dor parecia com uma cãimbra bem forte; motivo pelo qual tomei muita água de coco e comi várias bananas. A dor passou e com isso concluí erroneamente que tratava-se de cãimbras mesmo.

Já na segunda-feira da semana seguinte, fui ao ortopedista. Tirei um raio-x e nada de fratura. Como o joelho estava bastante dolorido, tive que fazer uma ressonância magnética. Citei as dores e o inchaço na panturrilha ao ortopedista, que prontamente respondeu que não era normal e que talvez devesse ir consultar-me com um angiologista (especialidade que trata do sistema vascular).

Realizei o exame de ressonância magnética, e como o laudo ficaria pronto na quarta-feira, decidi que o esperaria para então decidir o que fazer. Com o laudo na mão, agendei o retorno no ortopedista, que ficou somente para a terça-feira da semana seguinte. Não houve tempo.

No dia seguinte acordei com a panturrilha e o tornozelo bastante inchados. Tentei trabalhar (sentado), mas as dores tornaram-se insuportáveis. Chamei minha esposa, que vendo a situação, imediatamente tomou a atitude de levar-me à emergência do pronto-socorro. Antes disso resolvemos ligar para o ortopedista para tentar obter alguma orientação. Infelizmente ele estava indisponível, em cirurgia. Minha esposa explicou a situação à secretária, que ficou de dar um retorno. Nem cinco minutos depois, o ortopedista já ligava de volta.

Ao explicar minha situação, o ortopedista solicitou que eu fosse com urgência a um angiologista. Como não conhecia nenhum, solicitei uma indicação. Ele me indicou uma clínica com vários angiologistas, e pediu para que eu demandasse uma consulta com urgência, e que informasse que seria a pedido dele. Fui prontamente atendido e percorremos o centro de Maringá numa quinta-feira chuvosa ao meio-dia (o que obviamente demorou mais do que gostaríamos) rumo à clínica.

Chegando na clínica o angiologista me atendeu rapidamente e num exame clínico explicou que talvez não fosse uma trombose (a situação temida), mas mesmo assim solicitou um ecodoppler (ultrassom) de emergência.

Mais uma jornada rumo à outra clínica. Fui rapidamente atendido para o exame. Inicio o exame e o médico radiologista em silêncio e de cara fechada. Finalizado o procedimento, pergunto se havia algo de estranho. É quando ouço a resposta: "Você está com uma trombose grave, vai levar este exame para o seu angiologista agora pois ele vai lhe internar no hospital com urgência."

Estranhei a confirmação da trombose, pois sempre imaginei como doença de mulheres idosas, obesas, diabéticas etc. Enquanto minha esposa levava o exame ao angiologista e eu aguardava dentro do carro, pude procurar no Google através do meu iPhone sobre "trombose venosa profunda". Foi aí que percebi a minha situação: "Ih, f*d*u".

Não sei quantas veias tem-se na perna, mas eu estava com quatro veias (das grandes, suponho) com trombos (coágulos) impedindo a passagem de sangue. Estava tudo coagulado da virilha até o tornozelo. Ou seja, situação gravíssima com risco de morte iminente. Pelo que o Google me alertou, a complicação era a possibilidade de uma embolia pulmonar a qualquer momento. Esta situação costuma ser fatal.

Durante a rápida viagem da clínica até o hospital, minha esposa tentou "distrair-me" falando das sequelas que eu teria na perna graças à trombose. Mas eu já sabia do risco que estava correndo. E pensei (ironicamente): "Que bom, se eu sobreviver, minha perna vai ficar uma b*s*a". Contudo, um problema de cada vez. Primeiro resolvi pensar em viver pra contar a estória; o resto fica pra depois.

Chegando no Hospital Paraná, havia uma lista de internação. Você sabe que o seu caso é grave quando você "fura" a fila e é internado antes de todo mundo. Maravilha...

Mal entrei no quarto e já iniciou a rotina (durante os próximos seis dias) de medicações. Comprimidos, injeções na veia, exames de sangue e heparina sódica (uma injeção extremamente dolorida) ao redor do umbigo. Eu não tinha muita restrições quanto às injeções, mas essa injeção ao redor do umbigo mudou minha opinião...

A boa notícia é que de um dia para o outro, graças à medicação, minha perna desinchou bastante. Quando dei entrada no hospital minha panturrilha estava da largura da coxa, e meu tornozelo estava da largura da panturrilha. Meus dedos estavam todos "unidos". Para critério de comparação: eu costumo calçar um Croc's bem larguinho para ficar confortável. Deve ter pelo menos 2cm de sobra. Meu pé estava tão inchado que não entrava no Croc's.

A medicação leva de 4 a 5 dias para fazer o efeito. Durante este período meu risco de morte continuava alto, mas diminuía à medida em que o tempo passava. Meu médico mesmo relatou: você teve muita sorte. "A sorte te protegeu até agora". Eu provavelmente acredito que foi outra coisa. Mas não deixa de ser muita "sorte" o fato de não ter morrido.

No 5.o dia de internação, quando já esperava ter alta, acordei meio "indisposto". Talvez culpa das bolachinhas amanteigadas que a namorada do meu irmão trouxe para me "alegrar". Mea culpa. Eu adoro doces, e depois de quase uma semana de abstinência eu acabei comendo praticamente a caixa inteira sozinho durante a noite. Relatei minha indisposição à enfermeira, o que bastou para ligarem o "alerta vermelho". Oxigênio e em menos de 5 minutos o médico já estava do meu lado fazendo perguntas e a enfermeira colhendo exames. Alarme falso. O exame mostrou que provavelmente era só uma indisposição estomacal. Nada de embolia.

Fiquei sob "vigilância" dos médicos e enfermeiros durante todos estes dias. Mas sou muito agraciado por poder estar vivo ainda para poder relatar esta estória. Hoje, terça-feira, tive alta. Meu risco de morte já deve estar próximo de somente 1%. Estou bastante cansado, continuo tendo que tomar comprimidos e a injeção dolorida, tenho que usar uma meia cinta-liga de alta compressão, minha perna ainda dói e não posso ficar de pé ou andando por aí. Mas estou extremamente feliz! Um grande agradecimento a todos os amigos que ficaram preocupados. Já deixo também o alerta: se sentirem dores na panturrilha sem muita explicação e um certo inchaço, corram para o angiologista antes que seja tarde! Pra mim, quase foi tarde demais.

sexta-feira, 20 de janeiro de 2012

Vídeo do Agile Tour 2011: Tirando o código a limpo



Obrigado ao Juliano Ribeiro pela gravação, codificação e disponibilização no YouTube!

Realmente acho que tenho que melhorar bastante como palestrante, mas tenham certeza de que a minha intenção sempre é a melhor possível.

quinta-feira, 19 de janeiro de 2012

Como assinar uma applet ou jar


Muitas vezes precisamos assinar o jar de uma applet para que o Security Manager da JVM permita a execução de determinadas ações fora da sandbox. Não é nada difícil, mas pra quem precisa de uma "receita de bolo", apresento duas opções: utilizando a linha de comando ou através do maven.

Através da linha de comando:

Através do maven, gere primeiro a sua keystore com o 1.o comando do gist acima no raiz do seu projeto. Depois pode executar o package normalmente:

sexta-feira, 13 de janeiro de 2012

Nossa maltratada e querida Língua Portuguesa


Gostaria de refletir um pouco sobre um "sofrimento" que me atormenta todos os dias. Sou uma pessoa da área tecnológica, e o aprendizado que tive da nossa língua pátria, o português, resume-se ao conteúdo acumulado até o ensino médio. Creio que isto me coloca no mesmo patamar que boa parte das pessoas.

O meu "tormento" é causado pela enorme (e infelizmente exponencialmente crescente) quantidade de material escrito de forma impressionantemente errada. Isto me faz pensar se o problema está em mim, que primo pela forma correta e "sofro" quando vejo essa infinidade de erros de grafia e concordância; ou se o problema está nos "outros" que tiveram o mesmo nível de educação que eu, e escrevem muito mal. Notem que quando digo "tiveram o mesmo nível de educação que eu" (que não é muito, como já apresentei) já excluo a parcela das pessoas com menor nível de instrução, já que não é razoável cobrar de alguém algo que não lhe foi ensinado.

Já abro aqui uma exceção e digo que considero normal o "internetiquês" utilizado em rápidas conversas e interações. O que me preocupa não são os "vcs", "t+" e "tbm"; mas sim o restante das palavras.

É um consenso que consideramos o nível de educação decrescente nos últimos anos. Mas vejo também pessoas mais velhas escrevendo errado (muitos professores, inclusive). A minha dúvida é: o aprendizado do português tem decaído nos últimos anos? Ou é a Internet que permite que esse enorme contingente de incultos se expresse de modo errado? Pois é possível que as pessoas escrevam realmente mal (desde sempre), mas como antes não era possível elas massificarem esta ignorância, simplesmente não se percebia.

A expressão "nem escrever direito sabe, imagine o resto" tem validade? Escrever errado invalida o argumento de alguém? É necessário escrever corretamente? Ou a forma correta da nossa língua virou item de museu?

Vale uma reflexão? Espero que sim...

terça-feira, 3 de janeiro de 2012

A hora e vez do NOSQL (Not Only SQL): Persistência Poliglota

A primeira vez que me deparei com o termo NoSQL imaginei que ele se referia a "No SQL": nada de SQL, uma ruptura com o nosso modo relacional de pensar em persistência. Como todo conceito revolucionário, causa muita resistência na maioria das pessoas por trazê-las fora da "zona de conforto".

Uma releitura necessária sobre o assunto me trouxe o acrônimo NOSQL como "Not Only SQL": não somente SQL. Esta sim, uma definição muito mais palatável e apropriada sobre o assunto. O "Not Only" pressupõe a convivência (pacífica, espero) entre tecnologias consolidadas e a inovação. Chamo de inovação, mas vale enfatizar que estas soluções já encontram-se num nível bastante avançado de maturidade.

NOSQL não é a solução para todos os problemas. Mas trouxe à luz da discussão uma máxima da computação que é "utilizar a ferramenta correta para o problema correto". Não consegui rastrear o autor original, mas esta citação é uma de minhas favoritas:
"A good algorithm is like a sharp knife - it does exactly what it is supposed to do with a minimum amount of applied effort. Using the wrong algorithm to solve a problem is trying to cut a steak with a screwdriver: you may eventually get a digestible result, but you will expend considerable more effort than necessary, and the result is unlikely to be aesthetically pleasing."
Ou numa tradução literal:
"Um bom algoritmo é como uma faca afiada - faz exatamente o que deve ser feito com uma quantidade mínima de esforço. Utilizar o algoritmo errado para resolver um problema é como tentar cortar um bife com uma chave de fenda: você eventualmente pode conseguir um resultado digerível, mas vai gastar muito mais esforço do que o necessário, e o resultado não será esteticamente agradável".
Como todo conceito "novo" muita coisa vai mudar antes de se consolidar, mas baseado na minha experiência no assunto, o que eu posso recomendar é:
  • Se os seus dados são homogêneos, com poucos relacionamentos entre entidades e numa grande quantidade: use um banco de dados. O modelo relacional foi feito pra isso.
  • Se os seus dados possuem muita variação entre um e outro (o que num banco de dados implicaria em muitas colunas vazias ou em muitos relacionamentos com outras tabelas): use uma base de documentos como o MongoDB.
  • Se os seus dados possuem muitos relacionamentos com outras entidades (com possível necessidade de geolocalização): use uma base de grafos como o Neo4j.
  • Se os seus dados são do tipo chave-valor (key-value) e você precisa computar grandes quantidades (voláteis) desses dados com alto desempenho: use uma base de dados chave-valor em memória como o Redis.
  • Se os seus dados são do tipo chave-valor (key-value) e você precisa persisti-los: use uma base de dados chave-valor persistente como o Riak.
Farei uma menção honrosa para as situações em que você precisa de uma base de dados confiável, de altíssimo desempenho e transacional: use o Prevayler ou o Disruptor para prevalência de objetos.

Vale ressaltar que a persistência poliglota pressupõe a coexistência destas diferentes bases de dados na mesma aplicação. Avalie e considere a utilização de mais de uma base de dados se for adequada ao seu problema. Mas não caia na tentação de "vou usar o XXX porque é bacana". É o mesmo pecado de se utilizar um Design Pattern só porque ele é "bonito". Tem que resolver um problema.

Todo essa excitação ao redor do NOSQL também está relacionada, claro, ao conceito de BigData. Todas estas bases de dados alternativas foram construídas com a premissa de tratar imensos volumes de dados que bancos de dados relacionais não estão preparados para lidar.

Avaliem todas estas novas alternativas e estejam preparados para, no problema certo, utilizarem a base de dados certa. Boa sorte!