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.

O que me intriga é que a Oracle não é tradicionalmente uma empresa de serviços. Ela costuma desenvolver e vender produtos, e a prestação de serviços é feita através de parceiros, como a Concrete por exemplo. Não consegui ter ainda a visão de como essa aquisição vai se encaixar dentro da estratégia da Oracle.

Não sei bem também como será a relação da Oracle com Open Source. A Sun não vinha tendo resultados financeiros muito bons, mas mantinha muitos projetos open source importantes, como o Glassfish, Solaris, MySql, stack SOA e vários projetos Java em geral. Além disso, desempenha um papel muito importante no desenvolvimento de linguagens dinâmicas para a JVM, além do desenvolvimento da própria JVM.

Se em termos de software tenho várias dúvidas, em relação às ofertas de hardware da Sun eu já consigo ter algumas idéias. Um dos principais concorrentes da Oracle é a IBM, que tem um braço bem forte de hardware. Não é raro a IBM ganhar concorrências com a Oracle “dando” o hardware, e vendendo o software. A Oracle não tinha condições de oferecer uma proposta equivalente, mas agora isso será possível.

Além disso, a Sun anunciou recentemente sua oferta de Cloud Computing, que pode ser um mercado que a Oracle quer entrar. Como ela já possui muitas aplicações críticas para empresas, ela pode querer oferecer estas aplicações como serviços, em uma estrutura de Cloud. Posso estar totalmente fora do alvo, mas não duvido que isto seja um objetivo da Oracle para diversificar seu modelo comercial.

Assim como em outras aquisições, muita coisa ainda não está clara, mas já temos vários aspectos para prestar atenção.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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!

A idéia deste post é colocar dicas sem uma ordem específica, e comentar porque elas podem ser importantes. Provavelmente este post será atualizado várias vezes ao longo do tempo para agregar idéias novas, e com certeza as opiniões de outras pessoas ajudam muito para melhorar o conteúdo aqui. Não hesite em deixar suas observações

1. Escreva um blog: essa é a forma mais fácil e objetiva de expôr o seu trabalho para outras pessoas. Você não precisa ficar escrevendo com inúmeros detalhes tudo o que está fazendo. Mencione coisas relevantes que possam ser interessantes a outras pessoas, e naturalmente as pessoas começarão a ler o que você escreve. O Wordpress é uma excelente ferramenta de blogs, e permite que você mantenha gratuitamente um blog hospedado por eles, com ótimo nível de serviço.
2. Participe de grupos profissionais da sua área: grupos profissionais como os Java User Groups e semelhantes são muito interessantes para você conhecer outras pessoas fazendo o mesmo que você. Após algum tempo você terá conhecido as pessoas mais relevantes e conseguirá saber o que tem sido usado com sucesso, e o nível geral das pessoas da área. Isto é ótimo para trazer novas idéias e ajudar em decisões estratégicas. Networking é tudo.
3. Tente se manter atualizado sobre as novidades mais interessantes da área: isto é fundamental para que você se torne e se mantenha como um profissional de destaque por muito tempo. Se você ainda está programando sistemas client-server em Delphi, provavelmente não terá muitas coisas novas para discutir com outras pessoas, e acabará um pouco esquecido. Por outro lado, se você está trabalhando com novidades quentes em linguagens dinâmicas, Web 2.0, redes sociais e outras coisas que estão em destaque no momento, provavelmente terá muita gente interessada em conversar com você.
4. Tente fazer apresentações de coisas interessantes no momento: se você fizer apresentações sobre assuntos que estão sendo muito debatidos no momento, provavelmente atrairá o interesse de várias pessoas. Fazendo boas apresentações, você ganhará mais credibilidade e as pessoas vão SABER que você conhece daquele assunto, e vão querer trocar idéias sobre o assunto contigo.
5. Vá em eventos relevantes da sua área: em eventos normalmente são apresentados os conteúdos mais bacanas do momento, e você conhecerá mais sobre os caminhos que as coisas estão tomando. Além disso, é uma ótima oportunidade para conhecer pessoas e trocar idéias sobre temas que não há tanta gente qualificada para conversar.
6. Procure saber o que outras pessoas estão estudando e utilizando nos projetos, e troque experiências: casos de sucesso são o principal fator para a sobrevivência de qualquer tecnologia, metodologia ou qualquer outra coisa relacionada a software. Conheça o que está sendo usado com sucesso, e comente o que está funcionando pra você e o que está te trazendo problemas. Assim você aprenderá bastante com as discussões e as pessoas saberão o que você está fazendo.
7. Leia e interaja em outros blogs relevantes: mesma motivação que o item anterior, com o bônus de que você estará interagindo com a elite da sua área, e as discussões com essas pessoas podem te trazer muitas idéias legais, e te trarão ótimos contatos.
8. Participação em projetos open source ajuda muito: projetos open source agregam ótimas mentes e fomentam a participação de várias pessoas diferentes. Mesmo que você não seja um committer, participar em listas de discussão dos projetos e ser um “early-adopter” podem te ajudar a ficar mais relevante, e a ser uma referência para outras pessoas.

