Author: Jeff Kelley

I make iOS apps for Detroit Labs.

Coding in the Clink

It’s 5:15 AM on a Saturday—a precious Saturday—and I wake up, late. My alarm was set for 4:30. I get ready in a hurry, trying not to wake anyone up, and get out the door. It’s cold and dark, and it’s still cold and dark an hour later when I fill up my car with coworkers and a friend.

The four of us drive another 150 minutes or so, across the state border and into Ohio, to the Marion Correctional Institute, where we will spend the day pair programming with inmates in Java. This might sound crazy to you—taking a day off to go do more programming, and to do so in a medium-security prison, no less! Despite the cold, the drive, and the fact that we were behind several layers of gates and fences and very large doors, as soon as we started coding, that all melted away.

To call me inexperienced in Java is to make the understatement of the year, so leading up to the event I did some simple TDD exercises on my own in Eclipse to try to get my brain thinking more in Java than in C. This would prove invaluable, as one thing we didn’t have in prison was Google. Think about that for a minute: right now I effectively know any programming language, since it’s easy enough to pop over to a browser and type “how to make a hash map in x” where x is your language of choice. In prison, we had no Internet connection; just a browser pointed at a local copy of the language reference.

We were doing the EverCraft kata, which involves creating a D&D-style game, complete with HP, AC, attacks, rolling for damage, you name it. It was a fun problem domain, and one that I may come back to if I need a kata for learning a language. All told, we had six 40-minute rounds of pairing, and though we never got very far in any of the sessions, we had a good time, I learned a lot about Java, and (hopefully) I helped my partners learn as well.

I’ll leave the minutia of who all was there to the novel-length post on the JavaGuys site, but one of the highlights was a special guest appearance by Uncle Bob Martin. Any time he’s in the room you’re bound to learn, as if by osmosis. Between each coding session, we had a quick retro to talk about it, and in those it was clear that, in prison or not, a developer is a developer. We’re all just people, and some of us happened to be staying past 4:00.

So, why did I do it? What could possibly get me out of my warm bed at a stupid hour on a Saturday morning? On a superficial level, my co-worker Amber suggested it to me at work one day, and I try to keep an open mind about saying yes to things: speaking at user groups and conferences, appearing on podcasts, or going to lunch with functional programmers. I find that, more often than not, these opportunities to grow as a developer and a person are a great use of one’s time. I’ve never regretted spending my time in the community, and a lot of significant opportunities in my life (my current (amazing) job included) have been a direct result of saying yes.

There’s another, deeper reason to code in the clink. It can make an actual difference in someone’s life. Finding a job isn’t particularly easy for anybody these days, and much less so for people who have been incarcerated. Programming, whether it’s selling your own app in the App Store, picking up some freelance work online, or even just contributing to open source and trying to make a name for yourself, is one of those careers that requires no qualifications. You don’t have to fill out a résumé to send a pull request. To teach programming to someone in prison, therefore, is to give them a fair shot at a decent job when they’re out. That’s why I was there, and that’s why I’d love to go back next time.

Slides: Understanding Objective-C Inside and Out from CodeMash 2014

I braved the polar vortex to come down to Sandusky, OH for the always-amazing CodeMash conference. I gave a talk about Objective-C’s underpinnings in C and the like. You can find the slides on SpeakerDeck, and the slides and code on the unofficial GitHub repository for the conference. Thanks for coming, everyone!

Slides: Understanding Objective-C Inside and Out from CocoaHeads Ann Arbor

Last night I gave the Understanding Objective-C Inside and Out talk at CocoaHeads Ann Arbor. You can find my slides on SpeakerDeck.

We had a really great turnout—CocoaHeads Ann Arbor is almost outgrowing its space! If you’re in the SE Michigan area (or even further—there are attendees from Kalamazoo and Grand Rapids) you should come to the next meeting and learn about Auto Layout.

Understanding Delegation

I’ve seen a lot of people learning iOS for the first time. Some of them have been learning Objective-C as their first programming language. Understanding delegation is without fail a stumbling block as you learn the language and the frameworks. This blog post is going to attempt to explain delegation using what I have come up with as my best analogy for it so far. I call this analogy “the Shirt Delegate.”

While not many people can relate directly to the fantastically rich, we can imagine the things we would want in our life if, say, Google bought our app for a cool billion. You might want fancy cars or a new Mac Pro, but you know what I want? A Shirt Delegate.

When fantastically-rich Jeff goes to bed at night, I take off my shirt and put it in a bin. When I wake up, the shirt is gone and a new one is hanging in my closet, pressed and ready to wear. I don’t know how it got there, and I don’t care. All I know is this:

  • When I took my shirt off, I handed it to my delegate (in this case, using the bin in my closet)
  • In the morning, when I needed a shirt, it was provided by the delegate

I don’t need to know my shirt delegate’s name, or really even anything about him or her. Heck, I don’t even need to know if my shirt delegate is human. All I care about as far as he or she is concerned is the shirt situation.

Delegates, you see, are a lot like this. A given delegate is there to respond to its master’s whims. Consider a table view delegate. It knows someone tapped on a cell, so it calls its delegate’s ‑tableView:didSelectRowAtIndexPath: method—and that’s the extent of what it knows about what the delegate is going to do with that information.

Our shirt delegate, then, might have two methods:

@protocol ShirtDelegate

– (void)personDidRemoveShirt:(Shirt *)aShirt;
– (Shirt *)shirtForToday;

@end

Only the important information is included in each.

Consider the application delegate. The application starts up, and let’s say it has a push notification the user tapped to invoke it, so it has something in the launchOptions dictionary. The application reads the value passed in to UIApplicationMain() in the main.m file to find out the kind of delegate it needs, creates one, and hands over the launchOptions dictionary to it. In this case the application does know a little bit about the delegate—enough to create one, anyway. But it doesn’t need to know anything about the launchOptions dictionary or anything about what happens in ‑application:didFinishLaunchingWithOptions:.

The purpose of delegation is simple: to decouple your code. The more knowledge a class has about other classes, the more coupling there is in your code. Like a spiderweb sticking to everything, this coupling makes it harder to change individual portions of your app, harder to migrate your apps to new platforms, and is just generally messy. Bringing it back to our original analogy: the fantastically rich are too busy worried about their fleet of supercars, their investment portfolio, and the design of the foyer in their third home; they don’t care about what brand of detergent the shirt delegate uses.