Para uma referência dos ratings do Page Speed e YSlow, sites com rating acima de 80 podem ser considerados muito bons. É possível chegar até  90 sem configurações muito complicadas. Até hoje, o site com os maiores ratings que já encontrei em toda a internet é o site da Caelum. Rodei agora os testes e eles estão c/ 96 no Page Speed e 100 no YSlow. O meu blog está c/ 85 no Page Speed e 84 no YSlow

A maioria das técnicas de otimização é simples de aplicar, e é possível ter ótimos resultados com bem pouco trabalho. Escreverei uma série de posts curtos e objetivos explicando as principais técnicas e mostrando como utilizá-las nas arquiteturas mais comumente usadas.

Motivação

Todos os browsers modernos possuem recursos de descompressão de conteúdo, e boa parte dos arquivos servidos em aplicações web podem ser bem comprimidos. Habilitando compressão no servidor o tempo de resposta das páginas diminui, e com isso cai também o tráfego do servidor.

Como fazer

O servidor web mais utilizado na internet é o Apache. Mostrarei inicialmente a configuração somente dele, e caso alguém queira saber também do IIS e nginx, complementarei posteriormente.

Para habilitar a compressão, deve estar ativo mod_deflate. No Ubuntu você pode verificar os módulos ativos listando o diretório /etc/apache2/mods-enabled.

A opção mais simples de configuração é utilizar a diretiva: SetOutputFilter DEFLATE

Esta opção habilita compressão para tudo, no escopo onde for colocada. Podemos habilitar compressão em um virtual host, em um diretório ou até mesmo em todos os arquivos servidos pelo Apache.

Outra opção é habilitar compressão somente para alguns tipos de arquivos, com esta diretiva: AddOutputFilterByType DEFLATE text/html text/plain text/xml

Na documentação do mod_deflate há cenários mais complicados, como verificações do browser, manipulação de cabeçalhos HTTP, consumo de conteúdo comprimido, entre outras coisas. Se alguém tiver dúvidas posso ajudar no setup de testes.

Verificando que funcionou

Para verificar que a compressão está ativa, podemos utilizar o Poster para requisitar uma página do site e conferir o cabeçalho Content-Encoding da resposta, conforme imagem abaixo. Se aparecer o encoding gzip, a compressão está ativa.

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

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

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

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

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

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

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

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

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.

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.

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!

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

Os detalhes do projeto podem ser vistos na página do java.net, mas a arquiteturá básica terá Apache Tomcat 6.0.x + Apache Derby 10.x + Java RE 6 + Apache Wicket como framework web.

Quando tiver mais novidades do projeto, voltarei a postar aqui!

Embora não seja a mesma coisa, de certa forma podemos dizer que o AtomPub está para os web services REST assim como um framework como o Struts está para o desenvolvimento web. A comparação não é tão boa porque o AtomPub ainda é mais uma “inspiração” de implementação, um exemplo bem-sucedido de web services REST, enquanto o Struts é um framework para desenvolvimento web, no qual muitas aplicações estão baseadas e foram construídas por cima.

O AtomPub chega em ótimo momento, pois os web services REST vêm se firmando como uma ótima opção de implementação em boa parte dos casos, comparando com SOAP. Entretanto, REST é apenas um estilo de arquitetura, que permite uma enorme flexibilidade em termos de implementação. Como as idéias propostas pela arquitetura REST são abstratas em alguns aspectos, analisar como o AtomPub foi implementado é muito interessante e esclarecedor.

Um projeto open source que oferece uma API para criar, editar, ler e remover posts e feeds no formato Atom utilizando o Atom Publishing Protocol é o Apache Abdera. Este projeto ainda está incubado na Apache e ainda não está nem em beta, mas as releases atuais de desenvolvimento já permitem fazer algumas coisas interessantes e o projeto promete crescer, pois o Mule já está o utilizando como componente para implementação de web services REST no ESB deles.

Eu já consegui fazer uns exemplos legais com o Abdera, publicando através da API deles uns posts no blogger do Google e criando eventos no Google Calendar. Ainda estou estudando e conhecendo melhor o AtomPub, e o Abdera, mas tenho certeza de que veremos coisas boas daí, e penso que este é o caminho mais promissor de web services atualmente. Can’t wait to get to know it even better!

Quando souber de mais coisas interessantes nesse assunto, publicarei aqui!

Eu estou desenvolvendo no meu tempo vago um software para advogados. O principal intuito deste software é permitir a gerência de processos, clientes, audiências, reuniões, etc. A idéia é que o software possa ser utilizado individualmente por um advogado ou de forma compartilhada em um escritório por exemplo. A aplicação é Java e possui interface web. Qualquer pessoa com acesso à máquina onde a aplicação estiver rodando pode utilizar a mesma.

A idéia de instalar um servidor de aplicações e um servidor de banco de dados em um escritório não é tão amedrontadora, embora de certa forma dificulte a distribuição em massa da aplicação. Porém, imaginem que para utilizar a aplicação individualmente em uma máquina em casa um advogado precise instalar o Java e um servidor de aplicações, instalar um servidor de banco de dados, copiar a aplicação para o servidor de aplicações e então usar o software. That’s not gonna happen, forget it!!

Qual seria uma solução mais fácil? Criar um instalador que faça estas instalações todas, crie atalhos, etc? Acho que isso resolveria sim. Mas eu não tenho muita experiência em criar instaladores, e eu também quero permitir que a aplicação seja utilizada no Linux e no Mac OS além do Windows. Prefiro uma solução ainda mais fácil que a de um instalador.

Todo mundo hoje em dia possui algum software de compactação (zip, rar, etc) em casa, e acredito que qualquer pessoa que se proponha a utilizar um software para advogados saiba descompactar arquivos. E se fosse possível fornecer um único arquivo zipado para o usuário e este precisasse apenas descompactar o arquivo para qualquer diretório de sua preferência e clicar em um atalho para utilizar o software? Isto é ainda mais fácil que um instalador, não é?

O Jira Standalone é distribuído como um zip que você precisa apenas descompactar e usar, contanto que a sua máquina possua Java instalado (e que o Jira encontre seu Java). Eu gostei bastante desta forma de distribuição, ela é muuuuito mais prática do que a instalação do Trac ou do Bugzilla por exemplo.

Entretanto, eu não quero exigir que um advogado tenha instalado previamente o Java e muito menos que ele configure qualquer variável de ambiente para utilizar meu software. Então resolvi facilitar a vida deles. A minha aplicação web utilizará o Tomcat, Wicket e o Derby como banco de dados, e eu vou distribuir tudo isso empacotado junto com JRE em um único zip para que o usuário descompacte e use.

Fazendo isto eu consigo garantir que todos os requisitos da aplicação estarão presentes e bem configurados, e de lambuja saberei sempre que as versões de todos os componentes são compatíveis, porque eu distribuirei versões previamente validadas de todos eles. Quando eu quiser atualizar a versão de tudo, sem problemas também.

A propósito, já li as licenças de cada um dos componentes e eu posso livremente distribuí-los ao usuário final sem custos, contanto que eu distribua o JRE da forma que obtive da Sun.

Open source is powerful and beautiful, isn’t it? E aí, o que acham desta forma de distribuição? Críticas são bem-vindas!