I think we‘re far enough along to finally announce this: Trails is moving to Codehaus. I‘ve been less than thrilled with my Java.net site for some time and looking for something better. One of the newer members of the Trails community suggested Codehaus and took the lead in making the move happen. We have a much nicer looking website (I think) at www.trailsframework.org And we've mavenized to make it much easier to get a Trails project started. Check out the Quickstart Guide  for starting a Trails project with maven2. Still got a bit more work moving the mailing lists and bring over JIRA issues. But we should be ready to officially “launch” the new Trails website with the 1.0 beta release.

Update

Kudos to Brian Topping for making this move happen! Thanks Brian, and sorry for neglecting to mention you by name.

Just got back from an awesome weekend at NFSJ Cincinnati. This year I‘ve had the privilege to speak at TSSJS, JavaOne, and NFJS. All three have been interesting and fun, but from an attendee perspective it isn‘t even close: NFJS blows the others away. It‘s not necessarily just the content even (TSSJS usually has excellent sessions as well). The fact that NFJS is kept small by design (< 200) people is what makes it such a great experience. The chance for all the attendees to “hang out” with speakers and pick their brains in depth just doesn‘ exist elsewhere. It was great getting a chance to speak, but getting to attend was even better. I don‘t have time to blog about all the excellent sessions I attended just now, but I‘ll try to cover the highlights later on.

When I first saw Tapestry 4 and learned that it had it a DI framework built in my reaction was “Hmm.. interesting“. I didn‘t immediately grok the significance. When I saw the DI framework was not Spring, my reaction (along with many others) was “Why??“. Well, it took awhile, but after having benefited from the power of Hivemind in Tapestry I can say I “get it” now.

The thing that makes Tap4 so powerful is that almost everything is pluggable and decoupled. Persisting things to the session (or not) is a service. Writing links with parameters is a service. Just to name a couple. Sure, great, you could do that with Spring right?. Fine, but then let‘s think about how that might look. Somewhere in the Tapestry jar there would be a ginormous XML file with all the services defined. What if you wanted to change one? Ok, unjar Tapestry and search the ginormous XML for the one thing you want to change. Then rebuild the jar. Oh, and be sure to not to screw anything else up while you‘re modifying the XML or Tapestry is broken. Oh, and be sure to do this again everytime there is a new Tapestry release. Sound like fun?

Now let‘s talk about how things actually do work in Tapestry. Let‘s take a real world example: link parameters. In Tapestry, links bind to listener methods. These listener methods can take parameters. But what‘s cool is that the link parameters don‘t have to be simple Strings but can be real objects. So displayCustomer link can bind to a display(Customer customer) method. As long as Customer is Serializable, Tap4 can write a link for it and pass it along. Of course, if Customer is big your links may be pretty out of control ;)

But what really rocks is that you can easily tell Tapestry how to encode link parameters in a diffent way. And what‘s more, you can do this without touching Tapestry directly. This is what Hivemind makes possible. In Hivemind, all the services can be overriden or added to by “contributions“ from your own code. By adding an XML file anywhere on the classpath you can define just the one piece of Tapestry you want to change. This makes some pretty neat stuff possible. On Trails we actually use another project called Tapernate that “teaches” Tapestry how to write links for Hibernate objects by adding to the link encoding service in Tap4. By simply dropping the Tapernate jar on the classpath, Tapestry will now recognize any Hiberate object and write out a link containing the class name and id value. On the receiving side it will then look up the object from Hibernate and pass the method a live object on the the Hibernate session so all lazy relationships work properly. Magic, eh?

The more agile/XP practices I get a chance to apply on the job, the more I become convinced that they are not just good ideas, they are indispensable. This happened to me a long time ago with unit testing, more recently with continuous integration, and most recently with pair programming. Pairing is probably the most controversial of the XP practices, and even when I talk to people from Agile or XP shops they readily acknowledge they don‘t do this very much.

First off, let me admit being biased on this. I really enjoy pair programming. I find it incredibly more enjoyable and productive to do anything but the most basic grunt work in pair. But part of the reason I enjoy it so much is that it absolutely amazes me how much more productive it is, and how much better work comes out. The ideas that come up out of a pair session are almost always better than either programmer would have come up with on their own, I‘m convinced. And often jaw-droppingly better. I can‘t tell you how many times I‘ve been up against what seemed like a difficult task and bounced my planned idea off my partner and an incredibly simpler solution than mine will pop out.

The big question I‘ve always heard about pairing is “Doesn‘t that mean each task will take twice the man hours?“. I‘ve seen the research that indicates this just isn‘t true. And now I‘ve experienced and measured it on a real project. We‘ve actually measured iterations where we do pairing against those where we don‘t. We saw no drop in per programmmer velocity. What that means is you really done get twice as much done together as separately. There is no “pair programming penalty“.

Ok, fine, this would mean pairing or not pairing makes no noticable speed difference overall. But this would ignore the quality difference. I ran up against this today in some code that had not been done in pair compared with code that had. It wasn‘t fun. The quality difference was astonishing. It‘s harder to measure design quality of course, but it‘s easy to spot when you see it.

So when will this, like other XP best practices, “catch on” for real? Soon, I hope.

So I‘ve had 2 “media events” here recently. Not long ago my tech talk came out on TSSJS. And here today I found a recording of my JavaOne presentation.  Listening to yourself is wierd. Watching yourself is even wierder. I couldn‘t even bring myself to watch all of the TSS interview, I made other people watch it for me. I don‘t know why, it was just too strange. I kept wanting to tell myself “Quit saying ‘ya know‘ so much“ or “Man my face looks fat!”.

I‘m sure glad I‘m not on TV for a living :)