HP compra EDS. Mas isso faz algum sentido?

Atenção, este blog foi migrado para: http://brunopereira.org

Hoje foi anunciado que a HP está comprando a EDS. O valor divulgado da compra é de US$ 13.9 bi.

Li algumas notícias dizendo que este movimento da HP tem como objetivo fortalecer a empresa para competir com a IBM. Entretanto, tenho sérias dúvidas se isso terá sucesso. A HP tem muita força na venda de equipamentos, e também presta serviços de manutenção de infra-estrutura. Já a EDS é uma gigante na prestação de serviços de software, tanto na área de manutenção de infra-estrutura como no outsourcing de aplicações, e consultoria de uma maneira geral. Como algumas áreas das empresas claramente se sobrepõem, imagino que muitos empregos serão cortados.

A HP passará a ter uma estrutura gigantesca, mas ainda ficará atrás da IBM em termos de faturamento. Além disso, embora fortaleça a empresa na disputa com a IBM, não fortalece tanto. A IBM tem uma área enorme de produtos de software que a HP continuará não tendo. Será muito difícil para a HP ganhar espaço contra a IBM sem um braço de software forte. Principalmente na área de middleware, onde a IBM está muito forte. E além da IBM, a HP teria que brigar também contra a Oracle neste nicho, depois que ela comprou a BEA.

É bom lembrarmos que a HP não tem lá um bom histórico em compras. A aquisição da Compaq foi bem traumática e não teve custo-beneficio muito bom para a HP. O mercado americano também não reagiu bem a essa compra da EDS. As ações de ambas as empresas caíram razoavelmente, mostrando que a maioria das pessoas do mercado não achou este negócio uma boa idéia para as empresas.

Na minha opinião, a HP após esta compra ainda é uma empresa incompleta para competir com a IBM, Oracle e Sun. Antes dessa compra a HP não era tida como concorrente direta dessas empresas, mas agora ela é. Penso que para a HP ter realmente relevância nessa disputa, ela precisará de um braço forte de middleware, e uma boa pilha de software em geral.

Com o histórico que a empresa tem, duvido que ela se transforme nisso por conta própria. Na minha visão o que faz sentido é a HP comprar mais alguma(s) empresa(s), para conseguir complementar suas ofertas de serviços. Considerando a consolidação atual do mercado, acho que faria sentido que a HP comprasse a Red Hat, levando o JBoss de lambuja. Além disso seria interessante que eles contassem com algum servidor de BD na pilha, já que os concorrentes possuem isso (DB2, Oracle e MySql). Uma ótima opção seria comprar a EnterpriseDB, que oferece uma versão comercial do Postgres, o excepcional BD open source.

De todas as grandes aquisições que rolaram recentemente, esta da HP é a que menos faz sentido, pelo menos atualmente. Dependendo das ações que eles tomarem em seguida, esta compra pode ser uma boa jogada ou um episódio lamentável como a compra da Compaq. Torço para que a HP aumente seus já fortes vínculos com Linux e Open Source e compre a Red Hat para se apresentar firmemente como competidora de peso. E claro, continuo torcendo pelo sucesso do meu estimado Postgres 🙂

Netbeans growing stronger

Atenção, este blog foi migrado para: http://brunopereira.org

During several years I’ve been a pretty happy Eclipse user, rarely feeling the need to use anything else. We know there are plugins for many many things, and a lot of development tools are Eclipse-based right now. The editor is awesome, and so are the refactoring tools. The support for web app development is also very nice. Eclipse supports a wide set of frameworks and technologies, and it’s not only aimed at Java development.

Why would someone even look at anything else, having such a great tool? Well, it turns out that our field is evolving really fast, and it’s very hard to follow this current pace, even for the most dedicated and passionate ones. Currently there are several technologies evolving very fast, and they are meaningful to a lot of enterprise developers. The rise of the JVM’s dynamic languages is crystal clear. Strong is also the growth of RESTFul web services. I’m personally very interested in both fields.

