Bruno Pereira

Após um tempo exagerado lendo somente livros técnicos, retomei meus antigos hábitos de leitura. Estou acabando meu terceiro livro de Dostoiévski, “Os Irmãos Karamazov“.

Estou gostando muito do livro, e quando acabar de ler eu escreverei uma revisão aqui. Lamentavelmente esse é o primeiro livro não-técnico que estou lendo desde que comecei com o blog, mas eu pretendo comentar aqui sobre todos os livros que eu ler e gostar.

Hoje aproveitei ótimos descontos do Submarino, e pela bagatela de R$ 56 com frete grátis, comprei 7 livros que pretendo ler em 2009. O primeiro que lerei é um que eu já queria ler faz tempo: “Assim Falou Zaratustra“, de Friedrich Nietzsche.

Comprei outros 3 de Nietzsche, 2 de Julio Verne e um de Oscar Wilde. São esses livros a seguir.

“O Anticristo“, Nietzsche.

“A Gaia Ciência“, Nietzche.

“Para Além do Bem e do Mal“, Nietzsche.

“Viagem ao centro da Terra“, Julio Verne

“Volta ao mundo em 80 dias“, Julio Verne

“O Retrato de Dorian Gray“, Oscar Wilde

Quem já tiver lido algum desses livros e quiser deixar suas opiniões, vou gostar de conhecê-las

Discussões sobre processos e metodologias de software são um assunto recorrente hoje em dia. De 2 anos para cá, a situação vem mudando bastante, e muitas empresas estão adotando metodologias ágeis, destacadamente o Scrum.

Eu gosto muito de várias das práticas do Scrum, como também gosto de práticas de XP. O que eu não gosto muito é da necessidade de algumas pessoas de serem “doutrinadas”.

Quando aprendemos alguma ferramenta, metodologia, prática ou qualquer outra coisa, é normal ficarmos empolgados quando é algo bem feito. A ferramenta/metodologia/prática pode ser ótima para várias situações que encontramos com freqüência. É ótimo que seja assim, pois nosso estudo será recompensado com sucesso em problemas reais e melhores resultados nos nossos projetos.

O que me incomoda é ver posturas xiitas, querendo adotar metodologias como Dogmas. “Você quer fazer o quê?? Isso é contra as práticas do Scrum! Você será punido dolorosamente!”

Por falar em Dogma, uma cena do filme homônimo me veio à cabeça, e é muito interessante. Nesta cena o Matt Damon (que é um anjo renegado no filme) fica conversando com uma freira, e renega várias das crenças às quais a freira vivia apegada há anos.

Como ele era um anjo renegado, é claro que ele conhecia muito mais da doutrina católica do que a freira. Ele conhecia muitos detalhes que estavam por trás do que a freira havia estudado durante décadas, e então ele usa uma argumentação convincente e cheia de evidências para convencê-la de que ela havia sido enganada durante todo este tempo. No final ele comenta com o Ben Affleck (outro anjo renegado) que fazer isso é o seu hobby. Derrubar crenças e dogmas. Por favor ignorem qualquer conotação religiosa deste trecho, só tomei esse exemplo porque ele é semelhante ao que vemos no mercado de software.

Isso não acontece só com metodologias. Outro tema polêmico são as certificações. Não sou favorável a nenhum dos extremos. Eu não acho que possuir certificações indique precisamente se um profissional é bom ou não. Conheço profissionais com várias certificações que eu não colocaria no meu time de forma algum. Conheço também profissionais excepcionais que não ligam para qualquer certificação, e não correm atrás de nenhuma delas.

Um bom exemplo desse último caso é meu amigo e guru Bairos, que é um dos profissionais que eu mais respeito tecnicamente. Eu confiaria nele nos projetos mais críticos e difíceis, e já tive várias demonstrações de como ele se sai nessas situações. Talvez ele até tenha uma certificação de Programmer antiga, mas não sei nem se ele tem alguma. Entretanto, aposto todas as minhas fichas nele antes de procurar qualquer portador de múltiplas certificações.

Agora, já vi argumentos do lado extremamente oposto, como “Você faz certificações?? Ah, você é fraco!”. Essa postura é extremamente imatura na minha opinião.

Conhecimento e sabedoria são sempre valiosos. Embora as certificações não impliquem que um profissional é bom ou não, o estudo para obter as certificações com certeza pode ser muito válido. Eu tenho as certificações de Java Programmer, Java Associate, Web Component Developer e recentemente passei na 1a prova da certificação de arquiteto Java. Para as certificações de Associate e de arquiteto, eu praticamente não estudei, e não aprendi muitas coisas que me fossem úteis profissionalmente. Já os meus estudos para as provas de programmer e web component foram muito positivos. Aprendi muitas coisas úteis para mim profissionalmente e posso afirmar que me tornei um desenvolvedor mais produtivo e eficiente depois de estudar para essas provas.