Bom, espero que essas dicas possam ser úteis para outras pessoas, e já deixo claro que este post é um trabalho em progresso. Certamente melhorarei o conteúdo aqui e tentarei colher mais idéias interessantes sobre o assunto. Se você estiver interessado no tema, pode alavancar mais um pouco o seu marketing pessoal contribuindo aqui

This time I was lucky enough to make an interview with Eelco Hillenious and Martijn Dashorst, from Apache Wicket. I’m pretty happy with the results, and I hope you guys enjoy it too. On to the interview!

Bruno Pereira: How did you first get involved with Wicket?

Eelco Hillenious: At Topicus where I worked a few years ago, we had been looking for good web framework for a while to help us address the issues we had with scaling our developing effort. We were doing a couple of reasonably large projects using web MVC frameworks Struts and Maverick. The user interfaces were quite complex at times – they had things like nested tabs, wizards and paginated lists – and we had a hard time implementing them with those frameworks in a maintainable fashion. Also, we were bummed by the fact that we couldn’t reuse parts of what we did elsewhere in a project – search/ result panels for instance – and that we ended up with so much copy paste code and ad-hoc session usage. And for one of the projects, we were developing customer-specific variants. Again, we ran into the problem that it wasn’t easy to reuse elements of the user interface that we had developed elsewhere.

Another reason we were looking for alternatives for web development with Java is that we saw that colleagues who were using ASP.NET were faster and produced better maintainable code than we were with Java. They even had more fun doing it; pretty much everyone on the Java team hated to do the web work.

I started out evaluating JSF, which was by then nearing completion. In my experience however, one of the major problems with the way we were developing web applications was the fact that so much logic was put in templates. Not only does that make refactoring harder, it also means that you get thrown back to a procedural programming model where you can’t reap the benefits like static typing and encapsulation, etc. So I wasn’t to crazy about the role JSPs play(ed) in JSF. I did give JSF a serious look though. I read a book on it, walked through the source code and created a simple proof of concept. But the further I got with it, the more I hated it, up to the point that I simply didn’t want to put any of my spare time with it. I just didn’t like much of the architecture, and man, creating custom JSF components was even more work than creating custom JSP tags (which isn’t exactly the most elegant thing to code either).

After that I looked at Echo. I liked Echo. I still do in fact, even though I never actually worked with it. However, I didn’t think it would be a good choice for what we were doing, because it works with layout managers. As much as I like Swing coding, I actually prefer working with HTML/ CSS to Swing’s layout managers. Furthermore, I had this hope that one day we wouldn’t be translating Photoshop designs into screens ourselves, but rather have a designer creating mockups for us that we could use with minimal adjustments.

I also gave Tapestry (3) a serious look. I started reading Tapestry In Action, looked at the source code (which imho looked a lot better than JSF’s), and started experimenting. Halfway through the book, I had a big stack of ‘why?!’s. I could agree with the thoughts behind the concepts, but I didn’t agree with some of the solutions. Abstract classes, rewinding; it just had this stench of premature optimization to me. Still, I was ready to introduce Tapestry at Topicus, as I thought that it at least looked like an improvement for us. When I started talking to colleagues about this however, it turned out that some people had actually used it before and were quite unhappy with it. I would clearly make a couple of people unhappy by going through with it, so I didn’t.

A couple of months later – I kind of had given up for the moment – colleague Johan stormed into the office saying he found the framework we’ve been looking for: “Wicket”. It was (and is) centered around ‘Just Java’ programming, with clean templates and reusable components. I remember we checked it out, had a simple example running in under an hour and were pretty much sold to the framework that same afternoon. Wicket was very rough, incomplete even, back then, but it had the core ideas right. It was still alpha code, but the code base looked very well engineered, and Wicket already worked well for the things we tested.

