One Stilt At A Time 

10 May 2013

Jon Reid writes in a comment:

“Either you’re coding to get a new test to pass, or you’re refactoring. But don’t do both at the same time. We’re basically walking on stilts: Lift one, or the other, but not both. By keeping one foot grounded, so to speak, we reduce the risk of falling over.”

I wrote the other day that I have previously used “CDD” - “commit driven development” or “change driven development” and I often found that I had feature or bug fix code in with refactoring code to support it. And when git came along I could use GitX very easily to separate that code in the commits. So I’m yet to change my style to be able to stop, refactor as required, and then continue with the feature code. And it seems that that is only really feasible when you’re actually coding just one test at a time, as in this kata.

I’m not there yet, but I’ll press on.

A Giant Notice Board

08 May 2013

My grandfather, who turns 90 this year, just called me to ask how to “get a blog on his computer”. Some friends of his are travelling and have set up a blog, and he wanted to see it. I guess he had the idea that you had to set something up on the computer, and that it would be complicated, I guess because that’s true of a lot of things on a computer.

I described wordpress.com as a giant notice board, and the name of the blog (the “blogname” from “blogname.wordpress.com”) as the part of the board with the photos from your friends, and this seemed to make sense. When I said that you just need to type in the address in your web browser (the colourful circle down the bottom that I put there for him) he realised that he could do that no problem.

I then mentioned bookmarks, which may or may not be too much extra to bother with when computers are so foreign to your way of thinking. I suppose if he can see the photos from his friends, then I can call this a win for the web.

The only point to this story, if there is one, is me remembering that a lot of time and learning has gone into what I know about this digital electronic world, and not everyone has the same level of knowledge. It’s useful to remember this when creating parts of this world!

Is TDD worth it? 

06 May 2013

Phil Nash, commenting on Marco Arment about TDD:

It’s a shame that he appears to have just dismissed what is probably the best tool we have come up with to date for avoiding this ever happening in the first place.

I think that those of us who’ve written a lot of software before practices like TDD/BDD became well known have trouble changing mindset to work this way. I personally had developed something like CDD, “commit driven development”, over the years, where I carefully check each commit as I go, ensuring each change is heading in the right direction. Perhaps this came about from so often working on large pre-existing codebases without any tests.

The basic principle of my home grown approach is similar, in that the focus is on small incremental steps of good quality. But having an automated test suite is crucial, because the test code pushes against the production code, and that tension provides much greater confidence that you actually know what the production code is doing. And this is where writing tests first comes in, because to have confidence in your test code, it has to first fail, so that you can see it change from failing to passing when the production code is in place. But it can be hard to have to keep stopping and working out not only how best to test a particular bit of code, but then also how best to structure and manage tests overall, especially when the code starts appearing in your head and you want to get it down while it’s there.

I’m completely sold on the benefits both of having a test suite, and of writing the tests (or specs) first, and I’m now in the stage where I sometimes fall back under pressure to just writing some code on the fly, and then perhaps adding tests afterwards, and sometimes not. It took effort to start making the change, and now that I’ve started I know I’ll slowly tip the balance to having most code written test first.

Because it really is so much nicer to have clear specs that actually demonstrate how the production code behaves, than to not.

A Good Overview of Bitcoin and Currency 

23 April 2013

I am not an expert on currency, but I understand a lot more after reading this.

So How Is Poverty, Anyway? 

14 February 2013

Some interesting stats on the developing world, with respect to poverty and death. There is some good news.

Clay Shirky on Love, Internet Style 

12 February 2013

This is a really great look at community, and how you can tell if a community will last.

“They didn’t care that they’d seen it work in practise, because they already knew it couldn’t work in theory.”

Route requests based on the HTTP Accept header in Django

15 January 2013

I recently had need to route HTTP requests by the Accept header, in order to have versioned calls for an API. I found a piece of Django middleware that was similar to what I thought I’d need, and I modified it to support Accept header routing. Grab the full http header routing Django middleware and use it to your advantage.

Air Play is not Air Work

18 October 2012

