Escort Missions Logo

Escort Missions

You ever get the feeling that life is just one long series of Escort Missions?

Finding Relevant WWDC Videos

As I’ve said before, I find the WWDC videos to be invaluable and I try watch all of them eventually. But there are a lot of them, and it can be hard to find what’s relevant. And a lot of them I go back and watch again when I start working with a different part of a project.

So I’ve developed a trick, and I thought I’d share it with you all.

I go to the site where the videos are hosted and click on the “view all in iTunes button”. From iTunes, I download all the slides (Click a track like “Essentials”, then click “Slides” just above the list, and then click the “Get Tracks” button in the header).

I keep all the slides for WWDC 2010, 2011 and 2012 in subdirectories of a folder named “WWDC slides” in my Documents directory. It’s indexed by Spotlight on my Mac.

From then on, when I’m working on a project, and I’m having trouble with something, or trying to remember something I might have seen, I open up that folder in Finder, and type the Class or Method names of the Classes I’m working with, and Spotlight will tell me the session names of the videos I might want to watch.

So, for example, if I type ‘NSFetchRequest’, the first result is “Session 214 – Core Data Best Practices” from WWDC2012. I type ‘registerNib:’, and I get “Session 125 – UITableView Changes, Tips, Tricks” from WWDC2011 (among others).

Then I just go to iTunes or the website, and I know which video to go watch.

It’s a handy trick (and I use it to search through all my eBooks on programming, as well), and when I’ve recommended specific videos to people, I’ve had several of them ask me how I keep the videos straight.

So hopefully it’s useful to some of you.

New Work in Progress - Million Words: Multiplayer Crossword Game for Parents and Kids That Grades on a Curve

Although I do iOS Contracting to pay my bills (at least to date), I hope one day to earn a living from my own apps, and, although it’s not ready for release, the time has come to unveil my new project.

GamePlay ExampleMillion Words is a turn-based crossword game where you’re scored not by what letters you managed to get into your word, but by the grade level of your word, relative to your age. This way my six-year-old daughter could play “HELLO” and I could play “HELICOPTER” and we would get the same number of points (more or less).

My Top 5 Factors for iOS Contracting Success

About a year ago now, I was contemplating leaving my day job and becoming an indie* iOS developer. My last day working in a cube farm was June 30th, 2011. Now, as I pack to leave for WWDC in the morning, it occurs to me how much my life has changed since I made that decision.

When examining my finances in preparation for this trip, I determined that in my first year as an indie I’ve made within $1000 of the amount of money I made in salary my last year as an employee, while spending more time with my family and enjoying my work so much more. Personally, I consider that to be a success.

Looking back, I can think of 5 things that I did that I think contributed most to that success, and I wanted to take this opportunity to share them with you all.

What I Learned During My Mac App Store Review

Two things happened on Thursday that made it obvious to me what I should write about this week. Mountain Lion was announced, and my first Mac App was approved for the Mac App Store.

Even though iDevBlogADay is about iOS programming, more and more of us are moving from iOS to the Mac. With the announcement that GameCenter will be coming to OS X, I’m guessing that more iOS developers might be thinking about coding for the Mac now than might have been last week.

So today I’m going to talk about my experience in getting my first App on the Mac App Store and specifically the differences in the approval process between the Mac App Store and the iOS App Store.

HTTP Testing to the Edge on iOS: the School of Hard Mocks

I’m a big fan of Automated Testing, even on iOS projects, but even when I was doing mostly Ruby, Java and C# work, I was never a big user of mock objects.

Now, I’ll admit that Mock objects can be useful under some circumstances, but I’ve seen them used too often in cases where a bunch of different developers each build their own little fiefdoms of their own code surrounded by Mock Objects where they interact with anything else. Each developer’s code runs perfectly when being tested against Mock input, but when you put all that code together, you can’t get a transaction working end-to-end, because the real world doesn’t obey the assumptions inherent in the Mocks.

So the Automated tests I write have more of a tendency to be more like what are called “Integration Tests”, even though I use “Unit Testing Frameworks” to write them.

When you combine that with the fact that I write a lot of iOS apps that talk to web servers, I want a way to test how my code talks to HTTP. And I want to know that my code handles things even when any library I happen to be using hands me errors to deal with.

When I first solved this problem years ago, we were using the Google Toolbox for Mac as our unit test framework, because SenTest didn’t work well back then. So, at the time, I built a solution based on GTM, but I went recently to try to recreate that solution for a new customer, and I realized that the files I had used had been deleted from GTM.

So I went spelunking back in the history of GTM, and pulled out the last version of the the files I needed before they were removed, and put them up on github in a new repository I’m calling SyntheticServerTest.

The way you use it is to look at the example test file.

You just have to run:

[testServer startServerWithDocumentRoot:]

With a document root directory that contains web content (I usually use ‘curl -O’ to pull known pages (either good or errors) from the server and write them to that directory), and have a mechanism so, that, while your test is running, the host part of the URL gets replaced with

@“localhost:%d”,[testServer port]

and the test HTTP server, running in the background (in the simulator or on the device), will get the HTTP request and hand you back the test data file in response.

This way, you can test your App’s entire HTTP stack, including any parsing libraries you may be using, with both real data (that doesn’t require you to be on line) and with bad data, to make sure you are correctly handling whatever errors your parsing or network library is throwing off.

Using Regular Expressions Part 2 - the Cocoa Connection

Last time, in Part 1 of this series, I wrote about the basics of regular expressions, and the phrases I tend to use. Today, I’m going to talk about the mechanics of how I use Regular Expressions in Cocoa.

But first, an historical diversion

In my opinion there are, two different ways that programming languages implement Regular Expressions: The perl/ruby way, and the Java/C#/Python/Cocoa way.

In ruby and perl, regexes are implemented directly on the String type, whereas in the other languages, there a separate object that contains the functionality. Here’s what you need to know to do a regex substitution on a string in ruby:


clean, easy, and immediately useable if you know what pattern you want to use.

Here’s what you need to know to do the same thing in Cocoa:

+[NSRegularExpression regularExpressionWithPattern:(NSString *) pattern
options:(NSRegularExpressionOptions)options error:(NSError **) error]

-[NSRegularExpression replaceMatchesInString:(NSMutableString *) string
options:(NSMatchingOptions)options range:(NSRange)range
withTemplate:(NSString *)template]

which is not clean, not easy and contains a bunch of stuff you have to go look up to be able to get started. What are NSRegularExpressionOptions and

NSMatchingOptions? What’s a template? Do I really have to create an

NSRange for this? And that leads to the obvious question: Is all this effort really worth it?

Now I don’t know about you, but I don’t want to spend any effort remembering any of those option parameters, and I don’t want to take the time to look them up any time I want to use a regular expression. To me, the beauty of Objective-C is that it gives us the ability to build most of what you need to know directly into the method signatures.

Using Regular Expressions and Retaining Your Sanity

At a recent Austin, Texas Cocoacoder meeting, I made an offhand comment giving someone a regular expression that would help with a problem they were having. That led to two things. First, I was asked to put together a presentation (which I’ve been working on) on using regular expressions to give at an upcoming CocoaCoder meeting, and second, I was asked why on Earth anyone would use something as opaque and unmaintainable as a regular expression in this day and age.

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

Or so goes the old saying. Personally, I rarely find this to be true. On the occasions when I can identify with that quote, it’s because I’m trying to deal with a regex written by someone who, in my opinion, tried to do far too much at once.

I have a certain philosophy that I try use regular expressions that seems to keep me out of trouble. In this post, I’m going to try to make a set of rules out of that philosophy. They are:

*Limit yourself to only the basic meta-characters.

*Favor clarity over brevity.

*Take more smaller bites.

*Beware of greedy matchingLet’s break these down.

1. Limit yourself to only the basic meta-characters.

Pretty much every regex tutorial or man page has a giant laundry list of what characters in a regular expression match what characters in the string you’re trying to match. I ignore most of these and look them up when I have to (which is only when I’m looking at other people’s code). I use a few “phrases” over and over, so let me go through some of those to try to give you some examples:

^.* means “the junk to the left of what I want”

This breaks down as ^ (the beginning of the string) followed by .* any number of any character. Likewise:

.*$ means “the junk to the right of what I want”

This breaks down as any number of any character .* followed by $ (the end of the string)

[0–9][0–9]* means “a number with at least one digit”

The brackets ( [ and ] ) mean “any of the characters contained within the brackets”. So this means 1 character of 0–9 (so 0 1 2 3 4 5 6 7 8 or 9) followed by zero or more of the same character.

[^A-Za-z] means “any character that’s not a letter”

The ^ as the first character inside the brackets reverses means “not” so instead of meaning “any letter” it means “anything that isn’t a letter”. Likewise, [^0-9] means “anything that isn’t a number”.

. a literal dot

So this is what you’d use to match the . in .com

( …stuff… ) stuff I want to refer to later

This causes the string matched inside the parenthesis to be retrieved later.

2. Favor Clarity Over Brevity

There are a lot of shortcuts you can take, like \w means “any character that appears in a word” (I know because I just looked it up). Don’t use it or things like it. Because \W (that’s a capital ‘W’) means “not a word” and they look too much alike. Also, the mnemonic is rubbish, does “W” stand for “Word” or “Whitespace”? Use [A-Za-z] instead. It’s clearer when you’re writing it, and clearer when you look at it later. It’s more keystrokes, but it’s worth it. Likewise there’s a ‘+’ which means “one or more” so [0–9]+ is equivalent of [0–9][0–9] , but if you always do it the second way, there’s one less special character to remember and you won’t ever accidentally type [0–9] when you meant [0–9]+ and accidentally match nothing.

3. Take more smaller bites.

This is really the core of it. I often use several different regular expressions to get one string I want. It’s more typing and it may potentially create some intermediate strings that have to be thrown away, but it’s much easier to read. So if I were trying to extract an HREF link from an HTML document, for example, I’d use two regular expressions:




The first one of those matches everything up to the single or double quote before the URL, and the second one matches from the quote after the URL through the rest of the string. I use a substitute mechanism to throw both of those parts of the string away, and I’m left with the URL I want. *(Note – Those regex’s are simplified for illustration purposes. For example, the = sign might have whitespace around it, etc.)

4. Beware greedy matching

People get themselves in trouble by forgetting about greedy matching which is the requirement that a

in a pattern matches as much as it can. So let’s say we were doing URL extraction again, and you used the pattern:

^. href=“ (.*)”.$

In theory, that should say (out of the whole string, from beginning ( ^ ) to end ( $ ) grab the thing in between the quotes right after the string href=“ and remember it. However, if I gave you the string This is a link but This is a link, too. and you ran your regex against it, you’d get>This is a link but <a href=”** as what your regex remembered, because the “. grabbed everything between the very first quote and the very last quote. In this case, either use ^. href=“ ([^”])”.$ (replacing the . with [^“] so that the .** doesn’t match quotes) or use more regex’s, and take a smaller bite with each.

That’s a long enough post for now. Next time, I’ll introduce an Objective C category I’m working on and will hopefully have done by then which will simplify using NSRegularExpression, and we’ll work through more examples.

360iDev Conference Notes, or How I Spent My September Vacation

This Thursday, I got back home after four days at 360iDev 2011 in Denver. I went last year, which was easy for me because it was in Austin where I live. I was concerned about the extra time and extra money it was going to take to go this year, since it was in Denver. Now that I’m back, I’m so glad I went. I have no hesitation about recommending it to other people, so that’s what I’m about to do. This post is going to be long, because there was a lot going on, so feel free to skim the headlines and skip the things that aren’t relevant to you.

Let’s start with value.

My total out-of-pocket (not including food) for this 3-day conference plus one day of workshop was $1215.96. $299 for the conference ticket, $638.57 for the hotel, $195.40 for plane tickets (from Southwest Airlines) and some misc stuff like cab fare. By contrast, two days plus a workshop of an iOS conference coming up in a couple of months is $895 for just the conference+workshop (no lodging or travel) – and that’s the early bird pricing.

The talks

Photoshop for Devs

Pow screen from Mike Berg classI started Sunday with a Photoshop for Devs workshop from Mike Berg from We Heart Games. He walked us through some basics, and then we did a project mockup (see POW image right – exported from the PSD we did in class) and then sliced it into PNGs for export into Xcode. It was a very interactive talk. He took a lot of questions from the class, and handled them very well (even when the breakers kept blowing out), and even took several more advanced questions and walked them back so that even those of us that didn’t understand half the vocabulary in the question understood at least the concepts and issues involved by the time he’d finished answering.

Keynote – Matt Drance

Next was the Keynote.
Matt Drance, author of the fantastic iOS Recipes book and former Defense Against the Dark Arts Teacher Apple Evangelist did a great job of kicking off the conference, convincing us that, first and foremost, developers should be storytellers, and that code can be a lot like Sprinkler systems. (See a longer writeup here).

Going Indie without Going Broke

I saw Kyle Richter’s talk next. He reminded us that running a business was all about people and communication. He summarized for us literally decades of advice about working with people, running the gamut from Dale Carnegie to Daniel Pink. It was a lot of useful material and references, but most importantly, it helped remind us that all the cool coding techniques are useless if no person wants to use your code.


Next was a packed talk on blocks from Justin Williams, author of Elements. He gave us a quick rundown of what blocks are, then explained to us how to use typedef to make them not ugly (see his example on github). Then, he showed us how he uses blocks to simplify async calls, explained to us how he would redesign some common SDKs (like Dropbox) to use blocks, and then walked us through examples from at least 8 different open source block extension libraries covering everything from KVO, NSTimer, UITableView, and UIAlertView to JSON. It was a packed room and packed with information, and I still have several of the github projects he mentioned in OmniFocus waiting for me to have the time to go through them.

Understanding View Controllers a.k.a Debugging Magic

After lunch, I went to Bill Dudney’s talk on Understanding View Controllers. Bill is another former Defense Against the Dark Arts Teacher Apple Evangelist, and he really knows his stuff. He took “understanding” to a whole new level. Rather than being content to tell us how view controllers worked (which I would have been perfectly content to have had him tell me), he instead dropped us into gdb, set a break point on

–[UIApplication setDelegate:]

and led us up and down the rabbit hole call stack, stopping only to explain to us how to pick out arguments to objc sendmessage and how to inspect and alter objects on the fly. He told us to go look up Apple’s “Debugging Magic” docs on Mac OS X and iOS, and although I’ve barely scratched the surface of them, I’ve already fixed a problem I’d had previously with the application of

(gdb) po [[self view] recursiveDescription]

which I already know is going to save me a ton of time.

You know what @BMF stands for, right?

What is Step 2 Monday night was the indescribable Mike Lee’s session on Product Engineering. He was, as always, both the consummate educator and the consummate entertainer, even when the public address system utterly failed in the most painful way. He is also the first person to ever finally explain Step 2) to my satisfaction, and he did it in full Mariachi regalia, complete with backup band. A longer write up of his talk is here.

I heard some grumbling toward the end of Mike’s talk, when he started talking about Appsterdam. In the TUAW writeup I linked above, it even said “It was hard to tell how the developers in the audience felt about the Appsterdam pitch.” Well, I was a developer in the audience, so I’m going to take a couple of paragraphs and throw in my two cents.

I’m going to stereotype somewhat here, but I’m going to say that I met and talked to two kinds of developers at 360iDev: those whose income is directly dependent on how their Apps sell, and those that are expecting to get paid even if the Apps they are writing don’t sell at all, and Appsterdam plays much better in one camp than the other. I’m in the first camp – at the moment, I have no source of income except for the revenue my Apps make and the money I’m paid to write Apps on contract. It’s hard being a true indie developer. It’s scary knowing that if an App I worked on for months doesn’t sell (or I can’t work for health reasons), I don’t have a safety net except my own savings. It’s even scarier knowing that I’m living my life one patent-troll away from bankruptcy, because even in the best case, my Apps are unlikely to sell enough to pay the legal fees for a patent lawsuit in the U.S.

So even though I doubt I’ll ever move there, I like that the Appsterdam crowd is trying to help the indie developers. I like that there’s a place I can go and work where I can innovate and not starve if I fail. It encourages me to try to be a better indie, whereas most of what I read makes me want to go get a “real job” so I can support my family without all the fear. I think that the developers in the other camp – the W-2 employees whose paycheck is going to show up next month regardless, are less interested in Appsterdam and what it stands for. They want to learn about cool coding tricks, and they don’t want to think about legal and health care issues, so I think for them, that part of Mike’s talk wasn’t relevant. That was at least true of the group of folks that were sitting in front of me.

“I really don’t care, and it’s better that way, and I have the video to prove it”

Tuesday morning was David Whatley, telling us about how his Results Only Work Environment experiment contributed to the success of their latest game Tiny Heroes. It was a great talk, but the punch line was amazing. It was a set of videos of his employees answering the question: “how much would someone else have to pay you to give up the Results Only Work Environment?”. Their answers were priceless, occasionally even literally. To a person, they each said it would cost large amounts of additional money to get them to work under any other management system.

Memory Management and Crowd Control

Next was Dave Batton’s iOS memory management talk. It started off pretty well, and I was enjoying it, but there was an attendee in the crowd (who was typing away during the first part of the presentation) that objected to an edge-case in one of the examples that he hadn’t been paying attention to, and the talk quickly devolved into an argument between the speaker and a few members of the audience. I found it very disappointing, because I would have liked to hear what the speaker had to say.

Xcode 4 Tips and Tricks

Next was Kendall Gelner’s talk on Xcode 4. I had taken Kendall’s Xcode 3 workshop on Sunday in 2010, so I knew it was going to be a good talk. I wanted to take his workshop again this year, but I decided that I had more need to learn in the Photoshop area than XCode 4, so I compromised and went to this session instead. It was great, as I expected. I recommend you check out this git repo: which contains the coolest stuff from the talk.

How to make a game in 5 easy steps in front of a live audience

Sample GameThe next talk I went to was Intro to Cocos2D by Ray Wenderlich and Rod Strougo, who wrote the Learning Cocos2D book and who released their slides and sample code from their talk. They spent about half their time telling us about cocos2d and what it was, and the other half literally building a game right in front of us. They started with a few previously-prepared PNGs and WAV files, created a brand new cocos2D project in Xcode and did everything right in front of us, and it wasn’t rushed, and it was explained as they went. That it worked despite Murphy’s Law and the ever-present wrath of the “Demo Gods” is a testament to their skill as presenters, knowledge of the subject, and the simplicity of the cocos2D framework.

Good Product + Good Relationships = Good Press

The last session of Tuesday, I had a real quandary. There were three sessions I wanted to go to, the great Marcus Zarra was doing a talk and I wanted to go because I learned a ton from watching his Core Data Video series.
Michael Schneider was giving a talk on Legal Issues, which has been on my mind a lot lately since Lodsys. But the session I attended instead was Jonathan George’s session on Hacking the Press.

Jonathan’s talk was just what I needed. Being an introvert, talking to people doesn’t come naturally to me, and I’d much rather avoid it. But when he laid out his experience building relationships to get press for his Boxcar App (which is really handy by the way – I use it many times a week), it was great motivation for me to put the effort into building relationships. When I’d rather not do something, it’s easy (for me at least) to convince myself that it wouldn’t help anyway, and to put it off or never get around to it. By giving us concrete examples that taking the time to build relationships makes a huge difference, even for someone like me who wasn’t born a “people person”, he gave me ammunition I need to convince myself to send those emails.

It’s the end of the Console Wars as we know it, and I feel privileged

The general session to close Tuesday was Michael Gile on hacking the Apple TV2. There’s a good write up of it on TUAW, so I won’t say a lot about it, except to say that it made me feel that, as an iOS programmer, I’m ever better positioned to be in demand over the next few years than even I had expected.

performSelectorOnMainThread, you are dead to me

I skipped a couple of sessions Wednesday morning to go to the labs, so the next talk I attended was Nathan Eror’s talk on Queues and Grand Central Dispatch. He put the code from his talk on github. It was an abbreviated talk because the previous session ran over, but Nathan handled it like the pro he is. He told us what got called on the main thread and what didn’t, how to make calls concurrent or not, how to use a queue as a barrier to control access to a shared resource (in this case an NSMutableArray) and even how to use GCD to create a singleton instance in an ARC-compliant way with dispatch_once(). It’s going to save me a lot of time, and help me write better code.

On Consulting, Contracts, Contrariness and Contention

