There are two types of badasses in this world: idiots and heroes. We all know an idiot or two: the friend that, especially when drunk, is willing to do crazy things with nary a second thought to their safety. Their bravado is simple: fear is simply not part of the equation. But there’s a second type, too: the heroes. These are the average Joes whose life is punctuated by real danger and fear, but who fulfils their true duties despite the presence of fear.

Idiot badasses have no fear at all. It is as though they were born with a part of their brain missing. Or maybe they simply give no heed to the consequences of their actions, as though thinking further than 10 minutes into the future is beyond their capabilities. Or, most insidiously, a bigger fear overshadows every other fear: the fear of being exposed as a scared wuss. The idiot will chase cheap thrills (see: trainsurfing) without a trace of fear, but will never attempt the big challenges of life.

The idiot badass has a big disadvantage over the rest of us: with no fear, he has no compass that points towards what he should be truly doing. When you’ve got a set of goals in front of you, and you’re wondering what to do next, the easiest way to prioritise is to consider which one scares you the most. That is your internal compass pointing you towards which course of action is what you truly should be doing with your life. However, the idiot badass cannot rely upon this, because they have trashed their compass.

True badasses look like you and me. An average life, full of the normal big challenges we all face. These big challenges carry real danger: What if i can’t find a job? I’ll lose the house. These dangers gives rise to fear. This sprinkling of fear is what prevents most people from rising to the challenges they face, and thus they check out, and settle for a second rate existence. But a true badass sees these fears for what they are: hollow bullies that, once confronted, will crumple like a paper tiger. And thus the life of a true badass consists of moving from challenge to challenge, facing and feeling fear the whole time, but fighting forwards with the knowledge that ‘I have what it takes to beat this’.

It is a truly satisfying life, beating increasingly larger challenges and fears, free from the need to chase the cheap thrills that an idiot badass will do. Who needs to go train surfing to prove their bravado, when day in and day out you’re kicking ass when it comes to what is truly important? Personal demons, financial troubles, marriage woes, problems with the kids – all these are the challenges that you were put on this earth to beat. Your life is a hollywood blockbuster. These problems are the stereotypical eurotrash bad-guy, wreaking havoc on the people you love. You’re mission is clear – face your fears, overcome these challenges, do it scared, and kick his ass. Do that, and you’re a true badass in my book.

I think I finally understand the meaning of sacrifice in leadership now. For many years, I assumed sacrifice was all about taking yourself down a peg. It’s as though being born in a first-world country was somehow an unearned privilege, and that you have to make a sacrifice in some way to avoid being a bourgeois pig.

Now that always struck me as a guilt trip, and I hate those. So I relegated the notion of ‘sacrifice’ to the dustbin, and went on with my mission to improve my lot in life. And after my umpteenth frustrating time trying to get work done on my side business whilst packed into a noisy sweaty train, I realised: I’m sacrificing.

It flipped my realisation: sacrifice isn’t a guilt trip, some way of paying back some of what you owe, as though your position of privilege has endeared you with some kind of karmic debt. No – it’s just the nuts and bolts of what is required if you are going to do something with your life.

I could be riding my motorbike to work this morning. The riders at work think i’m crazy not to. But instead, i’m on the train, working on my laptop, gradually making progress on iPhone apps that one day will increase my family’s income. I’m certainly not paying off a guilt debt, i’m working hard towards improving my situation. It’s the polar opposite of my original thought of what sacrifice was about, but i think it’s the more accurate of what sacrifice is about.

All good in theory, but how does this affect my life, though? Well, your perspective on sacrifice affects the type of sacrifice you’ll take. Let’s say you have some unsavoury personality trait that you aren’t particularly proud of. For me, i get too impatient and lose my cool. Well, if I believed that sacrifice was about ‘paying back’, every time i lose my cool I’d go off on a guilt trip as my sacrifice. However if I believe in sacrifice as ‘paying forwards’ towards a better tomorrow, instead of wasting time on a guilt trip I’d be engaging with the painful work necessary to deal with my issues – hopefully with the outcome that i will eventually beat that flaw of mine. Now think – which of those two approaches is more worthwhile? Hands down the latter, in my opinion. Guilt trips will get you nowhere.