I’m currently using REST (lately with Jersey) for a lot of integrations between applications. The power it gives me is really nice, and I’m improving my developments each new month. I have also studied Groovy/Grails recently and really liked it. I wanna try JRuby on Rails sometime in the next weeks, to see what it offers and check how it compares to Grails. If you’re a Java enterprise developer, I’m sure you’re following the growth of these nitty things.

But where does Netbeans enter this talk? Well, Netbeans is doing a great job supporting these new technologies, and it’s way ahead of Eclipse in this field right now. Have you seen how easily you can develop RESTFul web services with Netbeans 6.1? Jersey support is great, very productive. The support for JRuby on Rails and Grails is also present, in a much more advanced state than Eclipse’s. Netbeans is doing a much better job than Eclipse regarding Web Services and JVM languages right now.

Swing development in Netbeans is very nice since version 5.0 (with the release of Matisse), and developing for mobile devices is also easier in Netbeans. Currently I don’t develop swing nor mobile applications, so this doesn’t really affect me.

However, I develop many RESTFul web services. And I wanna use more and more the JVM’s dynamic languages. Ignoring Netbeans is not a clever idea right now.

I still find Eclipse’s interface and editor much better than Netbeans’s. I also know a lot of Eclipse’s shortcuts and know very few in Netbeans. SWT is also faster than Swing, so Eclipse is faster than Netbeans. But considering what I said, I’m leaning towards the use of both IDEs at the same time. Since our machines are now much better equipped with RAM, I can have them open at the same time and also a couple of servers, with no memory shortage.

My Eclipse days are definitely not over, but now he’s gonna divide my attention with Netbeans 🙂 I hope I can become as productive with Netbeans as I am with Eclipse, even if it takes a few weeks. My first wish would be the Eclipse’s Quick Fix (Ctrl + 1) avaiable in Netbeans. Even without it, I’m sure my usage of Netbeans will certainly grow, and think this competition between the IDEs is very good for us. Let Eclipse Ganymede come!

Postgresql x Mysql: a diferença que faz uma estratégia correta

Atenção, este blog foi migrado para: http://brunopereira.org

Ontem fui no Tech Talk de MySql aqui na Globo.com, que me trouxe algumas idéias interessantes e também fomentou algumas discussões. Não vou falar muito sobre o tech talk especificamente, mas sobre uma discussão paralela.

Algumas pessoas sabem da minha preferência pelo Postgres sobre o MySql. Durante a apresentação ontem o Rafael me perguntou porque tanta gente utiliza o MySql e nem tanta gente usa o Postgres. Ele me perguntou isso porque usa o Postgres em alguns projetos e não viu vantagens em utilizar o MySql em vez do Postgres.

Bom, a resposta pra isso na minha opinião vem da diferença de estratégia. Banco por banco, sou mais o Postgres, embora eu considere que em boa parte dos casos, qualquer banco atende aos requisitos. Mas porque então o MySql ganhou bem mais adoção do que o Postgres?

Na minha opinião, o fator principal que levou a isso é que o MySql já há muito tempo oferece instalador nativo para o Windows. O MySql foi lançado em 1996 e começou com suporte apenas a Linux, mas desde 1998 permite instalação nativa no Windows. O Postgres começou como um projeto acadêmico em 1986, mas em 1996 se tornou um projeto open source com participação da comunidade de software livre. Podemos ver que nesta vertente atual de desenvolvimento, ambos estão disponíveis desde 1996. Enquanto o MySql suporta nativamente o Windows desde 1998, no Postgres isso só foi ocorrer em Janeiro de 2005, com o lançamento da versão 8.0. Anteriormente o Postgres só podia ser instalado no Windows com uso do Cygwin, que está longe de ser algo prático.

Considerando os recursos que ambos os bancos ofereceram ao longo de sua história, não restam dúvidas de que o Postgres é historicamente superior tecnicamente, e na minha opinião continua sendo. Entretanto, com a enorme quantidade de desenvolvedores que só utilizavam Windows (what a shame!), o fato de poder rodar o banco de dados na mesma máquina de desenvolvimento tornou o MySql muito mais conveniente para quem precisava de um banco de dados gratuito para suas aplicações.

