Skip to content

I was playing around with some code recently, and came across a very easy way to create a city lookup field using jQuery’s UI components and a very useful webservice provided by Geonames.

How the autocomplete functionality in jQuery works, is by wrapping the functionality around a standard html text input field, populating a dropdown list of values from an ajax call to a webservice, in this case, the Geonames webservice.

When supplied with a partial city name, the GeoNames webservice returns back a list of information for cities matching the partial city name supplied, allowing you to display, and keep track of, the country, province, full city name, and a host of other info. Full documentation is provided on the GeoNames site.

$( "#city" ).autocomplete({
  source: function( request, response ) {
      url: "",
      dataType: "jsonp",
      data: {
        featureClass: "P",
        style: "full",
        maxRows: 12,
        name_startsWith: request.term
      success: function( data ) {
        //Display city name, state name, country name
        response( $.map( data.geonames, function( item ) {
          return {
            label: + (item.adminName1 ? ", " + item.adminName1 : "") + ", " + item.countryName,
            value: + (item.adminName1 ? ", " + item.adminName1 : "") + ", " + item.countryName
  minLength: 2,
  select: function( event, ui ) {
    return false;

Hiking and getting out into nature is a great pastime, which I have always enjoyed. Nothing beats getting some fresh country air, enjoying scenic views

I have done my fair share of hikes myself ranging from short hikes of a few hours to a few multi-day hikes like a 5 day hike through the Fish River Canyon, and a 3 day hike in the Drakensberg in South Africa, and I loved every minute of them.

This is all well and good if you have lovely rugged landscapes to go explore, but the Dutch landscape is just a tad bit less interesting. It is absolutely flat, and, to be honest, the variation in terrain is rather limited, so once you have seen a bit of it, you have pretty much seen it all.

If you were to dump me in some random spot in the Netherlands (without my phone with Google Maps to help me, of course), I wouldn’t be able to tell if I was in North-Holland, Gelderland, or Braband. For me, it all looks very similar.

Therefore, for me, going on long multi-day hikes here would drive me insane from sheer boredom.

Yet, it is one of the favourite pastimes of the Dutch, which they call wandeling. There are whole books devoted to outlining various wandelroutes, and many organised events.

One guy I know regularly does 4 day, 80km walks.

It may be great exercise, and if the Dutch find it fun, then that is great, but somehow, I do not think I will be joining them any time soon.


Last week, as by know, no doubt, you have probably read, LinkedIn had a security breach, with 6.5 million passwords being stolen. It has caused a lot of people to argue back and forth that they didn’t implement good enough security measures and should have done things differently, such as using a salted SHA-1 hashing algorithm instead of an unsalted hash as they had used.

However, I found a really interesting interview with Thomas H Ptacek on the Krebson Security news site.

Ptacek maintains that no matter whether they had used salted or unsalted SHA-1 encryption, or even SHA-512 encryption, it would not have mattered. The problem lies not with how secure the hashing is, but rather how quickly the hash is calculated, making brute force attacks possible.

Ptacek goes on to explain how these cryptographic hashing techniques are designed to be as fast as possible, allowing many millions of attempts to crack the passwords in a reasonable amount of time, which is exactly what happened when the hashes of the LinkedIn passwords were stolen.

The solution that should have been using is password hashing. The key difference with password hashing is that it takes a lot longer – from milliseconds to a second or more – to hash the password (or any other value passed to it), which makes a brute force attack such as those that would work on a normal cryptographic hash virtually impossible. One common way of accomplishing this is to simply apply a cryptographic hash repeatedly, say a thousand times, on the value. With no increase in development cost, and with only a slight increase in server load for logging in users, it is possible to eliminate the threat of brute force attacks on password hashes.

So, why wasn’t it implemented this way in the first place then? Well, simply, most programmers do not know about it, myself included. The vast majority of programmers spend very little time analysing hashing techniques, relying instead on accepted practices to provide guidelines as to how to implement security.

As an example of this, 2 days ago, I wrote (and passed) the Microsoft Certified Technical Specialist module Accessing Data with .NET 4, which covers just about everything you need to know about manipulating data with .NET. There is a section in the module specifically covering how to protect passwords in a database, with the recommendations of the book being that you should use salted SHA-1 hashing, or if you want better security SHA-512. Nowhere in the book is any mention made of password hashing techniques such as discussed by Ptacek in the interview mentioned above.

Therefore, is it any wonder that most programmers are oblivious to the dangers when even official sources fail to mention the best way to protect your data, instead of methods that have time and again proven to be relatively easy to compromise.


One of the most frustrating things about JavaScript is being able to determine what events are being fired for a particular element, especially in a complex web application where a single element might have several different functions attached to a particular event.

Well, jQuery comes to the rescue.

jQuery has a very useful, and rather unknown, method to return all the events attached to an element, which is particularly useful when used in the web browser’s console while debugging a web page.

All this needs is one single line of code, and hey presto!


Google+ has been around for nearly a year now, and there have many conflicting news reports, some saying Google+ is a ghost town, while others saying that Google+ is growing at a phenomenal rate.

Well, having been an active user of Google+ since almost the beginning, I can personally say that Google+ is anything but dead. It is alive and well, with a very active community.

Each of the major social media tools has their own niche that they fill rather nicely, and are very successful in. Facebook is the way to keep up to date with your friends, Twitter works well for up-to-the-minute news and quick messages, LinkedIn is wonderful as a networking tool, while Google+’s niche is the trading of information.

It can be easy to think that Google+ is dead if you don’t see it for what it is – Google+ is NOT Facebook. People on Google+ are just not using it to find out their friends latest statuses, but rather to find out interesting information from the community they are involved in.

Personally, I follow a lot of people in the science, astronomy and tech communities on Google+ and my stream is always filled with interesting things to read. If I had only added my friends my circles, then I would have a rather boring time checking out Google+.

So, as a message to all you Google+ doubters out there: use it the way it is intended to be used, and you will find Google+ full of life. Use it like Facebook, and you will be disappointed.


In days gone by, if you wanted to imitate a book on a website, being able to browse content by flipping pages, you needed some Flash or some other extension to handle it.

Now, turn.js comes to the rescue.

With just a few lines of code and this open-source jQuery plugin, you can add a fully animated book feel to your site.

The only requirement to get it to work is an HTML5 compliant browser and let turn.js do the rest.


I just upgraded my installation of Gramps, my favourite genealogical application, to the latest version (3.3.1).

One of the nice things is that, compared to my previous version (2.6 I think it was) I had installed, the install file for Windows is self-contained, making it easy to install. Previously, I had to install Python separately, which can be a pain, but now one setup file installs everything you need.

However, there is one issue that still bugs me – there is no way to easily set the application language without a technical solution.

Gramps relies on the computer’s locale settings to determine the language, which is not always so great. For me, for example, my locale is set to the Netherlands, setting the language to Dutch, but I want to work in the app in English.

There is an easy solution though. It is fixable by creating a batch file setting the desired local before starting the app, and the language you want will be selected.

"C:\Program Files (x86)\GrampsAIO\bin\pythonw.exe" -EO ..\share\gramps\

Now, running this batch file, I can enjoy Gramps the way I want it.