Bruno Pereira

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.

No mundo de software nós freqüentemente encontramos ferramentas, frameworks e outros ítens que nos abstraem alguns conceitos, e nos dão uma maneira de trabalhar “mais alto nível”.

Nessas situações, é comum ouvirmos que essa abstração é “transparente para o desenvolvedor”, “transparente para o usuário”, ou “transparente alguma coisa”. Essa terminologia abstrai (usar esse termo aqui foi irresistível ) dois tipos de abstração bem diferentes, então vou falar um pouco sobre os dois tipos de abstração encontrados em software, com algumas opiniões sobre ambos.

O que eu chamo de Abstrações Transparentes são as que te oferecem uma forma de trabalho num nível mais alto, mas te permitem ver (é transparente afinal de contas) o que está por baixo dos panos sem tanto esforço. Um exemplo disso eu diria que é o que acontece no Struts e no Spring MVC.

Frameworks web deste estilo tentam te dar um desenvolvimento mais produtivo, sem que você tenha que se preocupar com tudo que está envolvido no processamento de requisições e respostas HTTP. Entretanto, o fluxo de processamento da requisição e resposta é bem intuitivo do ponto de vista do que está acontecendo na interação do usuário com o servidor. E se você quiser manipular a requisição e a resposta, você conseguirá facilmente, sem “burlar” a proposta do framework.

O que eu chamo de Abstrações Opacas são as que também te oferecem uma forma de trabalho num nível mais alto, mas te escondem bem mais o que está acontecendo por baixo dos panos. O objetivo é de fato que você não precise saber dos detalhes, e não queira se meter com eles. Um exemplo disso é o que acontece no JSF e no Wicket, e também no Aqualogic Service Bus.

O JSF e o Wicket oferecem um paradigma de desenvolvimento web diferente do tradicional modelo “Request/Response”. Eles têm um modelo componentizado, no qual a requisição e a resposta HTTP ficam bem encapsulados, e as suas interações com o usuário devem ser totalmente focadas nos componentes. A idéia é que você realmente não veja o que está rolando por baixo dos panos, e não se envolva mesmo com os detalhes.

Eu pensei um pouco sobre isso hoje mais cedo, mexendo com o Aqualogic Service Bus. Troquei umas idéias sobre o que ele faz quando ocorre mais de uma chamada a mais de um web service dentro da mesma transação, e na hora eu pensei: “Ainda bem que essa abstração é opaca!” :)  A ferramenta é sensacional e cuida de muitos detalhes cabeludos do trabalho com WS-* sem que você precise fazer na mão.

Sobre os dois tipos de abstração, a decisão de qual é mais adequado varia muito com a situação e com gostos pessoais. Em relação a frameworks web, eu tenho me dado muito melhor com Abstrações Transparentes, pois eu quero ver os detalhes e quero ter controle sobre eles.

Em situações em que não queremos controlar os detalhes do que está sendo feito, as Abstrações Opacas são muito boas, pois nos poupam esforços. É interessante saber em cada situação qual tipo de abstração você quer, porque a sua escolha de tecnologias e ferramentas será traçada com isso em mente.

Então na próxima ver que alguém disser que alguma coisa é “transparente”, veja logo se é Transparente ou Opaca

A documentação do Ibatis não explica adequadamente como funciona o mecanismo de Lazy Load do framework, e como este conhecimento é importante e útil, resolvi explicar brevemente por aqui.

Para habilitar o mecanismo de lazy load, é necessário declarar o elemento settings no sql-map-config, como o exemplo a seguir:

<sqlMapConfig>
	<settings
		cacheModelsEnabled="true"
		enhancementEnabled="true"
		lazyLoadingEnabled="true"
		maxRequests="128"
		maxSessions="10"
		maxTransactions="5"
		useStatementNamespaces="false"
		defaultStatementTimeout="5"	/>
</sqlMapConfig>

Nestas configurações, dois elementos são importantes. O parâmetro lazyLoadingEnabled habilita globalmente o uso de lazy loading no framework. Sem declarar esse parâmetro, todas as buscas serão eager, possivelmente gerando uma grande quantidade de acessos ao banco, dependendo da estrutura de classes.

O outro parâmetro importante é o enhancementEnabled. Com ele habilitado, o Ibatis usa proxies cglib no mecanismo de carregamento das classes, e ele aumenta o escopo do carregamento lazy.

Com o enhancement desligado, serão carregadas de forma lazy apenas as coleções de um objeto, como a lista de produtos de um pedido. Com o enhancement ligado, é feito também o carregamento lazy de atributos complexos de um objeto, como o endereço de entrega do pedido.

