Life, Technology, and Meteorology

Month: November 2007

Inside DynDNS Updater 2.0

I’m thrilled to link to a major update of DynDNS’s Mac client, DynDNS Updater 2.0. I’ve been working on the DynDNS Updater for quite some time, and this release is a complete re-write that has a lot of new functionality. Looking at 1.x and 2.0, you would never know the projects were related; there are far too many changes to even list. To try and summarize, DynDNS Updater 2.0 is built from the ground up to give a completely modern Mac experience to people who use the services provided by DynDNS. The updater now has auto Sparkle updating built-in, Growl integration, a custom Dashboard Widget, and an interface that looks right at home on both Tiger and Leopard. Core technologies like OpenSSL, libcurl, and pthreads are used on the back-end.

In case you aren’t familiar with DynDNS as a company, their products solve the problem of managing DNS for just about every type of user, from individuals to large companies. I believe Dynamic DNS is the project that is most well-known (at least that is how I heard of them years ago), giving users with dynamic IPs a method of having a static name point to their computer. The DynDNS Updater’s primary function is to watch out for IP address changes on your Mac, and let the DynDNS servers know when there is a change. The updater is broken up into two separate executables, one is a Cocoa application where you configure your accounts and hosts. The other executable is a background daemon running 24/7 that performs all the grunt work.

I started working on version 2.0 last year. Jeremy Hitchcock and the rest of the DynDNS crew had some nice feature ideas for the next version, and I mocked up a design that would implement some of these features. I was pretty excited about the project and started working on what was to be a fairly advanced update. Fast forward to around March or April of this year when the first beta was being wrapped up. This beta had the foundation of a solid background daemon where I tried to stick to the basic POSIX libraries, so it could run on multiple platforms. At one point, I was regularly compiling it on Linux and it was working well (I haven’t tried this for quite some time since then). The daemon was completely threaded, and supported multiple network connections. Unfortunately, while the code design was solid and the product had a lot of nice new features, the UI was horribly difficult to use and the interface to configure these complex setups was not pretty. The mock-ups looked nice, but actually using it is where we ran into problems. Seemingly simple operations took multiple steps, because a lot of advanced options had to be taken into account.

Enter FJ de Kermadec and his team at Webstellung. They suggested bringing the project back to basics–thinking more about the typical use case and not all the features we could give to power users in unique situations. Webstellung put together some very impressive UI design mock-ups to get things started. Jeremy gave the go-ahead, and it was back to the drawing board as I began coding up the fresh interface. Fortunately, since the daemon code was designed with flexibility in mind, it could be re-used by dropping the new interface on top of it. The initial UI creation went pretty quickly, and within a few months a new application was born. The first beta was ready just before WWDC this year. As soon as I started using this UI, I knew it was a keeper. There were a few adjustments that had to be made, but overall the interface is very intuitive. After the functionality was mostly complete, it was time to focus on the interface polish. We went through several iterations of the software, catching small changes here and there that all added up to a nice shiny app.

If you’re currently using DynDNS Updater 1.2, definitely upgrade to version 2.0. And if you aren’t, download the app anyway and check it out. Dynamic DNS accounts are free for up to 5 hosts, and it’s pretty easy to set everything up.

Populated Places

When developing weather software, one of the most important pieces of data you will work with is a location list. A weather application is useless if the user can’t find a city and download weather data for it. There are several different methods users might want to be able to search for a weather location. The methods Seasonality supports include zip codes (U.S. only, for now), city, state, country, and ICAO. Actually, ICAO was just a convenience method I added, so when a user double-clicks on an ICAO weather station in the satellite imagery, the add location dialog box will pop up with a listing of locations that use that ICAO.

So where do you find a good location listing online? The best resource I’ve found is theĀ GeoNames database. They have slightly over 80,000 cities, each having a population over 1,000 people in a simple CSV file you can download from their website. Each city has a state (if applicable), a country, latitude/longitude, elevation, population, time zone, and some other fields as well. Our basic needs are only the city name and it’s latitude/longitude, but some of these other fields come in handy when trying to calculate the local time, deciding which cities to mark on the map (higher population cities should take precedence), etc.

It’s not much use to have this location data unless you can correlate it with your weather data sources. You’ll definitely need a relational database to keep track of everything. I prefer PostgreSQL for my master location database. There are several aspects of data correlation that you’ll need to think about here. Everything from matching every location with the closest weather station ICAO, to getting zip code listings and matching each one with an appropriate city. It’s a lot of work (you’ll learn a lot of SQL along the way) but eventually you’ll have a giant web of location data that you can pull from.

Now that you have this master location database, you’ll want to trim it down to something you can actually ship with your application. For example, Seasonality’s master location database is over 4.5GB in size, which would obviously be too large to include in an application archive. A small download size is desirable, so only include the data you absolutely need. Also, PostgreSQL is a bit of overkill to be running in the background for a database this size, so convert your dataset to something different, like SQLite. Selecting a subset of data and converting it from PostgreSQL to SQLite all takes place in a custom script I wrote, so each time I update a location (and trust me, with so many locations there will be errors and corrections) all I need to do is re-run the export script and I have a fresh location database to include in the next version of Seasonality.

© 2026 *Coder Blog

Theme by Anders NorenUp ↑