So we started building a prototype with Wicket. We had a fun few weeks, and we already agreed that this should be the framework that would give Topicus their competitive edge in the near future. We also felt we weren’t ready to be transformed to be ASP.NET coders just yet. But then Jonathan Locke – the inventor of Wicket – sent a message to the list that he was about to shut down the project because he accepted a job at Microsoft and it would be a conflict of interest for him to keep working on Wicket. That would have such a waste to let that happen! So I got Johan and Martijn in a room, and asked them if they wanted to help out and take Wicket over. We agreed to commit to at least a year of whatever it would take of our spare time to turn
Wicket into a mature project suitable for Topicus, and hopefully with a viable community around it as well. We also invited Juergen and Chris to join us. They were already active on the list and had sent in a few good patches. The cooperation turned out great, and when Jonathan left Microsoft again a few months later (for unrelated reasons), we welcomed him back into a Wicket that was quickly approaching a 1.0 release and had a good core of early adopters.

Martijn Dashorst: Mostly like Eelco’s answer, but from a different perspective: I was a Windows client developer used to build GUI’s with Borland’s VCL. Then I had to build web apps using Maverick and Velocity. I hated that experience and constantly asked myself: WHY is this so hard and so much work. Wicket salvaged me from this negative experience: it felt like returning to VCL programming and for the first time I enjoyed
building web apps.

BP: We have perhaps a hundred Java web frameworks, and Wicket was not among the first of them. However, I like to put Wicket in a separate class from the others, as it offers a new paradigm of web application development. How would you say Wicket fits in this field and what does it bring to Java web developers?

EH: Many of these alternatives are really flavors of the same model 2 ideas. In my opinion, there are basically these frameworks – Struts, WebWork, SpringMVC, whatever-the-flavor-of-the-day – and frameworks like Wicket but also GWT, Echo and Tapestry that really provide a different alternative.

Most web frameworks go through great lengths trying keep their users far away from regular Java programming. Wicket provides a programming model that stays as close to Java as it can, with all the advantages of static typing, encapsulation, etc.

BP: JSF is perhaps Wicket’s strongest competitor (if there is such a thing), and it benefits from Sun’s support, good development tools and a huge set of avaiable components. How is Wicket evolving in terms of tooling support and avaiable components?

EH: Frankly, I think JSF isn’t doing so great when it comes to the availability of components. Much like the component market for ASP.NET, there is a lot of promise but not much delivery if you ask me. Yes, there are a bunch of component libraries out there, but they are often incompatible and are often quite monolithic. The latter is JSF’s fault really.

The fact that Wicket tries to make creating custom components as easy as possible (ideally, as easy as extending a class and maybe providing some markup that goes with it), makes that it is less relevant what
components are out there. You want to have a good base set of components that are easy to extend and/ or customize, and hopefully people will create their own library of components that suit their particular needs.

That said, Wicket actually has an impressive range of custom components. Besides the decent number of components that are available as part of the core Wicket projects, there are a ton of projects in wicket-stuff (of varying quality, but there are a few real gems in there), and there are initiatives like DataBinder and InMethod that provide custom components.

But really the best way to go with Wicket in my opinion is to create a layer of base components for your project that look and behave exactly what you need. A little bit of work upfront, but it can save you a lot of work and maybe even code duplication later on.

FWIW, I don’t view JSF as our largest competitor in Java land; I would think that is GWT. There’s pros and cons to both GWT and Wicket, and I certainly think Wicket has an edge in some areas, but GWT is very cool conceptually, and from what I’ve seen it is very nicely done and even has tooling support that actually works.

BP: We have seen many Ruby on Rails zealots claiming Java’s dead and that RoR is the next big thing. I’d like to know your thoughts on that. Can we consider ourselves Java’s orphans?

EH: Nah. The hype is already sinking in, and you read more about infighting dramas than success stories nowadays. I’ve also heard several stories from developers who actually did do one or two serious RoR projects, and as much as they liked having quick results the first few weeks, they got into a mess later on. Basically, their code base grew, they got more people on the project, all with their own ideas of neat DSL-like constructs and gung-ho LOC saving tricks, and pretty soon no-one understood much of what was going in that code on any more. And some of those people actually did have real scaling problems.

Much of the critique on Java from the RoR camp (and others) was quite justified however, and I think J(2)EE can take much of the blame for that. You can develop quite ‘light’ and practical with Java if you just ignore most of the heavy sounding advice you see on ‘enterprise development’ and use your own brain instead. Unfortunately, the idea that the next step in productivity is dumbing down development by providing more wizards, drag and drop tools and servers that clean your house and do your shopping on the side is wide spread. To me, the most exiting thing about the whole RoR uproar was that it brought back the spot light on coding instead of big fancy tooling and servers.

BP: I know several Wicket developers like Scala, which seems to be a very promising new language. Do you think it will become mainstream in a near future?  Will Wicket have something done in Scala?