Sacrifice isn’t about the past. It’s about the future. It’s the struggle of getting through the tough times necessary to build a better future.

Don’t even bother trying to lead others if you haven’t mastered the art of leading yourself first. Seriously, you’re wasting your time.

It works like this: you’re at the doctor, and he tells you to stop smoking. Even recommends a program. But you can’t help but notice that he smells oddly like cigarettes himself, has telltale yellow teeth, and looks a lot older than the 40 years that you know he is. You think about the program he’s recommending. Well, it worked so miserably for him – as if you’d waste your time.

Or you’re watching some random TV host recommend their latest results-guaranteed exercise program. The same host whose weight has gone up and down like a yo-yo over the years. That’s a recommendation that’ll probably be best ignored.

Here’s the thing: nobody’s looking for wisdom. Find me 10 people who don’t know that the best way to look after your body is exercise + eating properly – good luck! No, we all already know what we should be doing. We just want an example to follow.

Nobody wants to be told what to do. Everyone wants to be shown what to do. Show, don’t tell.

I think this is because we want to see that it’s possible before we try anything ourselves. We need to believe that a certain course of action has paid off for someone else, and that they’re willing to hold our hands, to show us how to do it. Only then will a person follow your advice, because it worked for you, and you’re willing to show them how.

This is also why you’ll end up like your friends: Their examples show you what is possible, and how to get it.

If you can’t kick your own ass into gear, someone whom you are intimately familiar with, how do you expect to be able to kick anyone else’s?

I recently had to make an iPhone app ping a server to check for it, and couldn’t find much helpful code out there. So I cobbled together a small helper which works with the SimplePing old code from apple’s site. Seems to work fine for me. Here’s how you’d use it:

- (void)tapPing {
    [SimplePingHelper ping:@"www.google.com"
        target:self sel:@selector(pingResult:)];
}

- (void)pingResult:(NSNumber*)success {
    if (success.boolValue) {
        [self log:@"SUCCESS"];
    } else {
        [self log:@"FAILURE"];
    }
}

Pretty simple to use – that’s all there is to it. The concept is that you use this as a very simple way of testing if networking will allow you to reach a server.

Keep in mind, that if you’re using this to poll a server to test for network connectivity, it’s probably worth using Reachability to check if they’re not connected to wifi, and if not then don’t ping too often for the sake of the poor old battery!

If it receives a response from the host, it calls pingResult immediately. If it doesn’t get a response, it times out after 1second and calls pingResult with failure.

It takes care of all the memory management for you, so you don’t have to worry about that. It retains target for 1 second, until it cleans up, so there’s no danger of it calling pingResult on a class that has been freed.

Source code can be found on github: https://github.com/chrishulbert/SimplePingHelper

To use it, grab the source and copy the 4 SimplePing* files into your project. Hope it helps someone!

iOS Automated Builds with Xcode4

I just spent the last (frustrating) week or more at work setting up our build server for some iPhone / iPad projects. It’s so complicated, and there’s so much misinformation out there, that it’s worth sharing some tips here which will hopefully be useful for us to read back on. And maybe this’ll save someone some hassles out there too.

In this article, i won’t give you a complete build script, as everyone’s environments are subtly different, but instead i hope to impart the knowledge and tips and pitfalls that’ll make it reasonably straightforwards for you to create your own script without all the horrible hassles I had.

Aims

Our final goal was to have two files arrive in our Dropbox each morning: zip files containing a dev branch build and a stage branch build. These zip files are to contain Xcode archives (for later app-store submission) and the ipa files (for TestFlight).

Our setup and requirements can be described thus:

• A ruby script is used to control the build process.
• Two Git branches: dev and stage. The idea is that all new features get added to the dev branch. Any bug fixes get added to the stage branch. Every two weeks (end of the sprint), with the testers' blessing, we merge all the new features from dev into stage, and then merge all the bug fixes from stage into dev.
• We use TestFlight to provide the builds to the testers. For this, we need signed IPA files to submit to test flight.
• We want to produce an Xcode archive (.xcarchive) – this is used for submission to the app store, and for sending to clients. With this file, we can double click it on any mac, which will import that exact build into Xcode, and we can then re-sign it with the App-store distribution profile and submit to the app store (so long as the Bundle Seed ID is the same – more on this later). This is so that we can ensure that what we submit to the app store is exactly the same build that was tested.
• We’re using Xcode 4, and don’t need to support pre-iOS 4, so that simplifies things a lot (e.g. no need for CODE_SIGN_ENTITLEMENTS plists or Ad-hoc build configurations).

