This is the 1001th post to this blog. Fittingly, the 1000th post was actually reasonably technical. Being late to the blogging craze I started on 25th January 2004, 2448 days ago. A average posting rate of roughly every 2 and a half days is pretty good – much better than I would have expected actually.

It’s already been mentioned on my travel/personal stuff blog but news this good should be shared as widely as possible. My wife and I are expecting a baby in April of next year. We’re very excited and pleased that Mum and baby are both doing well. If you’re interested in how things progress, we’ll be posting that over at “The Suttons”.

Despite all the hype about how everyone’s making advertising more targeted and therefore more useful to people, you still get gaffs like this one:

The advertising industry is booming and ads are popping up in more and more places, but the quality of ads are still really bad. It’s no wonder ad blocking technology has become so popular.

On a side note, it’s also somewhat worrying that there’s a minimum $10,000 investment for finding oil in the Gulf of Mexico – seems pretty easy to find at the moment…

Normally applets run in a security sandbox, much like JavaScript, but with signed applets those restrictions are lifted and the applet can do anything. At least, that’s the theory – in practice most implementations leave a security manager instance installed but with significantly reduced restrictions (such that most programs will never be affected by them). To get around these remaining restrictions, applets can remove or replace the security manager:

System.setSecurityManager(null);

Having set a null security manager though, you will start to get NullPointerExceptions in Firefox on OS X when you try to call Java methods from JavaScript (via LiveConnect). Basically, Firefox is assuming that there will always be a security manager in place. To get LiveConnect working again, rather than setting the security manager to null, simply create a new security manager that allows everything:

System.setSecurityManager(new SecurityManager() {
    @Override
    public void checkPermission(Permission perm) {
    }
});

No more exceptions from Firefox and LiveConnect is working again, but still no restrictions on what you can do. For the record, the exception Firefox will give is:

java.lang.NullPointerException
at netscape.oji.JNIUtils.checkClassAccess(JNIUtils.java:106)
at netscape.oji.JNIUtils.checkClassAccess(JNIUtils.java:68)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.privateGetPublicMethods(Class.java:2547)
at java.lang.Class.getMethods(Class.java:1410)
at netscape.oji.JNIRunnable.run(Native Method)
at netscape.oji.LiveConnectProxy.run(LiveConnectProxy.java:48)

I’ve been trying to solve this problem pretty much since Aperture 3 came out with it’s Places/GPS support. Every time I added location information to a photo, it wound up being tagged as where I really took the photo but also a completely incorrect, but consistent location (for me it was always The House of Binns in Scotland). Location information pops up in so many different places in Aperture and displayed in so many different ways that it was really hard to track down what was going on – sometimes it would have the first part of the place name right, but then had the country incorrectly shown as Scotland.

Today I finally worked out what was happening. The key thing to understand is that your photos aren’t tagged with a place name, the photo metadata only includes GPS coordinates. Aperture then maintains a separate database of place names which includes the name, the GPS coordinate at the center and the size of the place (as a radius). So a place record for your home address would have a very small radius, but you could just as easily create a place for an entire country with a big radius. When Aperture wants to display location information, it simply finds a list of all the places it knows about whose location and radius includes the photo’s GPS coordinates. As such, a photo might be in any number of “places”.

So the reason the photos are being incorrectly labelled, is that somehow a place was created called “The House of Binns” with it’s central location at The House of Binns in Scotland, but it’s radius roughly big enough to include most of Europe. So any photo taken anywhere in the UK or half of Europe was within the range of this place called “The House of Binns”.

To view the places that you’ve defined, simply go to the “Metadata” menu and choose “Manage My Places…”. You’ll get a dialog very much like the one for Assign Location but when you click on a place name in the left column a little minus icon appears. Simply click that icon to remove the place from your database, or adjust the location and radius on the map. Deleting places in this dialog won’t remove the GPS coordinates from your photos – only the particular name mapping you’ve added.