Na última quinta-feira eu fui na palestra do Bruno Borges no RioJUG, sobre Apache Camel. A palestra em si foi bem legal, pois eu já conhecia um pouco do Apache Camel e pude ver algumas coisas a mais. Mas o ponto específico que eu quero abordar é um comentário que o Bruno fez, que diverge da minha postura em relação a open source.

Ele comentou que tenta sempre utilizar produtos Apache, evitando produtos open source que tenham vínculo com alguma empresa, como JBoss, SpringSource, entre outras. Não me recordo do motivo exato, mas a razão principal que ele explicou é o fato da Apache Software Foundation ser uma fundação composta de pessoas, em vez de ser uma empresa com fins comerciais.

Eu tenho uma postura diferente da dele em relação a open source. Eu gosto muito e tenho um respeito enorme pela fundação Apache. Já usei inúmeros produtos Apache e certamente continuarei usando por muito tempo. Entretanto, já usei vários produtos JBoss e vários componentes do Spring, e acho muito importante e saudável a existência dessas empresas.

A história do movimento open source tem vários elementos “românticos” e “filosóficos”, e essa característica ainda é muito presente em várias comunidades hoje em dia. Entretanto, com o crescimento do Linux, Java, Python, Ruby e outras tecnologias, existe hoje um mercado enorme de trabalho e negócios em torno do software livre.

O surgimento desse mercado naturalmente trouxe a participação de muitas empresas que vivem de software livre atualmente. Sei que há pessoas que enxergam open source e capitalismo como coisas opostas, mas na minha opinião essa visão é míope. Open source é um modelo de desenvolvimento de software e oferta de produtos e serviços. A busca do lucro é o que move nossas empresas, e isso não é diferente para quem atua com software livre.

O surgimento das empresas profissionais open source foi importantíssimo para o amadurecimento das tecnologias e dos profissionais. Se o movimento open source continuasse restrito ao meio acadêmico, o nível de competição no mercado de software seria muito menor, e o avanço tecnológico teria sido bem mais lento.

Além disso, minha postura profissional é de tentar sempre entregar os melhores resultados para os clientes e para a empresa em que trabalho. Em algumas situações pode ser mais adequado usar open source, em outras pode ser necessário usar software proprietário. Temos que nos adequar às necessidades dos clientes, em vez de esperar que eles se adeqüem às nossas preferências.

No meu ponto de vista, empresas como JBoss e SpringSource contribuíram e contribuem muito no processo de profissionalização do software livre. A existência delas criou um mercado fortíssimo em torno do software livre, e eu só tenho a agradecer por isso.

A primeira delas diz respeito à diferença de filosofia entre o Ubuntu e o Debian. Eu uso Kubuntu em casa há quase 3 anos. É a minha distribuição preferida, depois de já ter usado várias desde 2003, quando comecei a usar Linux em casa.

Na sexta-feira chegou na Concrete o meu laptop para uso diário, um Dell Vostro 1510, e nesse fim de semana eu instalei nele o Debian Lenny e configurei tudo que eu precisava para já começar a trabalhar com ele na segunda-feira. Instalei o Debian porque ele foi definido como distribuição padrão da empresa, então tive que abrir mão do Kubuntu.

O Kubuntu é baseado no Debian, então a grande maioria das coisas não muda entre os 2. Contudo, como diz o ditado: “O diabo está nos detalhes”. As notáveis diferenças entre o Debian e o Kubuntu são as coisas que o Kubuntu facilita demais, como configuração de conexão wireless, drivers multimídia do teclado, entre outras coisas. Nesses detalhes você consegue perceber claramente a diferença de cultura, pois o Debian tem uma postura quase religiosa quanto ao uso de softwares que não sejam “totalmente open source”.

Já no Ubuntu, a postura é de usar open source ao máximo, mas facilitando a vida dos usuários. Assim, quando você precisa de um driver ou componente proprietário, o Ubuntu te avisa que não é totalmente open source, mas já prepara tudo para que você tenha o mínimo de aborrecimento. Isso faz toda a diferença, pois muita gente (como eu) quer usar um desktop Linux que “simplesmente funcione”.

Quando eu comecei a usar Linux em casa eu gostava de fuçar e conhecer cada detalhe, como aprendizado mesmo. Isso foi ótimo para mim, e certamente me ajuda muito profissionalmente. Porém, hoje meu foco é outro, e eu quero que minha máquina “simplesmente funcione”, sem ter que estudar para configurar coisas cotidianas. O Ubuntu ganhou uma fatia enorme dos usuários Linux porque oferece isso. Já o Debian te oferece ricas aulas sobre o “pensamento verdadeiramente open source” e sobre os detalhes das entranhas do Linux. Mas a contrapartida é que você vai ter que estudar muito pra fazer coisas que no Ubuntu são triviais.

