An iPhone locator app I’ve been building had a weird thing happen: if you denied it access to Location Services and entered a valid ZIP code, it would work — but an invalid ZIP code would always home in on Lancaster, Pennsylvania. At first, I thought it was a bug in how I was sending coordinates to MKMapView, but I quickly was able to confirm that the problem originated in my server-side geolocation service.

My server-side geolocation service uses Google’s deprecated Geocoding API version 2. The problem arose from sloppy coding on my side, coupled with Google’s map intelligence, and the v2 API’s reporting. Here’s how:

My code would assemble an address string from street number, city, state, and ZIP code (if provided). In this particular case, however, it was only receiving a ZIP code. But my code was crappy, and the address string it assembled looked like “null, null, null 90066”. If the ZIP code was legit (like 90066), Google’s geolocator is smart enough to figure out that it’s a ZIP code, ignore the “nulls,” and do the right thing. But the interesting thing happens when the ZIP code is not legit. Google’s algorithm evidently tries its best to match up the provided address with something you might be looking for. Perhaps due to previous searches with the API key we were using, perhaps for other unknown reasons, those “nulls” were matched to Noll Airport, East Hempfield, Lancaster, PA 17603.

Interestingly, the Geo Address Accuracy resolution value returned for that specific match is 9, or “Premise level accuracy” — the highest level of accuracy. Again, my crappy code had assumed that the Geo Address Accuracy was a confidence factor, not a resolution indicator. So that guess appears to be a really good fix, when, in fact, it’s no better than any other guess.

Revising the code to leave out the “nulls” resulted in another interesting result. Again, legitimate ZIP codes were found right off. Bad ZIP codes ended up being matched against other numeric codes, so, for example, “90000” ended up matching Belfort, France, and “91000” ended up matching Tawau, Malaysia. These results all come back with a Geo Address Accuracy of 5, or ZIP-code level.

One solution to this problem is to validate ZIP codes before submission to Google. Another solution would be to upgrade to the v3 API, where there’s more information about what’s going on.

Several years ago, we replaced our commodity hardware firewall (a Sonicwall SOHO from ’01) with pfSense running on an unused Dell 4100 desktop from that same year.

pfSense was a little confusing to configure the first time through (doing 1-to-1 NAT with virtual IPs and CARP was initially confusing, but the pfSense forums and The Google came to our rescue). Once in place, though, it did a great job. And when I say a great job, I mean that we could pretty much forget about its existence. It just hummed away in the background, and everything worked. When we needed to check up on our ISP, we discovered that quality of service logging was already supported, as well as pretty graphs of various connection properties. Very nice!

Over the last weekend, the 4100 locked up, and our connection was interrupted. Rebooting gave a firmware error about a bad disk in drive A: — but there was no disk in the drive. Power cycling, opening the machine, wiggling some cables, and blowing out some dust brought it back up, and all was well. Except it wasn’t, really. The machine spontaneously rebooted a number times over the next few days, and occasionally got into the “bad disk in drive A:” boot failure, requiring a hard power cycle. As I watched on the console, I saw the kernel fault out after too many memory checksum errors. The old machine was giving up the ghost.

After commissioning another old desktop (an ’07 vintage Dell, this time), I was able to install pfSense on it. I had to disable some of the extraneous hardware in the BIOS, but after about an hour I had it installed, booting, and ready to go. I was able to simple dump the configuration from the old firewall, load it into the new machine, reassign the LAN and WAN interfaces to the proper devices, and swap the boxes out. voila! Back in business!

With any luck, I won’t have to repeat this process for another five years.

I’m accustomed to having a hot-key in my text editor for inserting a time-stamp. Now I have a plain-text note-taking application that I want to use for managing my time, but it has no bells or whistles. It doesn’t allow the creation of macros and it doesn’t have a time-stamp function.

All is not lost! Using Automator, I created a service which calls a shell script to generate a nicely formatted time-stamp. I haven’t found a way to assign the service to a hot-key, but in many text input areas, a contextual services menu can be brought up with a simple right-click of the mouse.

Simple, nice, and convenient.

Here’s how to do it:
Fire up the Automator application. Create a new “Service” workflow:
(click to enlarge)

For the operation, double-click on “Run Shell Script” and set it up as shown in the image below:
(click to enlarge)

You’re done! Now you can insert 2011-08-04 16:58:06 time-stamps 2011-08-04 16:58:13 everywhere 2011-08-04 16:58:20.

Note: this is under Snow Leopard / Mac OS X 10.6.8. It probably will work under anything from Leopard onward.

Using Xcode and Interface Builder is like a bizarre, retro-futuristic dream, where Code Warrior for Palm OS has somehow evolved into the interface for the Great New Empire.

I just received my paper copies.

You can get a copy too!