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.

Posted in music | 1 Comment

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.

Posted in Business, cocoa, cocoaheads, iPhone | Leave a comment

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 :-).

Posted in cocoa, CoreData, objc, unittest | 2 Comments

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.

Posted in cocoa, iPhone, macdevnet, Talk | Leave a comment

Indie app milestones part one

In the precious and scarce spare time I have around my regular contracting endeavours, I’ve been working on my first indie app. It reached an important stage in development today; the first time where I could show somebody who doesn’t know what I’m up to the UI and they instinctively knew what the app was for. That’s not to say that the app is all shiny and delicious; it’s entirely fabricated from standard controls. Standard controls I (personally) don’t mind so much. However the GUI will need quite a bit more work before the app is at its most intuitive and before I post any teaser screenshots. Still, let’s see how I got here.

The app is very much a “scratching my own itch” endeavour. I tooled around with a few ideas for apps while sat in a coffee shop, but one of them jumped out as something I’d use frequently. If I’ll use it, then hopefully somebody else will!

So I know what this app is, but what does it do? Something I’d bumped into before in software engineering was the concept of a User Story: a testable, brief description of something which will add value to the app. I broke out the index cards and wrote a single sentence on each, describing something the user will be able to do once the user story is added to the app. I’ve got no idea whether I have been complete, exhaustive or accurate in defining these user stories. If I need to change, add or remove any user stories I can easily do that when I decide that it’s necessary. I don’t need to know now a complete roadmap of the application for the next five years.

As an aside, people working on larger teams than my one-man affair may need to estimate how much effort will be needed on their projects and track progress against their estimates. User stories are great for this, because each is small enough to make real progress on in short time, each represents a discrete and (preferably) independent useful addition to the app and so the app is ready to ship any time an integer number of these user stories is complete on a branch. All of this means that it shouldn’t be too hard to get the estimate for a user story roughly correct (unlike big up-front planning, which I don’t think I’ve ever seen succeed), that previous complete user stories can help improve estimates on future stories and that even an error of +/- a few stories means you’ve got something of value to give to the customer.

So, back with me, and I’ve written down an important number of user stories; the number I thought of before I gave up :-). If there are any more they obviously don’t jump out at me as a potential user, so I should find them when other people start looking at the app or as I continue using/testing the thing. I eventually came up with 17 user stories, of which 3 are not directly related to the goal of the app (“the user can purchase the app” being one of them). That’s a lot of user stories!

If anything it’s too many stories. If I developed all of those before I shipped, then I’d spend lots of time on niche features before even finding out how useful the real world finds the basic things. I split the stories into two piles; the ones which are absolutely necessary for a preview release, and the ones which can come later. I don’t yet care how late “later” is; they could be in 1.0, a point release or a paid upgrade. As I haven’t even got to the first beta yet that’s immaterial, I just know that they don’t need to be now. There are four stories that do need to be now.

So, I’ve started implementing these stories. For the first one I went to a small whiteboard and sketched UI mock-ups. In fact, I came up with four. I then set about finding out whether other apps have similar UI and how they’ve presented it, to choose one of these mock-ups. Following advice from the world according to Gemmell I took photos of the whiteboard at each important stage to act as a design log – I’m also keeping screenshots of the app as I go. Then it’s over to Xcode!

So a few iterations of whiteboard/Interface Builder/Xcode later and I have two of my four “must-have” stories completed, and already somebody who has seen the app knows what it’s about. With any luck (and the next time I snatch any spare time) it won’t take long to have the four stories complete, at which point I can start the private beta to find out where to go next. Oh, and what is the app? I’ll tell you soon…

Posted in Business, cocoa, macdevnet, metadev, usability | 2 Comments

On XP mode

This is a reply to @gcluley, who linked to this ZDNet story (which in turn took its quotes from Sophos Podcasts).

The second most crazy thing about the entire “XP mode” issue in Windows 7 is that the feature is entirely unnecessary. Corporate customers of Windows are already, for the most part, comfortable with managing virtual Windows desktops through third-party products with much better management options or at least have trialled such products. Home users of Windows just take whichever version is pre-installed when they buy the PC and if it means buying new versions of some apps, that’s what they do. They’re used to it. The group of people who could benefit from XP mode – people with a strong need for app compatibility with XP but with no experience of virtualisation – just doesn’t exist.

The very existence of the XP mode feature is a microcosmic example of the way Ballmer has been running Microsoft – if there’s a market out there that MS isn’t in, MS needs to be in it pronto. Bing, Morro, Web-Office, Zune and now virtualisation are all testament to the inability of Microsoft to concentrate on what it does. What Microsoft really does is to sell two things; an enterprise computing environment and an OEM software distribution. Forget that Windows and Office are accounted as two separate products; MS sell Windows+Office to businesses and Windows to computer makers.