Este mecanismo é bem simples de utilizar, e ajuda bastante, pois não precisamos tratar disso no código da aplicação.

Eu estava pensando em começar a estudar espanhol no começo do ano que vem, quando tive a idéia de procurar por gramáticas de espanhol e algum material online para aprender a língua.

Acabei descobrindo o Livemocha, um site com material online para aprendizado de línguas que faz uso de redes sociais. A idéia é excelente, e eu estou gostando demais do site. Há um vasto material para estudo, para leitura, escrita e conversação.

As línguas oferecidas no site incluem inglês, espanhol, português, francês, italiano, alemão, mandarim, japonês, russo e mais algumas línguas. O site teve uma grande sacada de uso de redes sociais, que é a revisão de exercícios de usuários feita por outros usuários. Os exercícios “automatizáveis” vocês consegue ver se acertou na mesma hora. Já coisas mais complicadas como escrita de textos e a pronúncia, você submete a sua resposta no site, e algum usuário terá que revisá-la.

Por exemplo, eu estou estudando espanhol, e falo português nativamente e inglês fluentemente. Eu posso por exemplo ter amigos lá no site que saibam espanhol e queiram aprender inglês ou português, e então nós podemos nos ajudar. Da mesma forma, qualquer um pode interagir com outras pessoas, ajudar e ser ajudado no estudo de línguas.

Existem inúmeras redes sociais nas quais o foco é conhecer pessoas, ver fotos e bisbilhotar a vida alheia, mas o Livemocha é o site que eu conheço que fez o uso mais inteligente das redes sociais.

Estou empolgadíssimo com o site e com certeza ele me ajudará bastante a aprender espanhol e francês, que são as línguas que eu pretendia estudar em breve. Se você também quer estudar línguas estrangeiras, não deixe de conferir o Livemocha, é uma excelente oportunidade de aprender rápido e sem gastar nada.

Depois de mais de 2 anos e meio, hoje é o meu último dia alocado na Globo.com. A partir de segunda-feira (01/12) já estarei alocado em um novo projeto, também nas Organizações Globo, mas desta vez na Globosat.

Eu levarei várias boas lembranças, de um período que foi muito positivo para mim. Comparando a minha experiência e maturidade agora com o momento em que entrei na Globo, a diferença é enorme. Tive a oportunidade de trabalhar com profissionais de altíssimo nível e em projetos de enorme importância técnica e de negócio. Tive também a sorte de atuar em áreas com as quais tenho muita afinidade e interesse, o que ajuda bastante no envolvimento de qualquer profissional.

Quando cheguei à Globo pude vivenciar uma situação nova para mim. Passei a ter a satisfação de ir trabalhar feliz todos os dias. Atuando em um ótimo ambiente de trabalho no qual o software fica em primeiro plano. Com o benefício extra de saber que meu trabalho teria a visibilidade do maior portal de internet da América Latina.

Além disso, posso dizer que vivi muitos progressos dentro da empresa. Acompanhei o surgimento de produtos como o G1, o 8P, o Futpedia e o Musas, além de um progresso fantástico na plataforma de Vídeos. Acompanhei de perto a produção interna para eventos como a Copa de 2006 e as Olimpíadas de Pequim. Poder vivenciar esse crescimento da empresa foi muito interessante.

Também me deixou muito feliz a abordagem da Globo.com em relação a Open Source. Quando cheguei na empresa, todo mundo usava Windows, o servidor de aplicações mais usado era o Weblogic e embora já existisse o uso de muitos softwares open source, isso não fazia parte da cultura da empresa.

Hoje em dia a relação da Globo com Open Source é excelente. Todos apostam no uso de Open Source, os desenvolvedores todos usam Linux, nossos servidores de aplicação são quase todos Open Source, já há vários projetos com banco de dados open source, e a maturidade dos profissionais em relação a Open Source aumentou muito. Pra mim isso foi muito gratificante. Durante mais de 1 ano e meio eu tive a satisfação de trabalhar full time com Linux, e acredito que consegui contribuir um pouco também para que outros utilizassem de forma produtiva.

Ainda mais importante do que a relação com open source foi a adoção de metodologias ágeis. Quando cheguei na Globo.com a maioria dos projetos era no estilo Waterfall. Não é necessário explicar com detalhes aqui, mas era muito perceptível que os projetos não andavam na velocidade que poderiam.

