Unfamiliar territory

People who've seen me play music more than once will probably have noticed more than a slight sense of a pattern - give me a fiddle (or if you're really unlucky then I'll bring my own), and I play English folk music. Give me a guitar and I'll play rock and roll. That's just what my fingers are used to - to me the guitar has six strings of rockabilly and the fiddle has four strings of constant billy. No, I didn't write this piece just to get that pun in, though I am glad that I did. I can now go to my grave a happy man, safe in the knowledge that I have compared fishes flying over mountains with blues-derived country music. Classy.

Well, I think it's time to change things around a bit. I want to leave my violin all shook up, and my guitar all in a garden green. It probably sounds quite easy, given that I already know all the tunes, and just want to play them on different instruments, but really it isn't. There are two important issues which make it hard for me to just swap over.

The first is that in many cases I don't actually know the tune at all, I just use muscle memory to get my digits moving in the right places for music to occur. That's particularly true in the case of rock n roll music, where there really aren't tunes at all. There are just 'licks', basic one or two bar figures which are strung together into a twelve bar part. But it's also true in folk music which has a similarly hypnotic repetition but with longer figures. So taking a tune to a new instrument means discovering what it is I'm actually playing on the first instrument, then trying to reproduce that on the second.

The second issue is that just playing the notes from one instrument on another isn't necessarily the correct thing to do, nor even particularly easy. For a start guitar strings are tuned to fourths (mainly) while violin strings are to fifths, and as the bridges are different shapes the instruments invite playing a different number of strings simultaneously. So what I need to do is not even to work out how to play the same tune on the other instrument, but what that instrument's version of the tune should be and how to play that.

I expect that the outcome of this little experiment will be mainly a cacophony, but with some increased understanding of what the instruments can do and how to play them. If I focus on cacophony then I'll probably get quick results, though.

Next Swindon CocoaHeads meeting

At one time a quiet market town with no greater claim than to break up the journey between Oxford and Bristol, Swindon is now a bustling hub of Mac and iPhone development activity. The coming meeting of CocoaHeads, at the Glue Pot pub near the train station on Monday October 5th, is a focus of the thriving industry.

I really believe that this coming meeting will be a great one for those of you who've never been to a CocoaHeads meeting before. We will be having a roundtable discussion on indie software development and running your own micro-ISV. Whether you are a seasoned indie or just contemplating making the jump and what to find out what's what, come along to the meeting. Share your anecdotes or questions with a group of like-minded developers and discover how one person can design, develop and market their applications.

You don't need to register beforehand and there's no door charge, just turn up and talk Cocoa. If you do want to discuss anything with other Swindon CocoaHeads, please subscribe to the mailing list.

Unit testing Core Data-driven apps

Needless to say, I'm standing on the shoulders of giants here. Chris Hanson has written a great post on setting up the Core Data "stack" inside unit tests, Bill Bumgarner has written about their experiences unit-testing Core Data itself and PlayTank have an article about introspecting the object tree in a managed object model. I'm not going to rehash any of that, though I will touch on bits and pieces.

In this post, I'm going to look at one of the patterns I've employed to create testable code in a Core Data application. I'm pretty sure that none of these patterns I'll be discussing is novel, however this series has the usual dual-purpose intention of maybe helping out other developers hoping to improve the coverage of the unit tests in their Core Data apps, and certainly helping me out later when I've forgotten what I did and why ;-).

Pattern 1: remove the Core Data dependence. Taking the usual example of a Human Resources application, the code which determines the highest salary in any department cares about employees and their salaries. It does not care about NSManagedObject instances and their values for keys. So stop referring to them! Assuming the following initial, hypothetical code:

- (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
	NSInteger highestSalary = -1;
	for (NSManagedObject *employee in employees) {
		NSInteger thisSalary = [[employee valueForKey: @"salary"] integerValue];
		if (thisSalary > highestSalary) highestSalary = thisSalary;
	}
	//note that if the set's empty, I'll return -1
	return highestSalary;
}

