Test Driven Development: Building Lots and Lots of Miniatures

Learning test driven development has been an adventure. As I have learned to use, and appreciate the process, it has really driven home in my head the opacity of programming. I have been trying to learn to code the same way I would do if I were building a watch. Insert a piece. Turn the wheel. See if it all moves. On an intuitive level that should work. There seem to be lots of moving parts in the program I am writing, but at the same time, it is also very static. All the moving happens inside the computer’s memory where I can’t easily see it, and there are lots and lots of parts moving.

In my recent work in operations, I can make a change, watch the process, identify the sticking point and correct it. There might be subtle things that affect efficiency that I can’t identify without careful tracking of statistics, and there are definitely times that it would be helpful to be way up high so I could see the whole process at once. But it is very accessible to me, I can see it happen.

Returning to my previous post on programming in the theatre, when I programmed a cue into the system, and ran it, there were two ways for me to me to track the changes as they are executed. First, the actual physical lights change. I can see them turn on or dim. If the output isn’t what I want, I can just look up and see which lights aren’t right (that’s how lighting designers die, too busy looking up at the lights to notice the orchestra pit). There are also two monitors attached to a lightboard and at least one of them is dedicated to displaying the progress of cues as they run. Every channel number is listed and the level at which it is set is displayed below it. As the cue runs the levels change.

When the output isn’t right, say a light comes on that shouldn’t, I can compare the monitor to the light and get a lot of information about where the problem lies. If something goes out that shouldn’t, I can watch the program run to figure out where it goes out and why. I can see the cogs moving.

It is possible a tool might exist to display what’s happening in memory, I know I have seen simple versions in debuggers for example, but I haven’t seen a tool that displays it in any large scale. Clearly time is also a big factor in this. The process in an operation might take days, a lighting cue can take minutes, but a computer program (hopefully) runs in fractions of a second. Even if there were a transparent display I couldn’t read it fast enough to find the problem.

So, in the end, it’s a sort of fundamental shift. Instead of monitoring the whole process from start to finish, testing takes the code in chunks, and runs them separately, out of the context of the larger process. Clearly this is useful in that it allows you to make sure that the whole code is working without having to run every single process in an application, but building a whole new instance for every test it is still a little mind boggling. It’s like building the same miniatures over and over again to make sure the plans are still good. Now, the metaphor isn’t perfect for a number of reasons, not the least of which is that one doesn’t typically make thousands of revisions to one’s building plans. I suppose if one were to do so, it would make sense to build a miniature after each revision, just to make sure the pieces still fit together. But it is still really difficult for me not to picture an entire studio filled with teeny tiny furniture.


Object Oriented Programming in the Theatre aka: why this is so weirdly intuitive

I think it is fitting introduction in a first blog post to choose a topic that ties in so nicely to my past. My background is in theatre, specifically in lighting design and theatrical electrics, which I did a lot of in high school and college. This has turned out to be oddly useful, not just because it has given me a great eye for well designed websites, but also because the process of lighting a show turns out to be a great example of/visualization for object oriented programming languages.

In the theater the theatre there are objects, lights, which for theatrical accuracy I’m going to call fixtures. The fixtures are totally interchangeable and don’t do anything until they are physically plugged into a specific socket, and which point it gets a unique name, usually the number of the socket into which it is plugged.

Once the lights are plugged in, they have a bunch of attributes that exist in the physical world, which for most lights are fixed: the location, the size and shape of the beam, the color, the focus. But there are other attributes that can be manipulated from the lighting console, attributes like brightness, and the speed at which the brightness changes. To control those attributes, the lighting designer basically writes a series of functions in the light console which will be run over the course of the show to produce the various effects.

Because they are going to be potentially writing several hundred functions, or cues, and manipulating several hundred fixtures, it goes much more smoothly if the fixtures are named systematically, so that fixture 102 is next to 103 is next to 104. Unfortunately more often than not, the placement of the pixtures and the sockets make it impossible, or at least extremely inefficient for even the most talented electrician to plug the lights into the sockets in such an orderly way. To solve this problem, there exists what is called a ‘soft patch.”

A soft patch is basically a hash in which the keys are called channels and the values are arrays. A fancy modern light board can have several thousand unique channel numbers, and all the fixtures are assigned to a channel so you end up with something that looks like this:

1: 203

2: 204

3: 354


5:631, 427

You’ll notice that there are two fixtures in channel 5, that is allowed. What is not allowed is having the same fixture in two different channels. One channel can have multiple fixtures, but each fixture can only belong to one channel. The cues are all written in terms of channel number, which means that if two fixtures are in the same channel they can no longer be (easily) manipulated individually, so it usually is only used for things like audience lights.

Once the fixtures are patched into the channels in a systematic way, so that no matter what the fixture numbers are, channels 102, 103, and 104 are next to each other, the cue writing begins. As I said earlier, writing cues is basically writing functions. The function for each channel takes the existing brightness of that channel, and moves it to a new brightness over a variable period of time. I don’t currently know the syntax to write such a thing, especially because in modern light consoles you can actually adjust the curve of the change, so it isn’t changing in discrete stages, or I guess it is probably changing in really tiny discrete stages. Consider this a challenge all you theatrically minded hackers! Then you can probably just work for ETC.

This post wouldn’t be complete if I didn’t at least may a little attention to moving lights, which perhaps are the best illustration of programing attributes in an object. In a fancy modern moving light, with a fancy modern console, almost all of the fixed attributes in a regular fixture can be controlled from inside the console. The fixture now in addition to having the brightness attribute, has tilt and rotation position attributes so it can point in pretty much any direction , red, blue, and green color attributes for color mixing, a size attribute which controls an iris, a focus attribute which controls the lenses. Each attribute is set equal to a numerical value, which in turn equates to a specific physical state. So, when you change the attributes in the computer you can physically see the effect on the object.

The last thing I want to mention is that writing these functions is actually a lot like programming. Each board uses a slightly different syntax, but they do generally all go something like this:

Channel 27 @ 35 ##changes attribute channel.brightness to 35%##

Record Cue 102 time 3 ##writes the function cue 102 such that it take 3 seconds to complete the change##

The biggest experiential difference is that on a light board each word in the program (record, cue, time, channel) has it’s own button, so you don’t have to type them. I think this would be a very useful tool for app programming as well, it would require a lot more buttons though.

Peace and Light