Cada um tem a sua própria visão e postura sobre open source, e devemos respeitar as diferentes formas de pensar. Eu particularmente me identifico muito mais com a visão “open source profissional”, sobre a qual falarei no próximo artigo.

Uma questão muito importante no mercado de software é o lock-in de fornecedores, no qual os clientes às vezes se vêem obrigados a manter um fornecedor de software mesmo sem estarem satisfeitos com o serviço/produto oferecido. Discussões em torno disso são muito freqüentes quando comparamos o modelo de desenvolvimento customizado com o trabalho em torno de produtos.

Além destas duas opções já antigas, há uma terceira na moda: Cloud Computing.

Embora eu tenha certas preferências pessoais em alguns cenários, não aponto nenhum desses modelos como o mais indicado de uma maneira geral.

Quando você compra serviços de software customizado, teoricamente o seu investimento inicial será mais baixo do que comprando um produto, mas deve-se avaliar o quão produtivo é o produto, o quanto de esforço você terá para desenvolver de forma customizada, qual é o “time-to-market” desejado, ROI, entre outros fatores. Isso varia demais de um tipo de projeto para o outro, e depende do grau de commoditização dos produtos e do conhecimento do domínio.

Além destes fatores, o lock-in é uma característica importantíssima que deve estar sempre na cabeça das pessoas. Existe uma tendência a achar que o fato de você comprar software proprietário vai necessariamente te prender a um fornecedor. Dependendo do cenário realmente existe uma dificuldade enorme em trocar, mas em outros casos isso é bem mais tranqüilo.

A questão é que com software customizado isso também ocorre muito. Software customizado pode amarrar o cliente até mais do que um produto comercial, dependendo de como for construído, e da participação do cliente no processo.

Sobre Cloud Computing, existe uma enorme febre nesse momento. Todo mundo falando em colocar aplicações “na nuvem”, nos ganhos de custo-benefício, na escalabilidade, e muitas outras “ilidades”. A proposta realmente é tentadora. Você rodar suas aplicações numa infra-estrutura gerenciada por experts do Google, da Amazon ou da Sun parece um sonho realizado. Se você pensar que eles compram hardware muito mais barato que a gente e já têm enormes parques tecnológicos com capacidade ociosa, praticamente fica impossível argumentar contra isso.

Para muitas empresas isso pode realmente fazer sentido. Colocar “na nuvem” serviços que não sejam muito críticos, para empresas de porte limitado. Agora, vamos pensar em empresas que já têm uma enorme gama de aplicações em produção, em datacenters existentes, com políticas de segurança, privacidade, etc.

Será que seria fácil e conveniente ligar a sua empresa “na nuvem”, expondo vários dados críticos e sigilosos, e trazendo riscos de segurança para seu ambiente? Pensem num cliente que já tem um site, uma intranet, ERP, e várias outras aplicações em produção atendendo a fins distintos.

Será que um diretor de tecnologia se sente seguro em abrir sua infra-estrutura para se integrar com redes, computadores e pessoas que ninguém sabe afirmar ao certo onde estão? Você teria certeza de que aqueles dcumentos valiosíssimos da sua proposta comercial não estariam acessíveis pelos concorrentes? Pense em quantas VPNs e configurações complexas de segurança seriam necessárias para adequação a esta nova topologia. Já não é tão sexy, não é mesmo?

Além deste aspecto, o hype em torno de Cloud Computing é tão grande que já estão sendo discutidas possibilidades de interoperabilidades entre Clouds. O mercado ainda está longe de amadurecer, e já vemos discussões comuns em mercados consolidados. Do meu ponto de vista, Cloud Computing pode ser muito interessante, mas é necessário um grau de confiança no fornecedor em níveis que eu raras vezes vi entre pessoas, e muito menos entre empresas.

Depois de tantos anos, comprar software continua muito difícil, e exige um conhecimento cada vez mais sofisticado. O segredo dos projetos melhor sucedidos que eu já vi é a parceria verdadeira entre os fornecedores e os clientes. Projetos de software que dão certo são os que têm pessoas competentes, bem intencionadas e ambiciosas em ambos os lados.

Os melhores fornecedores de software aproveitam cada projeto para trazer o máximo ROI para o cliente, e então conquistar sua confiança e parceria para mais projetos no futuro. E os melhores clientes são os que agem como donos do negócio de suas empresas. Eles buscam todas as oportunidades de melhorar os resultados das empresas, e com isso alavancar suas próprias carreiras.

A Concrete, modéstia à parte, é um baita fornecedor de software. E eu estou tendo a chance de atuar em projetos diferenciados e não há nada mais contagiante para um profissional de software. Estou tendo a chance e a responsabilidade de trazer resultados expressivos para a empresa, e se eu for realmente competente isso trará muitas vitórias para a empresa e para mim (bom, pelo menos eu espero.. ).

