So everyone knows Google has a vast amount of data about you and that Google tracking cookie that basically never expires. Now they own Double Click, completely with it’s own tracking cookie that tracks you on pretty much every site on the internet.

Essentially, Google now know what you search for, which links you follow and now between Google AdSense and Double Click, they probably know everything you do on that site pretty much regardless of which site you pick.

We took delivery of a brand new, shiny Dell preloaded with Vista today and I set about setting it up as a pairing station. Sadly, in the first 30 minutes I’d crashed Vista to the point of having to hard reset the entire machine.

Finding anything in the control panels is a nightmare, not just because it’s impossible to guess where things will be, but because it takes so many more clicks to get there now. Worse still, when you finally do get there, you wind up looking at the old XP dialog. What’s the point of all the fancy graphics and categorization if when it comes down to it I’m still confronted by an ugly, confusing dialog with a million tabs and settings coming out it’s ears?

If you’ve recently upgraded to PHP 5.2.1 (which is included in an upgrade to Debian Etch, the new Debian stable distribution), use WordPress, use the secure admin plugin and are now just seeing a blank page when you view your blog, I have a solution.

Quick Fix

For those who don’t care why this is broken and what I’ve done to fix it, you probably just want to download the updated plugin which works on my server, with my very brief testing. If you see any problems let me know, but be warned that it is very much untested and could destroy everything – make sure you have a good backup and try it on a friends blog first. I strongly suggest you wait until Haris takes a look at this and comments on whether it covers all the original functionality or not – I could easily have missed something critical. I’m also not sure if this works on versions of WordPress before 2.1.3.

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.