Provisioning

It’s worth going over provisioning: certificates, keys, profiles, etc. I’ll try to describe how it affects you, but you should really also read Technote 2250.

In short, it works like this:

Your private key signs a certificate, which validates provisioning profiles.

Keys and Certificates

Private keys are generated using the Keychain on your mac. Using this key, you request a certificate. So certificates only work if you have the matching private key installed – be aware of this, you cannot simply download the certificate from the iOS provisioning portal if you don’t have the private key. To copy a key to another computer, e.g. your build machine, right click > Export the key from within the Keychain, and make sure you export it as a .p12 file.

If, in the Keychain, you can’t see a little triangle next to your certificate, then it means your private key isn’t installed. Delete the certificate (it’s useless without the key), export the key from the original mac it was generated on, and import it on the other machine before you try importing the certificate.

You may see ‘Code sign identity’ mentioned in the project settings later on. This is a synonym for your certificate.

You’ll only need one distribution certificate, it’ll work for all your provisioning profiles (both adhoc and appstore).

Keep in mind that everything i’m discussing is to do with distribution, not development. Always ensure you’re in the ‘distribution’ tab in the iOS provisioning portal.)

Provisioning Profiles

You need two profiles: ad-hoc (TestFlight) and app-store.

When you generate a profile, it will be linked to your certificate, and will only work on a mac that has the cert (and key) installed. When you generate new profiles, however, you don’t need to re-generate the certificate – it isn’t necessary.

Profiles only work for a specific app id (discussed later), or they can work for a wildcard id. For this article, i’ll only be discussing those with specific app id’s.

When profiles are generated, they are locked to a Bundle Seed ID and a Bundle ID. When you compile an app, you must use a profile with a matching bundle id, or the profile won’t work. Your app’s bundle ID can be found in your Info.plist file.

Once an app has been signed with one profile (e.g. your ad-hoc TestFlight profile), you can re-sign it with another profile (e.g. your app-store profile) – IF the Bundle Seed ID’s match.

Provisioning profiles have a unique UUID to identify themselves, eg: 44A1166C-C096-4112-B3E0-9081520CBABC. This UUID can be extracted in the build script, as it changes each time you add a new device to your profile, and you don’t want to have to hunt down the UUID each time you re-generate the profile. It’s far easier to simply check the *..mobileprovision file into your repo, and let the build script look up the UDID, install the profile, and update the build settings accordingly.

App ID’s

An App ID = the Bundle Seed ID + ‘.’ + Bundle ID.

The Bundle Seed ID is also known as the App ID prefix, or the Team ID. When you generate a profile, it will be given your Team ID as it’s Bundle Seed ID. The Bundle Seed ID looks like: 5M3M5W7ABC.

Nowhere in your app’s configuration do you need to specify a bundle seed id, and the only time it matters is for app store submission time: when you want to submit the exact same build that the testers tested. When you go to re-sign the archive with your app store distribution profile, it’ll need to have the same Bundle Seed ID as in the ad-hoc profile you originally signed it with for testing.

The Bundle ID looks like: ‘com.splinter.myawesomeapp’. This is specified in your app’s Info.plist file. When you do a release/archive compile, you’ll need to sign against a provisioning profile that matches this bundle id. Eg, if you have two apps, with the following bundle id’s:

• com.splinter.world-domination-app
• com.splinter.servitude-app

In that case, you’ll need different profiles, with bundle id’s to match. (Or you can use wildcard profiles, but i won’t go into them here). The important thing to remember is: the bundle id in the profile must match your app’s bundle id, or it won’t compile.

Server setup

The server I use is a mac mini, with Bamboo. Personally, i don’t really recommend Bamboo as it over-complicates the git repository setup which makes it difficult to push commits up to your git server – which we use to make version number commits. You can use cron jobs, or Hudson, or any other CI setup you wish.

TestFlight

