If you’re still subscribed, and you’re interested in programming and design nerdery, you might want to direct your feed reader at Inject is for Wizards.

At the end of Chapter 8, Joe sets the first real programming tasks in the book:

Write a ring benchmark. Create N processes in a ring. Send a message round the ring M times so that a total of N * M messages get sent. Time how long this takes for different values of N and M.

Here’s my implementation, explained.

As we’re building a benchmark, the first thing we need to do is set up the timing code. Thankfully Joe covered this in a previous part of the book.

In line 1 we declare the module, we need this in order to compile and run the code. Line 2 tells the erlang compiler to make all functions public, usually we would declare which functions can be exported or made public, but this isn’t production code so we’ll give ourselves access to everything.

Line 4 is a function declaration, all the code after the -> symbol is contained in the function. So we’ve declared a function called ringBenchmark that takes three arguments: NumberOfNodes, _Message and NumberOfLaps.

The underscore in _Message tells the erlang compiler that we don’t care about this variable, so don’t complain about the fact that we don’t use it anywhere.

Using the statistics/1 BIF we can check the runtime (sum of run time of all erlang threads) and the wall_clock (real time passed). Each of these functions return the total time, and the time since the last call, in milliseconds.

In Lines 4 and 6 we run each of these methods once, then again in lines 7 and 8, capturing the time since last call of each. Finally we print them out in line 9.

Save the file as e21.erl and play along in the shell!

It works, but it doesn’t really do anything just yet. The exercise requires that we create a ring of precesses and pass a message around them. So lets create the first process and give it something to do.

To create a new process in erlang we can use the version of the spawn/3 BIF that takes 3 arguments: Module, Function and Args. It returns a pid.

This is done on line 8, we spawn a new process of the same module, running the loop function with an empty list as the arguments.

The loop function is defined on 14. It does nothing other than print the argument it was given.

Again not much is happening. The new process is spawned and prints to the screen when the loop function is called. Now that we know how to spawn a new process we need to create the rest of the processes that will make up the ring.

The createNode function does this job. Lines 18 through to 20 define the createNode function, which will continue to spawn processes recursively until it reaches the number defined byNumberOfNodes. This will build a linked list.

Erlang uses pattern matching to decide what to do when a function is called. Line 18 defines a pattern that matches: “When the first two arguments are the same, and the third is different”. When we match this pattern we want to simply return the third argument.

This is how we break out of the recursive loop defined by lines 19 and 20. Line 19 defines a pattern that matches when all three arguments are different. When matched it calls itself, incrementing the first parameter, and replacing the third parameter with the pid of a newly created process.

We kick start this chain of events on line 9, when we call createNode for the first time. If we run our program with NumberOfNodes set to 4, we will see 4 processes spawned, each pointing to the next one, creating a linked list.

The exercise calls for a ring of processes, so the next step is to connect the first and last nodes together to form a ring.

To do this we simply send the FirstNode a message with the pid of the LastNode. This is done on line 9 using the ! syntax.

So how do we capture and respond to that message in our processes? We use receive, to tell the process to wait for a message.

Since we fire up every process using running the loop function, this is where we will tell each process to wait for a message.

Inside the receive block we tell erlang that when a message that matches the pattern NewNext is received, and when NextNode is set to an empty list, that we should call loop again with the contents of NewNext.

As you can see we now have 5 iterations of loop being called. This closes the ring of processes by telling the FirstNode, which was running loop with a NextNode of an empty list, to now run with a NextNode of the LastNode.

Now that we have a closed loop of processes, we need to send a message around it. We’ll write a function called sendMessage that will do just that.

The first pattern matches when we’ve run out of messages to send, it does nothing. The second pattern matches and sends a message to ToNode.

Now that we have another type of message being sent out to our processes we need to handle it in loop.

We write a pattern that will matches the one we send from sendMessage. We’ll print out what we receive, send the message on with 1 fewer hops remaining, and then start loop again to wait for another message to come in.

We then need to call sendMessage after closing the ring, passing it the Message, FirstNode and the total number of times the message should be passed on.

Running it in the shell gives the following output:

There we have it, a ring of 4 processes, sending a message around the ring 5 times. Except there’s a problem, because we’re using processes to do the work, our timing code is being called before the message has been passed around the ring. This can be clearly seen in the output, we declare 0 milliseconds to send 20 messages, then we see all of the action happening.

What we really want to do is have our timing process wait for a message that says we’re done sending messages around the loop. Here’s the final program.

When run in the shell we can now see the timing code being run last.

Printing to the screen is very time consuming, if we want to send 300 message around a ring of 1000 processes it will take a lot longer than it should. Remove the io:fomrat lines in the loop function and let rip!

