Pete Goodliffe

Writing: Coping With Complexity

2012-01-11T09:53:00.000-08:00

The January issue of ACCU's CVu magazine is landing on doormats now. It contains the latest instalment in my Becoming a Better Programmer column. This one's called Coping With Complexity. It an interesting wee treatise on managing (and fighting) complexity in our software.

It's got sticks. And blobs. And people.

I have to say, this month's issue is a bumper one - you never get a feel for this when reviewing the PDF galley proofs. Well done all involved.

Installing Groove Agent 3 (Update from Version 1) on Mac OS Lion

2012-01-05T05:21:00.000-08:00

It all seemed so simple. I wanted to install my trusty copy of Groove Agent 3 on a new Mac OS Lion box. The license is on my eLicenser already. So it should just be a quick insert-DVD-and-install job.

Shouldn't it?

Of course not.

#Fail...

I've been using Groove Agent for years now. My version 3 DVD was an upgrade disk from the original version 1. If you run that DVD's installer it says you have to have version 1 installed to upgrade. That seems fair enough.

Except you can't install Version 1 on Lion; it is an old PPC application, and Lion doesn't support Rosetta any more.

It's a deadly circle; I now legitimately own some (not inexpensive) software that I can't install. Pete is not a happy bunny.

Attempt 1: tech support

I sent a tech support email through my Steinberg account. Not with much hope, I have to admit.

That was ages ago. What do you think happened?

Yup, you're right. Not even got a "we've got your message and it's in a queue" reply.

Thanks, Steinberg. Thanks a bunch.

But where there's a will, there's a way...

Attempt 2: Check for updates on the website

The Groove Agent 3 support site has a few update installers available (which, naturally, need the full program installed first to be able to update).

There is also a new "full installer" for the Mac to replace the DVD's installer for first-time users. This shows great promise.

Once downloaded, I run the installer. "Insert the Content DVD" it asks (impolitely). OK, again this is fair enough. The content is enormous, and is on the DVD already so I shouldn't need to download that again. It also proves that I own the product I'm installing.

I insert my Groove Agent 3 DVD into the machine. The installer doesn't recognise it. No message. No hint. No continue button. It just sits there.

Of course, it's looking for the "Groove Agent Installation DVD" not the "Groove Agent Update Installation DVD". Swines.

Absolute swines.

But where there's a will, there's a way...

Attempt 3: Trick the installer

Being a techie I wonder. I wonder how rubbish they really are... Is the installer just looking for a DVD called a certain name?

ln -s "/Volumes/Groove Agent Update DVD" "/Volumes/Groove Agent DVD"

Run the installer again.

Success!!!

The installer runs, it copies over the content from the DVD and there's my Groove Agent 3 sitting there, ready to run.

Goodliffe: 1, Steinberg: 0, (Steinberg Customer Support: -5)

But, we're not there quite yet

I fire up Cubase, pull in the virtual instrument, and a window pops up asking me to locate the content files. That's the content that the installer just installed. Into a standard place. Didn't it think to look there itself? Sheesh.

That's OK, I'll just use the file browser dialogue that appears to load it. Except that the content is automatically installed into "/Library/Application Support/Steinberg/Groove Agent".

Notice that first bit. Yes, "/Library". The folder that Apple now HIDES from users in Lion so they can't fry in innards of their OS. I physically can't navigate to the content. Genius.

The trick, of course, is to launch Finder, open the "Go" menu, and hold down the Command key. At this point "Library" magically appears in the middle of the menu's list of places you can go to. Select that folder. Navigate to the right directory in the Finder window that appears, and then drag the target directory into the patiently waiting application's file open dialogue.

What a palaver.

But that's it, I now definitely have Groove Agent 3 installed and running.

Whinge

Of course, I have a clue what's going on inside my computer, and was able to engineer this solution based on my experience and a selection of educated guesses. Goodness only knows what the average user would be able to make of this situation.

(Hopefully this blog post will help someone in time. Let me know if it does!)

Endnote

It seems that every time I want to sit down an use my computer to make music, the computer wants some love, wants its nappy changed, or wants feeding first.

New driver required! Update available! Incompatibility detected!

Technology really can get in the way of being creative.

Speaking: BCS Newcastle

2012-01-03T09:59:00.000-08:00

I will be speaking at BCS Newcastle on the 25th January. I'll be giving my iOS development talk; a quick start in developing applications for iPhone, iPad, and iPod Touch.

Here's the synopsis:

The iPhone, iPad and their iOS relatives are becoming an increasingly popular and important platform. More and more developers are looking into what the platform can offer and how to harness its power for their products.

In this presentation, an experienced iOS developer provides a boot-strap in iPhone development. The talk is an overview of how to get started as an iPhone developer. You will gain an understanding of the platform, the tools, and the core technologies, including:

The main languages: Objective C/C++
Using the Xcode IDE, and various deployment/testing tools
Common iPhone/Mac OS design patterns, idioms, and practices
Becoming a native: how to “think in iPhone”
An overview of the libraries and facilities that exist
Limitations of the development environment.

We’ll see the pros and cons of iPhone development. You will leave with an understanding of how to deploy your applications on the device, and whether it is the right platform for you to target.

Speaking: ACCU 2012

2012-01-03T09:22:00.000-08:00

I will be speaking at the ACCU 2012 conference in Oxford, UK this April.

I'm giving two presentations this year, both this year on version control:

Version control is never a laugh a minute topic, but I plan on these talks being interesting as well as informative. There will be the requisite amount of jumping, tomfoolery and general barefooted nonsense that regular attendees have come to expect.

This year's ACCU conference programme looks very strong, with understandable focus on C++ since the ink is still drying on the newest version of the language standard. But it still covers a broad range of topics, so there's something for everyone.

If you care about programming and live in proximity of Englandshire, I strongly suggest you check out this conference. It's one of the highlights of my programming year.

Skip Lists: A C++ STL-style implementation

2011-12-05T02:56:00.001-08:00

Recently someone mentioned an interesting container type to me, the skip list. It piqued my interest and so, naturally, I wanted to play around with it. It's been a while since I last wrote an STL-style container, so I thought I'd attempt to write an STL-compatible skip list implementation. Fun times.

And so I present to you my latest code offering, the C++ STL-style skip_list container. Grab it from the GitHub project here. Or read on for further information...

Skipping the list

The skip list is an interesting data structure. You could (simplistically) consider it a hybrid of a std::list and a std::set; it's a list-like data structure than provides good insertion, removal and search performance. As ever, the trick to good search speed is to trade off some memory to improve traversal performance.

Traditionally the skip list is an extension of a standard forwards-only linked list. Wikipedia has a pretty good page on the structure. Check it out if you want more gory details.

