Clay Dowling's Occasional Musings

I write code, build things, and occasionally lead teams. I also share my thoughts or things I've learned about them, so that others can learn from my mistakes.

Embedded Testing Suites

At Prairie.Code() I provided an example embedded project to demonstrate test driven development as part of an Arduino workshop. The example I gave used the Unity testing framework, but there are several others and they're worth exploring.

→

2017/09/27 23:35 · clay

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

→

2017/05/05 22:29 · clay

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.

→

2017/04/15 16:52 · clay

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.

→

2016/04/13 12:08 · clay

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.

→

2016/03/24 23:09 · clay