A ride of a lifetime

Today, my wife and I got the opportunity to rid in a Zeppelin run by Airship Ventures. The other day, I realized that I've been on a number of different aircraft ranging from airplanes (commercial down to a homemade one my uncle built), a hot air balloon, and 4 separate helicopter trips. Today I got to add an airship to that list.

The tour took us from San Diego's Montgomery Field to the coast, south to downtown and then back to Montgomery field. The ride is some much different than any other type of aircraft as it's quiet, moves pretty slowly (top speed is less than 80 mph), and flies relatively low. Like the other passengers, I didn't stop taking pictures; I posted a bunch of pictures on my server. I didn't realize that my GPS data logger wasn't on until part way through the flight, so the map is missing some points. This site is using a product called JetPhoto Studio which I plan on reviewing at a later time (putting the site up with the map took just a few minutes, so that's one feature that is really cool about it).

It's really hard to describe the flight other than amazing. While you can take a helicopter tour of San Diego, I don't think you can beat this for getting a full view of the city and getting to take in the breathtaking views.

Coding tip for if statements

When I was a young engineer, a more senior colleague of mine taught me a lot about writing code and helped me adopt my own style. Just like an artist, every developer has his own style with no style being wrong. However, there is one coding convention that he taught me I think all developers should use. Here's what developers shouldn't do:

if (something)
       dosomething;

Instead they should do:

if (something)
{
      dosomething;
}

(or if you prefer, put the { on the if line).

Why do I say is? It's simple, if you come along later and add a line to the first statement, like:

if (something)
        dosomething;
        dosomethingelse;

you could have the wrong thing happen. If you wanted the "dosomethingelse" to only happen if the if statement was executed, that's not what would happen (it would always execute). The brackets make it explicit what will happen on the if statement. I've seen this type of coding in a lot of code and it will definitely lead to failure at some point or another.

I'm sure some people will take offensive with what I say, but this tip will save lots of time in debugging at some point.

Managing Multiple iPhone Developer Certificates

Back in the dark ages of iPhone development, being part of 2 separate iPhone development teams was problematic as Xcode didn't deal with multiple developer certificates too well. Now Xcode will automatically select the right certificate (it took me awhile to find a reference).

Each developer certificate now has a unique hex value at the end which lets you have 2 certificates for the same developer. However, until today, I never managed to get this to work properly. It turns out that in order to make things easier, instead of following Apple's directions to create a certificate signing request, I control clicked on the private key I created for the first certificate and selected 'Request a Certificate from a Certificate Authority With "iPhone Developer Private Key (Scott Gruby)'.

After that I was able to create my second certificate and have it associated with the same private key (I don't think Xcode likes 2 different keys to have the same name). I'm not sure if this was absolutely necessary or if changes to how Apple generates certificates and changes to Xcode made things easier, but I'm not going to complain. I now can debug apps for multiple teams without having to change the bundle identifier and possibly make a mistake and check it into source control.

Easy version numbering in projects

When I start all of my projects, I do a few things to make version numbering easy.

First, I create a Defines.h file that looks something like this:

#ifdef INFO_PLIST
#define STRINGIFY(_x)        _x
#else
#define STRINGIFY(_x)      # _x
#endif