Quando o Postgres lançou a versão 8.0 em Janeiro de 2005, muitos desenvolvedores já utilizavam o MySql há anos, e com isso sua adoção já estava bem grande. Neste ponto podemos ver claramente a diferença que fez uma estratégia correta. O fato de ser limitado tecnicamente em comparação com o Postgres não impactou o sucesso do MySql, porque durante muitos anos ele foi simplesmente muito mais conveniente para o desenvolvedor.

Atualmente, só vejo chances do Postgres aumentar seu sucesso se for comprado por alguma grande empresa e colocado em uma pilha de produtos interessante. Eu gosto muito do banco, e nos meus projetos pessoais ele é minha opção default. Entretanto, temo que ele nunca saia da sua abrangência atual, pelos erros na estratégia. É uma pena, devido à qualidade do projeto. Mas é muito difícil qualquer mérito técnico sobreviver a uma estratégia perdedora.

Kubuntu 8.04: primeiras impressões

Atenção, este blog foi migrado para: http://brunopereira.org

Neste fim de semana eu atualizei o Linux do meu desktop em casa, instalando o Kubuntu 8.04 (Hardy Heron). Inicialmente eu instalei a versão com o KDE 4, pois já é a versão 4.0.3, e imaginei que já poderia usar tranqüilamente.

De mais chato, encontrei apenas um problema para instalar extensões do Firefox. Nenhuma extensão estava sendo instalada com sucesso, devido a um problema com o Extension Manager do Firefox. Pelo que pude ver, o problema é específico do pacote do Firefox que veio com o Kubuntu, pois ele estava configurado para utilizar um diretório de extensões incorreto. Eu consegui resolver o problema baixando o Firefox do site oficial e instalando-o por fora do gerenciador de pacotes.

O que me incomodou mais não foi nem isso, foram questões referentes ao KDE 4 em si. Pelo que pude ler depois, o pessoal do KDE não está recomendando ainda esta versão 4.0.x para os usuários em massa. Eles estão recomendando esperar pela versão 4.1.

O motivo por trás disso eu pude constatar. Diversas funcionalidades básicas de configuração que existem no KDE 3 simplesmente não foram implementadas no KDE 4 ainda. Por exemplo, eu não conseguia diminuir a fonte do relógio, e quando eu reduzi a altura da barra de tarefas do KDE, o relógio simplesmente ficou cortado no meio. Eu também não consegui criar atalhos na barra de “Quick Launch”, o que me incomodou bastante.

Um último detalhe que eu me lembro é que tanto o Dolphin como o Konqueror estavam com problemas para guardar as preferências de gerenciamento de arquivos. Eu gosto de deixar o modo de visualização de arquivos e pastas como “Lista Detalhada” e sempre ordeno a lista por tipo de arquivo. Por algum motivo que eu não cheguei a descobrir, eles não estavam salvando corretamente esta minha escolha e sempre que eu abria uma nova pasta, a exibição voltava para o formato “Ícones”, com alguma ordenação qualquer.

Depois de pouco mais de uma hora me irritando com estas limitações do KDE 4, resolvi instalar a versão do Kubuntu com o KDE 3 (3.5.9 especificamente). Esta versão já é bem melhor, totalmente estável e personalizável. Não tive absolutamente problema algum e tudo funcionou corretamente e de forma fácil, como já me acostumei em relação ao Kubuntu.

Eu recentemente usei em casa o Mepis e o PcLinuxOS, mas a verdade é que a melhor distribuição com KDE é o Kubuntu. No meu notebook eu ainda estou com o Mepis, e gosto bastante da distro. Não pretendo trocar não. Entretanto, a distribuição que mais recomendo é mesmo o Kubuntu e esta versão 8.04 está rodando redondinha aqui em casa.

Quanto ao KDE 4, embora ele seja bastante promissor, ele ainda não está adequado para a maioria dos usuários. Eu gosto bem mais do KDE do que do Gnome, e estou certo de que em breve o KDE 4 será a melhor opção disponível. Nos próximos meses, entretanto, recomendo a confiabilidade do KDE 3.5.x.

