Clay Dowling's Occasional Musings
I'd love to say that I'm gonna be a power blogger with lots of important stuff to say, so that I could promise weekly or even daily postings. The reality is that I'm a dude with a job and a family and too many hobbies, so you'll get posts when I really have something to say. Occasionally they'll even be worth reading.
A Functional Conway's Game of Life
Conway's Game of Life is an old standby for code retreats and coding katas. The game's simplicity means that implementation complexity won't get in the way of what you are trying to learn.
A few months back in a code retreat a fellow attendee implemented the game in a functional language. My first thought was “why would anybody do that?” My second was “how could I do this in C?” C isn't normally thought of as a functional language, but there's nothing stopping it from being used that way. Functions have always been first class objects, and applying a function to a collection of objects is trivial.
I put the thought away for a while, but recently I decided that building this as an LED array driven by a microprocessor would be fun. So I pulled the project out of the vault and started working on it during my lunch hour with my colleagues.
You can see the results at https://github.com/ClayDowling/functional-life
Branching By Abstraction
Recently at a client we had a discussion as a team about our continuous integration practices. One of the goals of continuous integration is frequently pushing changes to the master branch, so that it can be integrated into the build.
But how do you do that if you need to make breaking changes? You can push to master, break everybody's build, and earn the undying enmity of your entire team if you do this regularly. Or you can try a couple of different approaches, such as Branching by Abstraction.
Fear and Loathing in Legacy Code
We've all seen code bases that look like they might have been written as an ode to Fear and Loathing in Las Vegas. There's a good chance that we have even perpetrated such code. But now it's in production and the support is making you wonder why you didn't take that nice accounting job out of school. You could put tests on the code but it's such a mess that you should probably just throw it out and start fresh, if only you had the time and the Business wasn't howling about the way the software is causing them to bleed cash. Fear not, there are strategies that can help you out.
Mocking System APIs
One problem a lot of people run into is the need to test code that uses APIs they don't control. This came up tonight during a discussion on mocking at the Pillar Technology Plugged In event in Ann Arbor. The system in question was a remote service, but I encountered it recently with UNIX system calls. Fortunately there's a simple solution.
If you wrap the APIs in a class, you can mock that class. I'll show you an example from my own project, written in C++. The first step was to create an interface. In classes that need to access this API, they will declare a member which is a pointer to that interface.
Better Tests Through Mocking
If you have even a moderately complex application, writing tests can be a real pain. You either wind up writing complex, fragile tests, or you skip it altogether. There is a third path: fake out all of the parts that you aren't testing in this test. You can examine the fake parts to see what has been done with them, and you can make them respond however you want to your program.
clay