Aos poucos o Scrum começou a ser utilizado, e alguns meses depois isso desencadeou uma série de mudanças positivas na empresa. Este ano inteiro eu trabalhei em um time Scrum, e foi uma experiência excelente. Passamos a ter uma equipe multi-disciplinar, tendo contato diário com um designer, com um arquiteto de informação e um desenvolvedor client-side. Isso foi muito benéfico para mim. Acompanhar de perto o trabalho de profissionais de outra especialidade me ensinou muito sobre a atuação deles, e claro, aprendi muito sobre client-side e passei a gostar disso, o que é fundamental para qualquer desenvolvedor web.

Ao longo do ano nós amadurecemos muito a nossa forma de trabalho, e a utilização de práticas ágeis foi fundamental nisso. Claro que ainda existem arestas a serem aparadas e pontos que precisamos melhorar, mas sem dúvida nosso time evoluiu muito esse ano.

Tecnicamente o ano foi muito bom para mim também. Participei de projetos muito interessantes como a migração para o e-mail no Google, onde atuei diretamente na integração entre as empresas. Outros projetos muito bacanas foram o novo cadastro e a nova Central do Usuário.

O projeto de integração com o Google foi o primeiro projeto crítico no qual utilizamos REST, e como tivemos muito sucesso, todas as nossas aplicações já estão usando REST, e falta mais um pouquinho só para que nossa arquitetura seja 100% migrada de comunicações via EJB para REST. Aprendi muuuuuuuito nesse processo, foi uma experiência excelente.

Os projetos do Cadastro e da Central foram muito interessantes do ponto de vista de produto e do ponto de vista de desenvolvimento. As 2 aplicações foram desenhadas para terem módulos dinâmicos de cadastro. Isso permite que cada produto tenha o seu próprio template de cadastro, e as informações requisitadas dos usuários são configuradas por uma ferramenta de administração.

O desenvolvimento destas aplicações exigiu um trabalho muito interessante de modelagem e desenvolvimento, com muitas refatorações até que chegássemos no modelo final. Aprendi muito também com esses dois projetos.

Mas nem só de software vive uma pessoa :)  Nesse meu período na Globo.com eu conheci muitas pessoas fantásticas e fiz muitos amigos. O ambiente de trabalho e as pessoas da Globo.com são um dos maiores motivos para que tenha sido tão legal trabalhar na empresa, e com certeza vou sempre me lembrar disso.

Meu time de desenvolvimento esse ano é muito bem entrosado e positivo. Tacaram na mesma mistura 2 cariocas, 1 capixaba, 1 prudentino e 1 paraense, e deu muito certo Gostei muito da experiência, e vou com certeza sentir falta desses picaretas

Estou indo agora para um novo projeto na Concrete, atuando na Globosat. O pouco que sei do projeto até agora me pareceu muito interessante, e essa mudança de cliente é fundamental para as minhas perspectivas dentro da empresa. Torço muito para essa minha nova empreitada seja tão interessante e produtiva como meu período dentro da Globo.com, e claro, espero contribuir bastante para o sucesso da Concrete em um novo cliente e novo projeto.

No final das contas, sinceramente espero que eu tenha contribuído tanto com a Globo.com quanto ela contribuiu para a minha carreira e o meu amadurecimento. Foram 2 anos e meio sensacionais e tenho certeza de que a empresa continuará no seu caminho de enorme sucesso, que pude acompanhar neste período.

Chegou então o momento de dizer Adeus Globo.com, foi um grande prazer para mim!

Eu considero a Microsoft bem fraca em termos de atuação na Web, mas achei bem legal uma iniciativa recente deles.

Foi anunciado recentemente o Microsoft Office Web. Embora não seja nada inovador, pois o Google Docs já existe há algum tempo, eu gostei dessa novidade. O serviço ainda não está disponível, mas um FAQ sobre ele já foi publicado.

Achei interessante que o Office Web suportará o Firefox e o Safari além do IE. Além disso, usuários de qualquer sistema operacional poderão usar o serviço, contanto que tenham um dos browsers suportados. Quando eu soube que lançariam o Office Web, a primeira coisa que veio à minha cabeça foi que só funcionaria com o IE e que seria necessário instalar algum add-on que só funcionasse no Windows. Saber que isso não é verdade foi uma ótima surpresa.

Eu utilizo com freqüência o Google Docs, e gosto muito da praticidade do serviço. A facilidade de compartilhar documentos e editá-los de forma simultânea é ótima. Desde que comecei a usar o Google Docs, eu raramente uso o Open Office ou Word. Praticamente só uso um dos 2 quando eu tenho que escrever alguma coisa com preocupações em relação a estilos e formatação. O Google Docs é bem limitado neste sentido, infelizmente.