10 principais barreiras para o sucesso do desktop Linux

Atenção, este blog foi migrado para: http://brunopereira.org

Recentemente eu li um artigo muito interessante sobre as principais barreiras que dificultam o sucesso em massa do desktop Linux. Eu já uso Linux em casa desde 2003 e utilizei uma boa variedade de distribuições. Já usei distribuições baseadas em Debian, outras derivadas do Red Hat. Algumas utilizavam Gnome, outras KDE (meu preferido).

Entre as distribuições que me lembro que já usei estão (em ordem mais ou menos cronológica): Conectiva, Red Hat, Knoppix, Mandrake/Mandriva, Suse, Ubuntu/Kubuntu, Mepis e Pc LinuxOS. De uma maneira geral a minha distribuição preferida é o Kubuntu, pois faço questão do KDE e de uma maneira geral o Ubuntu/Kubuntu é a distribuição melhor suportada para a maioria das coisas que você for usar. Após esta experiência em variadas distribuições, pude conhecer o suficiente sobre Linux para saber me virar bem em qualquer versão que eu tenha que usar.

Recentemente a Globo.com migrou os desktops dos desenvolvedores para Linux. Eu já estou usando Linux no trabalho há quase 1 ano, mas as pessoas em geral receberam seus desktops novos com Linux no começo desse ano. Grande parte das pessoas ainda não havia usado Linux como desktop, conhecendo apenas algumas coisas de linha de comando pela experiência de acessar nossos servidores. Com isso, tenho tentado ajudar da melhor forma possível para que a transição deles seja suave. Eu gosto muito de Linux e quero que sua adoção cresça e que as pessoas em geral tenham uma boa experiência de uso.

Apesar de gostar bastante e utilizá-lo quase em tempo integral, não sou do tipo fanático que só vê vantagens. Há algumas coisas que incomodam razoavelmente se você não souber contorná-las, e um novo usuário freqüentemente encontra dificuldades com isso. Como este artigo que mencionei aborda de forma bem interessante estas barreiras comuns, listarei-as aqui e deixarei meus comentários.

1 – Consistência e percepção: com a enorme variedade de distribuições disponíveis, os usuários têm uma enorme liberdade de escolha. Entretanto, isso também traz a característica de que as coisas mudam muito de uma distribuição para a outra. Se você sabe como usar ou configurar alguma coisa em uma determinada distribuição, isto não garante que você conseguirá fazer a mesma coisa em outra distro. A facilidade de uso de uma distribuição para a outra varia bastante. Isto sem dúvida dificulta que um usuário experiente ajude um iniciante, caso a distribuição seja diferente. Como o Windows é uma coisa só, a interface e as configurações não mudam quase nada de um usuário pro outro. Isso facilitou muito a adoção em massa, e usuários novos conseguem rapidamente aprender com usuários experientes. Embora isto possa incomodar os puristas, eu acho que o Linux teria bem mais chances de sucesso se em vez de centenas de distribuições, tivéssemos umas 3 ou 4 no máximo, e os esforços ficassem concentrados nestas.

2 – Fraco suporte a dispositivos móveis: com pouquíssimas exceções, sincronizar dispositivos móveis no Linux é pauleira. Enquanto isto não for tão simples quanto usar um pen drive, esta barreira complicará muito o uso do Linux por usuários comuns. Eu sei que sincronizar um celular ou PDA é bem mais difícil de implementar do que acessar um pen drive, mas o usuário final não quer saber disso quando escolhe um sistema operacional para usar.

3 – Encontrar software compatíveis ao mudar de SO é difícil: é claro que existe muito mais software para Windows do que para Linux. A maioria dos softwares possui equivalentes no Linux, mas a qualidade destes substitutos varia muito. Usuário não-técnicos vão relutar muito em trocar o Office pelo Open Office. Apesar de eu conseguir usar tranqüilamente o Open Office em geral, os formatos amplamente aceitos ainda são os da Microsoft. Tentar usar o Open Office para modificar arquivos do Word ou Excel pode trazer muitas dores de cabeça, especialmente se você precisar salvar no formato Office original. Existe o Crossover Office que suporta muito bem o Office no Linux, mas ele não é gratuito e pouca gente conhece. Ainda temos muito que avançar nesta área.

