Uploading Mac App Store apps whose names contain a space

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)

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

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

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)

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

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!

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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.