On my last project, we decided to try out CoffeeScript. I was pleasantly surprised at how easy it was to get started with it and how nice it was to use, instead of JavaScript.

I’m a fan of object-oriented JavaScript code, but there are many different ways to structure the JavaScript (using the prototype, or constructing an object each time with private methods, to name a couple). I’ve seen several medium-to-large JavaScript codebases that use a range of techniques with no consistent pattern. CoffeeScript solves this problem by giving me a standard way to create new classes (which IMO is much easier to read and understand than JavaScript methods defined on the prototype). It’s performant (since the methods are defined on the prototype) and tries to produce easily-readable, JSLint-able code. (I had my first look at the JavaScript produced by ClojureScript last night, and it’s definitely much harder to navigate than the code produced by CoffeeScript).

Here are some tips to get started:

  1. The back-end was .NET and we were working in Visual Studio, so we used the free Web Workbench plugin to generate javascript files from our coffee files. It updates the files automatically at every save, which was really handy. Errors appear in the output window for Visual Studio.
  2. If you’re using the Node Package Manager, you can install CoffeeScript with that:
    npm install -g coffee-script
    You can then use the coffee command to compile coffeescript files:
    coffee -c
    This also works with wildcards:
    coffee -c src/*.coffee

I was pretty amazed how easy it was to integrate CoffeeScript with any other JavaScript frameworks, including JQuery and Jasmine. Jasmine tests in CoffeeScript look like this:

What this means is that if you want to start using CoffeeScript, you can – you don’t even need to rewrite any of the existing JavaScript if you don’t want to.

In general, CoffeeScript reads much more like English than JavaScript – === is replaced by is, !== becomes isnt, you can use unless instead of if (!) and it also has Ruby-style string interpolation, just to name a few nice things.

We did run in to a couple of things that tripped us up, so here are some things to watch out for.

Classes are not global

Chances are, you’ll be creating classes across a number of files. If you just create your classes using class MyClass, you won’t be able to create one in another file by using new MyClass since CoffeeScript puts all the code inside a single file in a single closure (which is a Good Thing).

You can solve this by creating classes called new window.MyClass. However, the better practice is to use namespaces. We added a line to the top of all of our files to ensure the parent namespace was defined:

window.MyNamespace or= {}

Binding to this

You can access properties of the object with the @ symbol. Inside the javascript code, you will have a reference to this.propertyName.
However, for methods that are to be used as the targets of events, you will need to bind to the original value of this. CoffeeScript makes this easy, you just use => to define the function instead of ->.

Example of when you don’t need to bind to the original value of this:

Example of binding to an event target, when you do need to use the original value of this to access properties:

Is it worth a try?

I would definitely say yes! In particular, for larger JavaScript projects, if you don’t have an established consistent way of writing JavaScript, or if you’re writing object-oriented JavaScript code, it will probably simplify a lot of the code base and remove the danger of accidental bugs like creating global variables.

If you’re more in favour of functional-style JavaScript, or if you’re a JavaScript guru and just luuuurrrrve those curly braces, then you probably won’t get as much from CoffeeScript. Maybe you could try ClojureScript instead 😉

First steps with Clojure

Over the last year, I learned Ruby. I’m not amazing at it and there’s still a lot to learn, but I know enough to be useful with it. In the spirit of learning a new language every year, the next one I wanted to tackle was Clojure.

I also decided to try using Emacs, since I had heard the Clojure support was pretty good.

After installing Emacs on my Mac (which is running OS X 10.7), I spent the morning surfing teh interwebz and trying a few different things to get Clojure working. Here’s how it looked in the end:

  1. Install Emacs from here.
  2. Read the tutorial to understand the basic shortcuts (C = control, M = alt below)
  3. Install marmalade – inside the directory ~/.emacs.d create the file init.el and enter:

    (require 'package)
    (add-to-list 'package-archives
    '("marmalade" . "") t)

  4. Run M-x: “package-refresh-contents”
  5. M-x package-install starter-kit
  6. Install clojure-mode by pressing M-x package-install and choose clojure-mode.
  7. Install Leiningen by folling the instructions here:
  8. Install swank-clojure: run “lein plugin install swank-clojure 1.3.3”
    Note – I initially installed 1.3.2 which gave me an error when I tried to run it from Emacs.
  9. Create a new project with Leiningen.
  10. Open Emacs, navigate to a project file and type M-x clojure-jack-in.

Once this was working, I also discovered a couple of key shortcuts that were really useful:

  • C-c C-k compiles the code in the current buffer.
  • C-x C-e executes the code in the buffer before the current line end.

Now I’m up and running, I’ve been able to complete all of the 4Clojure Koans at the elementary level. You don’t actually need to have clojure running locally, although I found it helped to figure out what was going on.

I’m also working on the Clojure Koans on github.

So far I’m finding both to be really fun and good learning resources ☺

Some of the best guidance I found

Finishing up with Io

As I reached Day 2 with Io, I continued to struggle with the syntax, in particular temptation to write object.method instead of dropping the ‘.’. I felt that I was starting to get some of the concepts of the language, the ability to rewrite core methods and override Operators.

However, I have also struggled throughout Day 2 and Day 3 with the lack of easily available documentation – the reference and guide on the main IO website did not seem to explain many of the things I needed to know, including how to read input from the console. I resorted in some cases to “cheating” by reading other people’s solutions to the exercises (although it’s not really cheating, since the point is to learn :)).

As I wrote my solutions, particularly the longer ones, they felt slightly clumsy – as though I wasn’t taking advantage of Io’s strengths. In the middle of Day 2 and start of Day 3, I really wasn’t enjoying working with the language, although by the end of Day 3 when I introduced the new Xml_Element object, it felt more natural. I’m glad I finished the chapter, although I’m still not really sure where I would use Io.

Overall, the main thing I’ve got out of the book so far is a greater understanding of meta-programming, which I’m hoping will help me take better approaches to new programming problems.

All of my solutions are on Github Gists:

Here are some highlights from the difficulties I ran into …

I was baffled for Day 2, Exercise 2 as to how to keep the original division method, but a quick internet search (and a minor cheat) revealed the solution: I needed to store the original division method in another variable:

When I reached Exercise 7, I discovered from other solutions that serialization in IO is actually really, really easy. All objects have a serialized method that writes it out to a string. When reading the object back from a file, all that was needed was the assign the results of the doFile("filename.txt") method to a new object. Writing to files is easy too – here’s the full solution:

For Exercise 8, I spent a considerable amount of time trying to find out how to read input from the console – turns out you can use File standardInput readLine. This gives you a string, so you need to use asNumber to complete this exercise.

Day 3, Exercise 1, was a massive struggle – at first I could not figure out how to pass the right indent, and I ended up looking around at some other examples before I figured out that I needed to:

  1. Write the parent node
  2. Add one to the indent
  3. Process the child nodes
  4. Remove one from the indent
  5. Close the parent node

I also discovered that using indent := indent + 1 doesn’t work – I guess you lose the reference to indent, so you need to do indent = indent + 1. Here’s the finished code:

In Exercise 2, I discovered after some internet searching and experimenting that Io has two built in methods: curlyBrackets (as used in the book) and squareBrackets – these can both be overridden to allow lists or maps, or anything else, to be created using {} or []. I guess this might be obvious to some people, but I was quite confused by it!

Here’s the list code:

The final exercise, adding attributes to the XML Builder, had me stumped for some time – in fact, I took a break from it overnight and a solution came to me in the shower :) My difficulty was figuring out when to write the contents of the XML node, I didn’t want a separate method but couldn’t write out the contents inside the loop.

The final solution still feels slightly clumsy but it does work (indents and all):

IO – Day 1

The group as a whole seems to have slowed down a bit on IO, with only a few of us sharing our Day 1 experiences. Installation has bitten a few people. I was lucky in that I was able to install it painlessly on OSX using Homebrew.

My next challenge with IO was figuring out the syntax for comments – turns out it’s a double slash: //

The homework: there was a lot of questions to answer, so I figured it was better to complete it in a blog post rather than a gist.

Stuff to find

Example problems
I wasn’t sure if they are looking for puzzles to solve, or problems with the IO codebase. I couldn’t find the former, but here are some problems with the codebase:

Yahoo group:

Style guide

Questions to answer

  1. IO is strongly typed. The following commented out code causes an error because “one” is not a number.
  2. All are true:
  3. Use slotNames:
  4. ::= Creates slot, creates setter, assigns value
    := Creates slot, assigns value
    = Assigns value to slot if it exists, otherwise raises exception

    The output of the slotNames in the code below reveals that Elf has the following slots: type, weapon, setWeapon, name

Stuff to Do

  1. To run an IO program from a file, just open terminal and type io
  2. To execute the code in a given slot, simply call the slot.

Note: for the last piece of homework, I was trying to think of what to write code about. I recently moved into a new flat, and my new housemate has a small, very cute dog, who has just discovered a new game: fling his smackos under the bed, and then bark at it until she comes to retrieve it for him. I decided to write a very simplified version of that :)

Sydney Ruby on Rails User Group

I attended the Sydney Ruby on Rails user group last week. There was a pretty decent size crowd, and the talks were hosted in the upstairs room at the Trinity Bar and Grill in Surry Hills, with beer and food available from the upstairs bar. I was disappointed to see that there were only three girls there though, it would be lovely sometimes to not stick out so much!

The talks are short, only 15 minutes each which is perfect because there’s never time to get bored. It also means, however, that it’s difficult to get very in depth with anything.

First up was Mario Visic talking about using declarative steps with cucumber, which are far less detailed and attempt to describe the business requirement, rather than the imperative style which is more granular and contains scenario data. The arguments are that declarative steps will change less as the design of the system changes, and that business people can write them. More about declarative steps.

I have my reservations over whether it would actually reduce the overall volume of changes or just move them out of the steps. I’ve never known business people write steps (and in fact somebody asked the question whether Mario’s client had written any steps, to which he replied no!) and I would be interested to know what QAs think of this style.

It’s an interesting idea though and one I might try on my next project if I can.

Next was David Parry on CoffeeScript, something I’ve been wanting to try for a while. I learned that one of its aims is to produce perfectly JS-lintable Javascript, which is very cool. You can also convert existing Javascript into CoffeeScript to make the move across easier – I think the tool demonstrated was JS2Coffee.

I also learned that CoffeeScript puts everything inside an anonymous function, so calling functions directly doesn’t work. I must put some time aside to play more with it!

The last talk was about learning from some specific mistakes by Andrew Grimm, which included large classes and the importance of writing maintainable code. These are things that everybody should be aware of, not just Ruby developers!

Lastly there were a few five minute talks including quick tips by Scott Harvey – who mentioned the ‘grep’ method for arrays that I discovered through the Seven Languages book, and two interesting talks encouraging people to join entrepreneurial courses and start up weekends. Some of these are similar to the Launch 48 events I enjoyed in London, so maybe I’ll go meet some Aussie entrepreneurs soon!

All in all it was a fun night, I’m looking forward to the next one as well as the SydJS group next Wednesday!

Seven Languages Week 1: Ruby

Week one of the seven languages is complete!

Having the support of the study group was great – motivating but without being too much. I was amazed at the breadth of the solutions, especially to the homework for Day 1 and Day 2.

Day 3, I was a bit underwhelmed by – the final part of the chapter introduced a lot of interesting techniques with meta-programming and modules, but the problem set didn’t really seem to challenge me to think too much about them.

The book encouraged me to look at the API to try and find solutions for different problems. Having the study group made this aspect even better, because we often found different things – for example, collect and zip methods for arrays. James in particular found some very short and neat ways to solve the problems.

Overall I think I like Ruby even more after doing this. It has so much “syntactic sugar”, and I definitely have a sweet tooth! Overall I’ve learned that while you can use Ruby to write programs in a rather boring, more Java-esque style, there is almost always a much neater, Ruby-ish way of doing it. I only wish I had more time and opportunities to learn it properly.

My highlights:

  • Day 1 reminded me of the usefulness of ranges
  • Quick ways to convert between hashes and arrays in Day 2:
  • Discovering the ‘grep’ method in Enumerable from James’ day 2 solution.
  • Finally getting a better understanding of modules (still far from perfect, but I definitely get them far better than before)
  • Learning the ‘zip’ method for arrays – although still not sure I completely understand how to use it!

My solutions are here:

Launch48, round 2. This time, it’s different.

This time, I know what to expect. I’m not pitching. I’m not project managing. I’m coding, and this time, I want to finish something.

Friday Evening

I’m stuck in traffic on the Putney Bridge, while somewhere in the depths of Kingston University, Ian is tutting and wondering why I haven’t arrived yet. Hours later, it seems, I nearly give up after wandering the empty halls fruitlessly trying to find a group of would-be entrepreneurs. Finally, a couple of lecturers point me in the direction of voices and I breathe a sigh of relief that I have just about managed to catch the last of the pitches.

None of the ideas scream out to me, but some spark an interest: a diet and exercise website, a specialist food store building on the Tesco API, and fashion website Look Book.

Second round: Joe jumps up to present mobile spy game Espionage, which is one of the winners alongside Look Book and group travel planning site Trips Together. He’s energetic and fun, and despite not being a gamer I am drawn to work with his team. We’re going to allow people to create secret agencies with their friends, and score hits for targeting their enemies. Good old passive aggressive fun.

Our team includes developer Michael, designer Bruno and front-end developer Richard as well as the usual marketing and business junkies – in this case: Joe, James, Jonny and Nick. We have a good mix of skills, and to my delight the team are in eager agreement to keep things small and simple.

We discuss technologies, and Joe’s eyes glaze over slightly, but he’s excited that we have something resembling a plan.

I go home inspired, and spend a few hours tinkering with Appcelerator and PhoneGap to get a basic Android application running. It’s way past bedtime, but sleep seems far away as the ideas keep flittering through my head … need … to … code …

Saturday morning

Junk food, it seems, is the theme for today: our team have a stack of chocolate biscuits and Haribo which Trips Together put to shame with their crisp mountain.

My first task for Saturday morning is to get the map up and running, but despite being from the same company, Google maps doesn’t want to run on the Android emulator. iOS seems happier with it, so I switch to iPhone, and by the time the first board meeting comes around I’m happily in the zone. I skip the opportunity to be distracted and hounded by the mean mentors (no offence, Ian) and remain at my laptop.

By lunchtime on Saturday, I have a working map with some fake friendlies and enemies appearing on it, and I can tap a target to make a hit. Bruno is producing slick designs and Richard is working on the styling. It’s like a dream come true, all I need to do is the fun stuff of making it work, and they make it look amazing.

Mentors stop by occasionally, I ignore them. I’m not here to start a business, I want to hack something together and I’m loving this team atmosphere.

By mid-afternoon, we’re in a position to pick a few features to focus on for Sunday. The app is working but isn’t very inspiring, so we decide to make improvements to the game play, including a revolving target area on the map.

I go back to my laptop and realise I have no idea how to calculate points on a circle, a quick google search reveals it involves some kind of trigonometry … I dredge my mind to recall lessons from secondary school maths, but it’s too deeply buried. Thank God for the interwebs though: I find that somebody has already done it and we’re moving forward again.

One topic for the second board meeting is technical strategy, so I reluctantly tag along. I should have known better: this is of course the point where the mentors flex their muscle, and we are no exception. Angry Bird Julien Fourgeaud questions why we have chosen the technically difficult route of creating a location based app rather than a website, and lectures us on building a decent user base.

I’m not too concerned since the app is built using web technologies anyway, but Julien is on a roll and declares that with the Rovio user base, he could easily take us out. Joe stands his ground, that could be true of any start up.

I’m mildly disappointed that I don’t even get a chance to talk about the technical architecture: Ian brushes this aside as he’s seen our app running, so we limp back to the team area. Feeling slightly battered and randomized, the team fall into debate over the game purpose and name while Bruno, Richard and I work on tidying up the game play and user interface.

Tired and growing irritiable from overdosing on sugar, we began to tail off around eight o’clock. I spent the evening playing with Ruby on Rails and Heroku, trying to build a simple back end for the app.


Sunday morning, I threw myself out of bed with the consolation that Monday was a day off work, and therefore, a lie-in. Launch 48 is truly exhausting if you give it your all, but it is only one weekend, and it didn’t take long to shake off the tiredness and start planning for the day.

We arrived to find Joe grinning and acting mysteriously. He declared that he’d cracked it, and it was amazing, and he would tell us everything shortly, but first we had to write down why we decided to join his team. I debated what to write, finally deciding on, “Passionate and energetic pitch, it sounded like it would be fun”.

Turns out the great idea was a strapline and mantra: Spontaneous Disruptive Gaming.

For the presentation, he said, we’ll go in there and tell them we don’t have a business plan, we don’t need one. We’re about fun and spontaneity, we’re being disruptive! It was a good way to avoid spending all day working on boring stuff, and I was intrigued to see what the mentors would make of it. After all, this is really a weekend people choose to attend, if we don’t produce a business plan, so what?

The day progresses and the code progresses. I’m having a lovely time. In the early afternoon, we have real users and Joe, James and Nick see the app working for the first time in a mobile browser. They are delighted, which in turn lifts the energy even further. We’re on fire!

With nearly three hours to go, a simple working app and lots of ideas, I hand Joe and James a pile of stickies with features on to prioritise. Joe immediately ditches over half of them, leaving us with a few tweaks that look pretty achievable within the time, including an array of guns with different ranges.

So the app is slowly coming together, but with no business plan to prepare, the group is meandering a bit. Where’s our facebook group, I demand, our twitter account, our domain name? They shift up a gear, and I bury myself in my laptop again.

The afternoon flies by and suddenly we’re being rounded up for the presentation. Typically, I break the app trying to adjust the web page in the last few minutes before the presentation, which I haven’t even seen until I’m standing at the front of the room, craning my neck to see the slides. It was slick and well put together, although I am hoping for a bit more attitude and disruption. I think that I would definitely have liked to see the boys in suits and shades or something. ;)

The demo is a bit rocky, and I make a quick fix during the mentor’s questions, but there is no denying that what we’ve achieved within two days is impressive and looking pretty damn good.

Finally the reason for writing down why we joined became clear when James reads all of our slips of paper out to the group: every single person had thought it sounded fun. We don’t have a plan for the future, but we’ve had a damn good time.

The other teams present: Trips Together still looks hopelessly ambitious to me as a project, but Look Book have a working website with commission based links and of all the teams, I think this is the one that may actually go far with it.

In our case, we’ve been in it for the fun, it’s been amazing, but I’m done, and I achieved my objective. I have no desire to be part of a game start up; it doesn’t fit in with my nomadic lifestyle. All I want now is a nice glass of wine and to go home and collapse.

But something’s not right: I go home but I can’t put my laptop down, I’m proud of it and I don’t want to let it go. I try to get the facebook integration working, when that becomes impossible I lose myself writing a blog post. I wonder to myself how I will think back on this weekend in a week, a month, a year; will it change my trajectory?

Monday is spontaneous and disruptive: maybe it’s not over after all. Over the following week, the six remaining team members (Joe, James, Bruno, Richard, Nick and I) exchange over a hundred emails, grab a domain name and a basecamp project, and make plans for another hack weekend. Apparently there’s still a lot of excitement and energy.

It may never become anything, but whatever happens … it’s definitely, definitely been fun.

The “finished” app: Espionage!
The in progress website: Espionage GPS
We did finally get a Twitter account

Review of Agile Coaching

The book: Agile Coaching by Rachel Davies and Liz Sedley (September 2010)

Why I chose this book …

I bought and read this book when I was approaching the first engagement where my role would be solely to coach. In nearly three years at ThoughtWorks, all of the projects I had worked on until January were either pure software delivery, or co-sourced delivery, where coaching of the team was a happy side effect of the work we did.


This is a great book for first time coaches. It consists of four parts: the first one covers coaching in general and people skills, and the rest walk through Agile practices and how to coach teams to use them. The last section also includes a chapter called “Growing You” which reminds the reader to look after their own skills – and sanity:

“It’s vital to invest in yourself and your own learning so you can grow as a person and keep your ideas fresh. You also need to take care of yourself in order to cope with the day-to-day demands of being an Agile coach.”

The good bits

The book is straightforward and easy to read. The content is broken up with lots of short stories and examples, which I really like – I find this helps to understand the points better.

The book encourages the reader to help the team to think for itself and make mistakes:

“Your goal is to grow a productive Agile team that thinks for itself rather than relying on you to lay down the Agile law. Showing people how to be Agile isn’t enough; they need to change how they work and how they think in order for Agile to stick.”

There are lots of practical recommendations and exercises for how to achieve this, which was great because it was immediately useful and applicable – I often found myself wanting to get into work and try out something the book had suggested. Alongside this, the authors pointed out common hurdles to introducing new practices, often illustrated with examples from their own experience.

I also enjoyed the chapters on development. The book isn’t a technical read and doesn’t try to be, but I thought it dealt reasonably well with the social issues around collective code ownership, refactoring, incremental design and pair programming.

Each of the chapters in the book is self-contained, so you can either dip in to the bits you want or read it from cover to cover.

The bad bits

I can’t really point to anything I disliked about this book! For more experienced coaches, it might not be as useful – I don’t think it contains anything groundbreaking or new.


I would definitely recommend this book for anybody looking to start coaching Agile, looking for a good general read on the subject or some tips and techniques for introducing Agile to a team.

A “Live Coding” experiment …

My colleague Rachel Laycock and I prepared a presentation in April on testing JavaScript with Jasmine. It is based on the work we had done introducing Jasmine earlier this year to a team of JavaScript developers who were working on a large and complex JavaScript application, with little or no unit testing in place already (I wrote about this here and here).

For our first “practice run”, we prepared demonstration code and tests based on the Bowling Game Kata and presented it to a group of fellow ThoughtWorkers. We demonstrated the tests running, and at the request of the audience, changed the code to break one of the tests and demonstrate the error messages.

Feedback from the group was that the pace of the presentation was fairly fast, and the most exciting bit was when we actually changed the code “live”.

More recently, our team on my current client were asked if we might be able to fill in for a lunchtime Tech Talk at short notice, so I dug out the Jasmine presentation again (sadly, I had to do it without Rachel, since she is thousands of miles away enjoying the delights of Bangalore as a trainer at ThoughtWorks University!)

With only a few hours to adapt the presentation, I decided based on the previous feedback to write all of the code and tests during the presentation. Brave maybe, slightly reckless and risky for sure! I ran through the code I planned to write only once with another colleague Chris, and stumbled in a number of places, particularly in the code I wanted to write to demonstrate Jasmine spies, but overall I was happy that it would be good enough. I also decided to try and recruit audience members who might be willing to write some of the code for me.

Learnings from how it went

Overall, I was happy with the decision to code live – the first half of the presentation went very well. When I reached the code around spies, the tests went red and I was unable to multi task well enough to keep presenting, see the bugs and fix them and the tests so I abandoned the real code and carried on, using just the slides and test code. I also received feedback that suggested that the action of writing tests first was a powerful demonstration of test-driven-development, which was also something that was interesting for the audience.

I also found it very difficult to keep talking and keep it interesting while I was either writing code or somebody else was writing a test, so there were a few short silences.

Lastly, I was aware that some of the code I was writing was not optimal, but I didn’t feel that I had the time or enough focus to refactor it (particularly when it wasn’t working anyway).

I think the presentation would work better with two people and a little more practice of the code. This way, one person could talk while the other focused on writing a test or making it pass. However, I would definitely keep the live coding aspect.

I fell back on the short preparation time as an excuse when things didn’t quite go to plan, but I hope a development audience would usually be fairly forgiving if you can’t quite write code right first time around!

The presentation and code is available from github. I hope to present it again at the London Java Community in July.

Review of Head First Design Patterns

The book: Head First Design Patterns by Eric T Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra

Why I chose this book …

I switched from BA back to development last year and was looking for good books to learn from, and one of my friends suggested HFDP. I didn’t know much at all about design patterns – I’d only really encountered MVC.


This is a book to work through rather than a reference book. It presents a series of design patterns with exercises including code ‘fridge magnets’, crosswords and general challenges. The code samples are all in Java, but very simple and should be no problem for non-Java devs – there is a very positive review from an ActionScript developer on Amazon!

The patterns it covers are: Abstract Factory, Adapter, Command, Composite, Decorator, Facade, Factory Method, Iterator, Model-View-Controller, Observer, Proxy, Singleton, State, Strategy, Template Method.

In the appendix, it also covers: Bridge, Builder, Chain of Responsiblity, Flyweight, Interpreter, Mediator, Memento, Prototype, Visitor.

The first time I tried to read the book I put it down after I’d read about half of it, because I was struggling to relate it to the real world. I picked it up again when I was also reading Pro JavaScript Design Patterns, to try and understand that better.

Although I did read the whole book in the end, I didn’t follow the exercises – partly because I was using an e-reader, and partly because I just didn’t want to spend that much time on it. By the time I finished, I felt that I had got what I wanted out of it, which was a high level understanding of the patterns, and the ability to better recognise where I was using them and have a conversation about them.

The good bits

The book is really easy to read and follow, and mostly quite fun to read, which is its main strength, and this also shows in the reviews on Amazon. Each pattern is introduced using a story of somebody asking for a software solution. Often the authors use conversations between a fictional team of developers trying to solve the problem to explain the concepts. There are lots of diagrams and “Q&A”, reviews of what you should have learned, and a nice summary at the end of each chapter, which was good to refer back to.

The book also explains and emphasizes OO principles, and how they are linked to each pattern, which I liked. The extra summaries in the appendix of the patterns that didn’t quite make it into the main text were also really useful.

The bad bits

My main gripe with the book is that the stories and code samples are too far removed from real life situations, which made it more difficult to grasp some of the patterns first time around. The second time I read it, I had a lot more context and could relate what I was reading to real-world code I’d seen on projects.

The puzzles and exercises don’t lend themselves well to reading on an e-reader. I also grew slightly tired of the ‘Fireside Chats’ between design patterns, and after reading about two thirds of the book I began to wish they would hurry up a bit more.


I would recommend this book as a good read as an introduction to design patterns, especially for people who have enough coding experience to recognise the patterns in what they’ve done but don’t really know much about them. If you already know a fair bit about patterns and just want to brush up or read up on a specific one, you’re probably better off asking the interwebs :)