Atop a standard linked it, it maintains a set of higher-order linked lists that act as indexes into the main structure below. These provide faster access to the middle of the list. This provides efficiency on a par with a balanced binary tree (i.e. what a std::set is usually implemented in terms of). Insertion, removal and search operations are typically O(log N). Remember: a standard linked list (which you'd have to manually keep in order) would have all those operations take O(N).

The particularly interesting detail about the skip list implementation is the algorithm used to determine the allocation of nodes to higher-order lists. Rather than use a fixed balancing scheme, or inspecting the data as it's added and comparing against the existing structure, we assign nodes to levels probabilistically - always adding them to the main list, and then (with decreasing levels of probability) adding them to the high levels lists, too.

My implementation

I chose to implement a bi-directional skip list, so each node in my version retains a back-pointer to the previous node. This makes the list more useful in general, and ensures that it's a drop-in replacement for std::list.

Like std::set, my version takes a template Comparison functor (typically std::less) so you can tailor the ordering of data in your container. I also, naturally, support custom allocators, and provide all "the usual" STL container operations.

I have tested the code on:

Mac OS using Xcode 4.2
Windows usigin Visual Studio 2008
Linux using gcc 4.4

I have benchmarked the performance of my skip_list container. Because of the probabilistic nature of the container, sometimes it will perform better than other times when given random test data.

The memory consumption is almost exactly the same as std::set in general, and it tends to allow faster forwards and reverse iteration. Depending on the way the wind is blowing, large node insertion/removal operations can be dramatically faster (taking a little as 25% of the time of std::set for the same data) or a bit slower (I've seen up to ~110%).

The source archive contains my benchmarking code, so feel free to try it yourself.

The GitHub project for skip_list is https://github.com/petegoodliffe/skip_list.

Future plans

I have not yet provided C++11 "move" or initialiser_list operations, so that would be an interesting addition.

I could extend the data structure to provide O(log N) random access (e.g. indexing and random access iteration), too, at the expense of one more integer value in each node. That would be an interesting extension to consider - probably as a parallel variant of the existing container.

Future writings

If there's enough interest, I might start a new blog series on writing an STL-like container based on this implementation. There was a lot of interest in my previous series describing an STL-style circular buffer. Since this is a meatier data structure, the case study would be more useful.

Let me know if you'd like this!

PGMidi moved and updated

2011-11-24T02:13:00.001-08:00

My popular PGMidi library for MIDI input/output on iOS has moved from Gitorious to a new location on GitHub. (This was requested many times, and who am I to disappoint?)

Please update your repos accordingly.

Over the next few days, I'll also be adding a few new tweaks and features to the project, so stay tuned.

Thanks for all the kind comments and feedback about the code - I'm really glad it's useful. Please do let me know if you've incorporated it in your own project.

Writing: How To Pick Your Programming Language

2011-11-23T01:06:00.001-08:00

The November issue of ACCU's C Vu magazine is out now. It contains the latest instalment in my Becoming a Better Programmer column. This one's called How To Pick Your Programming Language.

It's a masterwork that uses ancient dark arts (and frivolous flow chart technology) to help you select the programming language that best suits you.

Best read with a pinch of salt!

I quite like the artwork I produced for this month's cover, and have finally remembered to align the {cvu} drop shadow correctly, something that's been bugging me for months. (I doubt anyone else would even have noticed it)

Xcode 4 keyboard/mouse shortcuts

2011-11-16T04:11:00.001-08:00

(I'm posting this here mostly so I don't lose it, although I'm sure it'll be useful to other Xcode 4 users out there.)

There are a couple of really handy Xcode mouse click modifier key combinations that I can never remember when I want them (kind of like a Super Street Fighter key combo).

In particular, you can click on symbols in the code editor and have them open in this editor, in the alt editor, in a new window, or... even... with a (ugly looking) popup asking you where to open (e.g. in a new tab).

Here's the lowdown:

Xcode 4 editor symbol clicks

Modifiers Click What happens
⌘⎇^ + single Open in alt editor
⌘⎇⇧ + single Select where to open (with popup)

⌘ + single Open in this editor
⌘ + double Open in this new editor window
⎇ + single Show help popup
⎇ + double Show help in organiser

⌘⎇⇧ Make alt editor counterpart again (super useful)

Key (what the silly symbols mean)

⌘ Command (cmd)
⎇ Option (alt)
^ Control (ctrl)
⇧ Shift

It's the thought that accounts

2011-11-11T07:44:00.001-08:00

Thinking well is wise; planning well, wiser; doing well, wisest and best of all.

– Persian Proverb

I run. Every week. It's my waistline, you see. Perhaps it's aguilt thing, but I do feel I need to do something to keep it undercontrol.

Now,let's be clear: I'm no masochist. Exercise is notmy favourite thing in the world. Far from it. It definitely ranksabove hot pokers being stuck in my eyes. Marginally. But there areplenty of things I'd rather do with my evenings. Many of them involvesitting down, preferably with a glass of wine.

ButI know that I shouldrun. It's good for me.

Is that fact alone enough to ensure I go regularly, every week,for the full distance? With no slacking or slowing of the pace?

It is not.

I dislike exercise and would gladly employ the weakest of excusesto get out of a run. “Oh no, my running shorts have a loosethread.” “Oh no, I have a runny nose.” “Oh no, I'm a bittired.” “Oh no, my leg has fallen off."

(Ok,some excuses arebetterthan others.)

What unseen force coaxes me to continue running regularly whenguilt alone can't drag me out the door? What magical power leads meon where willpower fails?

Accountability.

I run with a friend. That person knows when I'm slacking, andencourages me out of the house even when I don't fancy it. They turnup at the door, as we'd arranged before my lethargy set in. I performthe same kind of service back. I’ve lost count of the times that Iwouldn't have run, or would have given up half-way round had I nothad someone there, watching me and running alongside me.

And, as a by-product we enjoy the run more for the company andshared experience.

Sometimeswe bothdon't feel like going on the run. Even if we admit it to each other,we won't let the other person off the hook. We encourage each otherto push through the pain. And, once we've run, we're always glad wedid it, even if it didn't feel like a great idea at the time.

Stretch the metaphor

Some metaphors are tenuous literary devices, written to entertain,or for use as contrived segues. Some are so oblique as to bedistracting, or form such a bad parallel as to be downrightmisleading.
However, I believe this picture of accountability is directlyrelevant to the quality of our code.

For all the good it does technical writers, speakers, and codeprophets like myself to talk about producing good, well-crafted code,and as much as the luminaries like Uncle Bob Martin extol the(genuine) virtues of “clean” code, and Fowler explains why weneed well-factored code, it matters not one jot if, in the heat ofthe workplace, we can't put it into practice. If the harsh realitiesof the codeface cause us to shed our development morals and resort tohacking at code like uninformed idiots, what have we achieved?

We can complain about the poor state of our codebases, but who canwe look at to blame?

We need to bake into our development regimen ways to avoid thetemptation for shortcuts, bodges and quick-fixes. We need somethingto lure us out of the trap of thoughtless design, sloppy, easysolutions and half-baked practices. The kind of thing that costs useffort to do, but that in retrospect we're always glad we havedone.

The spirit is willing, but when the deadline looms, all too oftenthe flesh is weak.

How do you think we'll achieve this?

Accountability counts

Iknow that in my career to date, the single most import thing that hasencouraged me to work to the best of my abilities has beenaccountability,to a team of great programmers.

It's the other coders that make me look good. It's those othercoders that have made me a better programmer.

Being accountable to other programmers for thequality of your work will dramatically improve the quality of yourcoding.

That is a single simple, but powerful idea.

Code++

To ensure you're crafting excellent code, you need people who arechecking it every step of the way. People who will make sure you'reworking to the best of your ability, and are keeping up to thequality standard of the project/team you're working on.

This needn't be some bureaucratic big-brother process, or aregimented personal development plan that feeds back directly intoyour salary. In fact, it had better not be. A lightweight,low-ceremony system of accountability, involving no forms, lengthyreviewing sessions or formal reviews is far superior, and will yieldmuch better results.

Most important is to simply recognise the need for such a thing;to realise that you must be accountable to other people for thequality of your code to encourage you to work at your best. Torealise that actively putting yourself into that vulnerable positionof accountability is not a sign of weakness, but a valuable way togain feedback and improve your skills.

How accountable do you feel that you currently are for the qualityof the code you produce? Is anyone challenging you to produce highquality work, to prevent you from slipping into bad, lazy practices?
Accountability is worth pursuing not only in the quality of ourcode output, but also in the way we learn, and how we plan ourpersonal development. It's even beneficial in matters of characterand personal life (but that's a whole other magazine's column).

Making it work

Thereare some simple ways to build accountability for the quality of codeinto your development process. In one development team we found itparticularly useful when the all coders agreed on a simple rule: allcode passed two eyes before entering source control.With this as a peer-agreed rule, it was ourchoiceto be accountable to one another, rather then some managerial diktatpassed down from faceless suits on high. Grass-roots buy-in was keyto this success of the scheme.

To satisfy the rule, we employed pair programming and/or alow-ceremony one-on-one code review, keeping each checked-in changesmall to make the scheme manageable. Knowing another person was goingto scrutinise your work was enough to foster a resistance to sloppypractise and to improve the general quality of our code.

Ifyou know that someone else willread and comment on your code, you're more likely to write good code.

This practice genuinely improved the quality of the team, too. Weall learnt from one another, and shared our knowledge of the systemaround. It encouraged a greater responsibility for and understandingof the system.

We also ended up with closer collaboration as a result, enjoyedworking with each other, and had more fun writing the code as aconsequence of this scheme. The accountability lead to a pleasant,more productive workflow.

Setting the standard

When building developer accountability into your daily routine itis worth spending a while considering the benchmark that you'reaiming for. Ask yourself the following questions:

Howis the quality of your work judged? How do people currentlyrate your performance? What is the yardstick they use to gauge it'squality? How do you think they shouldrate it?

The software works, that's good enough.
It was written fast, and released on schedule (internal quality is not paramount).
It was well-written, and can be maintained easily in the future.
Some combination of the above.

Which is seen as most important?

Who currently judges your work? Who is the audience for your work?Is it only seen by yourself? Your peers? Your superiors? Yourmanager? Your customer? How are they qualified to judge the qualityof your handiwork?

Whoshouldbe the arbiter of your work quality? Who really knows how well you’veperformed? How can you get them involved? Is it as simple as askingthem? Does their opinion have any bearing on the company's currentview of your work's quality?

Which aspects of your work should be placed under accountability?

The lines of code you produce?
The design?
The conduct and process you used to develop it?
The way you worked with others?
The clothes you wore when you did it?

Which aspect matters the most to you at the moment? Where do youneed the most accountability and encouragement to keep improving?

The next steps

If you think that this is important, and something you shouldstart adding to your work:

Agree that accountability is a good thing. Commit to it.
Find someone to become accountable to. Consider making it a reciprocal arrangement; perhaps involve the entire development team.
Consider implementing a simple scheme like the one described above in your team, where every line of code changed, added or removed must go past two sets of eyes.
Agree on how you will work out the accountability – small meetings, end of week reviews, design meetings, pair programming, code reviews, etc.
Commit to a certain quality of work, be prepared to be challenged on it. Don't be defensive.
If this happens team-wide, or project-wide then ensure you have everyone's buy-in. Draft a set of team standards or group code of conduct for quality of development.

Also, consider approaching this from the other side: can you helpsomeone else out with feedback, encouragement, and accountability? Could you become another programmer's moral software compass?

Often this kind of accountability works better in pairs of peers,rather than in a subordinate relationship.

Conclusion

Accountability between programmers requires a degree of bravery;you have to be willing to accept criticism. And tactful enough togive it well. But the benefits can be marked and profound in thequality of code you create.

Questions

How are you accountable to others for the quality of your work?
What should you be held accountable for?
How do you ensure the work you do today is as good as previous work?
How is your current work teaching you and helping you to improve?
When have you been glad you kept quality up, even when you didn't feel like it?
Does accountability only work when you chose to enter into an accountability relationship, or can it effectively be something you are required to do?

My latest iOS app: The Mahjong Score Book

2011-10-09T15:54:00.000-07:00

My latest iOS app is out now (thanks to the iOS 5 SDK having finally gone GM). It's called the Mahjong Score Book and, as the name suggests, is designed to help Mahjong players keep tabs on their scoring in Mahjong games.

Of course, once you have your scores captured inside a wee computer, there's more exciting things we can do with them. So the app allows you to:

keep records of all the games you've ever played, with a very clear visual presentation, associated with the date played
draw pretty graphs of game progress
adopt different rule sets (limit hand value, maximum wins as east wind, etc)
export games to databases, as images, or text files
automatically roll dice to determine starting positions
associate notes with each game
and much more.

If you're interested, then check it out in iTunes here.

I appreciate that it's a niche app. It simply something I wrote to fulfil a personal need. Of course, someone else out there is going to find it useful, too. And so I've polished it, honed it, and produced a really very slick app.

I wrote Mahjong Score Book app back in the summer whilst on holiday, playing Mahjong with friends. It serviced its purpose well then and many times since, and I've learnt a few new iOS techniques whilst polishing off the application.

I'm sure that it won't make me millions, but I'm very proud of what I've produced in a relatively short time. If you know someone who plays Mahjong then please point them at it!

iOS: Using older SDKs with newer Xcode versions

2011-09-21T02:26:00.000-07:00

When you update Xcode versions, the installer automatically removes any old SDKs you have lying around, and replaces them with the latest version.

This is fine behaviour, as the most recent SDKs remain backwards compatible. You can set your project to target older iOS versions. If you do this, the newer SDK features are disabled for you.

However, there are times when you need to use an older SDK.

For example, I am running the latest Xcode with a beta iOS 5 SDK installed. Since this was originally installed on a clean machine, I didn't set the beta install to use a parallel directory and leave the "release version" of the developer tools intact - they simply weren't installed. (Making a parallel install is, in general, the best practice when installing a beta Xcode/SDK set).

Fear not. You can still get your newer Xcode to build with an older SDK, without downgrading your Xcode or making a parallel install:

Close any running Xcode instance you have open.
Locate the install DMG for an old version of Xcode (e.g. Xcode_3.2.5_and_ios_sdk_4.2_final.dmg, they name them so well) and open it.
Do not run the installer!
Open the Packages directory in that disk image. It is a hidden directory. Try this terminal incantation: "open /Volumes/Xcode\ and\ iOS\ SDK/Packages"
Locate the iPhoneOS and iPhoneSimulator SDKs for the version you want. Run just those pkg files. (e.g. I ran the iPhoneSDK4_2.pkg and it's matching iPhoneSimulatorSDK4_2.pkg)
Make sure you specify the /Developer directory as your install location. If you don't, the SDKs will be installed in your root directory, under the /Platforms directory; you'll have to manually copy them into /Developer/Platforms yourself.
Now, re-open Xcode. If the SDKs installed in the right locations, they will be selectable in your project now.

How to set up Jenkins CI on a Mac

2011-09-20T15:40:00.000-07:00

In this post I will describe how to get a running Jenkins server set up on your Mac. Like most free software ("free" as in price and "free" as in freedom), Jenkins is very capable, very functional, and mostly documented. But it didn't quite work out of the box.

As with many such projects, you get far more than you pay for. But you can end up spending more than you expect.

There aren't enough step-by-step how-to guides. And there aren't many documents that help you out when things go wrong. There is a great community behind Jenkins, though, which does help. And plenty of people moaning and blogging. Now I'm adding to that noise.

It took me a few days to get the setup working properly. Hopefully this story-cum-howto will save you some of that effort.

The Prologue

All good developers know that a continuous integration (CI) server is a linchpin of the development effort. I joined a large software project without one, and made loud noises that we needed one. And so, it naturally fell to me to set up.

It's been some time since I set up a CI server. Previously, I've used ViewTier's Parabuild. It was more than adequate. But times have moved on. Although I still have a licence for it, the cools kids are hanging around at other parties these days.

Jenkins (the recent fork of Husdon) seems well-regarded, popular, and to have a good development and support community. It's also open source, so seemed the right way to go. Plenty of people have sung it's praises to me in the past, and that kind of thing counts for a lost.

Our requirements for the builds were:

to build two products from the same codebase on Mac OSX
to build two products from the same codebase on Windows

Both of these need 32-bit and 64-bit versions.

That's already a reasonable configuration matrix, and highlighted why we needed CI in place. A developer would check in a tweak that they'd built on one configuration. All the other config could easily get broken without anyone noticing for a while.

So: Jenkins to the rescue.

Almost.

I purchased a small Mac Mini to use as a build server. I downloaded a copy of Jenkins (free, whoop!), installed the Mac dev tools (free, whoop!) bought (and installed) Parallels, Windows 7, and the Visual Studio toolchain (not quite as free), and sat down for a small configuration session.

Getting your project ready for a CI build

Before setting up your build on an CI server, you should first create a simple script that builds everything from a clean checkout. Then check that script into the repository, to be versioned alongside the software itself.

For our project, I already had that in place. The script cleaned, built, versioned and packaged the software in one step.

Such scripts are clearly useful for deployment on a CI server, and also for making official software releases by hand, whether or not you release from the CI server builds. It's a record of the recipe needed to build a release.

With a fixed recipe like this in place, every software release can be guaranteed to be good and reproducible.

That's development 101.

Installing Jenkins on the Mac

The Jenkins website has a handy Mac installer that you can download. (In retrospect, I'm not sure if this was more hassle than it was worth, but this is the route I obviously sought to go down.)

STEP 1: Install Jenkins

Download the Mac installer and run it.

This installer creates a system launch daemon that fires up Jenkins when your machine boots. This runs in the background even if you haven't logged in, making a true stand-alone build server installation.

However, if you have a fresh Lion install you don't yet have Java.

STEP 2: Install Java

Try to run a Java app. Any app. The OS may fumble around for a while looking for Java. If you're lucky, it'll download and install it automatically. Otherwise, install it by hand.

And of course, now, Jenkins "just works".

Not.

Configuring Jenkins on the Mac

The Jenkins war (web application archive) is unpacked into /Users/shared/Jenkins. The application runs from there. All configuration is stored there. The source code checkouts and builds go in there. It's the center of your Jenkins universe.

A launch daemon plist is installed in /Library/LaunchDaemons. It runs a script /Library/Application Support/jenkins-runner.sh as the user "daemon" (a system specific user that runs background processes - it is not shown on the login screen, nor does it have a home directory).

This installation has all the hallmarks of a runnable system. You can now point your browser to http://localhost:8080 and start configuring the Jenkins server. The lights are most definitely on. But no one's home yet. As we're about to see...

STEP 3: Set up Jenkins to build a Mac project

I was a good soldier with a simple shell script that built and packaged my application. If you don't have this, write one now. To build Mac projects, you'll need some cunning invocation of xcodebuild and probably packagemaker.

This single script is a critical step in configuring your build job. Whilst it is possible to place multiple build commands into the Jenkins task itself, it's far better to keep them under source control in a script checked in to your codebase (if you need to ask why then you probably need to go to a more basic tutorial!).

Configure Jenkins to check out your repository, to react to appropriate build triggers (e.g. manual build requests through the UI, automatic detection of the repository changing, or other triggers) and to run the appropriate scripts to kick off the build.

Then press "Build Now" to start your first build.

In all probability Jenkins will crash and burn. But don't tear your hair out just yet. You'll be needing it for later on.

Fix Jenkins so it works

Welcome to the nether-world of almost working builds.

STEP 4: Configure the Java heap size

My project is large. It includes lots of third party libraries, including the vastness that is Boost and many other comparable-size libraries. There are also several SDKs that are shipped as large binaries (with versions for each platform and 32/64 bit). That's a lot of data to shovel around.

Jenkins choked trying to check out this monster. It would collapse with Java heap exhaustion errors before it even got to triggering a build. Goodness only knows why a large heap is required to check files out of a subversion repository, but the solution can only be to increase the heap size to remove the bottleneck.

By default, Java allocates a very conservative default heap size to running applications; I believe its 256M or so on 32-bit Mac OS.

On the Mac, this can be changed using the "Java Preferences" application (found in the /Applications/Utilities folder). The trick is to adjust the Java launch command line (hit Options...) to include the comand-line sneeze: "-Xmx1024M" (or whatever heap size you want). However, this didn't seem to affect the Jenkins Java process launched through launchd.

To set the heap size in that context, you have to adjust the launch script itself. You can place the command line switch into the jenkins-runner.sh file directly. However, the file does have provision to load the heap size parameter from a configuration plist. This plist does not exist by default, but you can create/edit it with the following incantation:

sudo defaults write /Library/Preferences/org.jenkins-ci heapSize 1024M

This will write a file /Library/Preferences/org.jenkins-ci.plist (note that you must not specify the plist file extension to the defaults command).

To make the system use this new heap size, you can't just restart Jenkins (either gracefully within the web interface, or by "kill -9"-ing the process. You can't even use "sudo launchctl {stop,start} org.jenkins-ci".

You could reboot. Or, more cleanly, you have to force launchd to reload of the configuration for the launch daemon using launchctl by unloading, and then reloading the daemon. It's the reloading that'll force the new configuration to take hold. (It took me a while to figure that one out!)

With an increased heap, Jenkins will fall over less. In my case, I got through a whole checkout.

But once Jenkins manages to check out the project and run the build script, you're still not quite done...

My script called xcodebuild to invoke Xcode from the command line to build the various configurations of the project. This script worked fine when run directly from the command line. However, when running within Jenkins it would bomb out with quite unfathomable errors - e.g. NSAssertions triggered from deep within the Xcode IDE codebase. Or it would just enter a hibernation state; lock-up completely, performing no work, but generating no error.

The reason for the strangeness is that xcodebuild doesn't work when run as a user that has no home directory, like daemon. It throws its toys out of the pram in as baroque a manner as it can muster.

STEP 5: Create a "jenkins" user

So, to solve this we can either have Jenkins run as one of the existing users, or - more cleanly - create a new user specifically for jenkins.

To do this:

Create a user called "jenkins" from Control Panel. If you care particularly, you might want to create a "hidden" user; follow the instructions here: http://hints.macworld.com/article.php?story=20080127172157404
Stop jenkins again: sudo launchctl unload -w /Library/LaunchAgents/org.jenkins-ci.plist
Edit /Library/LaunchAgents/org.jenkins-ci.plist, change the username entry from daemon to jenkins
Change all permissions on the existing jenkins files: "sudo chown -R jenkins /User/Shared/jenkins" "sudo chgrp -R staff /User/Shared/Jenkins"
Restart Jenkins: sudo launchctl load -w /Library/LaunchAgents/org.jenkins-ci.plist

Re-start the build. Sit and wait.

Job done

From memory, that was the set-up steps required to get builds to work on a Mac from a fresh Jenkins install. These things aren't really covered by the install guides. They're obvious once you know them. Hindsight is great like that.

Plenty of people followed my whining on Twitter with disbelief, saying that Jenkins "just works" for them. Others suggested moving over to Hudson instead, but I imagine I'd've had the same issues there.

Perhaps I'm unusual, and this stuff does just work for everyone else. If that's not the case, then I hope this rant proves useful.

As a postscript, I now have my Jenkins server working well. I have configured a Windows client, running under a Parallels virtual machine on the same computer. It's not the fastest build server when both run together, but it's passable.

There are definitely some rough edges and features lacking from Jekins, but I can't complain at the price. And there are plenty of excellent plugins that really do make it a very capable build server.

Writing: Smarter, Not Harder

2011-09-15T02:09:00.000-07:00

The September issue of ACCU's C Vu magazine is out now. It contains the latest instalment in my Becoming a Better Programmer column. This one's called Smarter, Not Harder.

In it I investigate how high-quality developers use their skill and experience to be maximally productive. I describe useful tactics to help you solve problems more easily and get the job done in the most effective way. In short: how to pick your battles.

Many-festos

2011-09-06T02:39:00.000-07:00

Confusionof goals and perfection of means seems, in my opinion, tocharacterise our age.

Albert Einstein

It's becoming an epidemic! They'respringing up everywhere. We've got them coming our of our ears. It'sas if you can't write a line of code, kick off a development process,or even think about the act of coding without signing up to one.

With all these manifestos for softwaredevelopment, our profession is in danger of becoming more aboutpolitics than the actual art, craft, science, and trade of softwaredevelopment.

Of course, a large and important partof professional software development is the people problem.And that necessarily involves politics, to some extent. But we'remaking even the foundational coding principles a political battle. Isthis for the best? Or is it just a fashionable, sound-bite-sized wayto get your point across, and to try to garner support for your pethobby-horse?

These “development” manifestos areoften too ambiguous for people to sign up to in any meaningful way.They're so general that they simply must be right. Akin to adevelopment horoscope, if you will. Very few of them break newground, or introduce anything genuinely radical. And, sadly, when amanifesto becomes popular we see factions form around it, leading to disputes about what the manifesto really stands for. Whole debatesspring up around the exegesis of the particular manifesto items.

Software religion is alive and well.

Whether or not manifestos are a goodidea, they seem to be springing up for any conceivable purpose. So,in order to stem the flow, and make it easier for future softwareactivists who'd like to pen their own manifesto, here I present theone, the overarching, generic software development manifesto.Manifesto,if you like.

A generic manifesto for softwaredevelopment

We, the undersigned, have an opinionabout software development. We are concerned about the future of ourprofession, and our passion leads us to draw the followingconclusions:

We believe in a fixed set of immutable ideals

over tailoring our approach to each specific situation.

We believe in concentrating on and discussing only the things that interest us

over thebigger problem.

We believe in our opinion

over theopinions and experiences of others.

We believe in arbitrary black-and-white mandates

over real-worldscenarios with complex issues and delicate resolutions.

We believe that when our approach is hard to follow

then itonly shows how much more important it is.

We believe in crafting an arbitrary set of commandments

over therealisation that it's just never that simple.

We believe in trying to establish a movement to promote our view

over somethingthat will be genuinely useful.

We believe that we are better developers than those who don't agree with us

because they don't agree with us.

That is, we believe we're doing theright thing. And if you don't you're wrong. And if you don't do whatwe do, you're doing it wrong.

OK, OK

Alright. I'll admit it. I exaggeratedfor effect. And my tongue is in my cheek. Mostly.

References

The Agile Manifesto http://agilemanifesto.org/
The Craftsmanship Manifesto http://manifesto.softwarecraftsmanship.org/
The Refactoring Manifesto http://refactoringmanifesto.org/
The SOA Manifesto http://www.soa-manifesto.org/
The GNU Manifesto http://www.gnu.org/gnu/manifesto.html
The Software Testing Manifesto http://www.softwaretestingmanifesto.org/
The Library Software Manifesto http://techessence.info/manifesto/
The OpenCloud Manifesto http://www.opencloudmanifesto.org/
The Mozilla Manifesto http://www.mozilla.org/about/manifesto
The Cluetrain Manifesto http://www.cluetrain.com/
The End-User Manifesto http://alistair.cockburn.us/User+Manifesto
The Experience Design Manifesto http://www.brazandre.com/manifesto/
The Hacker Manifesto http://en.wikipedia.org/wiki/Hacker_Manifesto

Questions

What foundational development “principles” do you hold dear?
Do you sign up to, or align yourself with, development streams like “agile”, “craftsmanship” and so on? How closely do you agree with each of the items in their manifesto?
What do you think these manifestos do have to offer the development community?
What kinds of harm might they really be able do, if any?
Or do you keep your head down and ignore this kind of thing? Should you actually follow these software fashions and fads to maintain personal development?

Pushing a git repository into an existing subversion repository

2011-08-12T02:12:00.000-07:00

I worked on a project using git as the version control system. Eventally I needed to share it with other developers, who had an existing corporate Subversion repository. They didn't want to be bogged down in the minutae of learning a new version control system.

So I had to push the code in my git repo up to the svn repo.

There are two options:

Take a baseline of the code and just comit that to svn, losing all version history. It's simple; it's quick; it works. Ten points for getting the job done. No points for elegance. And minus several thousand points for losing revision history.
Serialise the development history in git and use that to re-vivify the history within Subversion. Many, many, points for doing the right thing. Minus quite a few for the faff it takes to work out how to do it.

Clearly, (2) is the way to go.

For your delight, this is how I finally managed to do it. Hopefully it'll help you avoid similar head scratching and Googling.

How to push a git repository into svn

Obviously, we'll want to invoke the git-svn command. The trick is how to arrange your git repo so that it's tracking the subversion repository correctly.

Step 1: Create the landing point in the svn repo

svn mkdir svn://DEST/repo/projectname/{trunk,branches,tags}

It's worth noting that in this example, I was happy to just clone the mainline of development, and ignore any git branches.

As you can infer, the corporate svn repo has many top-level directories that are all themselves "mini-repos". This is why I had to push the git history into an existing svn repo, rather than just create a new svn repo.

Step 2: Create a git svn clone tracking svn

git svn clone svn://DEST/repo/projectname/trunk dest

Now we have a git repo that tracks the destination svn landing point for the import operation.

Step 3: Track the git repo we want to import

cd dest

git remote add -f source /path/to/git/source/repo

Now, if you inspect the git history (for this I used the excellent GitX (L) ), you'll see a whole series of commits from the original git repo and, disconnected from this, the master HEAD plus a git-svn HEAD pointing to the original (single) svn commit we cloned.

Step 4: Rebase the original git repo onto git-svn

Here's where the secret magic lies. I seems like there are many ways to go from here. This was the only one I found to work. Of course, I tried many ways that failed. Once I found one that worked, I stopped trying. So if there's a better way I'd love to hear it, but this seems to work well.

git rebase --onto remotes/git-svn --root source/master

At this point, I realised that my git history wasn't strictly linear; I had worked on a few machines, so the history of trunk wove arond a bit.

This meant that what I had expected to be a straightforward operation (that's what you'd expect with a SVN hat on) required a few rebase fix-ups along the way:

(

gvim foo # fix merge conflict

git add foo

git rebase --continue

)

# ... rinse and repeat

These were required because branches in the source repo from work on different machines that got merged together to form the "source" trunk line of development didn't flatten into a rebase without a few tweaks.

In general, the conflicts were small and weren't hard to fix.

Step 5: Admire your work

git log

You should now see that the entire master development line of the source git repo has been replayed into the master of your working repo, stacked on top of the git-svn point.

Again, GitX (L) helped to visualise this.

Step 6: Push up to svn

Now that we've arranged everything above git-svn, it's a simple case of:

git svn dcommit

To push the changes up into svn.

Now that's magic.

Xcode: Determining the current SDK version in a script

2011-07-22T08:26:00.000-07:00

In an iOS XCode project, I needed a shell script target (aka "External Build Tool" target) that invokes other scripts which in turn build stuff using Xcode. Curiously recursive.

Now, I needed to pass that script the current iOS SDK version being used so it could arrange its own build malarkey, and get all its SDK ducks in a row.

There is no environment variable for that defined by Xcode. Bah. The closest you get is the current deployment target version, which appears in $IPHONEOS_DEPLOYMENT_TARGET.

That seems like rather a large omission.

You do get given $SDKROOT which is a file path to the current SDK. But that's not quite the same thing as a simple version number.

Never, fear, shell gibberish to the rescue. This is what I came up with:

SDK_VERSION=$(echo $SDKROOT | sed -e 's/.*iPhone$OS$*$Simulator$*$[0-9]*.[0-9]*$.sdk/\3/')

If you know a better way to do this, I'd love to know.

C++: Declaring a pointer to a template method

2011-07-19T06:56:00.000-07:00

Busy writing some template gibberish, we needed to make a healthy trade in pointers to template-member-functions. Of template classes. (Where the template function parameters themselves were pointers to template methods on template classes, but let's not worry about that detail right now).

It took a little run-up to get the C++ syntax right, so I present it here for your viewing pleasure.

All code tested against g++ 4.2.1 only.

Case 1: Normal pointer to member

Let's just remind ourselves of the syntax for a simple pointer to (normal, non-template) member function:

Note: I've gratuitously changed the < < stream operators into "--" just to get the syntax through blogger's composer window. Sorry about that. I pray that no other C++ syntax was sacrificed in this publishing exercise

class Target1
{
 public:
   void Method(int a)
   {
     std::cout -- "Target1(" -- a -- ")\n";
   }
};

void PointerToNormalMemberFunction()
{
 Target1 target;
 // This is how we construct a normal pointer to member function
 void (Target1::*oneParam)(int) = &Target1::Method;
 (target.*oneParam)(1);
}

Relatively simple.

Case 2: A pointer to template member function

Here's the first incursion of templates. If you're looking at a template method, this is how you'd declare your pointers to it:

class Target2
{
public:
 template <typename T>
 void Method(T a)
 {
   std::cout -- "Target2("--a--")\n";
 }
};

void PointerToTemplateMemberFunction()
{
 Target2 target;

 // This is how we construct a pointer to a template member function
 // See how the template type of the method is mentioned at the end of the method name.
 void (Target2::*oneParamTemplateInt)(int)     = &Target2::Method<int>;
 void (Target2::*oneParamTemplateFloat)(float) = &Target2::Method<float>;
 (target.*oneParamTemplateInt)(2);
 (target.*oneParamTemplateFloat)(2.5);

 // However, the compiler can deduce the template type of the method
 void (Target2::*shorterInt)(int)     = &Target2::Method;
 void (Target2::*shorterFloat)(float) = &Target2::Method;
 (target.*shorterInt)(3);
 (target.*shorterFloat)(3.5);
}

Note that you can chose whether or not to specify the template types of the method when you assign it to your member-function pointer. The compiler can deduce these for you.

Case 3: Pointer to template methods with more than one template parameter

This is not significantly different from the above, we just extend the types in the pointer-to-member.

class Target3
{
public:
 template <typenameT>
 void Method(T1 a, T2 b)
 {
   std::cout -- "Target3("--a--","--b--")\n";
 }
};

void PointerToTemplateMemberFunctionWithTwoParameters()
{
 Target3 target;

 // This is how we construct a pointer to a template member function
 // with multiple template parameters. Just like above, really.
 void (Target3::*oneParamTemplateIntFloat)(int,float)   = &Target3::Method<int,float>;
 void (Target3::*oneParamTemplateFloatInt)(float,int) = &Target3::Method<float,int>;
 (target.*oneParamTemplateIntFloat)(4,4.5);
 (target.*oneParamTemplateFloatInt)(4.5,4);

 // Again, the compiler can deduce the type of the methods
 void (Target3::*shorterIntFloat)(int,float)   = &Target3::Method;
 void (Target3::*shorterFloatInt)(float,int) = &Target3::Method;
 (target.*shorterIntFloat)(5,5.5);
 (target.*shorterFloatInt)(5.5,5);
}

Again, note, the compiler can generally deduce the correct template method without you having to specify the template parameter types.

Case 4: Pointer to template methods in a template class.

Now it's getting sillier - a pointer to a template method in a template class. the syntax does still make sense, it just depends how far down the rabbit hole you want to go.

template<typename TYPE>
class Target4
{
public:
 Target4(const TYPE &value) : value(value) {}
 TYPE value;

 template <typename T>
 void OneParam(T a)
 {
    std::cout -- "Target4::OneParam("--value--","--a--")\n";
 }

 template <typename T1, typename T2>
 void TwoParam(T1 a, T2 b)
 {
    std::cout -- "Target4::TwoParam("--value--","--a--","--b--")\n";
 }
};

void PointerToTemplateMemberInTemplateClass()
{
 Target4<char> target('c');

 void (Target4<char>::*oneParam)(float) = &Target4<char>::OneParam<float>;
 (target.*oneParam)(6.5);

 // Again, we can miss off the last template types
 void (Target4<char>::*shorter)(float) = &Target4<char>::OneParam;
 (target.*shorter)(6.75);

 // Two parameters just extends the scheme
 void (Target4<char>::*twoParam)(float,int) = &Target4<char>::TwoParam;
 (target.*twoParam)(6.8,6);
}

Case 5: Using a pointer to a template method of a template class inside the template class itself

If you want to make use of a pointer to template method within a template class, you simply cannot specify the template method's parameter types. The compiler considers this a syntax error. So you have to rely on the compiler deducing the correct template method instantiation. (See edit below.)

In the case of this example, it copes fine. In more complex cases, it may hurt less if your call template method overloads different names.

template<typename TYPE>
class Target5
{
public:
 Target5(const TYPE &value) : value(value) {}
 TYPE value;

 template <typename T>
 void OneParam(T a)
 {
   std::cout -- "Target5::OneParam("--value--","--a--")\n";

   typedef void (Target5<E>::*MethodTypeToCall)(T);
   // Here, the compiler picks the right overload
   MethodTypeToCall toCall = &Target5<E>::Private;
   // In this case, the compiler does not let us write the following line (parse error):
   //MethodTypeToCall toCall = &Target5<E>::Private<t;;
   (this->*toCall)(a);
 }

 template <typename T1, typename T2>
 void TwoParam(T1 a, T2 b)
 {
   std::cout -- "Target5::TwoParam("--value--","--a--","--b--")\n";

   typedef void (Target5<E>::*MethodTypeToCall)(T1,T2);
   MethodTypeToCall toCall = &Target5<E>::Private; // compiler picks the right overload
   // you can't add the method's template parameters to the end of that line
   (this->*toCall)(a,b);
 }

private:

 template <typename T>
 void Private(T a)
   { std::cout -- "Target5::Private("--value--","--a--")\n"; }
 template <typename T1, typename T2>
 void Private(T1 a, T2 b)
   { std::cout -- "Target5::Private("--value--","--a--","--b--")\n"; }
};

void HoldingAPointerToTemplateMemberInTemplateClass()
{
 Target5<r> target('c');

 void (Target5<r>::*oneParam)(int) = &Target5<r>::OneParam;
 (target.*oneParam)(7);
 void (Target5<r>::*twoParam)(float,int) = &Target5<r>::TwoParam;
 (target.*twoParam)(7.5,7);
}

Edit: it's been pointed to to me that you can name a specific overloaded template method using the following syntax. Add this to your pipe and smoke the whole template shenanigans:

MethodTypeToCall toCall2 = &Target5::template Private<T>;

This kind of template gibberish is why you know you love C++.

Simples, init?

The extra thing we added to all this syntactical joy was to have one of the template method's (template) parameter types itself a pointer to a template method on a template class.

It was at this point our brains dribbled out of our ears, and we had to retrace our template syntax steps back up this rabbit hole.

Writing: It's The Thought That Accounts

2011-07-18T07:08:00.000-07:00

The July issue of ACCU's C Vu magazine is out now. It contains the latest instalment in my Becoming a Better Programmer column. This one's called It's The Thought That Accounts.

In it I describe how you can become a better programmer, and how you will be encouraged to write better code, through accountability. Far from being a dirty word, or some kind of bureaucratic nightmare, developer accountability can be fun, stimulating, enriching, and valuable.

You'll also find out about my wine and running predilections.

This is a great issue of C Vu, with some really interesting articles. If you're a developer who is not already an ACCU member, then I strongly urge you to join. It's super-cheap and really worthwhile!

I'll hold you accountable to that...

Are we there yet? (Becoming a Better Programmer)

2011-06-24T01:40:00.000-07:00

In the name of God, stop a moment, cease your work, look around you. Leo Tolstoy

A program is made of a number of subsystems. Each of those subsystems is composed of a smaller parts - components, modules, classes, functions, data types, and the like. Sometimes even boxes and lines. Or clever ideas.

The jobbing programmer moves from one assignment to the next; from one task to another. Their working day is composed of a series of construction and maintenance tasks on a series of these software components: composing new parts, stitching parts together, extending, enhancing or mending existing pieces of code.

So our job is simply a string of lots of smaller jobs. It's recursive. Programmers love that that kind of thing.

Are we there yet?

So there you are: getting the job done. (You think.)

Just like a small child travelling in the back of a car constantly brays “are we there yet?”, pretty soon you'll encounter the braying manager: “are you done yet?”

This is an important question. Its essential for a software developer to be able to answer that one simple request: to know what “done” looks like, and to have a realistic idea of how close you are to being “done”. And then to communicate it.

Many programmers fall short here; it's tempting to just keep hacking away until the task seems complete. They don't have a good grasp on whether they're nearly finished or not. They think: There could be any number of bugs to iron out, or unforeseen problems to trip me up. I can't possibly tell if I'm almost done.

But that's simply not good enough. Usually, avoiding the question is an excuse for lazy practice, a justification for “coding from the hip”, without forethought and planning. It's not methodical.

It's also likely to create problems for you. I often see people working far too hard:

They are doing more work than necessary, because they didn't know when to stop.
Without knowing when they'll be done, they don't actually complete the tasks they think are finished. This leads to having to pick things back up later on, to work out what's missing and how to stitch it in. Code construction is far slower and harder this way.
The wrong bits of code get polished, as the correct goal was never in sight. This is wasted work.
Developers working too hard are forced to put in extra hours. You'll not get enough sleep!

Let's see how to avoid this and to answer “are we there yet” effectively.

Developing backwards: decomposition

Different programming shops manage their day-to-day development efforts differently. Often this depends on the size and structure of the software team.

Some place a single developer in charge of a large swathe of functionality, give them a delivery date, and ask them for occasional progress reports. Others follow “agile” processes, and manage a backlog of more granular tasks (perhaps phrasing them as stories), divvying those out to programmers as they are able to move into a new task.

The first step towards defining “done” is to know exactly what you're working on. If it's a fiendishly large and complex problem, then it's going to be fiendishly complex to say when you'll be done.

It's a far simpler exercise to answer how far through you are through a small, well-understood problem. Obvious, really.

So if you have been allotted a monster task, before you begin chipping away at it, break it down into smaller, understandable parts. Too many people rush headlong into code or design without taking a step back to consider how they will work through it.

Split large tasks up into a series of smaller, well-understood tasks. You will be able to judge progress through these more accurately.

Often this isn't a complex a task, at least for a top-level decomposition. (You may have to drill down a few times. Do so. But take note: this is an indication that you've been handed a task at far too high a granularity.)

Sometimes such a decomposition is hard to do, and is a significant task itself. Don't let that put you off. If you don't do it up-front for estimation purposes, you'll only end up doing it later on in less focussed ways as you battle to the finish line.

Make sure that at any point in time, you know the smallest unit you're working on; rather than just the big target for your project.

Define done

You've got an idea of the big picture; you know what you're ultimately trying to build. And you know the particular sub-task you're working on at the moment.

Now, make sure that for whatever task you are working on, you know when to stop.

To do this, you have to define what “done” is. You have to know what “success” means. What the “complete” software will look like.

Make sure you define “done”.

This is important. If you haven't determined when to stop, you'll keep working far past when you needed to. You'll be working harder and longer than you needed to. Or, you won't work hard enough – you'll not get everything done. (Not getting everything done sounds easier, doesn't it? But it's not... the half-done work will come back to bite you, and will make more work for you later down the line, whether that's bugs, rework, or an unstable product).

Don't start a piece of coding work until you know what success is. If you don't yet know, make your first task determining what “done” is. Only then, get going. With the certainty of knowing where you're headed, you'll be able to work in a focused, directed manner. You'll be able to make informed choices, and to discount unnecessary things that might side-track or delay you.

If you can't tell when it's done, then you shouldn't start it.

So how does this look in practice? How do you define “done”? Your “done” criteria needs to be:

Clear

It must be unambiguous and specific. A list of all the features to be implemented, the APIs added or extended, or the specific faults to be fixed.

If, as you get into the task, you discover things that might affect the completion criteria (e.g. you discover more bugs that need fixing, or uncover unforeseen problems) then you must make sure that you reflect this in your “done” criteria.

This criteria is usually directly traceable to some software requirements or a user story – if you have them. If this is the case, make sure that this connection is documented.

Visible

Make sure that the success criteria is seen by all important parties. This probably includes: your manager, your customers, the downstream teams using your code, or the testers who will validate your work.

Make sure everyone knows and agrees on this criteria. And make sure they'll have a way of telling – and agreeing – when you are “done”.

The nature of each task will clearly define what “done” means. However you should consider:

How much code must be completed. (Do you measure this in units of functionality, APIs implemented, user stories completed?)
How much is design done, and how it's captured.
Whether any documents or reports must be generated.

When it's a coding task, you can mostly clearly demonstrate “being done” by creating an unambiguous test set. Write tests that will show when you've fashioned the full suite of code required.

Use tests written in code to define when your code is complete and working.

There are some other questions that you may have to consider when you describe what “done” is:

Where is the code delivered to? (e.g. to version control)
Where is the code deployed to? (Is it “done” when it's live on a server - or do you deliver testable product ready for a deployment team to roll out?)
What are the economics of “done”? The exact numbers required that may lead to certain tradeoffs or measurements. For example: how well should your solution scale? It's not good enough if your software only manages 10 simultaneous users if 10,000 are required. The more precise your done criteria the better you understand these economics.
How will you signal that you're done? When you think you're done how will you let the customer/manager/QA department know? This probably looks different for each person. How will you garner agreement that you are indeed done – who signs-off on your work? Do you just check in, do you change a project reporting ticket, or do you raise an invoice?

Just do it

When you've defined “done”, you can work with focus. Work up to the “done” point. Don't do more than necessary.

Stop when your code is good enough – not necessarily perfect (there may be a real difference between the two states). If the code gets used or worked on an awful lot, it may eventually be refactored to be perfect – but don't polish it yet. This may just be wasted effort. (Beware: this is not an excuse to write bad code, just a warning against unnecessary over-polishing).

Don't do more work than necessarily. Work until you're “done”. Then stop.

Having a single, specific goal in mind helps you to focus on a single task. Without this focus it's easy to hack at code randomly trying to achieve a number of things and not managing any of them successfully.

Questions

Do you know when you're current task will be “done”? What does “done” look like?
Have you decomposed your current task into a single goal, or a series of simple goals?
Do you decompose your work into achievable, measurable units?

The Enigma Continues

2011-06-09T18:26:00.000-07:00

Version 1.4 of my cool iOS puzzle game, The Enigma Squares, has been released. Check it out here. In this version, I present you more than 80 new levels, with a number of fun, a number of fiendish, and a number of speed-trial puzzles.

Check it out on iTunes now.

I've also released a new game. The Enigma Kids is a family-oriented puzzler. With child-friendly puzzles, great graphics and lots of fun, everyone will enjoy this game.

Check out The Enigma Kids on iTunes here.

Let me know what you think!

Optimising Parallels performance for development

2011-05-25T06:16:00.000-07:00

I use the wonderful Parallels 6 to perform all my Windows development. (I find working on a Mac makes Windows development a lot more bearable - at least for this old Unix-head).

In general, Parallels works superbly (and is reported to perform a lot better than VMware, if you believe the hype). However, for operations like rebuilding a large, complex C++ source tree, the virtual machine performance lagged a long way behind a native machine. Large compiles can take more than twice the time of a real Windows PC. Clearly, this taxes the host machine hard: hammering CPU, memory, and disk at once.

This problem exhibits on my four core Mac Pro with as many resources as I could throw at the problem, as well as on my more humble MacBook Pro.

I performed a number of experiments to work out how to fix this:

Tweaking the allocated CPU cores, memory, and disk space
Tweaking the settings for the virtual hard drive
Network building from host mac file system

None of these made much difference. In fact, I was somewhat surprised that operating on a networked disk was fantastically slower. That was a shame, as it would be advantageous to share a single source tree with my Xcode development for cross-platform development. (As it happens, I manage this by having a Windows-side git clone of the git repo on the Mac side).

However, I've now managed to get my compile times right down. Here's how.

Do bare in mind that these tweaks are in addition to the obvious steps you should take with any machine:

Have as fast a CPU as possible.
Throw as many CPU cores as you can at the problem - builds can be parallelised very easily.
Throw as much memory as you have at your disposal at the problem.

1. Swap the swap

The factor slowing me down the most turned out to be the Parallels virtual disk that Windows was running on. First, the swap file was hosted on it. So I made a second virtual disk, and pushed the virtual memory off onto it. That made a small, but appreciable difference.

2. Only ever use fixed size disks

In your disk settings, do not use automatically expanding disks. That's just another overhead for the computer to manage whilst accessing disks. Create a fixed size blob of disk space and run with it.

3. Use a virtual SCSI disk

This is the big one. So pay attention at the back.

It seems that Parallels can emulate a SCSI disk far, far faster than it can emulate and IDE disk. However, it defaults to creating IDE disks. I believe that this is to make installation of Windows simpler, as you don't have to fettle with custom SCSI drivers during installation.

You can't just switch the main disk from IDE to SCSI, though. Windows has a minor eppe and refuses to run if you do that. I couldn't be bothered to wipe it all and try to reinstall on a new SCSI virtual disk, so I added yet another large SCSI virtual disk for my source trees and checked out onto that disk.

Remember: it's a fixed size, non-expanding SCSI disk.

With this configuration the build simply screams in comparison to building on the virtual IDE C: drive.

I hope you find this information useful!

iOS: The Enigma Squares (1.2)

2011-05-13T16:34:00.000-07:00

The Enigma Squares version 1.2 is available in the App Store now. Amongst other excitement, it adds Game Center support. You can now share your achievements and high score with other players. Woo hoo.

So far, I'm very impressed at how far players have got. I'm glad the game is providing an interesting challenge!

More interesting updates are in the pipeline...

iOS: Packaging apps store submissions from the command line (my zip broke)

2011-05-12T07:01:00.000-07:00

How to package iOS apps for submission to iTunes Connect from the command line.

I'm a firm believer in the power of the command line. I like my GUI tools as much as the next man (as long as he's a bearded Unix guru from the 1970s). But for sheer power, repeatability and flexibility you just can't beat a good script.

Which is why every project I work on has to have a simple single script that configures, builds, and packages the code, creating a well-named payload that can be installed/submitted/deployed. I feel a lot safer about the quality of a release if it's generated by a tried-and-tested script, rather than by a series of button clicks in a series of separate tools.

You know it makes sense.

iOS projects submitted to the App Store are effectively zip files with a particular directory structure. You can drive Xcode with the xcodebuild tool to build and link your distribution version of an iOS app.

However, whenever I tried to zip the project up from the command line, the Application Loader utility (what you use to submit your app to iTunes Connect) just gave bizare errors.

The CodeResources files must be a symbolic link to _CodeSygnature/CodeResources. Make certain that the bundle is on a locally-mounted volume...
Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate.

Well, that's nice gibberish. Not.

However, a zip archive created using the Finder's "Compress" menu entry worked fine. Very frustrating.

Don't fear! I fixed it. Here's how to do it in your very own build script: your zipper is broken; throw it out. Use ditto instead. Here's the line from my build script:

APP_FILENAME=/path/to/build/Application.app
PACKAGED_FILENAME=MyGoodPackagedFilename.zip
ditto -c -k --keepParent --rsrc "$APP_FILENAME" "$PACKAGED_FILENAME"

Enjoy your build scripts.

Becoming a Better Programmer

2011-05-05T05:35:00.001-07:00

My Becoming a Better Programmer presentation given at ACCU 2011 has been very popular recently. It's one of the most-viewed presentations on slideshare this month.

At the time of writing, there have been more than 12,500 views of the entire presentation.

That is both exciting and flattering - and nice to know that developers truly do care about improving their skills. And nice to know that I have been able to help.

Check it out here.

Writing: Relish the Challenge

2011-05-05T05:25:00.001-07:00

The May issue of ACCU's C Vu magazine will be hitting doormats any moment now. It contains the latest instalment in my Becoming a Better Programmer column. This one's called Relish the Challenge, and is an encouragement to stay motivated and challenged, to seek out new things, and to avoid becoming stale and staid as a developer.

I hope it's useful. For your stimulation, I've added the final questions from the article to the end of this blog post.

The PDF version of the magazine will be available for download by ACCU members shortly.

The cover I created for this month's issue is quite dense and busy. I wonder if that's any reflection on the designer?

Questions

Do you have projects that challenge you and stretch your skills?
Are there some ideas you’ve thought about for a while, but not started? Why not start a little side-project?
Do you balance ‘interesting’ challenges with your ‘day to day’ work?
Are you challenged by other motivated programmers around you?
Do you have a broad field of interest that informs your work?

iOS: The Enigma Squares

2011-05-04T06:39:00.000-07:00

My first personal iOS project has finally seem the light of day. Please welcome into the world The Enigma Squares. It's an interesting (and dare I say it) entertaining block-moving puzzle game.

Check it out on iTunes here.

I've produced plenty of iOS projects for my company. But this has been an entertaining personal side-project, to keep me busy through those long spring evenings.

It is actually a version of a game I first wrote (ahem) 20 years ago. Back then it was written for the Acorn Archimedes, and I sold it to a magazine for inclusion on their cover disk (remember those?) This version is a little more polished, a little more challenging, and a lot more fun.

The code's a fair bit better too, but that's another story. One that I'm sure I'll tell one day...

Let me know what you think of it!

Code: Gibberish++

2011-04-20T06:46:00.000-07:00

I love C++.

And I hate it.

Whenever I pick up my C++ compiler, it feels like I'm coming home. It's a wonderfully powerful language, and one that, in the hands of the experienced, can be used to craft exquisite code. It can also be made to construct a bloody mess. Literally.

It's a sharp tool. With sharp edges. Whenever you pick it up, you realise that you have a sharp tool already covered in the blood of previous unfortunate users.

With great power comes great responsibility.

The language ranges from the sublime to the ridiculous, through fields of the inexplicable, unusable, and unreadable.

A great example of the gibberish end of C++'s spectrum is this example given me be a colleague.

What does the following code print?:

using namespace std;
int x = 50;
cout << setw(8) << setfill('0') << showbase << hex; cout << x << endl;

Any guesses?

The answer is: 00000x32. Um, handy.

What you have to say is this:

using namespace std;
int x = 50;
cout << setw(8) << setfill('0') << internal << showbase << hex; cout << x << endl;

To get: 0x000032.

Iostreams. Gibberish++

Speaking: ACCU 2011 slides available

2011-04-19T07:52:00.000-07:00

The slides from all of my ACCU 2011 talks are now available for your viewing pleasure on SlideShare.

Find them here:

Thanks for all the great feedback!

If you're interested in me giving these talks for you, then get in touch.

iOS: A Fading AVAudioPlayer

2011-04-05T06:39:00.000-07:00

In a recent iOS project I needed to play some background music and have it fade smoothly in and out when it starts and stops.

The "play some music" part is easy. iOS give us AVAudioPlayer in the AVFoundation framework. Super sweet and easy to use. However the "fade in and out" bit doesn't come for free.

The canonical solution suggested on the web is to hand-craft some nasty looping logic to get the job done. This is 2011 and we can do better than that. And, indeed, here it is, in all it's Objective C glory.

My solution makes interesting use of categories, associative references and blocks. It's worth strolling through the implementation if you're interested in any of these. If not, you can just grab my code from the Gitorious project and use it in blissful ignorance.

1. Add a category

First, we open up our own category on the AVAudioPlayer class and define the methods we would ideally like the class to provide:

@interface AVAudioPlayer (PGFade)
- (void) stopWithFadeDuration:(NSTimeInterval)duration;
- (void) playWithFadeDuration:(NSTimeInterval)duration;
@end

That's the joys of categories - you can extend existent classes in your own application easily to make it look like methods were part of the original class interface. The common convention is to save this in a file called "AVAudioPlayer+PGFade.h".

Now client code can create a bog-standard AVAudioPlayer object, and call my new methods as if they were part of the base interface:

AVAudioPlayer *player = [AVAudioPlayer alloc] initWith...]; // however you want it set up
[player playWithFadeDuration:2.0];

2. Associative References

Now, our implementation of this is going to require some instance variables (ivars) to work with. The problem with categories is that they only allow you to add methods - you can't extend the set of instance variables defined in the class' @interface.

Or can you?

Associative references to the rescue! This is a handy Objective C runtime facility that allows you to associate another object with an existing object, with a lookup system very much like a dictionary - referenced by a void* key value.

The associated object is lifetime-managed with the original object, so when you release the parent, all associated objects are also released.

Using this facility we can "graft on" some of our own private ivars to the original class. Dirty, but effective.

One of the variables I need is a boolean variable tracking whether a fade is currently in progress. I actually expose this as a property called fading in the category interface. The implementation looks like this:

@implementation AVAudioPlayer (PGFade)

static char fadingKey;

- (BOOL) fading
{
NSNumber *number = (NSNumber *)objc_getAssociatedObject(self, &fadingKey);
return number && number.boolValue;
}

- (void) setFading:(BOOL)fading
{
objc_setAssociatedObject(self, &fadingKey, [NSNumber numberWithBool:fading], OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

That's relatively simple. We just use two objective C runtime functions,  objc_getAssociatedObject and objc_setAssociatedObject. For the association we use the address of a static variable - this will be an unambiguous value in the whole program. The object we store is an NSNumber object initialised with the value of our boolean.

It's a simple and effective trick.

3. Blocks

The final bit is for bonus points. You can see the implementation of my fade routine in the example project code itself. It's pretty simple - I just initialise the fade state in a few more "associative reference" variables and schedule a method call with performSelector:withObject:afterDelay. Each time this is called, I adjust the AVAudioPlayer's volume, and schedule a new call if one is needed.

However, to truly perform a stop with fade, we need to ramp the audio volume down, and when it gets to zero stop the player. This could be achieved with some more state variables and clumsy logic, but iOS now provides us with blocks which are perfect for this kind of activity.

For sanity, I typedef a block (closure) type. The syntax practically identical to typedefing a pointer-to-function in C, but with ^ instead of *.

typedef void (^AVAudioPlayerFadeCompleteBlock)();

I make one more associated variable of this type, the block to call on completion:

- (AVAudioPlayerFadeCompleteBlock) fadeCompletion
{
return (AVAudioPlayerFadeCompleteBlock)objc_getAssociatedObject(self, &fadeCompletionKey);
}

- (void) setFadeCompletion:(AVAudioPlayerFadeCompleteBlock)completion
{
objc_setAssociatedObject(self, &fadeCompletionKey, completion, OBJC_ASSOCIATION_COPY_NONATOMIC);
}

Note that blocks can be traded like objective C objects. You can retain, copy, and release them. In this case our code needs to take a copy (using the OBJC_ASSOCIATION_COPY_NONATOMIC flag). This ensures that any set block exists on the heap (persistent) rather than the default on-the-stack location.

Now, the internal "audio fade" routine need only check whether there is a completion block registered when the fade is complete, and if so call it:

    if (fadeIsComplete)
{
    self.fading = NO;
    AVAudioPlayerFadeCompleteBlock completion = self.fadeCompletion;
    if (completion) completion();
    self.fadeCompletion = nil;
}

Invoking a block looks just like calling a function. Once called, we clear out the stored block in case it is holding other resources that should be released.

This provides an elegant way to perform any arbitrary action after the fade is complete.

That's all, folks!

The trio of Objective C facilities used here work together well to provide a simple and elegant solution to a problem that is often achieved with complex "strings-and-glue" logic. Check out the entire project on Gitorious here.

Speaking: ACCU 2011

2011-04-05T00:38:00.001-07:00

I will be speaking at the ACCU 2011 conference in Oxford this month.

My talk is entitled Becoming a Better Programmer, and it's going to be great fun. And hopefully very useful, too. This year green is very much the new blue. Details (intentionally vague) on the session are here.

I will also be speaking in the Key practices to cope with complexity session (details here). Let's hope I don't make my contribution needlessly complex.

iOS: Prettier auto-rotation

2011-03-18T08:53:00.000-07:00

A simple Friday iOS coding tip for you:

When your app auto-rotates do you have an unsightly white frame appearing around the edges of your beautifully hand-crafted UI?

The default Xcode UIView-based project template creates a UIWindow with a white background. The white frame on rotation is the background of the UIWindow peeping out behind your UIView subview.

The simple fix to your UI woes: make the UIWindow background clear (either in the XIB file, or just before your call to [window makeKeyAndVisible].

Simples!

[ios] iOS Development talk slides available

2011-03-16T03:33:00.000-07:00

The slides from my popular iOS development talk, last given at BCS Edinburgh are available for you to view on Slideshare.

To view them, follow this link.

Writing: Many-festos

2011-03-11T02:15:00.000-08:00

The March issue of ACCU's C Vu will be hitting doormats any moment now. It contains the latest installment in my Becoming a Better Programmer column. This one's called Many-festos, and is a slightly irked rant on the proliferation of software development "manifestos" that have sprung up recently, and some of the arguments that have arisen around them.

The PDF version of the magazine will be available for download by ACCU members shortly.

[ios] Dynamic cast in Objective-C

2011-02-11T08:40:00.000-08:00

In C++, you can cast a pointer between two (related) types, and ask the runtime to check if the conversion is valid using dynamic_cast. Usually in C++ the use of dynamic_cast is a sign that you're doing something wrong - good C++ design generally avoids such constructs.

However, Objective-C is a far more dynamic language, and often you do need to do something similar. The runtime provides all the smarts for this, but doesn't deliver it in a simple one-liner.

So let's fix that...

Wondering if a view controller's view property is a UISwitch? Try this:

UISwitch *switch
= objc_dynamic_cast(UISwitch,viewController.view);
if (switch) NSLog(@"It jolly well is!);

That's nice, isn't it? Here's how:

#define objc_dynamic_cast(TYPE, object) \
  ({ \
      TYPE *dyn_cast_object = (TYPE*)(object); \
      [dyn_cast_object isKindOfClass:[TYPE class]] ? dyn_cast_object : nil; \
  })

For the curious, here's what's going on...

First, we define a preprocessor macro using a gcc extension: the macro compound statement. That's the ({ ... }) block. This is a little dirty, and I certainly wouldn't use a gcc-specific extension in my "portable" C++ code. However, Objective-C lives in a different ecosystem, where you can guarantee that compound statements will be supported. So we'll go with it.

The reason I use a compound statement is to define a "local" variable - dyn_cast_object. This is just to cover the macro's back - it needs to mention the name of the object argument twice, and if that expression has side effects you'd get twice the number of side effects otherwise. Side-side effects. So I store the argument in a local variable to avoid this. (Most of the time this is unlikely to be an issue, but if you ever got bit by this problem, you'll appreciate having done it right the first time).

Then we simply ask the object is it is of the class of our cast's destination type, using NSObject's isKindOfClass: selector.

Not too complex. And you could do the isKindOfClass: dance wherever you need to cast. But it's nice to write the macro once and then write clear code that reveals it's intent.

[ios] Cancelling a UIGestureRecognizer

2011-02-11T01:14:00.000-08:00

You have a view with a handful of gesture recognizers. Perhaps some of them are chained together with requireGestureRecognizerToFail so that they interact well.

Sometimes, you still need to respond to other user interaction, and cause any pending gesture to immediately fail. There isn't an API for that.

I had this issue when my application's "timeline" view, which was using pinch, tap, and pan gestures in concert, needed to grow temporary UIButton subviews. The buttons worked fine, but pressing them also triggered the gesture recognizers - very confusing for the user.

Here's the solution.

How to forcibly cancel a UIGestureRecnogizer

Add a new category (I call it "Cancel") to the UIGestureRecognizer class extending it with a new cancel method:

@interface UIGestureRecognizer (Cancel)
- (void)cancel;
@end

And implement the new method like this:

@implementation UIGestureRecognizer (Cancel)
- (void)cancel
{
self.enabled = NO;
self.enabled = YES;
}
@end

The simple trick of switching off and back on a gesture will force it to cancel.

Then for bonus points, I add a category on UIView to make it easy to cancel all the gestures attached to it. I tend not to hold the gestures as member variables in my view controller because there isn't any need to do so - they are retained by the view you attach them to.

//-----------------------------------------
// In .h file:

@interface UIView (CancelAllGestures)
- (void) cancelAllGestureRecognizers;
@end

//-----------------------------------------
// In .m file:

@implementation UIView (CancelAllGestures)
- (void) cancelAllGestureRecognizers
{
for (UIGestureRecognizer *gesture in self.gestureRecognizers)
{
[gesture cancel];
}
}
@end

This new method could then be easily used in my main view controller, by attaching it to the my UIButton objects as a new action:

[button addTarget:myViewWithGestures
action:@selector(cancelAllGestureRecognizers)
forControlEvents:UIControlEventTouchDown];

Categories are a useful Objective C feature that really do help to make your code more clear and readable. Here they provide the means for another simple solution. I hope you find it useful.

So you need some software?

2011-02-04T06:33:00.000-08:00

This is your handy cut-out-and-keep guide to software development.

Click on the image for high-res version.

PGMidi updated

2011-02-04T04:44:00.001-08:00

Attention PGMidi users! I've updated my MIDI Monitor example project again, this time making PGMidi less of an example, and a lot more useful for general use.

Check it out on the GitHub project page (historical note: it was hosted on this gitorious project page, but that is now deprecated in favour of GitHub).

What's changed:

The PGMidi class now allows you to determine what MIDI sources and MIDI connections are currently available.
It allows you to determine whether the source/destination is a networked session, or a physically attached device.
The "events" PGMidi sends through the delegate interface are far more explicit.
I've added some useful tools to find a matching source/destination pair if you want to speak to one specific MIDI device.

The MIDIMonitor example application continues to show how to use the PGMidi API.

Thanks for all the comments and feedback I've received about this code. I hope you find these updates useful.

Speaking: BCS Edinburgh (iOS development)

2011-01-28T02:27:00.000-08:00

I will be speaking at the Edinburgh branch of the BCS on the subject of iPhone development on March the 9th.

The details of the session, times, and location are available here.

Here's the synopsis:

Developing applications for iPhone, iPad (and other iOS devices)

"An introduction to iPhone development for beginners or those who are casually interested and want a leg up the learning curve"

The iPhone, iPad and their iOS relatives are becoming an increasingly popular and important platform. More and more developers are looking into what the platform can offer and how to harness its power for their products.

In this presentation, an experienced iOS developer provides a boot-strap in iPhone development. The talk is an overview of how to get started as an iPhone developer. You will gain an understanding of the platform, the tools, and the core technologies, including:

The main languages: Objective C/C++
Using the Xcode IDE, and various deployment/testing tools
Common iPhone/Mac OS design patterns, idioms, and practices
Becoming a native: how to "think in iPhone"
An overview of the libraries and facilities that exist
Limitations of the development environment.

We'll see the pros and cons of iPhone development. You will leave with an understanding of how to deploy your applications on the device, and whether it is the right platform for you to target.

iOS: performSelectorOnMainThread: with two arguments

2011-01-27T03:02:00.000-08:00

iOS's NSObject class provides a mechanism to run any selector on a different thread. The most often used variant runs the selector on the "main" (i.e. UI) thread, the snappily titled: performSelectorOnMainThread:withObject:waitUntilDone:. However, the limitation with this call is that you can only supply one argument.

Sometimes, one is not enough. There is a two argument non-thread version, here. So why not invent our own two-argument threaded version?

We can add this easily enough to the base NSObject class by opening a new category on it just for the purpose.

Here's how...

1. Define our API

We open a category on NSObject (note the category name in brackets)

@interface NSObject (PGPerformSelectorOnMainThreadWithTwoObjects)
- (void) performSelectorOnMainThread:(SEL)selector withObject:(id)arg1 withObject:(id)arg2 waitUntilDone:(BOOL)wait;
@end

Naturally, it follows the existing performSelector API signatures, but just adds our extra withObject: argument.

2. Implement it

Here's the secret sauce. Careful application of NSMethodSignature, and NSInvocation.

@implementation NSObject (PGPerformSelectorOnMainThreadWithTwoObjects)
- (void) performSelectorOnMainThread:(SEL)selector withObject:(id)arg1 withObject:(id)arg2 waitUntilDone:(BOOL)wait
{

NSMethodSignature *sig = [self methodSignatureForSelector:selector];
if (!sig) return;

NSInvocation* invo = [NSInvocation invocationWithMethodSignature:sig];
[invo setTarget:self];
[invo setSelector:selector];
[invo setArgument:&arg1 atIndex:2];
[invo setArgument:&arg2 atIndex:3];
[invo retainArguments];
[invo performSelectorOnMainThread:@selector(invoke) withObject:nil waitUntilDone:wait];
}
@end

That's it.

Now you have your own simple way to invoke a call to selector on the main thread from wherever you are in your code. Handy.

Speaking: ACCU 2011

2011-01-26T06:56:00.000-08:00

I will be speaking at the ACCU 2011 developer conference in Oxford, UK in April.

This year, my ACCU presentation is called Becoming a Better Programmer (yes, following the title of my magazine column - but it's not the same content, honest!).

Here's the talk synopsis:

You're a programmer. You spend your life programming. (You dull person, you!)

Don't you want to do it as well as you possibly can?

This entertaining talk will provide a number of practical, simple methods to become a better programmer. There will be plenty of hand-waving and jumping, a little philosophy, and much wisdom from our excellent programmer forebears.

Be the best programmer you can!

Reflections: The year that was

2011-01-26T06:04:00.000-08:00

I'm a bit late to the table with this one given that we're almost a full month into 2011, but it's always good to take stock of what you've achieved in a year. And: better late than never, eh?

I was prompted to perform this exercise by a few other people's similar posts; perhaps you'd like to do the same thing?

I'll admit that I actually began writing this list at the end of last year, but have only just got around to finishing off my notes. Enough with the procrastination. I seem to suffer from a bad case of everything-is-more-important-than-everything-else-itis recently.

Amongst other things, in 2010:

I continued writing my regular software development column for ACCU's CVu magazine. This year I renamed the column, from the slightly stuffy and ambiguous "Professionalism in Programming" to the more lucid "Becoming a Better Programmer".
Speaking at developer of conferences. I gave two talks at ACCU 2010 in Oxford, and one in the Software Craftsmanship track of QCon London 2010. I also gave a presentation on iPhone development for Software East in Cambridge. It was refreshing to attend other techie conferences as a "mere" attendee.
Book contributions. I contributed three entries to O'Reily's 97 Things Every Programmer Should Know book, edited by Kevlin Henney.
Kept on developing... Produced a number of iOS apps for my company (DJ apps, Synths, and a hardware MIDI SDK). And worked on Mac apps, getting them available in the Mac App Store when it launched.
Kept on developing more... It's been gratifying that a lot of my publicly available code components have been very popular in 2010. Especially the iOS MIDI I/O library I wrote which has found its way into many iOS apps, and my work getting the Boost libraries easily available on iOS.
Continued graphic design and layout work, overseeing the layout and design of CVu and Overload magazines, as well as producing the covers for both publications.
Performed a number of techie book reviews. Mostly this year, I have been reviewing iPhone/iOS development books for ACCU.
Learnt new technologies: this year was definitely the year of git, which I now use for everything, including accessing Subversion repositories.
Preached on a Sunday morning at Old Windsor Parish Church.
Spoke at the wedding of two great friends, Steve and Frances.
Playing keyboards at three conferences in Cambridge (as well as regular stints in the Sunday morning band at C3).
Leading a smallgroup at C3.
Moved house (I now have a studio, wooo!)

Phew! That list's not exhaustive (I wonder what I've forgotten about), but its enough for now. It's been a busy year. And not a dull one.

2010 albums of the year: Bonobo's Black Sands, Brandon Flower's Flamingo, Foal's Total Life Forever, Seasick Steve's Songs for Elisabeth, Vampire Weekend's Contra, 65daysofstatic's We Were Exploding Anyway, St. Lola In The Fields' High Atop The Houses And The Towns, Lou Rhode's One Good Thing, Jonsi's Go, Goldfrapp's Head First, and Klaxon's Surfing the Void.

Writing: When It's Done, It's Done

2011-01-14T01:24:00.000-08:00

The January issue of ACCU's C Vu magazine is out now. It contains the latest installment in my Becoming a Better Programmer column. This one's called When It's Done, It's Done, and is a description of how to do the "right" amount of work; to work out when your current task will be complete, and when you should stop working on it.

The magazine should have landed on ACCU members' doormats already. The PDF version is available for download on the website.

This is the first issue of C Vu for which I have produced the cover using Photoshop (previous issues were drawn in The Gimp). Most people probably won't notice, although I took the opportunity to make a few small visual tweaks. Ironically, Paul (the guest editor) asked me for a cover that was a bit "Java-y", and then there were no actual articles about Java. Ah well...

More iOS MIDI (using networked MIDI connections)

2011-01-05T01:38:00.000-08:00

My iOS MIDI I/O example code has been incredibly popular. It's great to know that many music apps out there have incorporated my code to get their MIDI interfacing working.

Thanks for all the kind feedback.

I have been updating the MIDI code with a few structural tidy-ups, and an often requested feature - the ability to use networked MIDI sessions (connections).

Doing it manually: Using networked MIDI connections

iOS provides some a neat networked MIDI connection facility. However, despite being easy to set up, network MIDI sessions aren't initially obvious.

First, you must include:

#import <CoreMIDI/MIDINetworkSession.h>

Because network sessions are not included in the umbrella CoreMIDI.h include file. Sigh.

Next you must establish a network session by winking the (evil) singleton instance into existence:

MIDINetworkSession* session = [MIDINetworkSession defaultSession];

Then, merely turn it on:

session.enabled = YES;
session.connectionPolicy = MIDINetworkConnectionPolicy_Anyone;

Yes, that is all.

Documentation for MIDINetworkSession is available here.

The easy way: using PGMidi

If you're using my MIDI classes, then you can just call the PGMidi class' enableNetwork: method with YES or NO.

Get the code

The latest version of my MIDI interface code, and a sample project that shows it in action is available from the GitHub project page.

Feedback, as ever, is welcomed.

Uploading Mac App Store apps whose names contain a space

2010-12-08T06:34:00.001-08:00

As the launch of the Mac App Store grows ever nearer (mere days if interweb rumours are to be believed) developers are hastily uploading theirMac apps to be there at launch time.

For the most part, Apple have streamlined the upload procedure and integrated it into the Xcode IDE well (although, you MUST remember to download and install an Xcode plugin from the developer site, or the facility is mysteriously absent).

However the upload-to-iTunes-Connect procedure doesn't always work. In particular, it fails spectacularly (see the image) if your application name includes spaces.

Clearly, application names including spaces are Not The Right Way To Do Things. No one would want to do something like that. (No, we don't use applications like "Address Book" "DVD Player" "Front Row" or "Photo Booth". They'll never catch on.)

The worst part of the problem is that Xcode's upload error is completely cryptic. Rather than:

You tried to upload a binary whose bundle name contains a space.

you get something like:

Apple's web service operation was not successful.
Unable to authenticate the package: 4084782348.itmsp
ERROR ITMS-4000: "Line 6 column 62: bad character content for element at XPath /package/software_assets/assets/data_file/file_name"

Catchy, eh? User friendly, eh?

It's particularly galling as the "Validate..." step in the Xcode organiser window will not check for this problem, and tells you that your application is valid for upload. Sigh.

After discovering that there are problems with bundle names containing spaces, there are obvious things you could try:

Rename the application without spaces. FAIL: No one wants to use an application called AddressBook.
Fiddle the NSBundleName Info.plist entry so that it doesn't have a space in it, but leave the the "Application Name.app" filename as it was. FAIL 1: I don't think that this is a valid bundle any more. FAIL 2: It doesn't work. You still get the upload error.
Scream, cry, whinge. FAIL: Whilst it doesn't actually make any technical difference, this will make you feel better for a short while.

There is a solution, though. And it turns out to be quite simple.

Rather than following the Apple instructions for uploading your app to iTunes Connect, perform the "Build and Archive" step. "Validate..." your application for luck. Then click on "Share..." and chose to save an image to your hard disk.

Now use Application Loader to upload the pkg image created to iTunes Connect.

It just works.

Make some noise! (Audio on iOS)

2010-11-18T02:28:00.000-08:00

There are two main APIs on iOS for playing programatically-generated audio:

Audio Units [see here]
Audio Queues [see here]

Audio units are a lower-level, lower-latency technology. And also, a relatively complex API. Audio queues are higher-level and simpler to use, but have far greater latency.

I have produced a sample project showing the simplest creation of an audio unit and audio queue output so you can compare and contrast the two APIs. Get it on Gitorious here.

The following series of blog entries will describe each technology.

About the project

The project builds a sample iOS application that plays a steady sine wave as long as it is running. If you look at main.mm you'll see a single #define for USE_AUDIO_QUEUE_OUTPUT that can be used to switch between the audio unit and audio queue back ends.

There are extra things a well-behaved iOS audio app should do that are not (yet) illustrated by this example project. Notably, your app should use the Audio Sessions API to define what kind of audio session it requires and to handle interruptions to the audio output (e.g. when a phone call it received whilst your app is running).

Make some noise!

Before we work out how to make noise with our iOS devices, we need some audio to start with. For this reason, the AudioProducer protocol defines a simple interface that the audio backends can grab an audio stream from.

It looks like this:

/// Type of audio sample produced by an AudioProducer
typedef SInt16 Sample;

/// Protocol for objects that produce audio
@protocol AudioProducer

@property (nonatomic) float sampleRate;

/// Fills a buffer with "size" samples.
/// The buffer should be filled in with interleaved stereo samples.
- (void) produceSamples:(Sample *)audioBuffer size:(size_t)size;

@end

That is, we'll be peddling signed 16-bit integer samples, and have a single method that can be called to grab the next block of interleaved stereo audio samples.

Given that, I have written a simple SineWave audio generator. It's not the most elegant generator, I'll admit. It uses a resonant filter to approximate a sine wave rather than the maths library trig functions for performance reasons.

The SineWave interface adopts the AudioProducer protocol, and adds two extra properties - the frequency of the sine wave and the peak (amplitude) of the wave. You can see the interface here and the implementation here.

Atomicity

Note that since this is a simplistic example I have made all of these properties nonatomic. However, both audio units and audio queues will pull audio from your application in a background thread (not the main user interface thread).

The audio unit uses a very high priority background thread, as it is a very low latency audio pipeline with little buffering. The audio queue thread is not set as high-priority, as it employs a large amount of buffering.

You must bear these threads in mind when writing an audio generator. Ensure that any parameter that can be changed is thread-safe. Make sure that if the UI is in the process of adjusting values and gets interrupted by the audio thread that no disasters (e.g. nasty audio glitches) can result.

What this looks like in practice is different for each application. But this is an important warning to heed.

Next time

So now we have some audio to play, next time we'll look at how to use the audio queue APIs to play it.

Writing: This Time I've Got It...

2010-11-12T01:55:00.001-08:00

The November issue of ACCU's C Vu magazine is out now. It contains the latest installment in my Becoming a Better Programmer column. This one's called This Time I've Got It... and is a software development parable. As the article strap-line puts it: Pete Goodliffe tells us a story of stress, short-sightedness, and solutions.

The magazine should have landed on ACCU members' doormats already. The PDF version is available for download on the website.

Sending MIDI through CoreMIDI

2010-11-02T05:04:00.000-07:00

The 4.2 iOS GM seed is out. CoreMIDI is coming to the masses. So I've updated my CoreMIDI example to show how to send MIDI out through the USB port. (I've had a lot of people ask me for this.)

Go to the GitHub project page and check out the update. It's a simple addition, but shows the simplest way of getting MIDI data out of your application and through CoreMIDI.

Interestingly, the later - and the GM - versions of iOS 4.2 are far less forgiving of attached USB control devices. Most of the devices I test with are rejected by the iPad because they draw too much power. These are devices with LEDs, but that are certainly within USB power specifications. That's quite a shame.

As ever, I welcome feedback about this example project. Let me know if you find it useful.

Using CoreMIDI in iOS (an example)

2010-10-21T05:34:00.000-07:00

In iOS 4.2 the CoreMIDI framework is dropping into the standard operating system. MIDI connectivity using generic class-compliant USB MIDI hardware will be available to all.

It's not a big framework, with a handful of pure-C APIs. But its affect will be profound. What was previously only possible using Akai's AkaiConnect SDK (which is a very nice Objective-C API) or Line 6's MIDI Mobilizer SDK will be available to all.

From what I can see, the iOS CoreMIDI version is going to be the exact same API as the Mac OS desktop variant. I expect developer take-up of this API to be far faster than for the existing two (non-standard) iOS MIDI interface APIs. Pretty soon every iPhone synth app will support Apple's generic MIDI API.

That is, if they can work out how to.

CoreMIDI isn't the best documented API (this is all you get: a list of typedefs and functions). Fortunately, the headers are well-commented and the API is mercifully simple and sensible. However, with no compelling examples (that I could find) it takes a little digging to work out how to use CoreMIDI.

So here I present a very simple example project, with a reusable Objective-C MIDI interface class. With this code, you can get up to speed with CoreMIDI quickly. Indeed, if you just paste my MidiInput class into your synth app you'd be good to go.

Grab it from the GitHub project here. (Update note: the repo master used to be hosted on Gitorious here but we've moved to GitHub in these enlightened times)

Please let me know if you find it useful, or if you use it in your own projects.

Integrating CoreMIDI in your application

First, you need to decide if you want your app to support devices running iOS versions before 4.2. Since CoreMIDI is only introduced in 4.2, you have to jump through a few hoops to keep your app running on earlier versions:

Weakly link to the CoreMIDI framework, so on OS versions without it your application will still launch. (You do this by going to your application's target in the Xcode tree view, selecting "Get info", and in the "General" tab's "Linked libraries" section ensuring that CoreMIDI is set to "Weak" not "Required".)
Including CoreMIDI functionality conditionally. The best way to do this is inspect the kCFCoreFoundationVersionNumber variable and only initialise your MIDI handling if the value represents iOS 4.2 or later. (See the iOS version detection header file in my example project for an elegant way to do this).

A demonstration of all of this is available in my example project.

Using CoreMIDI

CoreMIDI itself isn't too complex if you're happy to read the headers and work out what's going on. You need a basic grasp of how Mac OS's Core Foundation works, to understand lifetime management issues and to access string properties, etc.

CoreMIDI has a few basic concepts: most importantly clients, devices (with endpoints) and ports. The C APIs let you enumerate these, and register a notification to keep abreast of changes in MIDI connection state.

MIDI inputs are "sources" in CoreMIDI. MIDI outputs are "destinations".

Given those basic facts, you should be able to read through my MidiInput class and figure out what's going on.

Parsing MIDI

My example program just spits out a stream of binary MIDI data. I'm not showing any parsing of the MIDI data stream here. This parsing isn't rocket science, but is another step you have to perform.

Contact me if you want to know more about parsing MIDI.

Get the code here.

Learning: Some Practical Ideas To Help You Learn

2010-10-21T00:25:00.000-07:00

A I wind down my blog series on software developers learning, I present some practical ideas to help you improve your learning:

Cultivate a healthy set of attitudes: take responsibility for your learning.
Learn one programming language per year. (This is excellent advice in The Pragmatic Programmer that is still very valid today.)
Scratch an itch! (What are you curious about? Consider something “leftfield”, not programming-related. Ensure that at all times you have something you're learning about that isn't directly related to your day job).
Read at least one book every two months (Read more if you want, but set some kind of benchmark to aim for).
Look after your learning machine – get good nutrition, and plenty of rest. Avoid stress. Have fun!
Build mental maps as you learn.
Try to use both sides of your brain.
Perform deliberate practice & exercise as you learn.
Network: actively learn from others, and seek to teach/mentor others.
Enjoy learning. This stuff is fun.
Apply any new knowledge cautiously.

Conclusion

You have to take responsibility for your own learning. It's not up to your employer, your state education system, an assigned mentor, or any other person.

You are in charge of your own learning. It's important to continually improve your skills to improve as a developer. And to do that you have to learn to learn. To make it rewarding you have to learn to love doing it.

Learn to live to love to learn.

Questions to ponder

When were you last in a situation that required learning?
How did you approach it?
How successful were you?
How quickly did you learn?
How could you have performed better?
Did you learn, then work, or learn as you worked?
Which do you think is most effective?

Write Less Code!

2010-10-20T14:36:00.000-07:00

It's a sad fact that in our modern world that there's simply too much code. I can cope with the fact that my car engine is controlled by a computer, there's obviously software cooking the food in my microwave, and it wouldn't surprise me if my genetically modified cucumbers had an embedded micro controller in them. That's all fine; its not what I'm obsessing about. I'm worried about all the unnecessary code out there.

There's simply too much unnecessary code kicking around. Like weeds, these evil lines of code clog up our precious byes of storage, obfuscate our revision control histories, stubbornly get in the way of our development, and use up precious code space, choking the good code around them.

Why is there so much unnecessary code? Perhaps it's due to genetic flaws. Some people like the sound of their own voice. You've met them; you just can't shut them up. They're the kind of people you don't want to get stuck with at parties. Yada yada yada. Other people like their own code too much. They like it so much they write reams of it. { yada->yada.yada(); } Or perhaps they're the programmers with misguided managers who judge progress by how many thousands of lines of code have been written a day.

Writing lots of code does not mean that you've written lots of software. Indeed, some code can actually negatively affect the amount of software you have – it gets in the way, causes faults, and reduces the quality of the user experience. The programming equivalent of anti-matter.

Some of my best software improvement work has been by removing code. I fondly remember one time when I lopped literally thousands of lines of code out of a sprawling system, and replaced it with a mere ten lines of code. What a wonderfully smug feeling of satisfaction. I suggest you try it some time.

Why should we care?

So why is this phenomenon bad, rather than merely annoying? There are many reasons why unnecessary code is the root of all evil. Here are a few headlines:

Writing a fresh line of code is the birth of a little lifeform. It will need to be lovingly nurtured into a useful and profitable member of software society. Then you release the product.

Over the life of the software system, that line of code needs maintenance. Each line of code costs a little. The more you write, the higher the cost. The longer they live, the higher the cost. Clearly, unnecessary code needs to meet a timely demise before it bankrupts us.

More code means there is more to read – it makes our programs harder to comprehend. Unnecessary code can mask the purpose of a function, or hide small but important differences in otherwise similar code.
The more code there is, the more work required to make modifications – the program is harder to modify.
Code harbours bugs. There more code you have, the more places there are for bugs to hide.
Duplicated code is particularly pernicious; you can fix a bug in one copy of the code and, unbeknown to you, still have another thirty two identical little bugs kicking around elsewhere.

Unnecessary code comes in many guises: unused components, dead code, pointless comments, unnecessary verbosity, and so on. In a future post, I'll look at some of these pernicious beasties in a little more detail.

Learning: Mapping your learning journey

2010-10-19T03:26:00.000-07:00

In the last few posts on learning I've been reviewing a number of tools that help us, as software developers, learn.The final tool we'll look at in our arsenal is a powerful old favourite: the mind map. Mind maps are a powerful outlining technique that appeases the left brain's linear organisational fetish whilst satisfying the right brain's spatial, relational desires.

Mind maps are structured outlines in which you start with a key concept in the middle and add information around it forming a web. You can add extra relations between items, and freely use colour, illustration, size and position to highlight extra information.

I often produce mind maps for talks and articles I'm writing. Being an unashamed sad geek, I tend to produce these electronically (I used FreeMind which works on Windows, Mac, and Linux). Then I can keep them under source control and version them alongside my articles.

However, many people claim that you will miss the full benefit of the mind mapping technique by doing this. The more visceral, physical act of creating a hand-written version helps you explore and retain information. By laying out the relations yourself rather than relying on a machine to typeset the “document” for you, you consider inter-relations and build a tangible picture in your mind that will aid later recall.

Next time you're learning, why not try to record knowledge in a mind maps you go? When investigating a learning route and working out what you need to know, record your findings in a mind map.

Use mind maps to catalogue information. They are a proven, powerful tool.

A UITableView with an "empty" view

2010-09-30T00:48:00.001-07:00

Most every iOS application that presents a list of information is built around the UITableView class. It's a central part of the iPhone UI arsenal.

The really polished apps use this class particularly well. Look at the iPod application, for example. When there is nothing to display in a table view, the iPod app shows a placeholder view with a pretty icon and some text explaining why the list is empty:

It's these neat little UI touches that set a truly great application apart from a merely adequate one.

I want one of those

It's not rocket science to code such UI behaviour, but why do that when someone's already done it for you?

Mosey on over to the TableViewWithEmptyView Gitorious project and grab my code from there.

Most of that project's files comprise the requisite scaffolding to provide an example demonstrating the class. To use the class in your own project you need only copy over the PGTableViewWithEmptyView.h and PGTableViewWithEmptyView.m files.

Using the class is simple. It works exactly like a standard UITableView, but has one extra property emptyView. Assign this property the UIView you want displayed when there are no items in the table. The rest happens automatically for you.

The empty view fades in and out smoothly for added UI chintz.

To make things even easier, you can wire all this up in your XIB file, so your code need never mention the PGTableViewWithEmptyView class itself. Now that's magic.

I'd be grateful to hear from you if you use this class. Please also feel free to send me any suggestions, improvements, or bug reports.

Building a Boost framework for iOS (iPhone, iPad, etc)

2010-09-29T08:23:00.000-07:00

Several Boost versions have ticked past since I last posted about building a Boost framework for use with the iPhone. Each version of Boost requires subtly different build steps, and each version better supports building iPhone versions out of the box.

The good news: Boost 1.44.0 builds for iPhone a lot more easily than previous versions.

The bad news: making a framework is still not easy.

But first, why?

First, let's answer the obvious question: Why would you want to bother building a framework at all?

Quite simply: to make your life easier.

Using the native Boost build, you (may) need to link against a number of different Boost libraries in your application. And then you need to do a clever dance to ensure you link against either the i386 (simulator) or armv6/armv7 (iPhone devices) versions, depending on your build configuration.

That is tedious and annoying, and not the way it should be. Other Apple "libraries" are provided as a "framework" which you just need to mention once in Xcode, and then the build system works out how to link to the correct version and how to find the right headers.

So, if we can turn Boost into a framework life would be so much easier.

And that's what I have done.

Pete: Doing all the hard work to save literally... some... people all the hassle.

Executive summary

Now, you can do it too.

Just run the script you'll find in Gitorious here: http://gitorious.org/boostoniphone/boostoniphone

Download yourself boost_1_44_0.tbz into the same directory, run the script. Make a cuppa. Make another cuppa. And then admire your new shiney Boost framework.

Use it like any other framework. Draggy droppy. Happy happy.

What changed?

For the hardcore faithful who care about htese things, here's what's changed since my last script version:

Boost now builds for iOS far more easily (I think this changed for the better in 1.43.0). Now, you just need to write some gibberish in a user-config.jam and run a boostrap script. That is a darned site easier than it used to be.

To make it build for the simulator, you still need to invent some missing header files.

But the biggest hassle in this version was creating the final universal library file. Since the ARM builds themselves are now fat archives (including an armv6 and armv7 version of each .o file) I needed to work out how to make a functional uber-lib file. Because Apple's binutils are not useful GNU ones, their ar is braindead. The only way to make a correctly functioning library (that I could find) was to un-lipo the fat ARM binaries, un-ar each archive, link all the original .os into an uber library, than lipo up each of those. Does that sound painful? Yes. It hurt.

Learning: A cunning plan...

2010-09-27T05:41:00.000-07:00

In the common work scenario you start from ground zero and need to get up to speed with something in super-fast time. You need to pick up a new codebase, a new set of technologies, and a new problem domain. And be effective and productive almost immediately.

This is rarely possible. But you can be effective fairly rapidly as long as you recognise that you are starting out at the novice Dreyfus level (remember our look at the Dreyfus Model of Skills Acquisition?). In order to be effective at this point you must find a good set of rules to follow, since novices rely on rules to get work done.

But you want to progress beyond novice level, don't you?

In order to learn effectively you need to put in place a considered learning plan. Now, if I wanted to get from my home in Cambridge to visit a friend in Inverness, I wouldn’t just jump in the car and set off. I’d need to plan a route first. I wouldn’t even set up my satnav and follow its instructions. Should I really trust a device to know best?Does it know how I prefer to travel, any particularly busy roads at this time of year, which roads the authorities have decided to perform military assaults on today, etc? Similarly, does a teacher know better about how to get me from here to knowledge?

So I'd have to carefully plan a route first. Maybe getting in the car isn’t actually the best way to get to Inverness – perhaps I should instead fly there, and hire a car at the other end.

Put in place a deliberate learning plan.

So how might we apply this practically to our learning? Start by recognising exactly what you do know right now. Determine what you need to know. Weigh up the possible routes to get there: books, courses, web research, podcasts, etc.

Then determine two or three waypoints along the way you can purposefully aim for. Don't aim too far into the future, as once you have learnt more you may need to re-plan your learning route. Work out how to learn enough to get to those first waypoints. Work out exactly how you'll know when you've got there. (Consider this Test Driven Learning – work out some tests (katas, specific tasks, etc) that will prove you know something. You can use these same tests in the future to check for regressions in your learning). Then once you have a specific plan in place, begin learning.

Planning and executing a learning journey will make your work more focussed and directed. It may prevent you from wasting time by browsing for far too general information on the web, or reading all of a book when only two chapters in the middle are relevant.

Learning: Some How-Tos

2010-09-17T05:06:00.000-07:00

Continuing my blog series on software developers learning, I'm going to look at some of the tools available to help us learn most effectively.

Using tools

So what tools are available? When I ask at conferences what the best learning tool is, without fail someone immediately says "The Brain". However, that is not the right answer.

As strange as it sounds, the most potent and powerful tool we can employ is the entire human body. A human being is a large interconnected system, the brain is important, it's our CPU, but it's connected and influenced heavily by the rest of our fleshy substance.

We'll see how the whole body is important and can be exploited to help us learn more effectively.

The little grey cells

But let's start by focussing on the brain. Sadly, we’re not really ever given a user’s manual for the brain. (And even if we were, most men wouldn’t read it anyway...)

Firstly, we must keep this thing well prepared mechanically. Use the correct fuel: enjoy a healthy diet and make sure you keep well hydrated. It is said that the best brain foods are protein-rich foods such as meat, fish and cheese; these are good sources of amino acids. Also ensure you give yourself a good supply of the appropriate vitamins and minerals (vitamin B, sodium, potassium, and omega-3 are all said to be important for brain function). To keep your brain working at it's top condition (and let's be clear – to be an effective developer you really should consider how to keep your brain working as well as you can) you should pay attention to this kind of thing.

Other very obvious basic brain mechanics are to get plenty of sleep and avoid as much stress as possible to enable you to be less distracted and better able to think. It sounds glib advice, but how often do you consider how continual stress or burning the candle at both ends affects your effectiveness?

Using all of the brain

In a previous blog entry we investigated the left/right brain modes. Most developers lean towards left-brain modes of thinking, so to maximise use of our potential brain power we need to learn to dial down the left side of our brain to give the right side a fighting chance. Otherwise we'll only exploit half of our potential learning power.

Do remember, though, that both modes of thought are essential. We really need to work out how to get both brain modes to work in concert. In order to think and learn effectively we must be able to bring both “sides” of our brain into use.

There are some very basic documented ways to stimulate the right side of your brain. Cross-sensory feedback will stimulate parts of the brain that we don't normally exercise. Consider trying some of these actions whilst learning:

listening to music whilst you work,
doodling whilst you think (yes I am paying attention in your meeting, look at how many doodles I've made...),
fiddling with something (a pen or a paperclip, perhaps),
talking whilst you work (vocalising what you're doing or learning, it really does help you retain more knowledge),
making thought processes concrete rather than purely intellectual – like modelling things with building blocks or CRC cards,
meditative practices (many help you attain greater focus and cut out distractions)

These actions can help to invoke the right brain whilst performing activities that you might naturally focus more on left-brain operation. Each of these expand sensory input and serve to activate more neural pathways than normal.

Multiple input, maximal output

Different personality types learn in different ways. I can’t prescribe the best method of learning for everyone. However, try to learn a topic by absorbing information from many different information sources. In this modern connected world we're presented with many media forms:

The written: e.g. books, magazines, blogs.
The spoken: e.g. audio books, presentations, user groups, podcasts, courses
The visual: e.g. video podcasts, tv shows, performances

Some people will respond better to particular media. What works best for you? For the best results mix several of these sources. Use podcasts on a topic to reinforce what you're reading in a book. Attend a training course and read a book on the topic, too.

Use as many input types as possible to maximise your learning potential.

Take note

Whilst learning grab a notepad and capture information as you uncover it, rather than let it wash over you.

This serves two purposes. Firstly, it keeps you focussed and helps you to maintain concentration on the topic. It's a basic idea, but remarkably helpful. Secondly, even if you throw those notes away immediately afterwards, the cross-sensory stimulation will aid your recall of facts.

Takes notes as you learn. Even if you throw them away.

The practice of learning

Our key to learning is to pay attention to the practice of learning. Here I'm not using the noun practice. No, learning is an activity; unless you remain consciously and actively involved you will not learn effectively. Learning without practice, without applying the new knowledge, will not lead to deep understanding or long-term recall. We need to perform what is known as deliberate practice (Self-theories: Their role in motivation, personality and development (1999) Carol S Dweck. ISBN-10: 1841690244)

It is perfectly possible to perform pointless practice; to not pay full attention and waste your own time and effort. I'm reminded of some high-school recorder lessons that I was subjected to (ooh, many years ago now). This class was dumped into a room, each given a “learn the recorder” book, and expected to get on with it. It's true that that teaching method does leave a lot to be desired. And it's obvious that a group of kids that don't care at all about playing recorder will never learn to play the recorder. There was no motivation, a failing attitude.

But more importantly, a thirty minute lesson where no one is paying attention or trying to deliberately learn will never lead to learning. At the next lesson all the kids started back at page one again; they'd forgotten everything they'd read previously. There was no actual learning taking place in those lessons. A whole term saw very few people progress beyond the first half-hour of the teaching plan. The lessons were literally a load of hot air. And raucous screeching sounds.

Learning without doing is a fruitless task.

Ensure that your learning regimen involves mindful practice. Powerful techniques to consider here are Coding Katas and Coding Dojos. Katas were introduced into the development worlds by Dave Thomas of pragmatic programmer fame. A kata, like its martial arts synonym, is a small task or process that a student can repeat deliberately in order to learn a skill. Perhaps a simple coding exercise or refactoring task. Coding Dojos are meetings where programmers gather to perform katas together. Specific, deliberate learning meetings.

Dojos are becoming increasingly popular. Jon Jagger and Olve Maudal ran an excellent Dojo at this year's ACCU conference, for example. Follow the link for the software system they developed to run it.

If the brain is the CPU of our learning machine, then we should consider other uses of the machine that will aid learning. In the modern world, few computers are an island. Networking is an essential learning aid. The social context enhances our learning, and adds accountability (aiding attitude) and greater interactivity (aiding deliberate practice and cross-sensory feedback).

These are all invaluable social learning practices:

pair programming
study groups
mentoring and teaching (by teaching others you solidify your knowledge, you are forced to learn more yourself, and as you see a newbie begin to gain a wider picture you will realise flaws in your own knowledge, or see foundational knowledge in a fresh light that will be really beneficial)
writing articles (for magazines, for the web, for blogs)
discussion (perhaps in the pub)

Writing: Becoming a Better Programmer

2010-09-17T04:50:00.000-07:00

Issue 22.4 of ACCU's CVu magazine is out, containing my latest column. This month it's called People Power. It describes the importance of working with high quality, passionate programmers.

This issue, though, has seen a very significant change in my column.

For over ten years now I've been regularly writing a column entitled Professionalism in Programming. (I originally named it after the ACCU's "motto".) Times change, and although there's nothing wrong with the title per-se, it doesn't reflect clearly and unambiguously what I've been writing about.

So I've changed the column's name. I now call it Becoming a Better Programmer. I think this is clearer, snappier, and more useful. I hope you agree!

I've also modified the way I tackle topics somewhat. I hope you'll appreciate it.

I'd love to hear your comments and feedback.

The magazine should have landed on ACCU members' doormats already. The PDF version is available for download on the website. (And yes, for the cover I have been working through my "pink phase").

Learning: Some How-Tos

2010-08-11T02:44:00.000-07:00

Tell me, and I will forget. Show me, and I may remember. Involve me, and I will understand.
– Confucius

So far we've investigated why learning is important to software developers, and what we should be learning. We've looked at some learning models and uncovered many valuable facts about the way the brain stores, processes and retains information. But that's all been background. We've not yet actually put any wheels on our boat, and looked at the practical tools and processes that will help us to learn better.

Now it's time to rectify this omission.

Manage your knowledge portfolio

The pragmatic programmers describe a vivid and potent metaphor for learning – they talk about your knowledge portfolio. Consider your current working set of knowledge like a portfolio of investments.

This metaphor beautifully highlights how we should manage the information we have gathered, carefully investing to keep our portfolio current, and bringing in new investments to strengthen it. Consider which items you should retire from your portfolio, to make room for other things. Be aware of the risk/reward balance of the items in your portfolio.

Some things are common knowledge, but a safe investment to hold – they are low risk, easy to learn about, and guaranteed to be useful in the future. Other investments are riskier – they may not be mainstream technologies and practices, so studying them may not pay off in the future. But if they do become mainstream then you will be one of a smaller set of people experienced in that niche, and so able to exploit that knowledge more. These higher risk knowledge investments may pay much greater dividends in the future.

You need a good spread of risk and a healthy range of knowledge investments.

Purposefully manage your knowledge portfolio.

The angle of approach

Whenever I look at a topic in programming (and by now, I've written about quite a few in my columns and my book), the essence of success always seems to be determined by a single issue. And in the field of learning it seems as clear as ever: to be successful at learning you have to adopt the correct attitude. Your attitude towards learning will directly determine the quality of your learning.

We saw previously how mental state can affect performance, and the social psychologist Carol Dweck's research into the affect of mental attitude on ability to learn: that those who believed they could learn did so far more effectively than those who thought they couldn't. Self-belief is an incredibly important attitude.

We must take responsibility for learning – it is something we must do for ourselves, we cannot expect others to make us learn. We must adopt an attitude of continuous learning, never believing that we know it all or that we know enough – there must always be a hunger for new knowledge, a driving curiosity. This couples with humility; again recognising that we don't know everything and that we can learn from anyone and anything.

The most effective tool in learning is to care about what you're learning, and to be prepared to invest effort in order to learn. Dweck wrote about this in her book Self-Theories: Effort is one of the things that gives meaning to life. Effort means you care about something, that something is important to you and you are willing to work for it. If you are prepared to invest effort into learning about something, it not only shows that you value the topic, it means that you intend to and desire to learn.

Coming next: some practical mechanisms to improve your learning.

This is how we build software

2010-08-09T07:29:00.000-07:00

My tongue was planted firmly in my cheek when I drew this little masterpiece. (Click on the image for a larger version.)

It originally appeared in the June 2010 issue of ACCU's C Vu magazine as part of my regular software development column.

Learning: A review

2010-08-09T05:08:00.000-07:00

It's been a while since I wrote a blog about software developers learning. Previous postings have investigated learning models, the mechanics of the brain, how, why and what to learn, and more.

There's more to come, but let's just take a little refresher of some of the points I've raised so far:

Learning is a basic human skill. We can all do it. We do it all the time.
Our learning is too narrowly focused. Consider a wider sphere of reference. Draw inspiration from other fields.
Learning is hard work. It doesn't come for free. But you don't get a reward without an investment.
Learn to learn. That's why I'm writing this series! The most effective learning is done on purpose and planned to maximise effectiveness.
The left brain/right brain split We need to employ all of our available brainpower to make our learning maximally effective.
Personality type affects learning style Understand how you best learn and exploit that to your advantage.
Memory fades Unless you refresh your knowledge by using it, your memory of it will become unreliable.
Memory grows Constant stimulation is required to maintain growing mental capacity.
Mental state effects learning Cultivate a positive attitude towards learning. Otherwise you may as well not bother.
Learning models Certain models can help us classify levels of expertise and plan how to gain it.

Shortly I will describe at some very practical techniques to help improve our learning capabilities.

Eulagise: Adding a EULA to a DMG

2010-08-03T04:05:00.000-07:00

My code projects usually include a release script, a shell script that does something like this:

cleans the build tree,
rebuilds the project,
runs the unit tests (stopping if they fail), and
packages the project.

It's that last step I'm concerned with here. On Mac OS packaging usually involves building a DMG disk image. Automatically creating a DMG isn't entirely straightforward in a shell script. In fact, it's not straightforward at all. It took me a while to master the process; I bastardised and tweaked part of the Audium build process to perform this feat of engineering.

A recent requirement was to add a EULA to the DMG. If you're a Mac user then you've probably seen them once or twice. They look something like this (this isn't my one, for client confidentiality purposes).

The EULA appears when you double-click the DMG file, if you agree to the EULA then the disk image opens. If you don't agree, then, well you can work out the rest.

Something so simple, and so standard, must be easy to add. Right?

I hate to spoil a good story, but it's a bit tricky. Don't worry, the story has a happy ending.

It's not an easy task because:

The EULA has to be in a very particular format.
The EULA has to be added to the resource fork of the DMG.
You can only add resources (i.e. the EULA) to an unflattened DMG object, use the Rez utility to add resources, and re-flatten the DMG.
There are no clear and easy docs on the subject. (That I could find.)

Of course, being a script we want this to be automated, rather than a clicky-draggy process. There are programs that'll do clicky-draggy. We have to rule those out.

Ideally we want a script that takes a text file as input and the DMG to attach it to. Magic invisible elves inside the script do the rest.

I spent some time writing my own script, hitting a number of obstacles each time around, and then research pointed me towards the Seamonkey build system. Seamonkey has a script here that can do it. Hurrah! The script also creates the DMG in the first place, setting icons, volume name, etc. Sounds great, except that it does all the other stuff rather badly. Or at least, less well than the script I already created.

So I removed all the other cruft, and paired Seamonkey's script down into eulagise. Eulagise is a simple (ish) script to add a EULA to a pre-existing DMG. You use it like this:

./eulagise.pl --license MyEula.txt --target MyDiskImage.dmg

Simples.

You can get the script on gitorious here. I hope to neaten it up, and remove all the extraneous cruft shortly.

Writing: Software Development in 2010

2010-07-22T00:59:00.000-07:00

Issue 22.3 of ACCU's CVu magazine is out now. It contains the my latest Professionalism in Programming column, entitled Software Development in 2010.

In case you were wondering, my tongue was firmly planted in my cheek when I wrote it. Well, drew it, really. It was time for a little light relief after the previous installments on software developers learning.

There's also another of my book reviews printed in the issue. This time, I look at APress' iPhone User Interface Design Projects.

As ever, it's another interesting issue of CVu. Recommended reading.

Speaking: iPhone Development Software East June

2010-06-17T05:34:00.001-07:00

I will be speaking at Software East on the 24th June 2010 in Cambridge UK, on the subject of iPhone Development.

This is a talk I will be giving with Phil Nash and Lee Mallabone. It promises to be a fun, practical, and very interesting introduction to developing apps on the iPhone. It already appears to be a quite popular event judging by signup.

The event is free to attend (if you book in advance), and kicks off sometime after 6.30pm (I think the talk starts about 7pm IIRC, there's a buffet served beforehand).

Places are limited, so sign up now to guarantee yourself a place.

The event page is here. Go sign up now. What are you waiting for?

Book review: iPhone User Interface Design Projects

2010-06-14T07:43:00.000-07:00

Name: iPhone User Interface Design Projects
Author: Various
Publisher: APress
Price: $39.99
Pages: 252
Reviewed by: Pete Goodliffe
Book homepage: here
Verdict: OK

This is another book in APress' iPhone development series. Like all the later books in the series, it's produced in black and white, which is a shame given that the book focuses on user interfaces.

It is a collection of essays from ten different authors. Each chapter stands alone. Some of the authors are clearly programmers, and their descriptions of interface design come from a techie viewpoint. Others authors are domain experts or people who hired in programmers to get their job done. These discussions are far less technical in nature.

I've read quite a few of the APress iPhone books now, and although they are good, I'm starting to get tired of each chapter starting with a gushing "the iPhone is great" section before getting into the meat of the topic. I'd like to see a little heavier editorial control if this series continues. The chapters are personal in nature, and that is part of the charm of these books. However some of the lengthy intros add nothing of value to their chapters.

The material in this book is not as strong as others in this series. This opinion does reflect my bias as a coder rather than an UI designer, but experienced UI designers won't find much essential or new information in this book. In general, good iPhone UI design requires an understanding the native iPhone idioms and of how to create compelling touch-based interfaces for small screen sizes. Some chapters go a way towards describing this; but sadly the book is by no means a compelling or thorough discourse on the subject.

I will admit my favourite chapter was a very interesting one on the Font catalogue application FontShuffle. The UI material here was somewhat thin, but it was a really interesting insight into the world of typography.

If you're starting off on some iPhone UI design work, know nothing about the topic, and fancy a chatty, but brief, introduction to subject this book is OK. If you are a UI designer then you'll probably not find much of value here.

Desert Island Books

2010-06-03T04:12:00.000-07:00

I was asked to contribute to the Desert Island Books feature in the current issue of ACCU's C Vu Magazine by Paul Grenyer. This is a techie take on Radio 4's Desert Island Disks format. Programmers are asked to chose about five books, one of which must be a novel, and one or two albums.

It's an interesting choice to have to make, and shows a lot about you.

Here's what I wrote. The C Vu article begins with Paul's intro, which was pleasantly non-disparaging! Thanks, Paul!

While I was speaking aloud about ways to describe Pete Goodliffe, Jez Higgins suggested I use a recent comment from accu-general, ‘blond, balding, barefoot’. While accurate these aren’t a particularly nice way to describe Pete, although barefoot is at least accurate and not disparaging, like the other two.

When I think of Pete four things instantly spring to mind, his friendly personality, his bare feet, Cambridge, and curry. I have had many a curry and more than a few beers with Pete Goodliffe, both in Oxford and on occasion in Cambridge. When I think about Pete technically, his sound and solid technical knowledge and advice stand out. He has a lot of experience in software development and not only does he make it work for him to generate great software, he is always happy to help others and pass on the knowledge where he can (sorry Pete, I won’t mention the book).

I very narrowly missed out on working with Pete a few years ago, which was a shame because I would have learnt a lot.

So here I am, stuck on a desert island with nothing but the birds for company. Still, it could be worse; at least the conversation won’t get too geeky. I can’t help but wonder what kind of calamitous event catapulted me from my secure (if dull) office chair to this remote tropical location. Probably one of those stories that no one will ever believe back home, but it almost certainly involved a few whiskies, an ill-placed wager, and a temperamental particle physicist. Curse you CERN and Speyside!

At least I’ve got the decent weather. Let’s just hope global warming doesn’t shrink my new island home even further. Perhaps this stack of improbably placed books would provide me a small tower to sit on if the tide does indeed rise.

For my company on this forsaken isle, the gods of Fate and Calamity [PJG: I’ve never been described like that before!] have seen fit to bestow upon me four programming books, one novel, and two albums.

The computer books seem sadistic, cruel and somewhat ironic, as they haven't left me a computer [PJG: You didn’t ask!]. If they had, I’d ram it full if e-books, anyway. At least I’m good for toilet paper for a while. The CDs are just plain torture, as the swines didn’t leave me a CD player [PJG: See previous comment]. I’ll have to fashion one from a coconut tree and an albatross. Or just whistle.

So that means it’s only the novel that’s useful, then. Better pick a big one..

So what computer books should I chose? I could select four books I have always wanted to read, but never got round to buying. I could select four random books on a whim that might be interesting. But given that I won’t be able to fiddle with a computer any more (unless I find myself a convenient passing rescue party), I may as well select four classic books that have enthused me in days gone by. Books that will help me reminisce about the good old days when I had hair, when keys were rubbery, and when computers had rainbows on them.

And that is indeed my first choice. I’ll re-read First Steps with Your ZX Spectrum by Carolyn Hughes. I haven’t picked this book up in about 30 years, but it was my first ever programming book, and the thing that first gave me a passion for programming. I digested the entire book before I ever got near a computer. It has immense personal significance to me. And it also had pretty cartoon pictures of computers telling you what to do. I’ve not read a book like it since.

In a fit of nostalgia, I recently bought that same book on Amazon. For three pence. Seriously. Three pence. The postage was two orders of magnitude more than the book itself. That really does show how the value of knowledge decreases over time.

The next book providing this stranded programmer with a stroll down memory lane is Booch’s classic Object Oriented Analysis and Design With Applications. I may be developing a theme here, as I recall this book also had a number of interesting cartoons in it. But that’s not why I’m choosing it. I first encountered OOAD at university and it provided an incredibly clear, well reasoned and enjoyable overview of quality design techniques and the application of OO principles to software design. It was a genuinely great introduction to the philosophy of software design. It is also unusual, being one of the minority of hard-cover programming books

I’ve ever owned. So it might be useful for hitting wild animals with.

This book pre-dates the quadrilateral joys of UML, and I always loved Booch’s OO diagramming style. He represented classes by clouds; simply because they were easier to draw on the back of a napkin. The man’s a genius.

The Pragmatic Programmer by Andy Hunt and Dave Thomas will be my third book. It’s a wonderful clear, entertaining, and motivating discourse of the practice of programming from a personal and social standpoint. It’s the kind of book that I love to read, and one of the few books that you can read over and over again, because you actually want to.

It’s full of sage, refreshing advice.

However, it could have been vastly improved with a few carefully placed cartoons.

My last techie book is a hard call. Of the numerous books that have challenged and/or aided me in my career I’d struggle to chose just one. I could spend some serious

time digesting a hardcore C++ tome, like Bjarne’s TCPPPL, or any of Meyer’s or Sutter’s excellent C++ references. I could pick up a development process book, like Beck’s eXtreme Programming Explained (I remember that one being a very fresh read when I first opened it). Or I could drill into any of a number of design books, like the classic (and painfully obvious) Gang of Four tome or a number of later pattern languages. Perhaps something more recent would be a good companion like Michael Feathers’ legacy code book.

I’m stuck.

So I think I’ll select Sam’s Teach Yourself C++ in 24 Hours and be done with it. It’s bound to be wonderful nonsense, and is certain to produce an emotional response. Can’t be any worse than a Schildt book, can it? I think I’ll need the laughs.

Now to ship those books securely to my remote prison I’ll need to pack them carefully. I wonder if anyone will notice if I wrap them in a stack of ACCU magazines?

Presuming that I’m supplied with standard desert island accoutrements such as a copy of the Bible and the complete works of Shakespeare (perhaps with an accompanying infinite number of monkeys on an infinite number of typewriters – hopefully on their own island) then my choice of novel will be a collection of C.S. Lewis’ Chronicles of Narnia. I’ve always had a soft spot for these books (as with much of Lewis’ other writing). I love the Christian symbolism in them, and have started getting into them with my children, so these books would bring back a selection of old and new memories as I’m stranded here.

It just remains for me to make the choice of two albums. I’m an avid music lover with a wide and somewhat eclectic taste. However, should my soundtrack for a tropical adventure be something relaxing like a Sigur Ross album, something by Lamb, or Air’s chilled Moon Safari, or perhaps something more upbeat like a Kings of Leon or Killers album? My choice will instead be the awesome Flaming Lip’s masterwork Yoshimi Battles the Pink Robots, and Delirious’ Mezamorphis. Both of these are epic, dense, layered, meaningful and rewarding listens.

So that’s it. Spare a thought for me marooned here, and pray I don’t suffer from a coconut allergy or sun stroke.

Writing: Live to Love to Learn (Part 3)

2010-05-07T06:30:00.000-07:00

Issue 22.2 of ACCU's CVu magazine is rolling off the printers now. It contains the third (and final) part of my mini-series on software developers learning: Live to Love to Learn. This installment is the 61st Professionalism in Programming column I have written. Phew!

I've also contributed to Paul Grenyer's Desert Island Books column, describing five techie books and two CDs that I'd take with me to my very personal desert island prison. It was an interesting and challenging choice to make. Paul wrote some very kind words about me, too. Paul, I'm blushing!

This issue also contains a book review I wrote (of iPhone Advanced Projects by aPress), as well as a photo of me speaking at ACCU 2010. I'm going for maximum exposure, clearly.

When I sent this month's cover image to Steve Love, the editor, he said it looked like I'd spilt coffee all over it.

It's another great issue (despite all my contributions). If you're not an ACCU member but you're passionate about programming do consider joining ACCU now.

Learning: Learning Models

2010-04-30T03:54:00.000-07:00

Continuing my series on software developers learning, here is a brief look at a couple of very interesting and useful learning models. (See also learning styles on Wikipedia for other interesting material).

There are a wide variety of interesting and applicable models, and so this investigation is naturally not an exhaustive survey of what might be applicable to us, as software developers.

This material has been adapted and expanded from my March 2010 CVu Professionalism in programming magazine column.

Learning models

There are a number of very illuminating models of learning that have been constructed by educational psychologists. The Dreyfus Model of Skill Acquisition is a particularly interesting example, postulated by brothers Stuart and Hubert Dreyfus in 1980 whilst they were working on artificial computer intelligence [A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition. Stuart E. Dreyfus; Hubert L. Dreyfus. Storming Media. (Available from: http://handle.dtic.mil/100.2/ADA084551)]. After examining highly skilled practitioners in fields such as airline pilots and chess grand-masters, they identified five specific levels of understanding:

Novice A complete newbie. Novices want to get results fast, but have no experience to guide them in doing do. They look for rules they can follow by rote, and have no judgement to tell whether those rules are good or bad. Given good rules (or luck finding suitable resources on Google), novices can get quite far. Novices have no knowledge of a topic (yet).
Advanced beginner At this level, some experience that has lead to learning; you can break free from rules a little and try tasks on your own. But perception is still limited, and you'll get stuck when things go wrong. At this level there is a better understanding of where to get answers (you know the best API references, for example) but you are still not at a level where you can comprehend the bigger picture. The beginner can't focus out irrelevant details, as far as they're concerned everything and anything could be important to the problem at hand. Beginners rapidly gain explicit knowledge – the kind of factual knowledge than can be easily written down and articulated.
Competent This stage sees you with a mental model of the problem domain; you've mapped the knowledge base, and have begun to associate parts and understand the relative importance of different aspects. This big picture view allows you to approach unknown problems, and plan methodical routes into those problems rather than diving in and hoping rules will get you to a solution. This is a good place to be.
Proficient people move beyond competency. They have a much better understanding of the big picture, and are frustrated with the simplifications that the novice needed. They can correct previous errors and reflect on their experiences to work better in the future. At this point you can also learn from other's experiences and assimilate them into your body of understanding. Proficient people can interpret maxims (as opposed to simplistic rules) and apply them to a problem (e.g. they know how and when to apply design patterns). Now it is easy to identify and focus only on the issues that really matter, confidently ignoring irrelevant details. Here we see the person has gained significant tacit knowledge – knowledge that's hard to transfer by exposition, that is only gained by experience and deep understanding.
Expert This is the pinnacle of the learning tree. There are very few experts. They are authorities on a subject; they know it completely, and can use this skill interlinked with other skills. They can teach others (although they probably teach competents better than novices as there is less of a disconnect). Experts have intuition, so rather than needing rules they naturally see an answer, even if they can't articulate why it's the best solution.

Why is the Dreyfus Model interesting? It's a revealing framework to understand where you currently stand in the mastery of a topic, and help determine where you need to get to. Do you need to be an expert? Most people are competent and this is satisfactory (indeed, a team of experts would be far too top-heavy, and probably dysfunctional).

It also illustrates how you should expect to be solving problems at each stage of your learning. Are you looking for simple rules to apply, hungrily gathering maxims to draw experience from, or intuitively sensing answers? How much of a “big picture” view do you have of the topic?

The Dreyfus model is also a very useful aid for teamwork. If you know where a colleague sits on the notice-expert spectrum you can better tailor your interaction with them. It will help you learn how to work with other people – should you give them some simple rules, explain some maxims, or leave them to weave new information into their broader understanding.

Note than the Dreyfus model applies per skill. You may be an expert in a particular topic, and a complete notice in another. This is natural. And should also be a source of humility – even if you know all there is to know about Behaviour Driven Design, you may no nothing about the Joe Bloggs Test Framework. It should excite you that there is something more to learn that may enhance your expertise in BDD, whilst keeping you humble that you aren't an infallible expert in every subject! No one likes a know-it-all.

Shu-Ha-Ri is another interesting model of learning that originates in Japanese Martial Arts. It is a set of three terms describing the stages a student goes through to to achieve mastery in their discipline, roughly translating to Learn, Detach, Transcend. In the Shu phase, the student studies under one teacher; he does not understand enough to mix concepts from different streams, but aims to imitate the teacher precisely. He must build up experience in the field, absorbing the teacher's explicit and tacit knowledge. Once he has a full understanding of the techniques, the student reflects on them in the Ha phase. The knowledge he has learned will not change, but he can interpret, reflect and explore the deeper meaning. Finally, the student progresses to Ri, where he moves beyond studentship; he has original thoughts, and becomes a master himself. He now has the skills and experience to innovate.

Heed this model. Don't try to transcend and innovate until you have completed the Shu phase of your learning (remember to be aware of unconscious incompetence) and have completed the Ha phase of understanding the knowledge.

In my recent conference presentations on this subject, I've also looked at the fashionable "craftsman" model, and seen how the historic guilds system of the pre-industrial revolution applies (and doesn't apply) to our learning. It's an interesting model that bears comparison to shu-ha-ri.

Software Developers Learning: Slides available

2010-04-26T04:02:00.001-07:00

The slides from my ACCU 2010 presentation on software developers learning, poetically entitled Stood at the bottom of a mountain looking up are now available.

This was a very popular presentation, and the room was packed, so thanks to all those who came along and squeezed in. I've had a lot of great feedback, so I'm glad that the talk was useful. As promised, there are a lot of references at the end of the slides that you can follow for more information.

The slides are available on SlideShare here.

If you'd like me to give this talk at your site, user group or conference, then please get in touch.

iPhone Development slides available

2010-04-26T02:57:00.000-07:00

The slides from my ACCU 2010 presentation on iPhone development are now available, for those who wanted a copy.

You can view them on SlideShare here.

If you'd like me to give this talk at your site, user group or conference, then please get in touch.

Learning: Understanding the brain

2010-04-11T14:45:00.000-07:00

Psychologists, biologists, and other similar evil geniuses have studied the human brain for years, and have formulated many models of brain behaviour and models of learning. There is an overwhelming quantify of research on the subject (some quite contradictory).

Understanding (at least at a basic level) how the brain works, and some of its characteristics will help us, as software developers, work out how to learn most effectively. Even a rough understanding of some basic principles will help us unlock the potential learning and processing capabilities of our grey matter.

The left brain/right brain split. We hear a lot about the “left-brain” and the “right-brain”. These terms have entered pop culture, and you are as likely to hear them discussed by artists and CEOs as by psychologists. It comes from research (pioneered in the 1970s by Roger W Sperry who coined the left/right brain terminology) discovering that our mental activity is split between the two hemispheres of the brain; either side controlling a different mode of thinking (Lateral specialization in the surgically separated hemispheres. R.W. Sperry. In Neurosciences Third Study Program. F. Schmitt and F. Worden (Eds.), Cambridge: MIT Press 3:5-19 (1974).).

The left hemisphere tends to govern analytic and logical activities (language, symbolic representation, rational deduction, the linear thought process) whilst the right hemisphere performs non-linear processes (characterised as non-rational, spatial, holistic, and identifying spatial relationships).

The common view is that people rely more, or tend towards using, one side of their brain rather than other. Artistic, creative types favour their right brain; academics and office-workers favour the left. Apart from reinforcing a social stereotype, this is not strictly accurate since the split of brain activity is not pure laterally biased. Several psychologists have since tried to come up with other terms, but popular culture has latched on to left- and right- and we're stuck with them.

Both parts of our brain and both modes of thought are essential. In order to think and learn effectively we must be able to bring both “sides” of our brain into use. Since programmers tend to lean towards the left-brain mode of operation, we must learn to introduce more right-brain thinking into our regimen; this requires us to find ways to “dial down” our left brain activity to give the other side a fighting chance.

I'll describe some ways to do this in later postings. There's a lot more that could be said on this subject; it is a huge topic, and well worth investigating more if you are interested.

Personality type affects learning style If you favour the right-brain mode of thinking you will learn best when presented with patterns and a holistic view of a subject, rather than a serial stream of information. You'll prefer to make associations and understand overarching themes. If you favour the left-brain you want a linear rational presentation of the topic. You'll prefer to assimilate facts than to have a grand story told you.

Clearly your brain wiring has a radical effect on the most effective style of learning for you.

There are many models of personality type, perhaps the most famous being the Myers-Briggs Type Indicator (MBTI). MBTI classifies your personality along four axes. Your personality type will effect how you associate knowledge, and how you best learn. One MBTI axis is Introvert-Extrovert. Introverts would rather learn on their own – they need private mental space to work things through. Extroverts learn well in groups where they can discuss and feed off the ideas of others. Another interesting axis is Sensing-Intuition. The Sensing personality is the classic left-brainer who emphasises facts and details. They must complete one task before moving on. Intuitive people are right-brainers who use their imagination more. They can move on without completing a task or before they understand everything about a subject.

Understanding your particular personality type (there are many MBTI tests available on the web, for example) will reveal specific ways to make your learning routine maximally effective.

Understand how you learn best.

Memory fades. There was a time when psychologists believed that a memory, once made, was permanent. However this is not the case: a certain enzyme (PKMzeta) is required to keep synaptic connections valid. Lose the enzyme, you lose the memory! (See this for more info).

Our memory is also fallible in other, less chemical, ways. The brain isn't perfect. You'll notice that old memories can change and distort in your mind. (So it's probably not true that things aren't as good as they used to be.) Memories and opinions can easily warp as we recollect them, to fit our current preferences or preconceived notions. We can very easily implant our own false memories (unconsciously) or become subject to false suggestion from others.

In order to keep your memory active, it must be refreshed – constantly read and exercised. If you don't need and employ a skill then you will use it.

Use your knowledge. Or you'll lose it.

Memory grows. It was originally thought that mental capacity decreased over time; that humans start off with a fixed number of brain cells and over the course of a lifetime this number decreases (due to the ageing process, damage caused by trauma, or other abuse – like excessive alcohol intake).

This was determined by scientists studying animals in laboratory cages; they saw no sign of neurogenesis – the growth of brain cells. But this was simply because a brain devoid of stimulus need make no new connections. The test subjects' brains didn't expand because there was no need to; life in a cage stunts brain growth. That's a pretty damning inditement of modern cubicle working!

In the early 1990s psychologist Elizabeth Gould discovered that in suitable conditions (an environment with stimulation and opportunities to interact and learn) the brain is perfectly capable of growing neurons and making new connections (Neurogenesis in the Neocortex of Adult Primates. Elizabeth Gould, Alison J. Reeves, Michael S. A. Graziano, Charles G. Gross. In: Science 15 October 1999:Vol. 286. no. 5439, pp. 548 – 52.). Other subsequent studies have drawn links between exercise and increased brain growth.

So that's good news – you have a practically limitless ability to expand your mind. And the scientists have proved that you need stimulation do to so! Break out of your cubicle, and feel free to drink a beer!

Mental state effects learning. Factors such as stress and a lack of sleep will clearly contribute to an inability to concentrate, and so will degrade your ability to learn. Your mental attitude also dictates how well you will learn. Psychologist Carol Dweck's research (Mindset: The New Psychology of Success. Carol S Dweck. Ballantine Books. ISBN: 0345472322) shows that students who believed that they couldn't increase their knowledge were not able to do so. Those who believed they could increase their mental capability were easily able to.

Believe in your ability to learn.

People who enjoy learning naturally learn more. People who want to learn, learn more. Is this the power of mind over matter? Perhaps it is; and it's something we need to exploit. I've long argued that our attitude effects the quality of our work. This is the central theme of my book Code Craft (Code Craft: The Practice of Writing Excellent Code. Pete Goodliffe. No Starch Press. ISBN: 1593271190).

I will be speaking more on this topic at the ACCU conference next week.

Speaking: QCon 2010 learning slides now available

2010-03-30T01:15:00.001-07:00

A belated thanks to everyone who came to my QCon London 2010 talk on software developers' learning. I've had some great feedback, which just goes to show that a hangover doesn't do much to dent my presentation skills! I'm glad people found the talk useful; I know it's an interesting topic, and one that programmers don't think hard about too often.

For those who wanted the slides, they are now available online here. They've got a lot of extra reference information that I didn't have time to pack into the talk. Don't eat them all at once.

The conference itself was full of very interesting stuff and, as ever, a lot of the most interesting learning happens outside of the talks themselves. The organisers did a great job.

I will be presenting an extended version of this talk (and speaking on other topics too) at the ACCU Conference in Oxford this April.

Writing: Live To Love To Learn

2010-03-09T02:30:00.000-08:00

The latest issue of ACCU's CVu Magazine is out now. It contains the second part of my series on software developers learning: Live To Love To Learn.

This is something I've been looking into a lot recently; I've spent many hours researching, writing and speaking on the subject. Learning is a large topic (seriously vast), and the more I learn about it, the more I realise I don't know!

It's quite a lengthy article this month; looking at some basic learning facts, some interesting models of learning, and investigations into how the brain works in order to gain and retain knowledge. I hope you find it interesting and useful.

This is the 60th column in my Professionalism in Programming series. That means I've been writing these articles for 10 years now. That is a frightening thought!

I should have learnt how to quit by now...

Speaking: QCon London 2010 (this week)

2010-03-08T16:16:00.000-08:00

I am speaking at QCon in London this week. The official details for my session are here.

My talk is entitled: The Craftsman Learns (or Learning the Craft) and it's going to be both practical and a great deal of fun. We'll investigate why software developers learn, what software developers (should) learn, and some keys that will help us to learn more effectively.

Useful stuff for any programmer who cares about their craft.

Book: 97 Things Every Programmer Should Know

2010-03-05T02:20:00.000-08:00

The latest book in O'Reilly's 97 Things series is out now: 97 Things Every Programmer should know. I have three items in this book, and have just received my paper copy (photographic proof attached for the non-believers!).

Despite the somewhat underwhelming cover (it's now the series ident, apparently), it's actually a very well produced book. Thanks to everyone involved.

Details from the publisher's website here.

My contributions are:

Chapter 26 Don't Ignore That Error!
Chapter 39 Improve Code by Removing It
Chapter 96 You Gotta Care About the Code

Book review: iPhone Advanced Projects

2010-02-22T02:16:00.000-08:00

Name: iPhone Advanced Projects
Author: Various
Publisher: APress
Price: $39.99
Pages: 374
Reviewed by: Pete Goodliffe
Verdict: OK
Book homepage: here

This is another book in the APress iPhone "projects" series. It follows the form of its predecessors; it is a series of 11 essays by different authors on a particular topic which that they have some familiarity (I'm not sure I can always say "expertise") in.

Production

First, the book production bears discussion. Unlike previous books, this one is printed in plain black and white rather than the accustomed luxurious full-colour. The book still costs the same amount, so this appears to be a ploy by publisher to increase profit rather than a way to position book at lower price point to gain more readers.

Unfortunately, the book suffers because of this. Not only is it less visually appealing, it is less practical and easy to follow. Some visual modification should have been applied to the format to make it work in B&W. Without colour, the sans-serif body text is harder to read and is less distinct from headings, subtitles, and illustrations.

In particular, many screen shots suffer. Often an author refers to details that are completely lost in a sea of black ink. These images should have been edited to improve contrast, or the text reworked to explain the point without an illustration.

Editing

On the whole this book has been well edited and proofed, probably better than some of the other books in the series. There are only a few typos. It hangs together as well as the other books, which is fine - it's a series of unconnected essays on different topics.

As another "grab bag" book, you'll either want to make a purchase if you care about a specific topic included (see below), or you just want a general overview of a number of topics.

Topics

The book covers the expected iPhone topics: Graphics/UI (creating particle systems, OpenGL ES reflections, and making responsive UIs), networking (writing an app backend server to integrate with iphone app, using push notifications, yet another socket-based UDP example, and sending an email from your app), audio, debugging, and data handling (both in SQLite, and Core Data).

Most chapters are sufficiently detailed. The audio chapter, I felt, was a chatty overview, but didn't provide as good a grounding as just reading the iPhone audio docs.

As ever, the detail in each chapter cannot replace the iPhone SDK docs which are complete and detailed. However, there are often little information gems that will help your development and save you a little time working with that technology.

Conclusion

If you're new to iPhone programming, this might be an interesting book. Also consider the other Apress titles in the series, and chose the book with the topics you are most interested in.

Speaking: Sunday Morning Service, Old Windsor

2010-02-11T02:00:00.000-08:00

One of my more baroque speaking engagements of late: this Sunday I will be preaching in the morning 9.30 service at Old Windsor in Berkshire.

The service theme is the transfiguration. My talk will therefore probably involve feet in mouths.

Developers Learning: The Facts of Life

2010-02-11T01:53:00.000-08:00

Learning is like rowing upstream: not to advance is to drop back.

– Chinese proverb

Continuing my exploration of the ways we (software developers) can improve our learning, here are a few facts that provide some useful context. None of them are at all specific to the software development but, as ever, I'm writing from the perspective of the software developer, and addressing the development world.

Learning is a basic human skill.

We all do it. We just do it in different amounts. Small children are constantly learning and amassing new skills. Language, cause-and-effect, and social skills are picked up rapidly from birth. As are basic physiological capabilities like eating, walking, and continence. (Although continence might also be considered a social skill of sorts.)

When it arrives freshly formatted, the human brain rapidly absorbs information and develops skills across a wide range of experiences. It's a remarkable device, both intricate and powerful, and we need to learn how to best use it. Unfortunately, it doesn't come with a User's Manual. (Even if it did, most men wouldn't read it, anyway).

Our learning is often too narrowly focused.

Infants absorb information in many disciplines rapidly. And simultaneously. They don't know that they're simply not supposed to. But all too soon, our training starts; we're introduced to the thought police.

Or, rather, at school we hop on board the academic train and our incredible generalised learning capability is slowly frittered away. At primary school we are taught a range of topics. At secondary school these topics are formalised and compartmentalised somewhat. As we progress through the academic system we cut out certain topics and concentrate on those that suit us best (because of interest or aptitude). At (UK) GCSE level, we narrow the focus to about 8 subjects. We progress to A-Level and narrow that focus to 3 or 4 subjects. Then we progress to university level where we focus on a single subject.

This increasing focus in learning is useful in that it allows us time to become highly proficient in one area, and to devote time to practice the specific skills required to master that subject. It also allows us to chose a single topic that excites and interests us: surely a prerequisite for effective learning.

But often such high specialisation is detrimental to your ability to learn in general. It ingrains a lack of curiosity for other disciplines or any appreciation of the wider human experience. However, it is when disciplines collide that we often see the the most exquisite insights (consider, for example, how Alexander's architectural work illuminated the field of software design [1]).

Learning is hard.

When an infant learns, the world is new and exciting; as they coast through it they just absorb stuff. After a certain point, the things you have to learn become less interesting. Adults force you to learn stuff. It involves effort. Effort which you could expend on other tasks, like playing with your friends, or your toys. Then you're given homework and learning starts to take over your precious “free time”. It feels like hard work. It is hard work.

Learning is hard.

That hard work will, though, be rewarded. But it's easy to resent learning as a tedious chore that stands between us and “fun” or “ability”. Many people's early school experience of learning still colours their adult life approach to learning, even if they don't realise it. How often have you balanced the reward of learning something against the effort involved? How often has the initial learning effort put you off learning something new? Are you now automatically programmed to avoid areas you know nothing about because it is uncomfortable to appear ignorant?

Have your past experiences coloured the way you approach learning?

We must learn how to learn.

Many people were spoon-fed information in school, and told not to criticise. This instils a bad attitude to learning; where it is something someone gives you, or that a teacher does to you. Learning is actually a personal process that you have to take individual responsibility for.

Do you take personal responsibility for your own learning?

Don't blithely accept what you're told. Keep your brain engaged. It's dangerously easy to fall into the trap of believing what you're reading or being told is the gospel truth, rather than something that should be evaluated.

How many people read things on the internet and presume that they are true? Wikipedia has a genuine air of authority, yet contains many remarkable mis-truths. Some of the tubes of the internet are rather grimy.
How many people read things in their newspaper and unquestioningly presume that they are correct? True, there are lunatics out there on the web, but paid journalists wouldn't make things up, would they? Wrong: there are plenty of lunatics in the media, too. If you believed everything you read in the newspaper then you wouldn't eat or drink anything for fear that it would given you an incurable disease.
If it's in a textbook, written by an academic, peer reviewed, and recommended by a prestigious university then it must be correct. But consider who paid to write the book, or who funded the research. What are their motives driven by? Many things presented as fact in the most prestigious journals are, in fact, opinion and conjecture backed up by slim arguments. For example, 70% of everything I've written up to this point was made up. Including that statistic.

Be aware that you can learn the wrong thing and believe it's the right thing. This can be at best embarrassing, and at worst dangerous. This is illustrated by the Four Stages of Competence (a classification posited in the by 1940s by psychologist Abraham Maslow). You may have:

Conscious incompetence. You don't know something. But you know that you're ignorant. This is a relatively safe position to be in. You probably don't care – it's not something you need to know. Or you know that you're ignorant and it is a source of frustration.
Conscious competence. This is also a good state to be in. You know something. And you know that you know it. To use this skill you have to make a conscious effort, and concentrate.
Unconscious competence. This is when your knowledge of a topic is so great that it has become second nature. You are no longer aware that you are using your expertise. Most adults, for example, can consider walking and balance as an unconscious competence – we just do it without a second thought.
Unconscious incompetence. This is the dangerous place to be. You don't know that you don't know something. You are ignorant of your ignorance. Indeed, it is very possible that you think you understand the subject but don't appreciate how very wrong you are. It is a blind spot in your knowledge.

So be very careful when claiming competence in any subject, let alone any level of expertise.

Speaking: QCon London 2010

2010-02-03T03:58:00.000-08:00

I will be speaking at QCon 2010 in London this March. Details of my session are listed here.

I'm excited to be talking in the "Software Craftsmanship" track (something I care about - my book is called Code Craft, after all...) My talk title is The Craftsman Learns (or Learning the Craft). It's an investigation of how, why, and when a software craftsman should learn.

Here's a little more info:

Software developers should be perennial students.

Exceptional programmers aren't the ones who know it all. No one possibly can, no matter what the self-professed gurus would have you believe. Truly great software developers know their limits, and constantly strive to push them, to learn new skills and amass a catalogue of new techniques that can be applied to their craft.

As a programmer you constantly face fresh challenges; you will frequently be forced to learn a new language, a new technology, or a new project. And you will have to know it all by... yesterday. It's both our responsibility and, hopefully, our pleasure.

I this talk we'll investigate:
how the software craftsman approaches learningwhat information to learn, and what to ignore
how to learn new things effectively
techniques for quickly picking up new technology
healthy attitudes to towards learning
the craftsman's curiosity, and how to assuage it

Keywords: Craftsman, Learning, Soft-skills, Software practice

Target audience:
Software developers who care about their craft and want to improve their coding skills.
No assumption will be made about specific technical knowledge.

Live to Love to Learn

2010-02-03T03:54:00.000-08:00

Learning without thought is labor lost; thought without learning is perilous.

– Confucius

These are a few thoughts on the importance of learning. It's a theme I've been dwelling on lately, as I've been rapidly learning a lot of new technologies, skills, and languages. I am writing on the topic in my Professionalism in Programming magazine column, and will be talking on the subject at a couple of conferences this year.

This blog entry is addressed to software developers, as I am a software developer. However I believe it's applicability extends beyond software development...

Learning to learn

Programming is a creative, intuitive process. I, like many other programmers, like to think of it as an artistic pursuit; one of working a medium to produce something of utility and beauty. But all too often the commercial reality of coding is something more akin to being placed in a meat grinder, until every last ounce of coding prowess and motivation has been sucked from your soul.

Nonetheless, programming is an exciting and dynamic field to work in. One of the main reasons is that there is always something new to learn. Rarely are programmers forced to run around in circles performing the same repeated task for years and years, only discovering new ways to develop RSI and failing eyesight. We continually face the unknown: new problems, new situations, new teams, new technologies, or some combination of these. True, some programming jobs face more excitement than others, more of the unknown than others, and garner more techie thrills. But if you're going to be stuck in an office sat behind a desk, you may as well keep your mind occupied.

We are continually challenged to learn, to increase our skills and our capabilities. If you feel like you're stagnating in your career, one of the most practical steps you can take to get out of the rut is to take the effort to learn something new. On purpose.

Now, some people are naturally better at absorbing new information and “getting up to speed” more rapidly than others. They are better at taking on new concepts and relating new concepts to gather a greater understanding. That's natural. But it's something we can all improve at. You need to take charge of your learning.

Check point

Ask yourself now whether learning is something that you think about consciously as a programmer? Is it something you consider as one of your programming skills? Do you actively try to learn things? Do you willingly put yourself into areas of the unknown? Or do you try to stick to what you know best, looking for an easy life?

Are you motivated as a programmer to find out new information and improve yourself? Do you relish learning? Or is it something of an inconvenience?

Do you want to improve as a programmer? I suspect that in this regard I'm preaching to the converted in this article. An ACCU member reading CVu clearly wants to widen their knowledge. Well done, give yourself a pat on the back! The simple fact is this: if you want to improve as a programmer, you need to be a skilled and seasoned learner. And you need to learn to enjoy it.

So lets think about the what, why and how...

Why learn?

Sometimes you have no choice but to learn; you are faced with a new task and you know nothing about the technology or the problem domain. You've got to get up to speed, and fast. Often the killer problem is that you have no time to do this in, and have to make a work estimate or deliver the first bit of functionality before you'd even have time to gather the vaguest overview of the topic.

The programmer's lot is not a happy one.

But even when you're coasting – working on reserve knowledge, with no need for new information – it's important to keep the grey cells ticking over and absorb new knowledge. One important reason is to simply cultivate a good learning habit; to maintain your ability to absorb information. Continually learning also helps to shape your programming attitude; to prevent you from believing that you're an expert! No one likes a know-it-all, after all.

There are plenty of other good reasons to develop yourself by learning. Your motivation might be to keep yourself fresh, to sharpen your existing skills, or simply to satisfy your natural curiosity. Or the reason might be more mercenary: the strengthen your employability, or allow you to manoeuvre into a programming field you're more interested in.

If you don't keep up a habit of continual learning you will go stale. You'll stagnate. The technological world will pass you by.

This demonstrates a simple learning maxim: Learning. You've either got to, or you ought to.

What to learn?

There's a whole world of things you could attempt to pick up. So what should you look at? Donald Rumsfeld summed up this conundrum in a particularly apt way when he made an infamous White House press conference: As we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say, we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know.

So what do you pick? Clearly not something you know you know (although learning a topic more deeply, or attempting to consolidate your knowledge on a topic is a valuable task). Instead should you chose something that you know you don't know, or first learn about what you don't know in order to chose what to learn? That might make your brain bleed. Thanks a bunch, Rumsfeld.

Perhaps the list below will help. If you are learning for “fun and personal profit” rather than your job leading you to a specific topic, you might consider:

Learn a new technology. For programmers this is the obvious choice. We're fascinated by the different ways we can make electrons dance, and there's a wide field here to mine.

You might choose to find out about a new programming language; there is no shortage of new and interesting languages being developed, there are many widely-used languages that you could learn to gain employability-enhancing skills, and there are many interesting existing languages. Consider looking at a language that promotes a different paradigm to your current languages to learn new ways to approach and solve problems – perhaps a functional programming language like Haskell would be a good choice. In their classic 1999 book, the Programmatic Programmers recommended learning one new language every year [1]. It's good advice. You don't have to become an expert, but do get beyond “Hello, World!”

You could instead choose to learn a new library or application framework; perhaps an interesting low-level utility or a snazzy new high-level UI toolkit. After all, you can never have enough UI toolkits.

Or learn a new software tool. You should never underestimate the usefulness of learning new tools that will make your work more productive and/or more enjoyable. Learn how to use a new text editor, or IDE. Learn a new documentation tool or a test framework. Learn a new build system, an issue tracking system, a source control system (indulge yourself in the new distributed version control craze that all the cool kids are going on about), a new operating system, and so on.

Even if you are not going to use the new technology immediately in your “day job”, learning about it will almost certainly help you to use your existing technology in better ways, and will help you to evaluate new technologies when the need arises.

Learn new technical skills. You might want to learn how to more effectively read code, or write technical documentation. You could learn how to manage a software team and climb the greasy career ladder.
Learn how to work with people. Yes, this is tediously “touchy-feely” for most code monkeys. But it can be an incredibly interesting field, and very useful. You could look at sociology, or study some management texts. This kind of information will help you to become a much more capable team worker, and will enable you to lead teams into directions that you think they should go in, rather than suffer in silence. It will help you to understand how people are communicating to you, and how to communicate effectively with them. You'll discover how to understand your customer better, and filter their requirements.
Learn a new problem domain. Maybe you always wanted to write mathematical modelling software, or do audio DSP work. Without any experience or knowledge you'd be unlikely to fall into a job in a new sphere, so give yourself a head start and begin to learn about it. Then work out how to get practical, demonstrable experience.
Learn how to learn. Seriously! Perhaps you could invest your time into finding out some new learning techniques that will help you absorb knowledge more effectively. Do you find there's a constant barrage of information you need to tap in to, and it just seems to flow past you? Investigate ways to seek out, consume, and absorb knowledge. There's a whole lot more to this than I can cover in these C Vu articles, after all! Consider learning and practicing new skills such as mind mapping and speed reading.
Learn something completely different. Or, more interestingly, you may prefer to choose something completely left-field with no relevance to your day job, and no obvious software applicability. Learn a new foreign language, a musical instrument, a new branch of science, art or philosophy. Hey, even spirituality. Far from being a pointless waste of time, or a distracting personal hobby, doing this will open your world view wider. If you're willing to look for the interesting themes and techniques you will certainly find that it helps to inform the way you program.

Above all, pick something that interests you. Pick something that will benefit you (the act of learning in itself is a benefit, but choosing something because it will give you fresh usable skills, broadens your insight, or brings you pleasure is a good thing). You will be investing a significant amount of time, so invest wisely!

Writing: New article in CVu

2010-01-18T12:33:00.000-08:00

The January issue of ACCU's CVu magazine is hitting doormats around the world. It contains the latest in my Professionalism in Programming series - Live To Love To Learn. This article is the first in a mini-series investigating how we learn as software developers.

Writing: 97 Things Every Programmer Should Know

2010-01-07T08:17:00.000-08:00

The 97 Things Every Programmer Should Know book from O'Reilly, edited by Kevlin Henney has almost come to completion; it's due for publication next month.

They've just posted the list of contributions appearing in the book. I'm pleased to say that three of my five submissions are in the list. You'll be able to purchase a paper copy of the following entries:

You've Gotta Care about the Code (link)
Improve Code by Removing It (link)
Don't Ignore That Error! (link)