Autolayout basics

Leave a comment

To align one button to another in storyboard do this. Drag out your second button and center it by control dragging out and selecting ‘Center Horizontal’.

Screen Shot 2015-11-25 at 12.04.18 PM


Then, to make your second button trail the first, control drag second to first and select ‘Vertical Spacing’.

Screen Shot 2015-11-25 at 12.03.29 PM

You can then double click on the constraint to set whatever spacing you like.

Screen Shot 2015-11-25 at 12.13.43 PM

To test your layout select ‘Update Frames’ from the triangle located near the bottom of the storyboard frame.


Screen Shot 2015-11-25 at 12.04.46 PM

And to see all your constraints,  select this well hidden slider, Hide Document Outline, near the bottom left of the storyboard screen.

Screen Shot 2015-11-25 at 12.15.03 PM

And you should see a frame slide out showing you all the constraints for your current project.

Screen Shot 2015-11-25 at 12.16.20 PM



How to define protocol Objective-C

Leave a comment

Define your protocol

@protocol RemotePlayer <NSObject>
- (void)play:(void (^)(NSError *error))callback;
- (void)pause:(void (^)(NSError *error))callback;

Define your implementation

@interface RemotePlayerImplementation : NSObject <RemotePlayer>

Use your protocol

id<RemotePlayer> player = [RemotePlayerImplementation new];

How to make generic iOS library

Leave a comment

To add files to your generic iOS library make sure the header file you want to include is in the target header section. Like this.


Note – if you click on the headers section and you don’t see the class you want to add, try dragging it from the left project area into the header section. Thank you Johan.



Screen Shot 2015-11-24 at 7.25.35 AM

Screen Shot 2015-11-24 at 7.25.55 AM

iOS test classes not running

Leave a comment

If you’ve added unit tests to a new project and for some reason they aren’t running… try this.

Double click your blue project icon

Screen Shot 2015-11-13 at 11.18.26 AM

Click the Test Target, Build Phases, and expand Compile Sources

Screen Shot 2015-11-13 at 11.18.43 AM

Screen Shot 2015-11-13 at 11.23.55 AM

Click the ‘+’ sign then ‘Add other’ at the bottom, navigate to your files, and try adding them manually. May fix your problem.

XP Days at Spotify


Screen Shot 2015-10-30 at 1.08.46 PMToday I had the pleasure of hosting the second day of a two day XP style workshop with some incredible developers at Spotify. Here’s what we did.

Build something fast!

We kick things off by asking the class to build a Reverse Polish Notation (RPN) style calculator. In 10 minutes.

We do this partially by design – to create a little stress. But it’s also an ice breaker. Just to verify everyone’s machine is up and running. As well as gauge the experience level of the class.

We then have a discussion about what some of the challenges are when building software. As well as what quality means, and how we can shoot for that in our software.

The birth of XP

This then segues into the birth of XP. Here I share Kent and Ward’s original vision of what XP was. Talk a little about the C3 project. And basically explain the XP attitudes behind if certain things are hard, we are going to continuously do them, all the time. Testing, integration, pairing, design, etc.

I also draw the cost of change curve and share how Kent wanted a way to develop software, such that the cost didn’t increase exponentially over time.

Screen Shot 2015-10-30 at 1.08.55 PM

Elephant Carpaccio

Partly because smaller stories are a good idea, and partly because it helps them with the project they do on day two, we then do an Elephant Carpaccio story slicing exercise.

This is great because it reminds people about what makes stories valuable in the first place, while also giving advice on how to slice. Basics, but really good stuff for people who may not have read or had any story training.

TDD together

This is where we formally introduce TDD, and revisit the RPN calculator we built at the beginning of the course.

As a class, I start with one other person, showing them the mechanics behind writing the test first, making it pass, and then … sometimes refactoring. Sometimes I don’t refactor, just to let the duplication build up and save for conversation later.

But we do this as a group, and it gives students a nice intro on a codebase and a problem they already know.


Something that’s surprised me as a middle aged programmer (cough) is how many people still haven’t read Martin Fowlers seminal book on refactoring. I have a lot of fun with this.

Refactoring, even in really tight circles of programming, is still a very misunderstood term. Usually it just means rewriting code. But people don’t appreciate always that when you are refactoring you aren’t adding any new value. You are only improving the existing design.

