The First Two Weeks.

My cohort of students began on December 8th (2014) but I didn’t get round to writing this till over the Christmas break. So here’s a brief overview of the first two weeks:


Ruby is a programming language that is supposed to be legible for humans. Sometimes it looks like this:

puts “What’s your name?”
gets name
puts “Hello #{name}!”

But then it can also look like this:
possible_dim_arrays = {|dim_array| {|loc| @loc[loc] != “X”}.length == 3}

This is a line from a noughts and crosses game I wrote, and am now a little embarrassed by. Part of what we’re learning at MA is to write code in a style that can be read by other people and easily maintained.

Pair Programming

The first week was also an introduction to pair programming. When pairing one person is the driver, i.e. has the keyboard and writes, and the other navigates, spotting problems and suggesting alternatives. Some aspects of pair programming I find easy. At the level of individual lines of code, a simple typo can break everything so it’s helpful to have another pair of eyes spotting trivial mistakes. When planning the architecture of a program it helps to have someone to bounce ideas off. Coding as a pair also wards off the tunnel vision I sometimes get while coding solo.

The hardest thing I have found about pair programming is the connecting bit between writing lines of code and discussing the abstract structure of a program. Often you can have long strategic discussions about how objects might interact, how they interact in the real world, how they really should interact, that result in some decisions on those questions but don’t really lead to much because it’s not easy to predict how such decisions are best realized in Ruby syntax.


As fellow makers who got my lecture about the Dependency Inversion Principle (comparing it to the international trade in used clothing) know, I love a good metaphor. For me, a class (which is really what we’ve been testing so far) is like a factory production line. The production line takes in instances of objects, puts various “machines” to work on them and then spits them out the other side maybe as slightly different objects. To test that the production line as a whole is doing what it should be doing wouldn’t be very helpful. Maybe your car comes out of the production line without any tyres on. But is that the fault of the tyre-fitting machine? Or is it the tyre-making machine? Or maybe the wheel-fitting machine put the wrong sized wheels on? It could be hard to tell.

RSpec, a testing environment for Ruby, is like a mechanical claw that can pick up individual machines, parts of your production line, and check that they’re doing what they should be doing. Here’s a graphic illustration of my point:


The First Two Weeks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s