Quando vamos aprender que o importante é a caminhada?? Não é o fato de ter uma certificação ou não que importa mais. Se você evoluiu como profissional estudando para uma certificação, é isso que importa.

Da mesma forma, ferramentas/metodologias/processos de software não podem ser dogmas que defendemos com unhas e dentes. O ativo mais valioso de um profissional são as suas idéias, seu conhecimento, sua sabedoria.

Conhecer tecnologias, metodologias e idéias diferentes é sempre positivo. Mesmo que você descubra que na maioria dos casos aquilo que você acabou de conhecer não vai ter tanta aplicação prática, se você amadureceu e aprendeu na caminhada, isso é o mais importante. Não se prenda a dogmas, e continue caminhando e amadurecendo.

Hoje o Sacha Labourey (CTO da JBoss) publicou um post interessante sobre as dificuldades que a Sun vem encontrando, em especial com seu modelo de negócios open source. Como eu já pensei um bocado sobre isso e conversei com algumas pessoas, vou deixar aqui algumas opiniões.

Na minha opinião, a Sun fez e vem fazendo um excepcional trabalho mantendo a plataforma Java como um todo. O problema todo está no contexto que girou em torno disso.

Em um determinado momento a Sun lutava bastante contra a Microsoft e suas soluções Windows/.NET, e de fato parecia que as empresas seriam adversárias. O que ocorre é que a Sun gastou tantas energias combatendo a Microsoft que não dedicou o esforço necessário para conquistar espaço dentro do próprio mercado Java.

O Glassfish V2 foi o primeiro bom servidor de aplicações da Sun, mas ele chegou bem tarde. Muito antes a BEA e a IBM já tinham um vasto portfólio de produtos Java Enterprise, e servidores de aplicação bem melhores do que o antigo Sun Application Server. Com isso, mesmo com o enorme sucesso da plataforma Java, a Sun não estava muito bem posicionada no mercado de software.

Creio que em decorrência deste primeiro problema (a falta de um bom app server), veio o problema que eu acho o mais grave. Na minha opinião o que fez mais falta à Sun é um bom modelo de serviços em torno da plataforma que ela desenvolveu tão bem. A Sun tem muitos grandes engenheiros, mas não conseguiu traduzir isso em muito lucro com Java. Penso que um modelo de serviços semelhante ao da IBM teria sido adequado à Sun, mas para isso eles precisariam de um portfólio de produtos melhor.

O grande (e bem-sucedido) esforço no desenvolvimento da plataforma Java consumiu energias que poderiam ter sido aplicadas na construção de uma linha de produtos mais rica, e com isso o sucesso do Java acabou drenando muito da saúde da Sun.

Mais recentemente a Sun tentou mudar a sua estratégia, e passou a abraçar ainda mais o modelo open-source. Embora isso tenha sido muito bem recebido pela comunidade de desenvolvedores, não podemos dizer que essa mudança tenha trazido mais sucesso para a empresa.

Eu tenho a clara impressão de que a Sun abraçou este modelo sem ter muita noção do que a esperava, mas talvez a sensação fosse de que não havia uma outra alternativa óbvia. A verdade é que a Sun está há anos lutando, mas sem encontrar a estratégia correta. O modelo de negócios em torno de open source foi mais uma tentativa da empresa, mas não estou vendo muitas perspectivas da Sun conseguir deste modelo as receitas necessárias para cobrir seus custos.

Eu fico triste por essas dificuldades da Sun, pois eles fizeram um excelente trabalho desenvolvendo a plataforma Java, mas isso custou a própria saúde da empresa.

E o que poderá vir em conseqüência? Difícil dizer, mas me parece inevitável que a Sun seja comprada por um player de maior porte, como a HP ou a SAP.

Como a Oracle agora é um concorrente direto da SAP em várias linhas, e a SAP começou a investir em Java, talvez faça sentido que a gigante alemã compre a Sun.

Quanto à HP, seria um movimento muito mais coerente do que a compra da EDS, que ocorreu esse ano. Comprando a Sun, a HP teria a stack completa, com hardware HP, sistema operacional e middleware da Sun, e serviços provenientes da EDS. Isto a deixaria em situação semelhante à da IBM, e acho que faria sentido nesse contexto atual.

Não sei qual será o futuro da Sun, mas sinceramente torço muito para que seja próspero, pois seu legado de contribuições ao cenário mundial de software é valioso demais para que a empresa tenha um final agonizante.

À primeira vista a idéia de um sujeito desengonçado dançando em vários lugares do mundo não parece algo muito interessante. Entretanto, ao assistir os vídeos deste sujeito abaixo dançando em muitos lugares lindos do mundo, me deu uma ótima sensação e muita vontade de conhecer vários desses lugares.

Coloquei o vídeo de alta qualidade, pois a qualidade normal é muito ruim. O vídeo demora para carregar, mas vale muito, muito a pena. Quem quiser saber mais sobre as viagens do sujeito, pode dar uma olhada no site dele. Have fun!

