Mac FizzyCalc

During the summer of 2011, I had some mythical Spare Time to blow the centimeter-thick layer of dust off my programming skills and port FizzyCalc, a Windows-based geocoordinate conversion utility that I’ve used for solving several puzzles in my obsessive hobby, geocaching, to the Mac. Mac FizzyCalc celebrated its 2500th download in November, a year after it was released. Cupcakes were served.

FizzyCalc is used primarily to precisely project waypoints and convert among the most common geo-coordinate formats. Applied judiciously, it can help you in finding the center of a circle given points on its circumference or the intersection of three circles. (Latitude/longitude is a Cartesian grid superimposed on a spheroid earth. At my latitude, one minute west is far less than the one minute north/south. Thus, my tenth-grade algebra fails.) One of the reasons I wanted to port it is using a Windows virtual machine always takes … a … w-h-i-lllllllllll-e to start because, oh, merde, Adobe Flash has another security update – Reboot to make the changes take effect!

Though this was going to be 100% function-equivalent, I wanted to do some cleanup of the user interface so it felt more like a Mac application — cut and paste had to work, output would be single fields, fields were lined up, and tab-ordering must not be psychedelic — all things I used to nag developers about when I was a product manager at a certain scientific plotting software vendor.

One of the challenges was learning the new tools, language, syntax, APIs and application process, because this exercise would not be as simple as:

           make clean; ./configure ; vi config.h; make love ; sudo make install

As a warmup, I worked through several examples from K+R’s C Programming Language. This book was a trip down memory lane as it exemplifies how a technical reference can be concise and offer helpful examples. Contrast this to the JavaScript book, that, at a thousand+ pages, is thicker than my American Heritage Dictionary of the English Language and not as much fun to browse.

Apparently I hadn’t forgotten as much as I’d feared. C’s syntax is similar to perl, which I used to use for data munging. (Ed note: Now I use python and am dabbling with R.) It was a nice week, especially as I worked most of the examples while at Issaquah Coffee consuming Tiger Mountain Mochas.

Apple’s equivalent of vi, make, cc and gdb is XCode (and gdb). Like Visual Studio, you can edit, compile, swear, debug and swear again in the same application! To become more familiar with the toolset, I worked through two of Apple’s recommended mini-tutorials. It was generally counter-productive, for as is vogue in the tech industry, the tutorials hadn’t been updated since the N-2nd version of XCode they were originally written for. They were technically correct, but referred to options that had been renamed, moved or consolidated (and renamed then moved). External documentation had itself been renamed, moved or consolidated. Yay?

The next step was muddling through the syntactical nuances of the new language (Objective-C) and technologies (Cocoa). Though this was greatly assisted by XCode’s Gentle Mallet of Understanding, I’d sometimes encounter a cryptic error message that I could make no sense of using the standard documentation. As you might expect, Googling “how do I make this shit work?” didn’t return a lot of useful results.

Enter Stack Overflow, where someone wrote about the problem and the solution. The trick in using it seems to be searching from Google, but focusing results on sites in the Stack Overflow portfolio. Many of these solutions suggested doing something from the command line. I am very comfortable in a command line, but it seemed to defeat the point of having an integrated development environment. Stack Overflow was invaluable, so I was especially stoked when I had a chance to contribute back.

Now I could now start productive work!

With only a modest bit of explicit casting (as I was moving from Windows 32-bit to Mac 64-bit), finding substitutes for the handful of C++ string functions that weren’t directly supported, and burning lemon-scented incense, I appeased the compiler. I had the Henry Ford version of FizzyCalc running on the Mac: you could do any conversion, as long as you were only interested in converting “N 47 37.777 W 122 06.310” into UTM format. Awesome!

Next came the beginnings of a user interface. Apple’s n00b tutorial presented a very simple example of a GUI using OpenGL graphics to make a screen saver because it looks cool. It was in no way useful for anything I needed to do. Thus began a cycle of knowing what I want to do, but not having the language to express it in terms that would produce an immediate example. Sans examples, I spent a frightening time on stupid things like futzing with a text box that was not doing anything because I didn’t use the secret control-click-fu drag operation to connect it to the function to Do Stuff.

Once I had a GUI and verified the program returned correct results, I spent a lot of additional time testing and the usability nuances I mentioned earlier. While I feel this is a good thing, it doubled the number of lines of code written. Efforts to create functions for things like “Save the preferred unit of measurement if it’s changed” were repeated when I couldn’t make it a function. (I’m sure I’m violating the MVC guidelines.) I’d really like to clean up this part.

1. Build a free Mac application
2. ?
3. Profit!

Figure 1: The prototypical 1999-era business plan

Even though it was always going to be free, I chose to post it to the App Store for the better exposure, easier dissemination of updates, and assuring users that it’s not a trojan horse. Before submitting applications to the App Store, you have to digitally sign the software. It is… the biggest freaking pain in the ass of the whole process. The instructions are distributed among several linked documents and the process has so many steps, there are several opportunities to mess one up. The error messages were not helpful. I feel I spent about as much effort complying with this process as I did porting and testing the application.

Submitting it for review was comparatively straightforward and anti-climactic. I had to create ginormous screen shots (even though the app’s window is comparatively small). The first one was kicked back because I used the word “Mac” in the title — even though this is permitted by the guidelines. The second version was fine and took five days form submission to showing up on the store. I was stoked. I posted notes on a couple of forums where there had been some interest in a Mac version.

The trickle of downloads expanded to a full burble when SoftPedia posted a note on its availability.

During subsequent testing, one of the esoteric functions that I had reservations porting (WAAS satellite calculation) would crash in a very specific way if a user were deliberately trying to be an ass. I didn’t see any crash reports (perhaps because as I thought, the feature wasn’t very useful), but fixed it and had a version ready in case they materialized. A month later, Apple sent a note to the developers list letting us know we’d have to sandbox applications. This was a good opportunity to post the bug fix. The whole shebang was processed in the same day, quite the contrast to the first time.

Overall, it was a worthwhile exercise. My best moment was earlier this year in an argument with a coworker (who was unaware that I even geocached) claimed a database we’d purchased was unusable because its longitudes were only accurate to five decimal places and likely in another zip code. (I suspect he was also not looking forward to loading the data.) Um, dude, that’s less than two feet. Look, there’s this free Mac FizzyCalc utility you can use to calculate it. Discussion closed.