This is how this pattern works:

1. Create NSManagedObject subclasses for the entities.
   

   @interface GLEmployee : NSManagedObject
   {}
   @property (nonatomic, retain) NSString *name;
   @property (nonatomic, retain) NSNumber *salary;
   @property (nonatomic, retain) GLDepartment *department;
   @end
   

   
   This step allows us to see that employees are objects (well, they are in many companies anyway) with a set of attributes. Additionally it allows us to use the compile-time checking for properties with the dot syntax, which isn't available in KVC where we can use any old nonsense as they key name. So go ahead and do that!
   

   - (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
   	NSInteger highestSalary = -1;
   	for (GLEmployee *employee in employees) {
   		NSInteger thisSalary = [employee.salary integerValue];
   		if (thisSalary > highestSalary) highestSalary = thisSalary;
   	}
   	//note that if the set's empty, I'll return -1
   	return highestSalary;
   }
   

   
   


2. Abstract out the interface to a protocol.
   

   @protocol GLEmployeeInterface <NSObject>
   @property (nonatomic, retain) NSNumber *salary;
   @end
   

   
   Note that I've only added the salary to the protocol definition, as that's the only property used by the code under test and the principle of YAGNI tells us not to add the other properties (yet). The protocol extends the NSObject protocol as a safety measure; lots of code expects objects which are subclasses of NSObject or adopt the protocol. And the corresponding change to the class definition:
   

   @interface GLEmployee : NSManagedObject <GLEmployeeInterface>
   {}
   ...
   @end
   

   
   Now our code can depend on that interface instead of a particular class:
   

   - (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
   	NSInteger highestSalary = -1;
   	for (id <GLEmployeeInterface> employee in employees) {
   		NSInteger thisSalary = [employee.salary integerValue];
   		if (thisSalary > highestSalary) highestSalary = thisSalary;
   	}
   	//note that if the set's empty, I'll return -1
   	return highestSalary;
   }
   

   
   


3. Create a non-Core Data "mock" employee
   Again, YAGNI tells us not to add anything which isn't going to be used.
   

   @interface GLMockEmployee : NSObject <GLEmployeeInterface>
   {
   	NSNumber *salary;
   }
   @property (nonatomic, retain) NSNumber *salary;
   @end
   
   @implementation MockEmployee
   @synthesize salary;
   @end
   

   
   Note that because I refactored the code under test to handle classes which conform to the GLEmployeeInterface protocol rather than any particular class, this mock employee object is just as good as the Core Data entity as far as that method is concerned, so you can write tests using that mock class without needing to rely on a Core Data stack in the test driver. You've also separated the logic ("I want to know what the highest salary is") from the implementation of the model (Core Data).
   

OK, so now that you've written a bunch of tests to exercise that logic, it's time to safely refactor that for(in) loop to an exciting block implementation :-).

CocoaHeads Swindon is this Monday!

The town of Swindon in the Kingsbridge hundred, Wiltshire is famous for two things. The first is the Wilts and Berks Canal, linking the Kennet and Avon at Trowbridge with the Thames at Abingdon. Authorised by act of parliament in 1775, the canal first passed through the town in 1804 and allowed an explosion in both the industrial and residential capacity of the hitherto quiet market cheaping.

The second is, of course, the local CocoaHeads chapter. Founded by act of Scotty in 2007, Swindon CocoaHeads quickly brought about a revolution in the teaching and discussion of Mac and iPhone development in the South-West, its influence being felt as far away as Swansea to the West and London to the East. Unlike the W&B canal, Swindon CocoaHeads is still thriving to this day. On Monday, 7th September at 20:00 there will be another of the chapter's monthly meetings, in the Glue Pot pub near the train station. Here, Pieter Omvlee will be leading a talk on ImageKit, and the usual combination of beer and Cocoa chat will also be on show. As always, the CocoaHeads website contains the details.