Com o Office Web, provavelmente o suporte a estilos e formatação será melhor que no Google Docs, e isto pode me estimular bastante a usá-lo e aposentar o OpenOffice e Word, e viver ainda mais na Web.

Algumas conseqüências bacanas podem surgir deste novo serviço. A competição entre o Office Web e o Google Docs provavelmente trará muitos benefícios aos usuários finais, que deverão ter serviços web gratuitos e de ótima qualidade.

Além disso, o Office Web fará a Microsoft sofrer um pouco com as incompatibilidades entre os browsers. Suportar as mesmas funcionalidades no IE, Firefox e Safari dará um certo trabalho. Talvez isso desperte uma iniciativa da Microsoft de consertar o IE, e fazer com que os desenvolvedores web em geral tenham menos trabalho com essas incompatibilidades.

Se o Office Web trouxer essas 2 mudanças, terá sido uma das melhores iniciativas que a Microsoft já teve. Torço para que esse projeto ganhe força e que todos possamos usufruir dos benefícios

Li recentemente uma matéria que fez um estudo interessante sobre a situação atual do uso de algumas das principais distribuições Linux. O estudo não utilizou uma metodologia exatamente científica, mas as conclusões não deixam de ser válidas.

O estudo observa uma tendência de que o Ubuntu seja cada vez mais a cara do Linux. Na verdade parece que a “marca” Ubuntu está com um progresso muito mais vigoroso do que a “marca” Linux, e provavelmente em breve a “marca” Ubuntu será a mais forte das duas.

Eu particularmente acho isso muito bom. Durante muitos anos o percentual de uso das principais distribuições Linux foi muito pulverizado. Havia uma gama enorme de opções, e não havia uma concentração tão forte em torno de nenhuma delas. É verdade que o Red Hat teve uns momentos muito bons até a versão 9 (última versão gratuita), mas depois que eles mudaram o modelo comercial, perderam muitos usuários caseiros.

Com a concentração em torno do Ubuntu/Kubuntu, acho que as chances de sucesso do Linux no desktop de usuários comuns aumentam muito. Um facilitador muito importante no rápido crescimento do Windows foi que muitas pessoas o conheciam, e então eram capazes de orientar novos usuários e ajudar na solução de problemas de forma rápida. Isso é muito mais fácil quando se tem um sistema operacional e interfaces de usuário com o mesmo padrão.

Se tivéssemos a grande maioria dos usuários Linux usando Ubuntu/Kubuntu, ficaria muito mais fácil que novos usuários tivessem facilidade em encontrar ajuda. Isso diminuiria muito as barreiras de entrada no uso do Linux em computadores caseiros por pessoas leigas.

É claro que continuarão existindo outras distribuições, mas com um foco direcionado em públicos específicos, ou finalidades específicas. Não há nada de errado em ter muitas opções, mas a adoção do Ubuntu como padrão facilitaria muito as coisas.

Uma coisa que eu não consigo entender é o que fazem algumas montadoras de computadores no Brasil. Já cansei de ver computadores com Linux à venda em supermercados e lojas em geral. Isso é legal de se ver. Porém, cada fabricante diferente (e são vários) usa uma distribuição diferente, e pouco comum. Isso com certeza dificulta muito o aprendizado de novos usuários Linux, e o que acaba acontecendo é que as pessoas mais humildes compram cópias piratas do Windows e instalam em suas máquinas que vieram com Linux.

Será que não seria mais fácil a Itautec, Positivo, CCE, etc etc etc, simplesmente usarem o Ubuntu/Kubuntu e customizarem só uma ou outra coisinha? Porque instalar umas distribuições que ninguém nunca viu, e que dificultam muito mais a vida dos usuários?

Será que isso é para conseguir vender suporte? Se for, acho que isso é um tremendo tiro no pé, pois as empresas correm um enorme risco de que as pessoas nem comprem os seus produtos ou então simplesmente troquem o Linux que veio instalado por um Windows piratão.

O sucesso do Linux no desktop do povão pode ser muito ajudado pelo sucesso do Ubuntu, então eu fico muito feliz com o crescimento vigoroso que este vem tendo. Só torço para que as montadoras de PCs nacionais acordem e passem a disponibilizar o Ubuntu em vez de umas distribuições sem-vergonha que ninguém conhece e que ninguém vai usar.

Ajude o Linux e o Open Source no Brasil. Use e divulgue uma distribuição que até o nosso presidente saiba falar! Ubuntu!