TestFlight has a brilliantly simply upload API that uses Curl from the command line to submit newer versions of your app. The only complication is if you wish to have both dev and stage branches available to your testers: since TestFlight groups builds by bundle name, only the most recent build will be available.

So, to get around this, I use ‘PlistBuddy’ to modify the app name and bundle ID prior to building the dev branch version. Please note that if you do this, you’ll also need to use a provisioning profile that matches the new bundle id.

Build Steps

The steps I follow for making a build are as follows:

• Increment the version numbers in the Info.plist file
• Check into git the updated Info.plist
• Override the bundle id and name, if it is the dev branch
• Install the provisioning profile
• Use zerg_xcode to update the project file, to use the desired certificate and provisioning profile
• Build the .xcarchive
• Create the .ipa file
• Upload to TestFlight

Incrementing versions

Our app’s versioning (for internal development and testing) follows a common major.minor.buildnumber strategy. Eg: 1.4.123. Each time the build runs, it increments the build number, updates the Info.plist, and checks it into git. The git commit uses the version number as the commit message so that later on we can see the exact code that was used to produce a given build.

To do this, PlistBuddy is used to extract the old version number, which is then incremented and saved to the Info.plist. In the ruby script, it looks like this:

oldVersion = `/usr/libexec/Plistbuddy -c "print :CFBundleVersion" Info.plist`.strip

This returns a string, such as ‘1.2.3’. We then need to increment this, which the following does:

components = oldVersion.split('.')
newBuild = components.pop.to_i + 1
components.push(newBuild).join('.')

We then need to save this new version number back to the Info.plist, which is a simple matter of using Plistbuddy again. So the complete function to read, increment, and save the file is as follows:

def incrementBundleVersion
    oldVersion = `/usr/libexec/Plistbuddy -c "print :CFBundleVersion" Info.plist`.strip
    components = oldVersion.split('.')
    newBuild = components.pop.to_i + 1
    version = components.push(newBuild).join('.')
    system("/usr/libexec/PlistBuddy -c \"Set :CFBundleVersion #{version}\" Info.plist")
    system("/usr/libexec/PlistBuddy -c \"Set :CFBundleShortVersionString #{version}\" Info.plist")
end

Don’t forget to add the code to check this back into Git after doing this.

Overriding bundle id and names

At this step, you can override the bundle id and bundle names. This is useful if you want to have different branches of your code available to your testers on TestFlight, such as dev and stage builds. Since TestFlight groups builds with the same bundle id/name, you’ll have to change it to do this.

PlistBuddy is used for this:

def overridePlistBundleName(infoPlist, name)
    system("/usr/libexec/PlistBuddy -c \"Set :CFBundleDisplayName #{name}\" \"#{infoPlist}\"")
    system("/usr/libexec/PlistBuddy -c \"Set :CFBundleName #{name}\" \"#{infoPlist}\"")
end

def overridePlistBundleId(infoPlist, id)
    system("/usr/libexec/PlistBuddy -c \"Set :CFBundleIdentifier #{id}\" \"#{infoPlist}\"")
end

Keep in mind of course that if you change the bundle id, you’ll need to use a different provisioning profile that matches the new bundle id.

Installing profiles

Your *.mobileprovision files should be checked into your repo, so that whenever you need to add a new device to your profile it is a simple enough job to update the profile on the iOS Provisioning Portal, download the updated profile, and check it in.

However, your profile will need to be installed. To do this, you first need to get the UUID out of the file, with code such as follows:

# Gets the uuid from a provisioning profile
def getProfileId(provisioningProfile)
    File.open(provisioningProfile,"r") {|f|
        raw = f.read
        nice = raw.gsub("\n","").gsub("\r","").
            gsub("\t","").gsub(" ","")
        matches = nice.scan(/UUID<\/key>(.*)<\/string>/)
        return matches.first.first
    }
    abort("Couldn't find UUID in: " + provisioningProfile)
end

Once you have the profile’s UUID, you can install it automatically, so that nobody has to log into the build server to install new profiles every time that someone updates the profiles. The code to install a profile:

# Installs a profile so we can compile against it and returns it's uuid
def installProfile(provisioningProfile)
    uuid = getProfileId(provisioningProfile)
    dest = File.expand_path("~/Library/MobileDevice/Provisioning Profiles/#{uuid}.mobileprovision")
    system("cp \"#{provisioningProfile}\" \"#{dest}\"")
    uuid
end

After installing the profile, you’ll need to store it’s UUID somewhere for later when it comes to updating the project file so that this profile is explicitly selected.

Zerg

Zerg_xcode is a ruby gem that is used to modify the Xcode project file so that we can explicitly set the provisioning profile and code signing identity (aka certificate).

It is unfortunate that we cannot set these as command line arguments and have to resort to updating the project files, but xcodebuild ignores build settings when archiving.

It is important to manually override the project file, as it gives us much more control over selecting the correct profile and certificate. This is necessary when we need to use different profiles for the different branches, because the bundle id’s are different for TestFlight’s sake (also, it prevents us from submitting a dev build to the app store!).

Here is the code I use to update the project file to manually set the certificate name (aka code sign identity) and profile’s UUID. Note that the certificate name is something like ‘iPhone Distribution: MY COMPANY’, which you can find in your keychain.

require 'rubygems'
require 'zerg_xcode' # https://github.com/ddribin/zerg_xcode

# Update the project to set the profile etc because
# xcodebuild only pays lip service to command line args
def doctorProject(target, identity, profileUuid)
    project = ZergXcode.load("MyProject.xcodeproj")

    configuration = 'Release'

    build_configurations = project["buildConfigurationList"]
        ["buildConfigurations"]
    configuration_object = build_configurations.select {|item|
        item['name'] == configuration }[0]
    configuration_object["buildSettings"]
        ["PROVISIONING_PROFILE"] = profileUuid
    configuration_object["buildSettings"]
        ["PROVISIONING_PROFILE[sdk=iphoneos*]"] = profileUuid
    configuration_object["buildSettings"]
        ["CODE_SIGN_IDENTITY"] = identity
    configuration_object["buildSettings"]
        ["CODE_SIGN_IDENTITY[sdk=iphoneos*]"] = identity

    target = project["targets"].select {|item|
        item['name'] == target }[0]
    build_configurations = target["buildConfigurationList"]
        ["buildConfigurations"]
    configuration_object = build_configurations.select {|item|
        item['name'] == configuration }[0]
    configuration_object["buildSettings"]
        ["PROVISIONING_PROFILE[sdk=iphoneos*]"] = profileUuid
    configuration_object["buildSettings"]
        ["CODE_SIGN_IDENTITY[sdk=iphoneos*]"] = identity

    project.save!
end

Build the .xcarchive

This is where the rubber hits the road: building the archive. Thankfully, with all the prerequisites taken care of by now, it’s a simple matter of the following:

xcodebuild -target "My Target" -scheme "My Scheme" -configuration Release clean archive

Note that we’re doing an ‘archive’, not a ‘build. It’s important to note the difference here. An archive builds a ’.xcarchive', whereas a build produces a .app and a .dsym. However, the .app and .dsym are fairly limited on their own – there’s not much you can do with them. An xcarchive is much more useful: you can import it into Xcode on another mac, re-sign it, and submit to the app store.

It is worth noting than an xcarchive is simply a package folder which contains the .app, .dsym, and a plist descriptor. So if you need the .dsym to symbolicate crashes later on, you can get it out of the xcarchive.

Xcodebuild will put the .xcarchive in a folder such as:

~/Library/Developer/Xcode/Archives/yyyy-mm-dd/MyArchive.xcarchive

To make it easier to find the just-generated archive, in my build script, before the xcodebuild step, I rename the Archives folder. Then after running the build, there will only be one xcarchive file inside the archives folder, which i grab, and then rename the Archives folder back as it was before building. This means that you can only run one build at a time on your build server, but it’s the best outcome given that you can’t control where the file is output.

The .xcarchive is really a folder, which contains the .app folder, among others. It contains symlink(s), which you have to be careful to preserve when copying, moving, and zipping it. If you break the symlink, you will get confusing code signing issues later on when you try to use it.

To preserve the symlinks, I make sure to use ‘mv’ to move the .xcarchive to my desired folder, as I could not get ‘cp’ to maintain relative symlinks. And when zipping it up, ensure that you use the -y option to preserve the symlinks, e.g.:

zip -rqy "MyOutput.zip" "/Folder/With/My/ArchiveAndIpa")
# -r means to recurse through folders, -q quiets the output,
# -y to preserve symlinks so as to not break codesigning

Create the .ipa file

Now that we have the .xcarchive, we need to produce the .ipa which we send to TestFlight for our testers to use. Use a utility called PackageApplication for this. But first you’ll need to find the path to the .app file within the .xcarchive first. I use the following in my ruby build script to do that:

app = Dir[outputFolder+'/*.xcarchive/Products/Applications/*.app'].first

And to generate the IPA filename that’ll go in my output folder:

ipa = outputFolder + '/' + File.basename(app).gsub('.app', '.ipa')

Once you have found those, perform something like the following:

/usr/bin/xcrun -sdk iphoneos PackageApplication
  "/Path/To/MyApp.app" -o "/Path/To/MyOutput.ipa"

One interesting point that took a while to realise, is that a lot of examples you’ll see on the internet for how to use PackageApplication are misleading: they show command line arguments for signing with a certificate and profile, but this is simply unnecessary, as your code was already signed as part of the archive process.

Also, be aware that PackageApplication only works if you pass it full, expanded paths for the .app and .ipa. So relative paths, or any path with ~ in it, will fail with no error message, confusingly. So be careful of that pitfall.

Upload to TestFlight

Once you have your ipa file, it is a simple matter of uploading it to TestFlight using their convenient curl api:

system("curl -F file=@\"#{ipa}\" -F api_token='#{token}'
  -F team_token='#{team}' -F notes=\"#{notes}\" -F notify=True
  -F distribution_lists='#{list}'
  \"http://testflightapp.com/api/builds.json\"")

This api is very simple and better documented on TestFlight’s site anyway, so i won’t get into it much here. It’s just worth reiterating that if you want dev and stage builds to be separately available on TestFlight for your testers, you’ll have to change the bundle id and bundle name as described in the section ‘Overriding bundle id and names’.

Here’s the gist of how you can build your iPhone app from the command line. Change into the folder that contains your *.xcodeproj, and run the following:

xcodebuild -target "My Target" -scheme "My Scheme"
  -configuration Release clean archive

This will generate an xcode archive (*.xcarchive) in ~/Library/Developer/Xcode/Archives/DATE/… somewhere.

Now you’ve got your xcarchive, and assuming that your project was set up to sign using an ad-hoc provisioning profile, how to generate the IPA file that you can submit to TestFlight for your testers?

/usr/bin/xcrun -sdk iphoneos PackageApplication
  "/absolute/path/to/MyApp.xcarchive/Products/Applications/MyApp.app"
  -o "/absolute/path/to/MyApp.ipa"

Note that PackageApplication somehow only works if you use absolute paths. So ~ and relative paths don’t work – beware of that.

Now, if you’re clever, you can script all this with ruby to be nicely automated. I’ll get into that in another post. This is part one of a series on continuous integration of iOS apps that i’m working on…

Guest post by Jason McDougall from Ironside Knights

If you had a business idea and someone offered to help you do all the hard work for you, help get your business up and running: what would be your response?

How good would it be if someone gave you proven instructions to help you get out of your current situation, guaranteed the return, and even offered to do the hard work for you. Would you take the leap?

I think sometimes we are scared, not confident in our abilities or just don’t want to see ourselves fail. But what if we could overcome that? When that person says to us: I will hold your hand every step of the way, get you up and running and ensure your success, and all you have to do is believe, what if we were able to take the risk?

Most of us say we would take it. But why is it then that most of us don’t?

Why is it that most of us are afraid: stuck where we are and not willing to step out and take a risk? Or we rationalise, thinking ‘I don’t have that person that will do it for me’. Ok, so I don’t either – but what if you spent an hour a week actually taking concrete steps towards your goals? After all it is only an hour – would you do it?

Take that risk, step out and believe for the impossible. Believe that we can, believe that we aren’t going to be stopped at every corner. Believe that like Benjamin Franklin, with a bit of hard work we too can achieve our destiny.