4 – Problemas com wireless: é vastamente sabido que utilizar dispositivos wireless em geral no Linux é muito complicado ainda, e dependendo do seu hardware e distribuição, isto pode ser muito tranqüilo ou um pesadelo. Os procedimentos de contorno disso variam muito de uma distribuição para a outra, e um usuário comum dificilmente vai saber se virar com isso. Probleminha complicado também.

5 – Listas de compatibilidade de hardware: alguns fabricantes principais de hardware já suportam muito bem o Linux e isto vem melhorando rapidamente. Para a grande maioria dos componentes já é possível usar tudo perfeitamente no Linux, mas caso você tenha algum modelo não muito comum, pode ter problemas. Além disso, é difícil saber previamente se tudo vai funcionar antes de você tentar. Os CDs bootáveis ajudam muito nisso, permitindo que você teste previamente seu hardware antes de instalar em disco. Este problema eu acredito que muito em breve deixará de ser considerado.

6 – Necessidade de compilar novos módulos de drivers: caso você precise instalar um novo driver no Windows, basicamente você usa um instalador com Next -> Next -> Next. No Linux, você pode precisar compilar o driver, e isto é bem enjoado. Eu lembro que quando comecei a usar Linux em casa, algumas distribuições não vinham nem com módulo de USB ativo. Eu já tive que compilar e configurar módulo de USB para conseguir usar pen drives e câmeras digitais. Isto é muito chato, mas felizmente hoje em dia acontece muito pouco. Exceto em casos muito específicos você nunca precisará mais fazer isso, e acho que já podemos deixar esse problema em segundo plano.

7 – Sério interesse comercial: boa parte das empresas não-técnicas ainda não se importam muito com Linux. Com isso, ainda é freqüente termos que nos virar para conseguirmos reproduzir formatos proprietários de música, vídeo e outras coisas. As empresas em si não disponibilizam codecs pra Linux na maioria dos casos. Eles são desenvolvidos de forma open source, e em alguns casos o suporte ainda é ruim. Acho que daqui a uns 2 ou 3 anos já teremos uma parcela suficiente de usuários não-Windows para que esta postura mude. Enquanto o Windows tem mais de 90% do mercado, financeiramente não é tão fácil convencer diretorias de empresas a investir em outros sistemas operacionais. Se conseguirmos ter algo entre 15 e 20% dos usuários com Linux e Mac, a coisa já muda um pouco de figura, e o suporte melhorará.

8 – Software prontamente disponível: os usuários de Windows estão acostumados a encontrar os softwares para instalar na internet, baixar o instalador e Next -> Next -> Next. No Linux isto é diferente, como já falei previamente. As pessoas estranham inicialmente o conceito de repositórios de pacotes, mas isso na verdade facilita bastante os usuários depois que eles aprendem isso. Este problema será reduzido à medida que mais empresas comecem a adotar Linux. Usuários iniciantes serão capazes de aprender isso rapidamente com usuários experientes, e daqui a algum tempo esta diferença já deve ser vista até como um ponto forte do Linux.

9 – Workarounds vs. correções de bugs: as distribuições variam muito em termos de agilidade de uma para a outra. Algumas oferecem o que há de mais recente em termos de software para os usuários, mas isto os expõe também a mais bugs. Como estas distribuições são mais populares, rapidamente surgem formas conhecidas de contornar os problemas, antes de saírem as correções dos bugs. Outras distribuições (como Debian e Slackware) colocam apenas versões altamente testadas e maduras em seus lançamentos. Os usuários ficam com software defasado, mas muito mais estável. Devido a este fato, algumas distribuições são muito mais usadas em desktops, e outras muito mais comuns em servidores. O kernel do linux e seus princiais módulos são muito, muito estáveis e confiáveis. Já os software gráficos e de uso por usuários finais têm qualidade bem inferior. Temos aplicações de alta qualidade (como as que fazem parte das suites do KDE e Gnome), mas também temos softwares cheios de bugs que podem prejudicar a usabilidade. Ao longo do tempo a qualidade vai melhorando, e para a maioria dos softwares usados por pessoas comuns os bugs são poucos.