The last talk I went to was by Andria Jensen of Appsolute Genius. She had prepared a very detailed talk with explanations of how she runs her successful App contracting business. She even included real numbers and percentages and data that many companies are too proprietary to share. Unfortunately, though, she didn’t get very far into her presentation and didn’t get a chance to finish. Sadly, some members of the audience didn’t like the way she estimates, or charges, or proposes work, or does something else and, instead of realizing that there’s more than one way to do things and trying to learn from her experience, they interrupted her and argued and robbed the rest of us of the opportunity to benefit from the information she had wanted to share.

Wrapping up (for now)

There’s still more to tell – I haven’t touched on the Labs or the Parties or the Networking, but this post has already gone on too long. I’m going to have to leave those for another time.

In short, though, if you have a chance to go to a 360iDev, you’re doing yourself a disservice if you don’t. It’s a great conference and an even better value. I can’t recommend it highly enough, and I hope to be attending again and again.

Steal This Code and Protect Their Data: Simplifying KeyChain Access

Invalidname Meet iPhone Explorer Invalidname Learn Keychain Noel Llopis Keychain is Obtuse



The Code

The last couple of months, I’ve been working on my first Mac App (more on that in a later post).  As part of this App, I’m calling a REST API that requires that I have the user’s password for that service to use in the API calls.  Although that API is a minor part of the App, and although the service doesn’t have horrible consequences if someone gets the user’s password for it (in my opinion at least), there was no way I was going to store that password on disk unencrypted.  After all, users have a bad tendency to use the same password for multiple services, and one of those other services might contain important information.

So I dug into the Keychain documentation, and it took me a while to figure it out.  Meanwhile, I was learning Bindings for the Mac App, since in my time programming iOS, I’d never had the chance to use Bindings before.  And I decided that it was a good opportunity for me to combine the two and learn something, and maybe help someone else along the way. I fought with it off and on for a month or so, and released it under the MIT license at the end of July.

This is the result.  It’s a project that simplifies using the Keychain by making it accessible through methods patterned after NSUserDefaults.

Their Data

So here’s the problem, anything you persist in your App unencrypted can easily be extracted by a program like this,   If you put your own encryption in your App, you could run afoul of Apple’s encryption policies and potentially Law Enforcement Organizations.  The KeyChain makes it possible to protect the data that you persist from (all but the most determined) prying eyes.

Now many programmers don’t think they’re persisting any data that they need to protect, because they don’t get passwords from their users.  But think for a minute about other information the user might not want anyone to be able to see.  And then think about any data that you wouldn’t want the user to be able to read (or alter).  I don’t write games myself, but when I talk to my friends that do, I hear them complain a lot about people “cheating” by trying to hack their save games.  While you wouldn’t want to stick a huge amount of data in the keychain, some strategically selected pieces of data (current amount of “gold” the user has, or maximum hit points) might be appropriate to store in a safer location than in a file on disk.

How to Use it

I intentionally wanted to write this library to be as easy to use as possible, so I decided to make it match the semantics of NSUserDefaults, since that’s in every iOS programming book I’ve ever seen, so in theory, it should be well known to anyone needing it.

To install it, check it out from github, grab the 4 files in the  PDKeychainBindingsController folder (the .h and .m files for PDKeychainBindings and  PDKeychainBindingsController) and drag them into your project in XCode.

Then, when you would normally have used:

[NSUserDefaults standardUserDefaults]

You should be able to call

[PDKeychainBindings sharedKeychainBindings]

instead (at least for the most common methods).  If you’re doing an OS X App, and you’re binding a NSTextField or the like, then where you would have called

[NSUserDefaultsController sharedUserDefaultsController]


[PDKeychainBindingsController sharedKeychainBindingsController]

instead (again, at least for the most common methods).

There are two differences, the first is that the Keychain API only wants to work with Strings (well, NSStrings).  So if you want to store something else in there, you need to convert it to a string yourself before you put it in the keychain (and change it back it when you take it out).

The second is that, in order to simplify it, I took out the need to run the synchronize method.  As soon as you call the set method, it gets persisted.

I’d like to thank  Chris Adamson and Noel Llopis for unwittingly helping me decide on the topic for this post.