This week I want to focus on what we believe is the impossible, whether it be changing our attitude, making those sales calls or just teaching our kids something that they will treasure for the rest of their lives. I want to encourage each of us to step up, step out and take a risk. Do it from a place of confidence that we have the potential and we can achieve it.

I’ve been thinking lately about the concept of ‘starting small’, and now it’s the time of year for new year resolutions I’m hoping to marry the two.

So the idea is to approach my new years goals in a small way. Sneak up on them, as it were. Catch them unawares. And then knock them flat.

Watch the chips fly

I maintain that it’s impossible to remain motivated at anything unless you can see progress, the metaphorical ‘chips flying’. So why do we set goals that will take an entire year to accomplish? Who has the kind of discipline to remain motivated in their goal half-way into the year, let alone for the full year?

So here’s my strategy to keep myself motivated: lots of small goals. Ideally, a week each. That way, as i can tick them off rapidly, and see my progress, it’ll be easier to remain motivated.

Games and Scouts

This idea of lots of little goals came to me, of all places, while playing jetpack joyride on my phone. This game has a very common ‘game mechanic’ these days, which is aimed at keeping you engaged with the game. Because the longer they can keep you engaged with the game, the more likely it is that you’ll spend money on upgrades etc.

The game mechanic is to give you lots of small accomplishments as you play. At any time, there are only three goals that you can achieve. The small number of goals avoids too-many-options paralysis and helps keep you focused. And the fact that the goals are simple to achieve keeps you motivated because you can see your progress.

There’s nothing more demotivating than trying to do something incredibly difficult and making absolutely zero progress, is there? You just feel like you’re wasting your time. Which is the feeling this ‘game mechanic’ aims to avoid.

And this mechanic isn’t even a new idea – the Boy Scouts thought of it a very long time ago! Their badge system is the original game-like engagement strategy: lots of small, achievable goals that you can try. And as you achieve each one, you get a nice pat on the back: a little badge to sew onto your uniform. Sometimes i wonder if the game companies deliberately copied this system. It’s genius.

One more thing: as I’ve written about before, it’s impossible to really stick with something if you don’t really believe that you stand a chance at achieving it. So by keeping these goals within your reach, by making them believable, you stand a much better chance of sticking with it.

Example goals

So, when coming up with my goals, i’m keeping a few things in mind so as to emulate the game/scouts system: Keep them simple, short, achievable, and part of a bigger goal.

A bigger goal i have this year is to be less tired and irritable. So my first few mini-goals are:

• Get to bed by 10
• Not drinking any coke/coffee late in the day
• Go cycling every day

These goals will hopefully help me sleep better, by making me more regular in my sleep patterns, with less caffeine in my system and a bit more tired. Better sleep = less tired = less irritable. Brilliant!

How

So how to put these goals into place? In my case, i’m taking one at a time. Each goal will last for a week, and i’ll make a little checklist on a post-it note for each day. I’ll keep this in my wallet and check it off each day, and at the end of the week i’ll hopefully have done well. Once a week, i’ll use Trello to keep track of 3 lists: upcoming goals, my current goal, and accomplished goals. The accomplished goals is important: looking at this list rapidly grow is the key to keeping motivation and momentum up.

The key here is that everything is so simple and achievable. I’m not shooting for the stars or anything crazy. All i’m doing is getting to bed early for a week. Anyone can do that. Then i’ll cut out some caffeine (still have it in the morning though) – who can’t keep that up for a single week? As for cycling, well i’ll do the best i can.

Anyway I think it’s a more realistic system than massive goals like ‘Learn another language’. I mean, goals like that will get you nowhere. It’s like going indoor rock-climbing and going straight to the difficult wall. You’re not going to get anywhere. Much better to start at the shorter walls with lots of easy-to-hold rocks. Which is, in a nutshell, what i’m doing.

And, if i could be so presumptuous, you should too.

So, it’s curtains for 2011, and i’m old now, having just had another birthday. Time to grow up, I guess. Well – in that vein, here’s a bunch of things i learned and grew in over the last year.

Be active, not passive

I spent 4 years in a dead-end job, waiting for something great to happen. Needless to say, it didn’t. Eventually, the revelation dawned on me that I was meant to make that ‘something great’ happen. I should have been active, taking initiative, rather than passive. We’re not meant to sit there and take life as it comes, we’re made to get out there make a ruckus.

