I felt brave this evening and upgraded this server to run Debian Etch since it’s been marked stable now. The upgrade was not without it’s flaws and the server experienced some down time so if you found the site unavailable in the past few hours, now you know why.

I still have no idea what kernel I’m supposed to use with the fancy virtualization – I suspect that it doesn’t really matter since the virtualization software seems to handle that level of things. Either way, the server rebooted and came back with everything working so I don’t really care.

As part of a restructure of the engineering team last week I was moved into a product management role, focussing on our ready-made integrations with third party products (eg: our Alfresco integration) and to be formally in charge of LiveWorks! There’s a bunch of details regarding what the new role entails that I’m still not completely clear on, but I’m sure they’ll be worked out soon enough. I expect there will still be a fair bit of technical work so I’ll still be hands on to a reasonable degree, but what I currently see the job being about is community. There are a number of aspects to this:

I’ve reached a point where I really need a logging framework for a small library. The trouble with logging in small libraries is that you want to avoid using a full logging system like Log4J or java.util.logging so that applications that use your library are still free to pick the logging system they want to use. Jakarta Commons Logging has been the de-facto solution for these situations for quite a while now, but it’s a library that people love to hate because of “class loading issues”. Now I happen to know a fair bit about class loaders, I know why the problems occurred with Commons Logging, I know how to avoid them, work around them and I understand why they’re not a fundamental flaw of commons logging. However, I also know that commons logging is a very simple logging framework and there is scope for a project to build on the basic idea of commons logging but provide more power and flexibility rather than just the absolute lowest common denominator functionality.

I’m going to show my ignorance of the actual differences between URLs and URIs here, but I was a bit surprised by the fact that java.net.URL didn’t extend from java.net.URI. Along those lines URL.toURI() suggests that some URLs can’t be converted to URIs. Is this just in the context of the URLs that Java previously successfully parsed or is this a generic constraint?

My main reason for asking is I’m trying to determine, when implementing an HTTP caching library, I should be using java.net.URI or java.net.URL to identify the source of resources. My original thought was to use java.net.URL because that’s what pretty much everything uses and besides I’m used to support Java 1.3 (URI was only added in Java 1.4). Somehow that seemed overly specific and I should use URI instead. Partly this is because it felt more generic and partly because it just seemed to have more geek cred. I must admit though I really don’t have a firm grasp on which I should use when and why. So dear lazy web, can you help?

One of the new features in EditLive! 6.1 that we released today is a plug-in architecture that handles deployment of extensions to the editor. Plug-ins in Java apps are pretty common these days, but there aren’t all that many applets that have them so I thought it would be worth documenting some of the challenges we faced and how we overcame them.

The biggest differences between plug-ins for applications vs applets are:

One of the things we’ve been wanting to do for ages was automate our release process so that with the click of a button we’ve deployed a new version out to customers. Today, at least for EditLive! itself, that became a reality, with the “autodeployer” being tested out with it’s new release capabilities.

At first glance it looks like releasing a commercial product like ours would be really straight forward, but there’s a surprising amount to it. No one step is difficult, but there are a lot of different systems involved from our main web site, to our source control, build machine, release notification system, integrations, demos etc. As usual for automation projects, the biggest challenge is working out exactly what you are doing manually. Finding the right way to automate it tends to be pretty simple once you understand what you actually do.

I’ve just spent the past three or four hours setting up Apache, Subversion, all my browsers etc etc to use SSL connections and client certificates for authentication with my Debian stable server. I’m sure the mod_ssl devs already know what’s coming here and are either chuckling gleefully or ripping their hair out right now. Anyway, the joke for all those who are mod_ssl devs, is that you can’t get subversion to use client certificates with a Debian stable server because Debian stable has Apache 2.0.54, complete with everybody’s favorite mod_ssl bug. It’s fixed in Apache 2.2, but not in 2.0.

Just a reminder for those in Brisbane that the Redemption 101 Movie Premiere is on tonight, 6:30pm at the Schonell Theatre, Union Rd. University of Queensland, St Lucia. It’s a light hearted, quirky, full-length science fiction film made by a local studio. Party with the, er, stars, afterwards and best of all, have something to poke fun at me with.

And for those who aren’t in Brisbane and can’t make it, check out the trailer below and buy a DVD from the website.

Most issue tracking/customer relation/todo list things have a concept of resolving an issue for later or a remind me later option. The idea is that you don’t want to or can’t deal with the issue straight away, but you need to come back and review it or follow up later.

Unfortunately, it turns out that marking an issue for later tends to mean “make this disappear so I have no chance of remembering it” because the issue disappears from all the open issues lists forever. Many systems have an option to e-mail you regularly about issues that are marked as remind or later, but the e-mails are hit and miss – usually they remind you about the issue too early and you just get used to ignoring them.

There is an awful lot of money spent on user interface research, carefully tracking what users do with an application and trying to find ways to improve based on that. It’s a shame that so much of it is wasted because the captured data is misinterpreted.

The Office 2007 Ribbon is a classic example of this, it was clear that Microsoft had real world data to back up their decisions about the Ribbon, they’d spent millions on it. Yet somehow it just didn’t seem right to me. Turns out at least Damien agrees with me. It turns out that despite the fact that usage data shows that users work in different modes, designing an interface that reflects those modes isn’t ideal.

Rob posted about his second month at Ephox and it made me realize it’s been a while since I’ve taken the time to reflect on how things are going for me. Warning, lots of rambling ahead with no attempt at editing.

Towards the end of last year it had gotten too long between holidays and I was getting stressed out and generally sick of work in general. Fortunately, if you haven’t taken holidays for a long time you also have a lot to take, so I took all of January off to recuperate. Since then I’ve been working on my own for the most part with the rest of the team tied up with other projects. I must admit, I quite enjoy going off and coding stuff on my own, still doing TDD and all the other XP practices except of course pairing. It does however tend to let the odd thing slip through and we’ve seen a few issues crop up that we’ve had to fix. Fortunately, since we run the latest builds internally the problems were caught before clients saw them. I’m really not sure if a pair would have picked them up anyway, but it may have helped.

Nice article from the Chief Happiness Officer this morning on pimping your office. Most of the things listed are just over the top, but I really did like the look of Softwall. If Ephox winds up moving offices we should definitely think about using these – it’d let us have an open plan development environment with the flexibility to close off sections as needed.

Very cool.