This method is called when a user taps a button inside a table cell. The purpose of the method is to find the table cell that the button belongs to, and then call didSelectRowAtIndexPath on that table cell.

Disregarding the fact that this methods purpose makes didSelectRowAtIndexPath one very bloated method, there are a few other improvements we can make to it.

First, this method uses a C-style for loop. Objective-C 2.0 supports fast enumeration. Fast enumeration is faster, looks better, and throws an exception if you attempt to modify the collection while it is being enumerated.

Because NSArray has a well defined order, and enumeration proceeds in that order, we can simply count the index.

We now have more lines of code than the original, but the intent is somewhat clearer. The implementation of this method however, still relies on a string comparison to find the correct table cell, which is not ideal.

Using our knowledge of the view hierarchy we can re-implement this method to forgo enumeration altogether.

Knowing that our button is inside a table cell we can ask it for its superview. Once we have the table cell, we can ask for its indexPath. We can then call didSelectRowAtIndexPath directly using the indexPath.

# TODO – Make this work properly for all cases.

At some point in time this comment made sense. Someone, somewhere had every intention of fixing this and removing the comment.

It’s quite possible that someone was you, but you don’t remember anymore.

todos are irrelevant

todos live in no-mans land. Stuck in a time warp for all eternity. Don’t kid yourself, you’re never going to re-visit a todo. They’re irrelevant.

They fly under the radar because they have no visibility. Out of sight, out of mind. If you’re not working on the code with the todo, then you don’t know it’s there, and you don’t care.

Other than doing a project wide search, you’re never going to find them all. Even if you do, you’re not going to understand the meaning of them all.

They’re irrelevant.

making todos relevant again

What’s the point of a todo list if nobody knows about it?

Take control of your todos and enshrine them in code that everyone sees every day. Write them into your test suite as pending tests.

Failing tests are bad. Passing tests are good. Pending tests are just plain annoying.

They clearly indicate that something hasn’t been finished properly. They’re visible every time you run your test suite. This means they annoy everyone until they’re fixed.

They define todos better than any other mechanism at your disposal.

Sprinkle in a touch of guilt

While a quick flick through svn blame will find the culprit, it’s not visible and it means work on your behalf.

Sprinkle in a touch of guilt by mandating all pending tests be created with the Authors name and todays date in the pending message.

That’ll ensure they don’t hang around like a bad smell for too long.

But how many developers apply it to their software engineering practices?

Stories

Agile developers work with the concept of stories. Essentially these are short explanations of what someone should be able to do with the software once the story is implemented.

A user should be able to manage their account.

This story is vague, open ended and typical of client feature requests.

Before estimating this story, you’re going to need to get some fine grained detail into it. After talking with your client you might end up with the following:

Managing their account consists of changing their name, updating their contact details, changing their profile picture, resetting their password and swapping between username/password and open-id for authentication.

Now you have enough information to estimate this story, you know what the client means by “manage their account”.

You might come up with an estimate of say 100 points.

This example is contrived but if every story your client sends you follows this same process you’re heading straight for a world of pain.

The Effect of Large Stories on Iterations

So you start work on your iteration with 10 large stories with your team and half way through you’re looking at the number of stories you’ve sent to your client for testing.

That number is zero and you’re starting to feel a bit stressed out. It’s ok though because by the end of the day 5 stories have moved into the testing phase.

You move on to the rest of the stories in the iteration and your client gets started testing the stories you’ve completed. Some of them pass and others get sent back because something is not quite right.

The cumulative effect of multiple large stories is an exponential story completeness graph.

The Effect of Large Stories on Developers

Working on the same story for a long period of time is painful. As a developer you feel like you’re climbing a mountain that just keeps getting bigger.

You’re not sure where the top is, and sometimes you think you’ve reached it, but as it turns out you’ve forgotten something and you’re not quite at the top.

The effect on the team is that everyone goes through this same journey every iteration.

Your client experiences the same in reverse. They sit around waiting to climb the mountain, and they wait, and then bang, they’re expected to be half way up the mountain almost instantly.

Divide and Conquer for Happiness

Large stories can often be broken down into smaller stories. In fact you already did this when estimating your stories. But you finished one step before you should have.

You should have split the original story into multiple smaller ones:

A user should be able to change their name.

A user should be able to change their contact details.

A user should be able to change their profile picture.

A user should be able to change their password.

A user should be able to switch between username/password and openid for authentication.

Each one of these stories is smaller, has easier to meet acceptance criteria and will be finished earlier.

Your client will love you because they don’t spend half their time sitting around and waiting for stories to test.

The developers in your team will love you because instead of climbing one massive mountain, they are climbing 5 mounds.

Everyone feels like they are constantly moving forwards through the iteration.

The story completeness graph moves from being exponential to linear.

That’s a much more positive graph to have hanging on your office wall.