So I really hit home that the reason why that word appears in a menu at the top of your favorite ID is because of this book. And then I ask how people refactor without unit tests.

It’s a trap of course. Because you can’t. But a lot of people still do. So we talk about that.

So that’s day one. And during the day we also sprinkle in discussions about YAGNI, production readiness, and other XPisms and attitudes.

Code me a game

Day two is all about putting TDD, unit testing, refactoring, continuous integration, collective code ownership, and pairing all into practice. In teams of four, the class then goes about building a text based adventure game.

Screen Shot 2015-10-30 at 1.12.24 PM

Text based games are great for learning TDD. They are fun, most people understand how they work, and they don’t contain a lot of hairiness. But they contain enough hairiness to give a taste of what applying TDD in the real world is like (like how do you handle all those input output streams?).

We have a few rules for the text based game we are going to build.

  1. No production code without a failing unit test.
  2. No code not written in pairs.
  3. Refactoring happens continuously while the code is being developed.
  4. Check in early and often.

Screen Shot 2015-10-30 at 1.14.34 PM

It’s really fun seeing how teams of x4 tackle handling a new code base. We also have the challenge that many people come from different parts of the world. So everyone has their own keyboard which can make pairing tricky.

But people overcome. We have lots of discussion about how to test, how to design, and how to tackle all the hairiness that seems to come with coding, even on a simple text based game.

We usually do x3 one hour iterations. With a demo, code review, and discussion at the end of each.

We also track number of commit, number of stories, and code coverage.

After three to four hours people are pretty pumped and exhausted. We then sit back and reflect on what we’ve learned.

It’s really interesting watching people try TDD for the first time. On the surface, when you see other people do it, it looks really easy. But it’s not. At least at first. It’s hard. It goes against everything not only everything you’ve been taught in school. It also not the natural state for people who are just used to hacking.

But once people get it, you can see a light go one. They design their code differently. They find they need less code. And it takes a lot of the guesswork away. They only end up creating what they need. And for many that’s a revelation.

Of course TDD is only one leg of the XP stool. And all the other practices also come into play – particularly pairing. People often ask how do you keep the discipline up. You play a big part of that I say. But your pair can help you too.

Insights, Actions, and Histories

We wrap up the day with Insights, Actions, and Mysteries. Here we ask people what they learned, things they want to do, and things we still wonder about.

Screen Shot 2015-10-30 at 5.09.06 PM

Screen Shot 2015-10-30 at 5.09.15 PM

Screen Shot 2015-10-30 at 5.09.22 PM
Big insights today were the awesomeness of pairing (you can learn a lot working with someone else). Actions were YAGNI – try hard not to over engineer. And mysteries were things like how fast to move when doing TDD vs going really slow and gearing down to really really small tests.

Overall it was a great day. I always learn as much if not more than the attendees. And this was a great group to work with. See you out there!

Screen Shot 2015-10-30 at 1.13.53 PM

iOS Objective-C trick to exposing private properties and methods in your tests

Leave a comment

If you want access to properites and methods in your Objectice-C tests try this.

#import "IAPClientImplementationTestBase.h"

@interface IAPClientImplementation()
@property (nonatomic, readwrite) NSUInteger currentRequestID;

@interface IAPClientImplementationTest : IAPClientImplementationTestBase

@implementation IAPClientImplementationTest

- (void)testRequestIdIncrements {
    XCTAssertEqual(0, [self.client currentRequestID]);


Redefine the interface in your test class and re-expose the properties and methods there.

iOS Objective-C trick to expose private methods and properties

Leave a comment

Say you have a class with some private properties that you would rather not expose at the header level, but you would sure like to use in a test.

One trick some colleagues showed me is you can redefine the interface in your test, and expose whatever properties and methods you want access to there.

Here I have a class called IAPClientImplementation and I want to expose the currentRequstId property. I can do that like this.

#import "IAPClientImplementationTestBase.h"

@interface IAPClientImplementation()
@property (nonatomic, readwrite) NSUInteger currentRequestID;

@interface IAPClientImplementationTest : IAPClientImplementationTestBase

@implementation IAPClientImplementationTest

- (void)testRequestIdIncrements {
    XCTAssertEqual(0, [self.client currentRequestID]);


Older Entries


Get every new post delivered to your Inbox.

Join 336 other followers

%d bloggers like this: