Stop Writing For Loops

Most of the time, when we use a for loop, it's to iterate over some collection. Typically an array. We used to write things like this:

for (NSInteger i = 0; i < [array count]; i++) {
    id obj = array[i];
    // do something with obj
}

Then we came up with the foreach loop.

for (id obj in array) {
    // do something with obj
}

That worked well unless you wanted to know the index of the object that you're using. We've all written code like this:

NSInteger i = 0;
for (id obj in array) {
    // do something with obj
    i++;
}

This one is particularly insidious since it creates a new local variable i outside of the lexical scope of the loop. Gross!

Please, stop using all of these. Instead, use enumerateObjectsUsingBlock:

[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    //do something with obj at idx
}];

This abstracts away how the computer is doing something and let's you focus solely on what it is you're trying to accomplish. You get the index of the iteration and can stop the enumeration at any time by setting *stop = YES.

We used to have to use arrays because Objective-C didn't have blocks. We've left the dark ages and can now focus on what we're trying to accomplish instead of being mired in the minutia of how the computer works.

EDIT: Several readers have pointed out the performance gains when using the different methods. Good point, and definitely worth a read.

WWDC 2013 Schedule

I'm going to be at WWDC 2013 next week. I land Saturday and leave the following Saturday. Normally I'd say if you're in the area, we should get together for a beer. However, my week is super busy this year.

On Monday, the tenth, I'll be speaking about ReactiveCocoa at the Spotify WWDC Developer Meetup before heading to the Crashlytics party. Tuesday, I'll be juggling the ReactiveCocoa meeting at the Square offices before going to the App Camp for Girls Happy Hour. Finally, on Wednesday, I'll be speaking at Pivotal Labs on a panel discussing reactions to the keynote and the future of iOS.

If you're attending any of these events, please say hi. Nerd parties are always awkward, but if we're awkward together, it'll work itself out.

Your First iOS App

I finished writing my book. The first chapter is available online, for free.

If you like it, you should go buy it. Better yet, buy it, and then tell all your friends about it.

Sorry to be all pitchy, but I worked really hard on this and it'd be super-awesome if it made a big splash. And sorry for apologising – I'm Canadian, after all.

"Open Your Objective-C" Day

Recently, CoffeeScript bumpbed Objective-C off the top-ten list of languages used on GitHub. What a shame. Let's use this as an opportunity to show the rest of the developer community that Objective-C developers care about open source, too.

On Saturday, June 29th, open an Objective-C repository or fork an existing one. Maybe publish some snippets to GitHub gists. Finished or in-progress, doesn't matter. All that matters is releasing code and having fun.

Check out the EventBrite page for a reminder.

Your First iOS App

So I finished my awesome crowdfunded, stick-it-to-the-man, self-published book. Whew! 208 pages of pure iOS goodness.

I'm giving away the first chapter for free, licensed under Creative Commons. You can also buy my book directly. It'll be up on Amazon eventually.

Please help spread the word – the more the merrier!

Don't Use UISwipeGestureRecognizer

Your job as an app developer is to craft a meaningful and delightful user experience. One of the best ways to accomplish this goal is to provide feedback as a user performs some gesture.

When using gesture recognizers, it is almost always far, far better to use UIPanGestureRecognizer than UISwipeGestureRecognizer because it provides callbacks as the gesture takes place instead of after it is said and done.

UISwipeGestureRecognizer doesn't provide developers with an opportunity to provide immediate, in-progress feedback. Compared to UIPanGestureRecognizer, it robs you of an opportunity to make your app juicy.

Release Notes Podcast

Go check out Release Notes, a new podcast for iOS from a pair of pretty smart dudes.

Yeah, I know, another podcast about iOS, but this one is diffrent. It doesn't talk about design or coding, but rather the business of iOS. Definitely worth checking out.

Their inaugural episode is about conferences and it discusses the value of conferences, how to choose one to attend, and how to get the most out of it.

Starters Guide to iOS Design

I just read an interesting and thorough guide to iOS Design – it's well worth checking out. It's a very concise distillation of Apple's Human Interface Guidelines with fantastic graphics illustrating the different points it makes.

Definitely something to keep in your bookmarks folder as a quick reference.

360iDev

I'll be giving a talk in September at 360iDev about how to effectively use open source software.

Use of open source code is quite common, but the tools don't support or encourage developers to use it – I'm looking at you, Xcode. I'm going to be presenting some different techniques to avoid the pitfalls of using open source software when developing OS X and iOS apps.

If you're attending 360iDev, I'd love to meet you. If you're not attending, I'd encourage you to do so. It's going to be a lot of fun.

Developers Should Learn Photography