EH: That’s hard to say. I like some of the ideas of Scala. It really looks like an incredible piece of work, and there are plenty of things in Scala that I’d love to work with today. It would make working with Wicket a lot more elegant, and it definitively would make my own code a lot nicer.

However. What almost everybody I spoken to about Scala says, is that Scala provides too much freedom, too many ways to achieve the same thing. They may be right. Part of me says, well, it would be great to have a language just for the experienced people who hopefully know how to use constructs with taste. But then again, I haven’t seen much actual Scala code or discussions on the Scala list that give me that warm fuzzy feeling. In fact, when I lurked on their list a while back, quite a number of the discussion were about how to make notations even shorter (and consequently less readable). Research says that the bulk of the cost of producing software comes ‘after version 1.0′, and that’s my own experience as well. Maintainable, understandable and predictable software is what we need, even if it means that you need to write out a few more lines. Less code is great for maintainability, but it needs to be readable at the very least.

Also, I firmly believe Scala needs a *very* good IDE to succeed. I’m a fan of good IDEs. I like the time they save me when looking at new code (code navigation, javadoc hoovers, code generation and completion). Without good IDE support for Scala, I’m simply more productive with Java, even though it means that I have to implement ugly workarounds for things that would have been easy and elegant with Scala. There are some initiatives for IDE support but I think that to get something really good, there has to be industry support. Maybe one of these days a vendor realizes how much of their effort they are wasting on JSF and see the potential in Scala.

Another thing Scala badly needs is a bunch of people who can sell it. The fact that RoR looked sexy from the start might have been quite an important factor in their success, and Scala currently is probably the un-sexiest looking framework on the planet. And that’s ‘just’ a matter of community building really. I’m sure if people are interested in making Scala a success, they can find people to work on their image and get the name out there.

Anyway, we’ll see. I hope Scala can be a good counter to .NET on the long term; it could be the Java variant of F#, and maybe we’ll get our own taste of LINQ with it.

BP: Wicket started as a project on Sourceforge, then it was incubated in Apache Software Foundation, and finally became an Apache top level project. I’d like you to comment on this process of joining the most respected open source foundation. How was this experience?

EH: It actually started as a project on codehaus. Unfortunately, we had problems getting commit rights after we wanted to take over from Jonathan, and after waiting for a few weeks, we decided to move the project to Sourceforge.

The experience was good. We had a couple of mentors who were great in guiding us through and backing us up with discussions.

What we got from moving to Apache is – amongst other things like image and stuff – that we are even more conscious about our community. I think we always had the proper open source attitude, which means so
much that you try to get people to participate, take them seriously in discussions, and understand that it comes with a responsibility, but now we don’t have just our name to keep high, but also Apache’s name.
Oh, and it was very nice to attend conferences and put some faces on the names of the people who have been slaving on their own cool projects.

MD: Joining took longer than we expected, but Apache folks constantly remind me that Wicket was actually one of the fastest projects to go through the incubator. The slowness was really our own fault: we didn’t concentrate on getting out but were too caught up in maintaining three branches. When we axed one main development branch we were able to get out of the incubator in a couple of weeks.

Apache brings us a solid legal foundation to our code. Although this adds more ceremony to releasing and accepting new code made by third parties. I think it is worth the extra effort to have a solid legal foundation at the base of our code.

Another thing that Apache brings and one probably can only understand by experiencing it first hand is that Apache is a Community of projects – not a couple of projects sharing a server. There is a large difference between Apache and sourceforge, googlecode, java.net. The latter three are just servers with a lot of projects on them.

BP: Wicket has a distributed development team, much like most open source projects. I’d like you to describe your development process, and how do you manage the community contributions.

EH: You can find all that on the Apache site! I would say every thing goes very bottom up. Everyone feels responsible to take up things, and activity of most people fluctuates. We have a large, very active community and there is lots of discussion, bug reports and patch submissions (though we can never have enough of those!) happening. We all have our own areas of the code base we like to work on, but in principal, anyone can work on anything. We don’t always do a lot of upfront discussing regarding fixes etc (unless of course, something isn’t clear to start with), but we all keep an eye on the commit logs, and you can regularly see a discussion start about a commit, sometimes resulting in rolling back or further tweaking the code. We’ve worked like that from the start, and I still think it works great.

BP: You guys are finishing the writing of Wicket in Action, the second book on Wicket. I read the first seven chapters, and the book helped me a lot understanding some aspects of the framework. I’d like you to talk about the book experience, and how do you expect it to help Wicket’s adoption.