This led me to wonder, ok so i’m meant to do something, but do exactly what? Options in life are basically infinite, so you need some boundaries when choosing. Which leads to my next two lessons.

Use what’s in your hand

So – what to do with my newfound zeal for action? Well, the first key is to look at what’s in your hand. Do what you can with what you have. In my case, that is programming skills with making iPhone apps. So I started making lots of apps in my spare time and on the train to work, and putting them on the app store. I contacted a couple of charities and offered to make apps for them.

Try a bunch of things

The next thought i had was to use the concept of ‘failing forwards’ when it came to trying to figure out what i should be doing. Basically, try a bunch of ideas, and see what fails and what works. The failures – well, give those up as a bad idea; as for the successes, keep at it with those.

So for me, working with the charities ended up being a failure. Working on my ‘comet server’ project was another failure. But working on iPhone apps in my spare time was a resounding success.

Start a book club with friends

This year I started a book club with a few friends. We mainly read inspirational / leadership themed books, and meet up every few weeks to discuss what we got out of them. It’s been a great source of inspiration and growth to us all.

Some practical things that have been important: Kindles, not paper books, are the only way to go in Australia – as it simply takes too long to ship books from the states for it to be workable. Also, we’ve decided it all works better if we’re reading the same book, so that we can all discuss it together.

It turns out that Benjamin Franklin did exactly this – set up a book club with friends. In the day of kindles and cheap ebooks, it’s a really easy way to grow.

Start small

One recurring theme in my life this year has been to ‘start small’. In my apps, i try to keep them small and manageable so that i’m more likely to finish them. Same with other projects in life: my friend one day wants to become an ambassador for fatherhood. So we’re working on getting to start small, as a blogger. Once he’s got 100 posts, he’ll write an ebook. Later on, possibly a printed book, and then we’ll see what doors that opens.

The key is to start small, with something that is within reach and currently achievable. Starting small is the key to achieving big things.

If you’ve got no platform, you can still work on yourself

It’s all about building a platform. Someone like Bono has a massive opportunity to make a difference, because of his influence. His fame and influence with world leaders are his platform. And he can act from that platform and achieve far more than most people can.

I’ve found that living an influential life is about building that platform. We start with no platform, then we may have a small platform when we have a family to influence, then a larger platform if we became a business leader, and so on. As before, it is all about starting small, and doing what we can with the platform we’ve got. As we do what we can with our current sized platform, it’ll naturally grow – and then we can do more.

But all this left my friends and I with the question – what do we do, as guys with no platform or influence? Well, we realised that if you’re not in leadership over anyone else, you’re in leadership over yourself. So your own self is your platform. So do what you can with that – build yourself, learn to lead yourself and grow yourself.

I’ve got a plan now

This year’s growth started with the thought: I’m getting older, probably should grow up and do something with my life. But no further plan was forthcoming until much later on. It’s funny how doing the best with what you’ve got brings ideas to the fore about what you can do next.

Anyway my plan (described in another blog post) is to keep working for a few years, meanwhile working on apps in my spare time. And when the time comes that the income from apps reliably eclipses my day job, i would leave work and start a business creating iPad applications for small businesses, with the dream being to emulate the success of Dr Chrono (an iPad medical management app) in Australian hospitals.

It’s surprising what you can achieve with a bit of work

There’s been a lot of hard work this year. Between me and a friend, we’ve written a heck of a lot of apps and blog posts. But it’s been amazing what has come out of it. In his case, his quality of writing has gone through the roof. His first book is looking more achievable by the day. As for me, 10 apps later things are looking bright.

This is used to increment a build number in a tracking file for use in a build / CI script:

#!/usr/bin/ruby

def increment(filename)
    # Read it
    file_str = ''
    if File.exists?(filename)
        file_str = File.open(filename, 'r') {|file| file.read }
    end

    old_version = file_str.to_i
    new_version = old_version+1

    # Write
    File.open(filename, 'w') {|file| file.write(new_version) }

    puts "Incrementing version number in #{filename} to #{new_version}" 
end

if ARGV.length < 1
    puts 'Usage: VersionIncrement '
else
    increment(ARGV.first)
end