Bruno Pereira

Continuando o tema do meu artigo anterior, agora quero falar sobre a importância do open source profissional.

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.

Eu sempre gostei muito de open source, e durante a maior parte da minha carreira trabalhei com open source em vários níveis. Com freqüência eu penso sobre vários aspectos da cultura open source, e recentemente tive contato com 2 coisas em particular que eu gostaria de destacar. Falarei sobre uma delas nesse artigo, e sobre a outra no artigo seguinte.

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.

Durante muito tempo trabalhei com desenvolvimento de software customizado, principalmente utilizando componentes open source. Nos últimos meses venho tendo uma experiência intensa com produtos comerciais, de código fechado.

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

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.

I gave up using m2eclipse with Eclipse Ganymede. That’s not premature. I tried my best to figure out a way to use the plugin in a reliable way. However, that’s over now, I quit!

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!

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!

This Saturday I installed Kubuntu 8.10 (Intrepid Ibex) on my home desktop, and finally got my hands on KDE 4.1.

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.