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.

James Duncan Davidson did the math and found he was better off without a land line phone:

Once the numbers have been looked it, however, it makes more sense to just go all the way. Of course, if $2400 per year was the only way to have decent access to the Internet, it’d be a different story. But it doesn’t need to cost that much anymore. So I’m cutting the twisted pair lines. Because, you know, they are historic and quant. Sure, a land line still sounds better than most mobile phone calls, but 3G calls are getting there in terms of clarity and on a good day sound as good to me as a land line. In a few years, they’ll be even better. Interestingly, I just got my phone bill from BT and am more glad than ever that I have a land line:

While reviewing some screen mockups for EditLive! today, it occurred to me just how limited an environment we’re forced to work in. It turns out that the default, and thus most common, size of a rich text area in IBM WCM is 740×450 (note to Ephoxians, I mistakenly quoted this as 740×360 earlier so we have slightly more vertical space than I thought).  Even in my blog’s editing interface, the editor is 718×600.

IWWCM has a component specifically to provide “inline editing” – in other words, adding links to content items so you can quickly edit, accept, reject or delete if you’re logged in as a user who has permission to do such things.  I have two problems with this approach:

1. You have to be logged in to see the links.
2. The links affect the way the page looks so you don’t see the site the same way as normal visitors.

Within a portal environment or even an intranet, neither of those problems really apply, but when you’re publishing out a public website they can be an issue.

You’re sitting on the train listening to music on your iPhone. Your wife rings, you answer it and the girl sitting cross from you suddenly gives you an odd look. What went wrong? When you have headphones in the iPhone makes no audible ringing noise. So people around you have no idea that you just took a call. Not that Id change this but it does generate some odd looks. Especially when you answer with “hey sweety”. Oh well.

The Ephox bloggers have been way too quiet lately (myself included) so I thought I’d start an Ephox meme. What’s your 5 favorite features of any of Ephox’s products?  They might be built in or plugins that we’ve developed, maybe even features of our internal systems that make your life easier, but preferably something that our clients could get hold of (teasing people just isn’t nice).

Here’s my list:

1. Built-in Image Editor. Particularly being able to resize an image and add rounded corners and drop shadow.
2. Pop out window mode. More editing space is always good.
3. Automatically detecting URLs on the clipboard and using them as the default value in the hyperlink dialog.
4. Styles menu. Not that I use it on this blog, but having access to classes in the site style sheet make it so easy  to apply some really nice formatting with just a couple of clicks.  The styles package prototype we use internally a lot is particularly useful for this.
5. The extensible APIs. It’s so nice to be able to quickly add support for footnotes, a shiny button generator or whatever I happen to want this week. I wish more clients used this functionality to make life easier for their users – even if it was just by providing a handful of simple templates they could insert.

I tag Suneth, Damien and Brett…

For future reference, James Tauber has a very useful article on using the HSL color scheme to create shiny gradient buttons.  It’s worth knowing that in Java HSL is actually called HSB (brightness instead of luminosity) and there are various methods on the java.awt.Color class for converting between HSB and RGB as well as creating color objects directly from HSB.

After my amazingly successful use of mod_proxy to provide clean URLs in an IWWCM instance, it’s been added to my bag of useful tricks to know about.  When you realize you can proxy differently based on the current virtual host it’s a very powerful solution.

My latest use for it was to add name based virtual host support to two completely separate virtual machines.  One machine runs IBM WCM and the other runs Quickr. Both use the same port, and in the future there will be more VMs with different versions as well, so while it would be possible to assign different port numbers, I’d prefer to not have to remember which VM is using which port etc.  The firewall however can only forward connections on a given port to one VM.

I was going to write a post around accessibility and WCAG 2.0 but got annoyed once again about the EditLive! toolbar taking up two lines instead of one.  I’d already removed a whole bunch of stuff from it but it was still wrapping around by a few buttons.

It occurred to me that there are a range of functions that I had on the toolbar because I use them frequently, but that aren’t actually required because I always use the keyboard shortcut. In particular, I have no need for cut, copy, paste, undo or redo because without exception I use keyboard shortcuts. I could probably apply the same logic to strong, em and insert hyperlink as well but my toolbar fits on one line with them so they may as well stay.

They aren’t really new anymore, but I just discovered them.  Apparently the Dutch accessibility laws go beyond just the WCAG standard and require a whole range of best practices for web sites.  Good stuff.

There’s a lot of talk around at the moment about how to allow cross-domain AJAX requests without compromising security. What I don’t get, is why this whole thing is an issue. What’s the difference between the two examples below:

Option 1: Browser connects to site A which loads JavaScript and initiates a request via AJAX to site B.

Option 2: Browser connects to site A which loads JavaScript and initiates a request via AJAX back to site A. The server at site A proxies the AJAX request to site B.