Now the interesting question to ponder is which of Microsoft’s (real or perceived; remember they aren’t necessarily in this market) competitors the “XP mode” feature is a response to. My interpretation is that it’s not actually VMware and its ilk at all – Microsoft is once again responding to nonexistent competition from Apple. Boot Camp and the third-party desktop virtualisation offerings on the Mac (including, without hint of irony, VMware) let users use OS X as their shiny new OS with an “XP mode” of sorts for legacy applications. I think what Microsoft are trying to do here is to show that Windows can be the new shiny with XP as the legacy mode, and are therefore positioning XP mode as a counter to the fictitious competition from Apple. Oh, and if you don’t believe me when I say that the competition from Apple doesn’t exist – Apple sell all of the premium computers while Microsoft take the aforementioned corporate and OEM markets.

OK, so if that was the second most crazy thing about XP mode, what is the most crazy thing about XP mode? It’s also that the feature shouldn’t exist. Windows has always had a problem with segregating distinct services which other operating systems don’t suffer from. While Microsoft’s avoidance of this issue has allowed a whole new software industry to spring up around it, the fact that they need to start a second copy of Windows just to get some applications running in Windows 7 doesn’t give me much hope for the future.

Posted in whatevs | 2 Comments

The next million-dollar iPhone application

I’m constantly surprised by questions such as this one. They invariably go along the lines:

I heard that I need to get a Mac to do iPhone development. I want to do iPhone development but do I have to buy a Mac? Is there any other way to develop iPhone software?

If the projected sales for your app don’t meet the cost of a new computer, whatever platform you’re developing on, it’s time to get a different idea for your app. I speak with the smug self-confidence of one who has yet to get his own app within smelling distance of the store.

Posted in whatevs | 4 Comments

A rap upon the noggin

When a patient may be concussed, it’s common for parademics to ask simple, topical questions to determine whether the patient is confused. Questions such as “who is the Prime Minister”?

I think somebody may have knocked this poor spammer upside the head (emphasis is mine):

Lloyd’s TSB Group plc
25 Gresham Street
London EC2V 7HN

Greetings,

Following the recent announcement by the Chancellor of the Exchequer, Gordon Brown that all assets in accounts that have been

dormant for over 15years be transferred to the Treasury i send this mail to you.

There is a dormant account in my office,with no owner or beneficiaries. It will be in my interest to transfer this assets

worth 20,000,000 British pounds to an offshore country. If you can be a collaborator/partner to this please indicate interest

immediately for us to proceed.

Remember this is absolutely confidential,as i am seeking your assistance to act as the beneficiary of the account, since we

are not allowed to operate a foreign accounts. Your contact phone numbers and name will be necessary for this effect.
I have reposed my confidence in you and hope that you will not disappoint me.

My Regards,
Jim McConville
Lloyd’s TSB Group plc

Posted in whatevs | Leave a comment

Website relaunch!

Today I have re-launched Thaes Ofereode to focus on my new role as an independent Mac boffin. I really like the new design, which was created by the ever-delightful Freya.

edit: Gecko doesn’t understand the CSS media selector I was using to provide the iPhone CSS. I’ve therefore reverted the iPhone design until I can find a way to get Firefox to suck less.


The one thing I added to her design was a more iPhone-friendly look. For those of you without iPhones, the screenshots demonstrate how the mobile version will appear. For those of you who are CSS experts, the following will probably be rather dull but for those like me who know enough to be dangerous but no more, here’s how it’s done.

The three-column layout works really well on the desktop, but the iPhone has a tallscreen-oriented display so not much space for horizontal layout. I therefore chose to put the leftmost, menu column underneath the main content on each page, so iPhone users get to see the heading and then the meat and potatoes. If they are interested enough to get to the end, they’ll see the links to the rest of the site.

The links, btw, are just paragraphs with a border, a lot of padding and the magic -webkit-border-radius providing the roundy edges; no messing with JavaScript and funny part-circle images.

So, the third column? Well those impressive-looking widgets can’t be displayed on the phone anyway, and would be a bit out of place so they’re gone for the moment with the mobile CSS. I may code up some JavaScript replacements soon enough, but I’ll need to find somewhere else for them to go. In the meantime, I know you read my blog because you’re here, and there are many apps which can help you follow me on Twitter.

Posted in whatevs | Leave a comment

Next CocoaHeads Swindon meet!

So for those of you who didn’t manage to enjoy the glories to be found in the town that was the inspiration for one of Legion’s more colourful adventures,[] next Monday, the 3rd of August, offers yet another once-in-a-monthtime opportunity! As ever, the location is in (or just outside) the Glue Pot, a strong man’s stone’s throw from the Swindon train station. This month’s meeting is a recap on QTKit, to allow those who weren’t there last time due to the reschedule to catch up on integrating QuickTime into their Cocoa apps.

[] What am I doing knowing quotes like that? Well, the clue is in the user name. When I was a student my UNIX username was leeg, clearly based on my real name. In short order, I was introduced as "He is Leeg, for he are many" and thus iamleeg.

Posted in whatevs | Leave a comment