Faca nos dentes, sempre em frente

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.

The plugin would be great and extremely useful if it worked. Really, I’d love to have this plugin as an everyday tool, helping me deliver software. It offers a very productive way to work with Maven in Eclipse, except that it brakes Eclipse in such an unbearable way that I cannot afford to think about using it anymore.

Initially I was using m2eclipse with an external Maven installation, instead of the embedded one. With this setup, I was facing many (and I mean MANY) NullPointerExceptions doing some Maven stuff in the IDE. It was impossible to work with that much errors, so I tried using the embedded Maven installation.

Initially it seemed like I was gonna be able to work without problems, but I was wrong. Instead of all the NullPointerExceptions, now Eclipse itself would crash hard when I used the POM editor. Adding a dependency, adding a new build plugin. I was frequently having Eclipse crashes doing this stuff.

I first thought that it could be just an issue in the “graphical” POM editor, so I tried using the simple XML editor. The errors kept occuring, and I got mad.

I could live with this problem if my Eclipse crashed 2 or 3 times a day. I’d gladly restart it, and keep working. However, facing Eclipse crashes every 5-10 minutes can make you crazy before you deliver any piece of software.

I am a man of faith, so I’ll try using it with Eclipse Europa and with minimal features, to see if it hangs on. I use this setup at work, and although it doesn’t work perfectly, at least it stands a whole day without crashing.

Maven is such a widespread Java tool. It’s far from unanymous among developers, but it’s a very valuable tool for me. I think it deserves much better tooling support, so I hope this Ganymede mess is fixed someday. But maybe the Eclipse ecosystem got so complex that it’s becoming impossible to keep everything stable.

I’ve tried using Netbeans before, but I couldn’t be nearly as productive as I am with Eclipse. So please Eclipse, please don’t let me down!

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!

This is not the first time I tried KDE 4, as I had installed Kubuntu 8.04 (Hardy Heron) with KDE 4 several months ago, but I didn’t like it by that time. Kubuntu 8.04 had a version with KDE 4.0, but at that version, KDE 4 looked more like a new concept than a “real deal” window manager. KDE 4.0 was released to gather feedback and to help developments on top of it. It wasn’t meant to be used by end users, so I sticked with rock solid KDE 3.5 for some more time.

Well, with KDE 4, we now have the real deal. Although it took me a couple of hours to do the mental shift from the previous version to this new one, I’m now enjoying it a lot. Regarding usability, the most noticeable feature consists in the “Plasmoids“, which are desktop widgets. These widgets are very similar to those present in Windows Vista, except that they don’t weigh a ton like its Vista brothers. Actually, KDE 4 performance seems to be similar to KDE 3, which is nice, since it’s better than Gnome’s and much better than Vista’s. KDE performance is similar to Windows XP desktop, so it runs pretty well in any machine built in the last 5 or 6 years.

In the picture below, you can see that I’m using some Plasmoids, like the Notes, the folder view (featuring my Desktop content) and a useful Dictionary plasmoid. I could think of several useful plasmoids, like Wikipedia and calendar plasmoids, and I’m pretty sure they’ll be avaiable some time from now. There are many plasmoids already avaiable at KDE-look, but from what I could see they’re still mostly beta and need a bit more work. But it’s indeed promising.

If you’re already a KDE user, I definitely recommend you take a look at this new version of the window manager. If you’re still a Gnome user, waste no time and get yourself a KDE desktop!   If you’re not using Linux yet, well… nevermind.

I’m using Jersey (the JSR’s reference implementation) for more than 6 months and I was anxious to have the specification approved.

In my team we’re currently using Jersey 0.7 in production, and were waiting for the JSR to be approved to analyse the final version of its implementations. Now we’ll wait for both Jersey and JBoss RESTEasy to release their final versions and we’ll analyse both to see which one we’ll use in our RESTFul services.

If anyone wants to give me good reasons to use either one of the implementations, now it’s the perfect time! I’m hearing…

The huge amount of jdbc error messages in the server logs were not actually errors. JBoss datasources have a configuration element called <track-statements>. When this option is turned on, JBoss logs massively when there are Statements or ResultSets that are left open. The application server closes the Statements and the ResultSets, and shows many many logs indicating this. The log messages I was seeing were not errors in the Registry, they were only JBoss warnings.

All our datasources in my team have this option turned on, and we always take care to close the ResultSets and Statements in all our applications. But since the server closes the ResultSets and Statements, I can live with the way the Registry does

I had to do some things to get the Registry working in JBoss. First, I had to remove the log4j the Registry had packed inside its war file. Our JBoss servers use the Unified Classloader, for several years already. This setup was there before I even joined the company, and it’d complicated to change this now, because it’d make us modify several applications. Not being able to change the Classloader, the log4j packed inside the Registry (1.2.13) would conflict with the one present in JBoss itself (1.2.8), so I had to remove it from the Registry’s war. The application worked just fine using log4j 1.2.8, so it’s ok to do this.

