One of the popular geek pissing contests is comparing how far back your email archives go. It’s a game I’ve enjoyed playing in the past and quite regularly one given that I’d never deleted an email (ahh the days before spam…). Still, as Andy has just discovered, it’s not always as useful as it first seems:

 I have to say though I’m not sure keeping all of this email was the best idea. I’ve glanced at a few old emails while sorting this evening and… well put it this way, would you want a detailed account of your uni years? If your email is just building up without requiring any effort on your part then there’s no real advantage to deleting it and it may as well sit there. Once you come to expend time and effort migrating that email though it just becomes a waste of your time. The trouble is, now that you’ve got all that email, you’ve got no idea which bits are important to keep and which aren’t. You’re stuck on the treadmill of migrations until it eventually gets so time consuming that you figure it’s easier to just dump everything and start again.

It occurs to me that for the past two years I’ve written at least one post a week (not as much here, mostly over there). In the next week or two I’ll be spending most of my time writing demo scripts, white papers, various other technical documentation and a couple of speeches. I’m pretty sure if I counted it all up I’d have written way more English than I have Java or any other programming language. That’s not even counting email, which I’ve been writing tons more of.

Shelley Powers on Burning Bird’s RealTech:

We’ll see a significant reduction in MSIE corporate users, as many will get laid off. Fair cop…

With LiveWorks! turning two it’s gone through a major stage of growing up and now sports the official Ephox website look rather than it’s more youthful green tinge.  The different look was originally put in place because LiveWorks! was designed to hold a bunch of unofficial, unsupported, experimental stuff – most of which is still there but has gradually become more supported and much less scary to use in actual production systems. In the mean time, we’ve added a ton of new, really useful, very much supported (i.e. used as answers to support questions) content which we want users to find and use.

Believe it or not, it’s been almost exactly 2 years since I kicked off LiveWorks! as essentially a skunk-works project to get some of our internal experiments out into the open so they proved useful. As it turns out the bigger success has been the weekly hints and tips that we started adding a few months later. Unless one of the migrations has messed up the dates, the first tip was a simple overview of how to integrate EditLive! that Rob wrote. I still regularly refer people to that article.  Since then we’ve posted a new article every single week without fail.

Geir turns out to be the latest in a very long and prestigious line of folk to bring up a rather common fallacy that I find amusing:

I’d love to see a common UI for things like this, just like cars have a common UI for the basics Cars do have some things that are very much similar – they have a steering wheel and at least an accelerator and brake. That’s good and while you could define that as the basics as Geir was probably thinking, that’s about the same complexity as turning on a computer and maybe opening a program or two.

Dylan posted a good blog post at a ridiculous time of night last night discussing software architecture, his role in it and more. Firstly, it’s really good to see these kinds of blog posts appearing – Ephox has gotten really slack at blogging and I think that’s a shame because we have a lot of good stuff to say. Actually publishing things makes you actually think it through and it allows people to build on those ideas and improve them. It’s always hard to find the time and energy to blog, but it’s worth it.

Antonio Cangiano:

In theory I could have been disappointed. After all, my visit didn’t fix the problem at hand, my expensive laptop seemed to be good as a door stopper, and repairing this thing could potentially be less advantageous than just buying a newer unit. Yet, as I arrived home, I told my wife that my next laptop would definitely be an Apple.

The reason for this is that I saw a genuine effort to help me out, an unheard level of care for the customer and an willingness to do what’s right, even if it costs the company some money. The whole experience was very positive and I felt that the premium cost of Apple’s products is easily justified by this kind of support.

If you haven’t heard already, we’re spending our first Christmas away up in the Swiss Alps so we’ll be sure to get a white Christmas.  We actually found a self guided tour from an Australian company which includes the hotel, Christmas lunch, a sleigh ride and a suggested itinerary for exploring Switzerland. The train ticket they give us includes most of the travel around the country and discounts off the optional parts so we should wind up seeing quite a lot of the country.

Andy Baio did an experiment with Mechanical Turk which is somewhat interesting on it’s own, but what really caught my eye was:

Upload a photo of yourself…

DON’T provide any identifiable information, like your name or email, since that’s a violation of MTurk policy.

When did technology take over so much that our face, the single most important aspect our brains use in identifying people, become not personally identifiable information?

One of the hardest types of bugs to track down is a deadlock situation. They are very time dependant which makes them intermitten, specific to a particular computer and configuration and generally impossible to reproduce in a debugger. Fortunately, at least in Java, it’s fairly easy to spot most of the situations where a deadlock is possible:

1. Calls to SwingUtilities.invokeAndWait
2. Calls to Object.wait()
3. synchronized blocks

There might be a few others depending on the libraries you’re using, but starting with those three, in that order, is very likely to lead you to at least one point in the deadlock.  Just put an old fashioned System.err.println before and after each of those calls and you’ll quite quickly see where things are waiting forever.

While many web visionaries are busy advocating the correct use of ETags and URIs etc etc, I just wish people could get the very basics of HTTP right.  I’m not even talking about mime-types here, just status codes would be a really good place to start.

If you’re returning the page as requested, use 200.

If you’re returning a server error, use 500.

If the requested page doesn’t exist, use 404.