Photography is the love-child of art and technology: you need a tasteful eye and skilled hands to get a great shot. Dipping your toes into photography, even without becoming a great photographer, will make you a way better developer. Let's talk about why – I'll share some of my personal experiences with photography and how photography helped me improve as a software developer, then I'll help you out with getting started.

Photography and development have a lot in common. So much so that I find it odd that more developers don't dabble in digital darkrooms. How are photography and programming alike? Good question.

Programming is an inherently creative process – you literally create. As a developer, you take abstract ideas that exist only in your mind and turn them into the living machinery of working software. Photography is also creative, but unlike other creative processes like painting or drawing or writing, it has a very strict technological component.

Like a computer, light behaves in specific, predictable patterns. Photographs are short exposures of light – how you control light defines how a photograph will look. Nothing says "software developer" quite like fiddling with the kinds of esoteric controls found on the back of complicated-looking cameras. Photography fits software developers perfectly – it's creative and involves science and technology – but what value can developers get from pursuing this hobby?

One of the biggest revelations I had when I first learned how to take photos was that what I see and what the camera sees are not necessarily similar at all. A camera's perspective – by which I mean the way it sees the world, not just its focal length – is very different from a human's. While we use our eyes and our brains to interpret a scene, cameras use specific lenses set with specific settings to expose their light sensors. This disparity in perspectives is a lot like how users and developers see the world very differently; it should remind you that not everyone sees the world like you do.

Not only do perspectives other than your own exist, but in fact most people don't see things from your point of view. Being conscious of this fact has really helped me while writing software because it is a reminder that I need to put myself in users' shoes – just like taking a photo, I need to consider things from another perspective. I need to have empathy. How will a user feel about my interface? How will another developer interpret my method name? These are important questions to ask while programming.

Another aspect of learning photography is reflection. Improving your photography, like any creative endeavour, requires you to reflect on your work. In order to improve as a photographer, you need to stand back and objectively evaluate your work. This takes a lot of effort. Taking a digital photo involves having a vision in your mind and trying to create that vision within the camera. You take the photo and reflect on how it realizes, or fails to realize, your original vision. Then you try again. Maybe the exposures you get aren't what you originally intended. Maybe you change your mind about what your goal is. In any case, reflection is a critical component.

When I first started taking photos, I realized that seeing the results of my photography differ from my expectations is no different from seeing a program take an unexpected path of execution. I now see improving as a photographer as just a macro-level run/debug cycle.

Both photography and programming demand a technological understanding of the tools, but to be great at either, you need empathy and reflection. After developing these two habits, I've applied those skills to my code. I noticed that my coding skills had deficiencies. Long-standing ones. Then I fixed them.

These two values exemplify the value I've gotten from photography. In my experience, developers tend to suffer from a somewhat limited perspective – they don't think in terms of their users' goals and their products reflect this.

Studying the principles of photography has also enabled me to learn about composition, colour, and other components of design, even though I lack the ability to draw. After all, a good photograph is designed to elicit some response from the viewer; photography is steeped in design. This competency in design has helped me build more usable applications, which in turn helps my career as a software creator.

I've also found that when a puzzling programming problem has me beat and frustrated, I like to go outside and take photos. Programming doesn't have to be a developer's only creative outlet – I use photography to unwind and relax. Switching gears and getting my creative juices flowing is often exactly what I need to solve a tricky problem.

Alright. Say you're convinced that photography is something that will improve your development skills. You've seen how learning to take photos boosted my programming skills and you want to get in on this horizon-expanding and perspective-broadening action. So what's next?

Getting started is not hard at all. In fact, you can probably already start by taking shots with your smartphone – most smartphones have pretty capable cameras in them. So start shooting!

Download Instagram, Google the "Rule of Thirds", take photos, and reflect on your own shots. Explore Flickr or 500px and contemplate on why you like the photos you do. Is the composition technically compelling? Does the subject matter evoke an emotional reaction? Do you think the photographer used natural light or a flash?

Ask your friends what they think. If any of them have experience with photography, let them know that you want their feedback – tell them not to hold back. It's not easy to hear critiques like this, trust me, but it's a great way to learn. In fact, being able to take critiques is a great skill in general – you'll learn to appreciate it.

Using Instagram is a great way to get started because the app places significant limits on your technical abilities as a photographer, and those limits will inspire your creativity. We all know that constraints breed creativity You'll discover the bounds of those limits really quickly, like when learning a new programming language. And just like when learning a new language, you'll come up with workarounds to circumvent those limitations.

You don't need to spend thousands of dollars on gear to get good at taking photos. You only need a basic camera, like the one in your smartphone, and some patience.

The biggest reason for developers to know to take and appreciate photographs is to grow, to become more well-rounded people. Our industry relies on growth for the rapid pace of progress it's seen in its short existence. If you stop growing, you'll be left behind.