10 – Evangelistas e puristas: algumas pessoas têm uma visão pragmática e realista quanto ao Linux, e enxergam claramente suas qualidades, mas também as falhas. Outras simplesmente acham que é a melhor coisa do mundo para todos, sem analisar as dificuldades que pessoas comuns enfrentam. Precisamos ter uma postura madura em relação a software. Não podemos “nos apaixonar cegamente” por nada. Se enxergamos os pontos onde o Linux precisa melhorar e discutirmos eles abertamente, será muito mais fácil progredir. Entrar em flame wars de Linux x Windows é perda de tempo e energia. Cada um tem suas vantagens, e as pessoas podem ter opiniões e gostos diferentes. É ótimo que existam os 2, pois a concorrência ajuda a elevar o nível geral dos sistemas.

Torço muito para que o Linux continue evoluindo bastante e que em breve tenhamos cada vez mais facilidade para usá-lo. Posso dizer que desde 2003 quando comecei a usar, ele já melhorou e muito. Não dá nem pra comparar a situação atual com a de 2003. Estamos num patamar muito superior.

O mesmo eu não posso dizer do Windows. Em 2003 o Windows XP já estava amplamente disponível e as pessoas já o conheciam bem. Eu gosto bastante do Windows XP, ele é um ótimo sistema operacional. Já a sua “evolução”, o Windows Vista, pra mim é uma porcaria. Eu não consigo usá-lo. É muito mais pesado que o Windows XP e não me trouxe nenhuma vantagem. Eu já instalei ele em casa e ele veio no meu notebook, mas eu já voltei para o Windows XP em todas as máquinas que tiveram o Vista. Por mim eu simplesmente pulo a atualização pro Vista e espero por uma nova versão do Windows que venha depois. Muita gente compartilha desta opinião, então a Microsoft precisa trabalhar bastante.

Com o crescimento da adoção de open source, acho que aos poucos o Windows terá seu domínio reduzido, embora ainda deva continuar dominando por muitos anos. Acho que o Linux está bem encaminhado e evoluindo bastante na comparação com o Windows. Vamos torcer para que ambos evoluam bastante ao longo do tempo, pois assim todos nós ganhamos. E chega de flame wars, por favor 🙂

IBM investe US$ 10 mi no Postgresql. Mais consolidações à vista?

Atenção, este blog foi migrado para: http://brunopereira.org

Essa semana fiquei sabendo pelo blog do Savio Rodrigues que a IBM investiu US$ 10 milhões no EnterpriseDB, uma derivação comercial do Postgresql, mas cujos desenvolvedores atuam no desenvolvimento do produto open source também.

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

mod_rewrite

Atenção, este blog foi migrado para: http://brunopereira.org

Hoje assisti a um Tech Talk bem interessante na Globo, sobre mod_rewrite. Além de funcionalidades interessantes deste módulo do Apache, as discussões na apresentação me trouxeram vários questionamentos de como incluir de forma mais ativa o Apache em uma arquitetura RESTFul.

Eu já utilizei bastante o Apache na remota época em que eu desenvolvia algumas coisas em Php. Na verdade não fazia nada de muito sofisticado, mas tinha boa familiaridade com os módulos, com a configuração, essas coisas. Depois que foquei mais no uso de servidores de aplicação Java, deixei o Apache em segundo plano. Praticamente só vinha usando o Apache para servir conteúdo estático, e claro, nele também ficam configurados os conectores para comunicação com os servidores de aplicação.

Como tenho trabalhado bastante com web services REST, venho tentando explorar ao máximo os recursos do HTTP para elaborar protocolos de comunicação concisos e intuitivos. Neste sentido, o Apache oferece recursos muito interessantes. Por exemplo, quando utilizamos URIs no formato /usuario/123456/item/25 para representar um determinado item de um determinado usuário, a resposta a esta requisição é cacheável pelo Apache. Entretanto, ao utilizar URIs neste formato você precisa definir uma forma de fazer o parsing da URI para pegar os parâmetros relevantes.

