JRebels with a JCause

JRebel has a great elevator pitch: install a simple tool and ensure your developers never have to do a repetitive, time-wasting task again. You don’t need a time-and-motion study to see the benefits to productivity – who wouldn’t want it?

The repetitive task JRebel eliminates is redeploying your application inside a container like Tomcat. If you’re developing a web application in Java, you may find yourself doing this every time you change a class, so you can get speedy feedback. With JRebel, your changes just magically appear in the deployed application – no human intervention required.

This would have been a lifesaver for us a couple of years ago. Back then, redeploying our app was something we all did hundreds of times a day, and it took minutes to complete – due in part to Hibernate caching the world at startup. And thanks to the lovely PermGen OutOfMemory error, every six or seven times you’d actually have to restart Tomcat, which took even longer. We could have gotten a lot of swordfighting done in those wasted hours every day.

However, as we try it out we’re finding that JRebel is less useful for us now than it would have been then, because:

  • We have much faster machines – a full Tomcat bounce takes under 20 seconds. At these speeds, there’s no point trying to optimise by redeploying – just start the bounce script, sip your coffee twice, and get back to work.
  • We use Test-Driven Development, which gives us an easy way to get immediate feedback on every code change as soon as we make it, no deployment needed. So we look at the changes in the application less often, which in turn means fewer bounces.
  • We couldn’t get JRebel to handle some of the clever code we write these days:
    • New static final objects didn’t show up in the application automatically. We use a lot of these in our controller code.
    • Adding a missing @Inject annotation to make Guice happy didn’t, because the change didn’t deploy. We use Guice to simplify our code and eliminate factories and singletons.
  • Looking at code JRebel had reloaded in the debugger was a confusing experience. Some ordinary objects showed up as opaque handles instead of their normal selves, and where our code dynamically reads a field on an object using reflection, we found that JRebel replaced this object with a Serializable with no methods or fields.

We had heard great things about JRebel, so we were a bit surprised by these results and consulted a friend from CITCON, David Gageot of Tech4Quant. David tells us that he finds JRebel invaluable in one particular case – editing Java Server Pages (JSPs). Because JSPs are a bit of a Frankenstein mix of HTML and Java, developers can wind up in a very tight tweak-view-tweak again loop getting the UI just right, and if seeing application changes means a restart and login every time, those are going to be some frustrated coders.

It’s clear that JRebel is a real lifesaver for David and probably would be for anyone using JSPs or similar code. Since we don’t, we’re unlikely to use it in a serious way. But we can certainly admire the JRebel team for solving a very hard problem elegantly!

Stay Out Of My Guts!

Our latest code-quality theme was the Law of Demeter, more descriptively known as The Principle of Least Knowledge or Stay Out of My Guts. Applying this rule helps you reduce dependencies in your code and avoid painful coupling (where to change A, you have to change B, which means you have to change C – a familiar litany in lots of our code).

We found several examples relevant to the Law of Demeter in our code, including

  • a data-holder class whose only methods manipulate its private members (sort of like a high-maintenance struct) – we converted this from a Shame item to a Fame item by replacing the data-holder with a simple primitive object
  • a couple of train wrecks with four successive method calls

You may enjoy the demotivational posters we came up with to illustrate the Law of Demeter:

Because a train wreck will spoil your day
One dot is enough
Stay out of my guts

JUnit 4.7 Rules, Dude!

Most popular software fades after awhile, but a few classics just keep dominating their markets. JUnit was the first unit-testing tool for Java. It faded for a bit and others, such as TestNG started to appear, but JUnit has come back strong. The latest release, 4.7, just went out the door with a cool new feature called Rules that will help us eliminate all kinds of special cases and test subclassing that make our tests less readable. Kent has a lot more to say about them, but to summarise they’re like test hooks on steroids. Want to log every test? Guarantee you close a database connection or a file in every test? Timeout every test? Use a Rule. Awesome!

At youDevise we will probably use it to mix and match test capabilties. Want a browser test that also has access to the database? No problem, just use the Browser and DatabaseAccess roles! I can see the possibilities opening up already.

Continuous Deployment

At one of the sessions that I attended at CITCON Europe 2009 Chris Read (I think it was him) talked about build pipelines and continuous deployment. As he explained his view on what continuous deployment means, I had a bit of an epiphany. We are already doing it! Of a sort. I say “of a sort” because we still are not perfect. We can’t deploy 50 times a day, but we can deploy often, reliably, and quickly (we have deployed a new version of the HIP nearly every other Saturday for the past year that I have been working here, each deploy normally takes just a few minutes). Every release that we do has also passed through our CI system. In fact every release that we do has to. The only release candidates are those that have been through this testing procedure, and any passing builds are automatically added to the list of release candidates.

Our deployments still require a little manual intervention (copying a file), but that is something that we are working on. At the moment we are overhauling our deployment mechanisms so that deploying a new release of either of our applications turns into a single click. This should make us able to deploy even more quickly and smoothly.

At previous companies I have worked we didn’t have this ability and we didn’t think that being able to do it was needed. After now having this ability I can’t imagine not being able to do it. No more fear of deploying. No more babying deploys. It all just works.

It is things like this that make you start to wonder maybe there really is value in a change even though you can’t see it right now. Maybe updating our deployment process and infrastructure so that we can deploy at any time during the day would have immense benefits that we just can’t see right now.

Insane Continuous Integration Video

We like to think we’re pretty good at continuous integration, and we were feeling rather proud after being able to give some advice to others at CITCON. Hey, we’re doing pretty well on that there CI Maturity Model, eh?

Andy Parker brought us back down with a bump by reminding us that companies who are really slick will never even bother to go to conferences or boast about their amazing skillz in blog posts. The reason is simple: there’s nothing they can learn from anyone else any more, so why bother? The classic example is Google, who apparently know more than anyone else on the planet about running giant server farms, and hardly ever tell anyone how they do it.

So it’s great to get an opportunity to peek under the hood of one company that does certifiably insane continuous integration, IMVU. Check out this hour-long video in which they describe releasing to production 50 times a day with automated rollback when any business metric drops and Stop the Line for every failure. Hmmm, guess we have some more to do – time to go fix that intermittent Javascript hang and find a blade server that comes with four hard drives.