EH: The third book by now even! Kent Tong also wrote a book on Wicket.

I hope the publisher isn’t reading this, but I hate(d) writing the book. Martijn and I did it primarily for Wicket and it’s community, so that people would have some more ammo convincing their managers to adopt Wicket, and to give Wicket’s users a better understanding of how Wicket can be used successfully. Neither of us wrote a book before, and we figured, oh what the heck, it’s something to brag about in front of the grand kids when we’re 70. Well, we certainly hope the bragging will be good, and many people will benefit from reading it, because it was a lousy experience for us. It brought me back to high school, when I pretty much never did any of my home work (in fact, I would often skip school to work on my C64 programs), but still had enough of a conscience to feel guilty about it. Writing Wicket In Action was like that. I would put things off – hiking, making music, checking out bands – because I felt I had to reserve my evenings and weekends for writing. And often, in the end, I didn’t even get to do much because I was uninspired, or a friend showed up, or we had to do shopping or cleaning the house. And then I’d feel guilty again!

I would sum it up by saying that for me it felt like work, whereas coding on Wicket in my spare time felt like a hobby. If I would do it all over again, I would take a few months off and write during the days. That would probably make the whole thing acceptable (though coding is still much more fun).

MD: One remark: don’t write a book in your spare time. Eelco and I have been writing this book for over 2 years now. This means: no hobbies for 2 years. Bringing laptops with you on vacations to write. Staying
up until 2am writing and getting up at 7am because the day job also needs your attention. And all this for more than 2 years.

If I would have to do it again (which I doubt, my wife would kill me), I would do it full time instead of in the little hours after work.

The book itself is coming together quite nice. We have quite a lot of folks that help us with the book: our early access readers (THANK YOU!) and we have an excellent editorial team. Since Wicket has such a large surface area, I even use the book to learn more or look up things. So you can say it caters to both beginners and more experienced Wicket users.

BP: Wicket recently released the 1.3 version, the first after becoming an Apache project. Could you provide us a vision of the current state and the future of the project?

EH: We are regularly discussing this on the list, and we’re currently working on Wicket 1.4.

1.3 is a solid release. 1.2 can be used in production environments just fine, but 1.3 is optimized in many ways, and we got most of our API streamlined in a fashion that should last for a few years now.

1.4 has a limited scope in that it only introduces generics and Wicket with a couple of other Java 5 features people have been wanting for a long time. 1.4 should be backwards compatible. You’ll just see plenty of warnings when you don’t use generics. So Wicket In Action should be good for 1.4 without adoption.

What we’ll do after that is open to debate. We definitively got the message from all the ex-Tapestry users that we should not go overboard with API changes between releases, so we’ll do our best to keep providing smooth upgrade paths between releases.

One thing we’ll probably look at is how to make controlling what URLs are generated even better. This is very flexible already, but a bit clunky at times.

Closures could make Wicket a lot nicer to work with as well. Though, considering that we just now switched to Java 5, that might take a while to get into the framework.

And who knows… if Scala gets good IDE support and a good sized following, I think it would be exiting to see what we could do with it in for Wicket. I think we could build on top of the Java version, and provide a thin framework that makes working with Wicket in Scala smooth.

MD: The future will bring beautiful things. I expect us to work on better integration with JavaScript libraries and trying to implement the Yahoo rules for performance (merging javascript files into one to limit the number of http requests, etc). Versioning of JavaScript libraries is also something I like to see solved in the future. We are also going to take a good look at our unit testing framework: it is pretty solid but the API doesn’t feel Wicket like. I’d also like to integrate an animation framework into our Ajax implementation to
enable effects when updating pages. I think that it currently is harder to do than strictly necessary.

BP: Closing thoughts…

EH: Thanks for the interview! And download the first chapter of Wicket In Action for free at: http://www.manning.com/dashorst/; even if Wicket isn’t your thing, I hope it gives readers some background in the problems it tries to solve.

MD: I know that a couple of Brazilian companies have adopted Wicket for their main development. I’d like to see a Brazilian community evolve and generate such events as we have in Europe (Amsterdam, London, Copenhagen) because I’d love to visit your country again . If you are not a Wicket user, then check out our examples: http://wicketstuff.org/wicket13 or http://wicketstuff.org/wicket14 (may not be available now, but will in the future). Our community is very welcoming and active: join our user list to ask questions and
help out. Join the dev list to help us make a framework you want to use. And if you don’t fancy email, you can join our irc channel that is always available: ##wicket at irc.freenode.net. Obrigado!

Well, if you read til this point, I hope you’ve enjoyed! Please leave your comments if you wish.

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

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!

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.