No meu artigo de REST da Java Magazine de Abril eu usei o StringTokenizer do JDK para fazer a quebra da URI e pegar os valores que me interessavam. A JSR-311 define uma forma bem interessante de fazer isso com annotations também. E hoje fui descobrir que o mod_rewrite também pode fazer facilmente a quebra de URIs neste formato em URIs com parâmetros em query string por exemplo.

Uma utilização inteligente do cache do servidor web e de módulos de proxy também pode tornar a arquitetura da aplicação bem eficiente e reduzir bastante a carga sobre os servidores de aplicação. Se eu posso utilizar diretamente o cache do Apache para várias URIs, não vale a pena deixar as requisições chegarem ao container de servlets, mesmo que ele responda também com dados em cache.

Vendo o poder e a facilidade de uso de alguns módulos do Apache, me sinto obrigado a ter total familiaridade com ele novamente. Aos poucos irei estudando e integrando os módulos do Apache à arquitetura das minhas aplicações REST, pois isto pode trazer um belo ganho de performance e escalabilidade. Afinal de contas, quem quer explorar a fundo os recursos do HTTP não pode abrir mão de explorar a fundo um servidor tão confiável e maduro como o Apache, não é mesmo?

OBS: uns anos atrás eu dizia pra mim mesmo que o dia que eu conhecesse pelo menos vagamente metade dos projetos na home da Apache Software Foundation eu já teria uma boa bagagem. Hoje em dia já conheço mais da metade do projetos da home, e admiro cada vez mais esta fundação. O mundo open source não chegaria aos pés do que é hoje sem a existência da ASF. Um belo exemplo de qualidade em software!

RESTFox

Atenção, este blog foi migrado para: http://brunopereira.org

Eu tenho trabalhado bastante com web services REST ultimamente. Para testar meus serviços, a forma padrão que eu uso para testar é criar alguns testes unitários que montam as requisições e recebem as respostas com o commons-http-client.

O commons-http-client é perfeito para testes unitários, e para uso por uma aplicação. Para testar manualmente, entretanto, eu gostaria de algo mais prático. Pensando um pouco nas características dos testes que eu faço, um plugin do Firefox seria a ferramenta perfeita. Eu precisaria criar requisições HTTP com qualquer método (além de GET e POST) e especificar o corpo da requisição (onde for o caso), assim como alguns headers também.

O caso de uso principal deste plugin seria a criação de requisições GET, POST, PUT ou DELETE nas quais eu pudesse especificar os XMLs do corpo (aplicável apenas para POST e PUT) e pudesse conferir a resposta HTTP completa, incluindo todos os headers. Isso já seria uma facilidade enorme. Para refinar, deveria ser possível guardar alguns templates de XMLs de entrada. Um exemplo claro que me vem à cabeça é um template de XML no formato Atom, que poderia ser usado para requisições à Google Data API, entre diversos outros serviços que já utilizam o Atom como formato padrão de documentos.

Eu dei uma procurada boa e não achei nenhum plugin que fizesse nem uma parte disso que eu quero. Caso vocês conheçam alguma ferramenta do gênero (mesmo que não seja plugin do Firefox) por favor me avisem. Se eu não descobrir nenhuma ferramenta que ofereça isso ao menos de forma parcial, pretendo desenvolver eu mesmo esse plugin para o Firefox. Eu ainda nem comecei a fazer nada desse plugin, mas já gosto do nome RESTFox. Vamos ver se sai algo bacana daí… eu nunca desenvolvi plugins para o Firefox, mas me parece que este será o primeiro 🙂

Diversidade de tecnologias

Atenção, este blog foi migrado para: http://brunopereira.org

Eu tenho postado com alguma freqüência sobre o que vem acontecendo no desenvolvimento das tecnologias dos web services Restful.

Este fim de semana o James Snell implementou um adapter do Apache Abdera para o CouchDB. Este adapter permite que se consiga facilmente implementar um armazenamento de dados no formato Atom com uso de uma instância do CouchDB.

Como eu já mencionei anteriormente, o Abdera oferece uma API para manipulação de conteúdo no formato Atom e a realização de operações do Atom Publishing Protocol. Já o CouchDB é um banco de dados orientado a documentos que é escrito em Erlang e foi projetado para extrema escalabilidade e permite fácil instalação em servidores com múltiplos núcleos ou em clusters de máquinas.

Em vez de utilizar tabelas com colunas (como os bancos de dados relacionais), o CouchDB armazena os documentos em formato JSON e disponibiliza como interface uma API Restful, com clientes já implementados em várias linguagens, como Javascript, Java, PHP, Ruby e Python.

Acho que isto expressa muito bem o horizonte que vem se formando. Em vez de pilha de tecnologias e protocolos proprietários, temos diversas tecnologias e plataformas diferentes conseguindo se comunicar através de HTTP. Um projeto open source Java que manipula conteúdo Atom já disponibiliza com facilidade um mecanismo de integração com serviços REST que manipulam dados em formato JSON.

É impressão minha ou estamos de fato vendo rapidamente uma mudança radical de abordagem na vanguarda da tecnologia? A mesma IBM que antigamente dominava de forma absoluta todo o mercado de hardware e software com soluções proprietárias agora patrocina diversos projetos open source e mantém sua elite intelectual trabalhando nestes projetos.

Soluções open source estão liderando várias frentes de desenvolvimento e com isso rapidamente surgem integrações entre componentes feitos em diferentes linguagens e plataformas. O conhecimento não está mais guardado a 7 chaves, e sim discutido abertamente por uma comunidade que aceita qualquer um com capacidade para agregar idéias boas.

A criatividade e a iniciativa individual nunca tiveram tanto poder, e isto é fabuloso. Com isso, claro que a versatilidade e o conhecimento diversificado ficam muito valiosos.

Hum… maybe it’s time for me to fight my disgust for Javascript and start developing something nice including JSON 😉

Jersey meets Abdera

Atenção, este blog foi migrado para: http://brunopereira.org

Talvez os dois mais promissores projetos atualmente sendo desenvolvidos na área de web services Rest são o Apache Abdera e o Jersey. O Apache Abdera oferece uma API para manipulação de conteúdo no formato Atom, e é bastante útil para implementações baseadas no Atom Publishing Protocol. Já o Jersey é a implementação de referência da JSR-311, que mencionei num post recente aqui no blog.

Os 2 projetos são complementares, já que as funcionalidades de ambos não tem muitas interseções. Ontem o Marc Hadley, um dos principais desenvolvedores do Jersey postou sobre um desenvolvimento que ele está fazendo, usando o Jersey e o Abdera em um projeto de web services Restful. No post do Marc Hadley ele menciona que utilizou os recursos HTTP do Jersey (como mapeamento de URIs em classes e métodos e a capacidade de manipular diversos content-types) juntamente com as funcionalidades do Abdera de manipulação de recursos Atom.

Esta iniciativa foi muito bem recebida pelo James Snell e pelo Dan Diephouse (fundador do XFire), que são os principais desenvolvedores do Apache Abdera. O desenvolvimento destes dois projetos vem trazendo enorme amadurecimento aos web services REST e hoje já é possível desenvolver web services neste formato com grande produtividade e poder.

Claro que os projetos ainda estão em um estágio intermediário de desenvolvimento, mas é deles que virá a adoção mainstream com maturidade desta linha de serviços. Estou acompanhando continuamente o que está sendo feito nesta área, e o que já pude ver até agora é fascinante.

A propósito, os dois projetos são open source e os principais envolvidos fazem parte de empresas como a IBM, Sun, Mulesource, entre outras. O desenvolvimento de software open source é hoje em dia a principal forma de desenvolvimento da vanguarda da tecnologia mundial. As empresas já perceberam o sucesso do movimento e estão apoiando firmemente o mesmo. Não posso deixar de registrar minha profunda satisfação com isso. 🙂