Ontem fui na palestra do Nico Steppat (da Caelum) sobre JBoss Seam no RioJUG. A palestra foi interessante, mas infelizmente não deu tempo pra ele mostrar tudo, e eu não vi muita coisa além do que eu já sabia.

Entretanto, um ponto destacado por ele me deixou ligado em um recurso interessante. Como ele mencionou, o Seam busca ajudar bastante em aplicações que precisam de estado, como um carrinho de compras. A proposta é de ser uma camada de ligação entre componentes stateful do JSF e EJBs stateful.

JSF não é dos frameworks que eu mais goste, mas realmente essa característica utilizada pelo Seam faz sentido em alguns dos projetos que eu participei. Por exemplo, alguns casos de uso envolvem fluxos com algumas telas, e é necessário guardar os dados ao longo do fluxo de um caso de uso. Entretanto, muitas vezes não é necessário que os dados permaneçam disponíveis para outro caso de uso, então o escopo de sessão é maior do que esta necessidade específica.

Este escopo do qual estamos falando é o escopo de conversação, e eu já sabia que o JSF oferecia algo neste sentido, mas eu não tinha ainda parado pra pensar muito sobre isso. Os dados neste escopo têm o ciclo de vida igual ao de uma conversação, que mapeia bem o fluxo de um caso de uso.

No caso do Seam, ele faz uso deste escopo de conversação para 2 coisas principais. Ele consegue manter os dados vivos por vários requests sem usar o HttpSession, o que é positivo, pois sabemos que é difícil escalar o HttpSession. Além disso, ele resolve o problema de casos em que o usuário usa o back do browser e submete novamente os dados referentes a um fluxo que ele já havia concluído.

No último projeto que eu participei com formulários de mais de uma etapa, consegui resolver esse problema do back do browser com uma solução customizada simples. Quando eu criava as etapas eu criava um hash aleatório e associava a cada uma das etapas que o usuário fosse preencher. Dentro do formulário eu colocava um campo hidden contendo esse hash, e quando o usuário submetesse o formulário conseguiria identificar qual etapa ele estava preenchendo. No final da “conversação” eu limpava esses hashes das etapas que o usuário preencheu, e caso ele tentasse submeter novamente os dados, o hash não estaria mais presente e o submit não seria aceito.

Entretanto, neste projeto eu colocava os dados no HttpSession e destruía o HttpSession no final do fluxo. Nesta situação seria mais interessante usar esse escopo de conversação, pois eu deixaria de pendurar dados no HttpSession e pouparia recursos do servidor.

Felizmente eu verifiquei ontem mesmo que o Spring Web Flow também suporta esse escopo de conversação, e então fica para mim o dever de casa de conhecer o Web Flow e passar a utilizar essa abordagem. O Spring MVC é atualmente o meu framework web Java preferido, e foi ótimo saber que eu não precisaria de JSF para ter uma solução para este problema

Hoje tivemos um belo exemplo de como um jogador de futebol pode ser mercenário. Já em final de carreira e depois de passar vários meses treinando no Flamengo e falando do seu amor pelo clube e mais um monte de farofadas, Ronaldo “Fenômeno de Mercenarismo” foi contratado pelo Corinthians.

Imagino que a opinião da Nike tenha pesado bastante nessa decisão, já que ela patrocina o Corinthians e também o nosso amigo mercenário. Agora, me pergunto: precisava dessa palhaçada toda? O cara deve ter um patrimônio de uns 200 milhões de dólares e ganha uma grana absurda mesmo sem jogar. Já está em final de carreira e com certeza suas maiores glórias já estão distantes no passado. Vai fazer 33 anos em 2009, já teve uns 37 problemas nos joelhos e não tem mais mercado na Europa.

Será que um sujeito nessas condições não pode se dar ao luxo de escolher jogar no que ele diz ser seu time de coração?? Cacete, que ele ganhasse 1 milhão de reais a menos no ano que vem pra jogar no Flamengo (o que eu duvido), será que isso ia fazer falta pra esse cara?? Com o tamanho da torcida do Flamengo, ele ganharia uma grana violenta de marketing e venda de camisas. Nem precisava brilhar muito em campo pra ganhar grana não.

Então, se era pra fazer essa cretinice, porque fazer aquela cena toda durante meses no Flamengo, treinando com o time, indo aos jogos e jurando amor ao clube?? Esse cara não sabe o que é amor por clube nenhum, ele sabe o que é ganhar dinheiro, só isso.

Depois de uma palhaçada dessas, acabou completamente qualquer respeito e admiração que já tive por esse jogador. Quero mais é que você vá gastar a fortuna que já acumulou e suma de uma vez por todas do Flamengo.

Com a minha mudança de alocação da Globo.com para a Globosat, continuo trabalhando bastante com integração de aplicações, mas agora com um ferramental e paradigmas diferentes.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.