Code Retreat Cambridge

Yesterday I had the pleasure of attending a Global Day of Code Retreat event held at Red Gate, Cambridge hosted by the local software craftsmanship group.

The format of the day is to solve the same problem a number of times with different constraints each time. Each problem is solved as a pair and generally uses test-driven development. After the end of each session, the code was thrown away. Although this might seem a little strange, it meant you couldn't form an attachment to the code and could more easily indulge with the given constraints.

The problem used this time was Conway's Game of Life. I think this is a great choice of problem, it's simple enough that the problem can be easily understood, but there's a really rich variety of possible approaches to solving the problem.

I alternated the sessions between C# and Haskell. I found the value in pairing directly related to the asymmetry in ability. The more asymmetry the better! I found that showing people unfamiliar with Haskell was a rewarding experience. People seemed to grok Haskell very quickly, and were impressed with the readability of the solution.

As a side note, I was really impressed with Mono.  I needed to get a C# development environment up and running on my Linux laptop, and I was slightly dreading doing so.  Turned out that was completely unfounded, it just worked.  The IDE lacks a few niceties (it's certainly not as easy as Visual Studio + Resharper), but it's not bad!

On the C# side, I learnt more about design than anything else. In particular, one thing that stuck out for me was the difference between the top-down and bottom-up approaches. Sometimes when I paired, my partner would aim to get a top-level test (evolving a grid produces a new grid for example). I found this really hard to drive from a TDD point of view - breaking down from the top is much harder for me. The other way up, writing the rules first (a dead cell that has three neighbours becomes alive for example) feels much more natural for me an certainly a lot easier to drive the tests. There did seem to be a middle ground that was more fun to work through; get the structure right with a top-level test, and then drive the functionality bottom-up. The seems to be the same approach as advocated by Growing Object-Oriented Software by Tests and I look forward to trying this out in anger.

I didn't pair with anyone who even considered mutable objects.  I'm not sure whether this was just a self-selecting group of people, but everyone was firmly in the "mutable state" is bad.  I would really like to run with a set of constraints to do with high-performance to see how that altered peoples perceptions.

The constraints that were chosen were interesting.

• No primitives (including enums)
• No if statements
• No mouse! (use the IDE)
• No long methods

No mouse wasn't very interesting for me, I've always been a big fan of learning keyboard shortcuts (bashing keys always makes it look like you know what you are doing, so I've found it a good way to hide my incompetence sometimes!). 

The most interesting constraint for me was the no if statements (see the anti-if campaign for some justification). The lack of if statements forced you into generating object hierarchies and using polymorphism.  It was a little artificial for the problem but it did result in cleaner code (just maybe a bit more of it!).

So now I need to try and take this back to my day job.  Always a bit harder trying to apply techniques learnt in the small to problems faced in the large.  Legacy code makes life harder!

Code Smells - The Lying Interface

I came across a code smell today that I hadn't seen / heard before. I've christened it the "Lying Interface". At work, we've been trying to refactor some code into a shared service accessible by WCF. To do this, we need to understand the interfaces and then develop the appropriate protocol to model this.

I've been faced with some interfaces like this:

public interface IPoller {   
     void Poll();
  }

This doesn't look too bad. The Poll method presumably calls every so often to poll something. Looking at the constructor then shows something a bit hidden.

public class Poller : IPoller {
    private IPollListener m_Listener;
  
    public Poller(IPollListener listener) { 
       m_Listener = listener;
    }

    public void Poll() {
      // run some code and generate some results
      m_Listener(results);
    }
  }

So despite the poll method being simple, it's deceptive. It actually relies on a constructor argument being passed in and invokes the results upon it. The interface is really lying, it's not showing the true responsibilities of the class. Perhaps another name for this is "hidden dependency"?

My opinion is that the interface should be self-describing, it should say what the class does without saying how. In this case, the hidden dependency on the IPollListener class is not expressed properly. I ended up refactoring the code to be more self-describing and using an event instead, roughly the new code ends up looking like this.

public interface IPoller {
     void Poll();
 
     event EventHandler<PollingEventArgs> Polled
   }

   public class PollingEventArgs : EventArgs {}

It's still not perfect, without a comment I have no way of knowing from the method signatures what events are triggered, but I think it's better than it was. This has the neat side effect of breaking the dependency on Poller on IPollListener and switching over to an Observer pattern.

I'm still not sure what the right name for this smell is, maybe it's more to do with hidden dependencies, but it's a start!

Circle CI and Haskell

This was going to be a long post on how to set up CI and Haskell.  Thankfully I found a simpler way.

One of the most essential parts of Continuous Integration is to have a self-testing automated build.

A CI server (such as Jenkins or TeamCity) aims to simplify this procedure .  Events on the version control system (such as a git push) trigger the CI server which performs a build of the code and runs the automated test suite.   Unfortunately, in my experience, it's always a pain to set these servers up, especially if you aren't using a standard curly brace language.

Circle CI promises one-click automated continuous integration from code pulled from your git repository.  It sounded too good to be true, and initially it was, there way no out of the box support for Haskell.  However, my e-mail to support was quickly answered and the latest version of the Haskell platform was installed and available a few days later (awesome support).

Once the Haskell platform was installed it took me literally 3 minutes to get a working build.

Each server that runs the process is a standard Ubuntu 12.04 and has the Haskell platform installed.  This makes it dead simple to install any extra libraries and then run the necessary cabal commands to configure and run the tests (I used the exitcode-stdio package to run the tests).

Being able to setup CI in a few minutes is really useful and takes a large part of the drudgery away.  Awesome sauce.

I hadn't realized that GitHub had an API for hooks.  As someone who's really interested in dev-tooling, there's a million and one useful ideas that come out from them.  I'd love to see more tools like this (e.g. static analysis, security vulnerability, fuzz testing, bench-marking, profiling, memory checking, code metrics and so on).