On iterative learning

Earlier this week, I had a chance to talk out my approach to learning new things in the context of Cocoa development.

I’ve always found that I learn best when I get to use it in anger, but when it comes to something as big and sprawling as the Cocoa framework, there’s a lot of stuff to learn.

Given that I do the vast majority of my development solo, I’ve found that the best way to approach this is to break the framework down into manageable chunks, write a little project based around that chunk, and then ship it.

I wrote my first app, HoneyJar, as a first introduction to Objective-C and Xcode. IDEs like Xcode are generally pretty similar—at their core, they’re text editors with some special features—but Objective-C looked like no other programming language I’d ever seen before.

- (void)doYouKnowTheMuffinMan:(TheMuffinMan)theMuffinMan;

(I saw this somewhere on Twitter and I wish I could remember who to credit for it!)

I also made the app iPhone-only, as this made for a much less complex platform as far as things like filesystems, window sizes, and interaction go.

I also took the opportunity to explore CocoaPods, adding some libraries to handle some view and viewcontroller tasks—I had my hands full trying to figure out the language and the platform. I also integrated HockeyApp into the beta version I was working on, to get feedback from friends.

Once I was relatively happy with the app, I revved it to 1.0 and submitted it to the App Store—again, something I’d never done before. HoneyJar was never expected to be some kind of successful product, but a few people have downloaded it, and I know it’s been useful to me on occasion.

When Apple announced Swift, its new programming language, I got pretty excited. Swift certainly looked a lot more like the programming languages I was familiar with, and there was something really neat about “growing up” with a new language.

So, I started work on my next app, Per. Per was all about digging into Swift (which has changed dramatically since the app was written)—there are no external libraries used anywhere in the app.

I also used it as an opportunity to play with some animations when presenting and dismissing view controllers:

This meant that I got to look into closures as well, again as a small chunk of their applicability.

Last week I wrote about writing for GitLab as a means of teaching myself more about their continuous integration features.

I’m now interested in working with fastlane tools, so I’m working on an app as a counterpart to a new article I’ll be writing for GitLab. The app is relatively simple: it consumes GitLab’s API to present some kind of a dashboard for project milestones that the user is involved in.

Because I want to focus on learning fastlane, I don’t want to worry too much about handling API requests and responses, so I’m using a great library called Alamofire, and I’m making this a tvOS app.

Why tvOS?

Well, firstly, it’s a new platform that I get to play with. That’s pretty interesting in and of itself, because while it brings a standardized screen size, it also includes the Siri remote as the sole means of interaction.

But, additionally, an Apple TV assumes a persistent connection to the internet, which means one less thing to worry about: testing for a lack of connectivity (or worse, spotty connectivity).

This way, I can learn about a new platform and a new toolchain without worrying about other pitfalls and perils.

So that’s how I like to learn: small, neatly defined chunks, where I can focus on the thing I want to find out about, and ship something that showcases what I’ve learned. I’d love to know what works best for you!