I spent a lot of this weekend working on the TWO challenges we were set. Do you know how long it took me to write the bit of code below? This code is most of the answer to the ‘inject challenge’ (the other bit of the answer was a load of unit tests which I won’t bore you with).

def injector
  iterations = self.length - 1
  result = self[0]
  (1..iterations).each { |x| result = yield result, self[x] }
  result
end

The point was to model the inject method for arrays only. Inject basically grabs each item of a series and does whatever the block you’ve specified dicatates using the the next item and the cummulative result of the process so far. It’s very handy for adding things up, multiplying, finding the longest item in a series etc… I now love inject, as it provides me with a shortcut to the above without having to write my own method, which I’ve now realised is a bit of a pain to write!

The other challenge was to model a takeaway ordering system, then kick out a text from the Twilio API if the order is satisfactory. I read a great deal of an awesome book called Practical Object Oriented Design in Ruby (POODR) which really consolidated last week’s learnings but also make each decision more painstaking.

The thing I’ve discovered about OOD is there are no hard and fast rules. This is both it’s beauty and it’s, er.. beast? You have to aim for as simple a structure as possible by ensuring each method has only one responsibility, injecting dependecy to write loosely coupled classes, reversing dependency if necessary, making each method respond to ‘ducks’ (I’ll explain in another post), having abstract interfaces… the list goes on. Most of these do fit nicely together to satisfy the overall aim, but I find it quite hard to ensure none of them are going wrong and that ‘bad things’ are not creeping in at any given time. All the while I have to make sure I’m only doing what the spec requires. Oh, but you should bear in mind likely potential future developments too and assume that various bits need to be amenable to change. But at the same time don’t overcomplicate things. Sometimes it really hurts my head.

I don’t claim to be an expert in the above YET, but at least the concept of OOD is taking shape in my mind. I surmise that the result of a well made OO program should have simple, highly readable code that can be worked on and changed in the future by others when requirements change. It should be built to satisfy user stories. Unit tests should be used both to test methods and to guide the developer to realise when a process is too complicated or relies on dependencies that are too rigid. Feature tests at every stage of the process can ensure unit tests are testing something that matters. Oh, and you must be sure to unit test only the behaviour of the class you’re testing and stub out methods that interfere.

After a pretty hectic weekend full of challenges and programming the object that is my mind, it was nice to have a day of following tutorials today. Until the line that basically said ‘now work out how to do everything else (ie the really hard stuff) on your own’. No rest for the wicked, wicked Makers students…

Nat x

Well, maybe a bit of rest. This is us after we'd all hit a wall.. That's my pairing partner working from a beanbag there