Bug with JQuery validation error messages showing tooltip text

I had the following html in my form:

Nothing complicated there I hope.
I had the help text set in the title attribute of the input which I styled with the lovely qTip to make it look nice. I validated my entry using the jQuery validation plugin which also works well. The problem is that if an attempt is made to submit the form before any attempt at editing the value or showing the tooltip, the error message would show the value of the tooltip (“Don’t worry…“) instead of the validation error message (“This field is required“).

It’s taken me a while to find the cause, but the fix is easy. When invoking the validator, throw in the option to ignore title attributes.

ignoreTitle: true

How to enable Offline Google Docs for Google Apps users

Do you still not have the offline option for Google Docs?

If you’re a Google Apps user, then your apps administrator has to enable it first:

  1. Log in to the Google Apps control panel at https://www.google.com/a/your_domain.com (replace your_domain.comwith your actual domain name).
  2. From the menu bar at the top of the page, click Settings.
  3. In the left menu, click Docs.
  4. Select the Allow users to enable offline docs check box.
  5. Click Save changes.

Then your users can choose to set it up in the same way normal gmailers can with the docs cog in the corner:

set up offline docs

Hope this helps you out.


How to write Singletons in java

Singletons get a pretty bad press. Often described as an “anti-pattern”. I think it’s a little unfair since I find them pretty useful in several situations. However, the reason they can be bad is important to understand:

Making a class a singleton can make it difficult to test its clients, as it’s impossible to substitute a mock implementation for a singleton unless it implements an interface that serves as its type.

That quote, and most of what I am about to write are completely stolen from Josh Bloch’s excellent book, Effective Java (highly recommended in paperback or kindle editions). Those are affiliate links, but I still recommend you buy it no matter where you get it from.

Anyway, it raises an important point about testability, but one that I think doesn’t matter. The way I see it, if you’re writing a singleton that represents something you want to swap with a mock, such as a database connection or network resource etc then your design will change as your tests evolve. You practice TDD right? You’ll soon realise that a singleton doesn’t make sense or you need an interface of some kind. This post is about how to write a good singleton.

In the bad old days before java 1.5 there were 2 common ways to implement a singleton. A public final field:

public static final Elvis INSTANCE = new Elvis();

or a static factory:

private static final Elvis INSTANCE = new Elvis();
public static Elvis getInstance() {
    return INSTANCE;

The static factory version is slightly better in that the you have a bit more flexibility to change your implementation details at a later date. In my two examples there is no performance benefit of either technique in modern JVMs. This is all well and good. There is only one Elvis in the world. There is the possibility a privileged client can invoke the private constructor reflectively but I’m not going to dwell on that.

Bloch raises another problem:

To make a singleton class that is implemented using either of the previous approaches serializable, it is not sufficient merely to add implements Serializable to its declaration. To maintain the singleton guarantee, you have to declare all instance fields transient and provide a readResolve method. Otherwise, each time a serialized instance is deserialized, a new instance will be created, leading, in the case of our example, to spurious Elvis sightings.

Oo-er, this sounds messy. You implied in java 1.5 there’s a better way, please, what is it, I’m desperate!

// Enum singleton - the preferred approach
public enum Elvis {
    public void leaveTheBuilding() { ... }


This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.

Have a little think about it, let it sink in, then run off and replace any singletons in any projects you can get your hands on.

How to dynamically choose the color of your Google maps marker pin using javascript

You can dynamically request icon images from the Google charts api with the urls:


Which looks like this: default the image is 21×43 pixels and the pin tip is at position (10, 34)

And you’ll also want a separate shadow image (so that it doesn’t overlap nearby icons):


Which looks like this: shadow the image is 40×37 pixels and the pin tip is at position (12, 35)

When you construct your MarkerImages you need to set the size and achor points accordingly:

var pinColor = “FE7569”;
var pinImage = new google.maps.MarkerImage(“http://chart.apis.google.com/chart?chst=d_map_pin_letter&chld=%E2%80%A2|” + pinColor,
new google.maps.Size(21, 34),
new google.maps.Point(0,0),
new google.maps.Point(10, 34));

var pinShadow = new google.maps.MarkerImage(“http://chart.apis.google.com/chart?chst=d_map_pin_shadow”,
new google.maps.Size(40, 37),
new google.maps.Point(0, 0),
new google.maps.Point(12, 35));

You can then add the marker to your map with:

var marker = new google.maps.Marker({
position: new google.maps.LatLng(0,0),
map: map,
icon: pinImage,
shadow: pinShadow

Simply replace “FE7569” with the color code you’re after. Eg: yellow