After fixing this, I had to enable Java 1.5 code in the jsps. JBoss by default does not allow Java 1.5 code in the jsps, and to modify this, I had to uncomment the code below inside JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/conf/web.xml:

<init-param>
<param-name>compilerSourceVM</param-name>
<param-value>1.5</param-value>
</init-param>

This init-param belongs to <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>, and solves the jsp compilation problem.

Well, that’s what I had to do to make WSO2 Registry work in JBoss. Most of the problems I faced were not Registry’s fault, so I’m sorry for having a wrong impression after some setup problems this week.

I’m currently integrating WSO2 Registry in our architecture and once I finish, I’ll document our architecture here, so that other people can see what uses we’re making of the product.

After looking better at WSO2 Registry, I figured out how to do what I need with the product. I had a very short time to evaluate properly WSO2 Registry and Mule Galaxy before my last post, but after another evaluation of them, I concluded I can use them in this case.

Last week I developed a Java client to consume my publications from WSO2 Registry. It wasn’t much fun to develop, because I had to make it compatible with JDK 1.4. This prevented me from using their client API, which runs only on JDK 1.5 and above.

Since I had to use JDK 1.4, I used XStream for my Java <-> XML mappings. Not being able to use the Registry’s Java client, I also had to consume data from their AtomPub API. I used Apache Abdera 0.3 for this task, which was their last version supporting JDK 1.4 (through retroweaver).

So far so good. Last week I had a prototype client consuming stuff from the Registry, so I moved on to some other tasks. Well, today I started integrating the Registry in my application. That meant moving from Tomcat 6 to JBoss 4.0.5. And that’s when I got in trouble.

Unfortunately I hadn’t seen this page before. It turns out that the only application server they have tested enough is Tomcat. And not any Tomcat, only Tomcat 6. Since their distribution format is a .war file, I never would think they support only Tomcat. In their download page it says: “This distribution includes the Webapp module with relevant JAR files and other resources to be deployed in the servlet container, providing a Web UI and an APP interface.”

Well, I’m probably just dumb. They didn’t say “a servlet container“. They said “the servlet container“. This certainly means “the servlet container we support, which is Tomcat 6″. But this is not written there, so dumb people like me will be subject to mistakes.

“Heck, this is open source, I’m gonna make it work on JBoss!”. This was my first thought. And then I started setting up the Registry in JBoss, right after lunch today.

The first thing I noticed is that the Registry packs a newer version (1.2.13) of log4j than the one present in JBoss (1.2.8). This shouldn’t be a problem, but anyone who has experienced some of the JBoss Classloader Hell knows that it’s not a wise decision to bring a newer version of log4j inside your application if you’re going to run on JBoss. This is not a Registry fault, so I gladly fixed the problem by removing the log4j they had packed inside the .war file.

After fixing this, I was gettings errors trying to open the Registry’s index page on JBoss. I quickly found out that their jsps had scriptlets using JDK 1.5 code, and JBoss was not able to compile the jsps. This was easy to fix by uncommenting a init-param in the web.xml in the Tomcat module inside JBoss. However, the amount of scriplets inside their pages was the first symptom that something didn’t smell right.

After fixing the jsp problem, I configured the Registry to connect to MySql through a JBoss datasource. I then could open their index page and even use some features. However, when I started checking the server logs I was shocked. A huge amount of errors in jdbc operations. I had no clue of what was going wrong, because the UI was apparently working normally and the database was being manipulated.

Well, since it’s an open source product, I promptly checked out their code and started looking for problems. Most errors occured in simple jdbc operations like the creation of a prepared statement. The application logs were not very helpful, and I couldn’t figure out where the problem was.

However, something scared me a lot. Between the zillions of jdbc errors, I saw JBoss screaming for help, saying that the PreparedStatements were left open. I went to look at their jdbc code, and it definitely needs care. There were a LOT of jdbc operations inside try/catch blocks, where they treated SQLExceptions. I didn’t see the finally blocks closing the PreparedStatements and the ResultSets. This explains JBoss’s complaints about the PreparedStatements.

After several hours trying to use WSO2 Registry inside JBoss and looking at their code, I must say I am VERY discouraged to put anything in production right now using the product.

I just downloaded Mule Galaxy and now I’m gonna try to integrate it in my application. A very good sign is that they say I can use it with ANY servlet container, including Tomcat and Jetty. I think it’ll be a successful effort, but it’s hard to say anything after my problems with WSO2 Registry today.

But knowing Dan Diephouse’s work for several years, I’m pretty confident in this new attempt. I’ll post the results later this week.