I just spent about twenty minutes puzzling over and reducing a crash in some iOS code running in the simulator until I got back to completely unmodified older code that I knew worked fine. The code was crashing on trying to play an audio file, a file that existed and loaded just fine, but caused EXC_BAD_ACCESS when attempting to play. Something about trying code that I knew worked fine triggered me to think a bit differently, and realise that the thing I’m doing different today is playing music from my computer over AirPlay to a new sound system.

It seems the iOS Simulator crashes when it hits audio code if your system audio is pointed at an AirPlay output. Just making a note of this in case it’s useful for anyone else (or me later!).

Brilliantly Bad Networking

27 September 2012

While exploring some of the new parts of iOS 6 I came across the Developer section in Settings, which features a brilliant new Network Link Conditioner. This feature allows you to control the incoming and outgoing network bandwidth, packet loss and connection delay, as well as a specific DNS delay. So, right from the device you can choose one of the predefined profiles, or create your own, and simulate various network conditions while testing your app.

What this means is that it just got a lot easier for everyone to test how their app behaves in bad network conditions, even when you’re working in a place with fast Wifi and cellular coverage.

One of the really nice features of iOS software compared to desktop software in general has been that iOS software usually handles poor networks much more smoothly, which is really noticeable if you ever try using a laptop on a train while connected via a cellular network. So I hope that this new feature of iOS 6 means that network resilience becomes even more common in iOS apps.

Paying the ARC __bridge toll

31 July 2012

After years spent writing Objective-C code and getting completely comfortable with balancing every alloc, retain and copy with a release or autorelease, ARC messed with my brain a bit when I first encountered it. At first I ignored it, because it’s optional, but when I discovered that in general it produces faster code, I started reading up on, and then using ARC.

After a while I’ve gotten comfortable with no longer thinking about object ownership in Objective-C when ARC is enabled. Except of course for occasions where I need to use (weak) in property declarations, mostly for delegates.

But one thing that hadn’t crossed my path until recently was toll free bridging from Core Foundation to Objective-C, and at first it was also quite confusing. Especially since ARC means that you really don’t think about this anymore for Objective-C, having to think again for CF is a bit of a jolt.

The Transitioning to ARC Release Notes provide this example of equivalent code, first non ARC, then ARC:

- (void)logFirstNameOfPerson:(ABRecordRef)person
{
	NSString *name = (NSString *)ABRecordCopyValue(person, kABPersonFirstNameProperty);
	NSLog(@"Person's first name: %@", name);
	[name release];
}

- (void)logFirstNameOfPerson:(ABRecordRef)person
{
	NSString *name = (NSString *)CFBridgingRelease(ABRecordCopyValue(person, kABPersonFirstNameProperty));
	NSLog(@"Person's first name: %@", name);
}

This is helpful to see one example of how to start using ARC, but when migrating code the compiler actually prompts you to fill in with __bridge style cast specifiers, and that seems to be the style that’s used a lot. So I had to understand how these differed, and I’ve come up with two more equivalent bits of ARC code that helped me understand:

- (void)logFirstNameOfPerson:(ABRecordRef)person
{
	NSString *name = (__bridge_transfer NSString *)ABRecordCopyValue(person, kABPersonFirstNameProperty);
	NSLog(@"Person's first name: %@", name);
}

- (void)logFirstNameOfPerson:(ABRecordRef)person
{
	CFStringRef nameRef = ABRecordCopyValue(person, kABPersonFirstNameProperty);
	NSString *name = (__bridge NSString *)nameRef;
	NSLog(@"Person's first name: %@", name);
	CFRelease(nameRef); // balance the *Copy*()
}

There are some things to consider:

  • You can’t use casts unless there is an Objective-C type to cast to, so sometimes you simply have to use CFRelease() anyway.
  • You can’t pass the Objective-C object out of the current scope unless you transfer ownership to ARC, using either __bridge_transfer or CFBridgingRelease().

So, in cases like this one, you actually have to choose between explicitly balancing the *Copy*() call with a *Release(), or handing over to ARC, using one of two styles. Which of these is preferable? I have no idea. I guess some kind of community consensus will develop over time, if it hasn’t already, and we’ll all just do it that way.