Archive for 2010|Yearly archive page

Closing the feedback loop

In Programming, Timeline on July 4, 2010 at 2:41 PM

I have recently spent some time reading the book Working Effectively with Legacy Code by Michael Feathers. I find it interesting because it describes techniques for making bad code better.

Feathers defines legacy code as code that does not have tests and further argues that code without tests is bad code. If you believe in this statement and have the intention of converting a piece of legacy code to code that is tested you face a problem: legacy code is often hard to test because it often has many dependencies that are hard to construct in tests. The main part of the book describes techniques for solving this problem: getting tests in place for legacy code.

In one of the introductory chapters the author talks about the effect that feedback has on changing code. Feedback here means the time it takes before you see the effect of a change in the code. If you have to manually perform some action in a GUI to see the effect of a change it will probably take you a minute ore two. If you have to do that many times you will perhaps become frustrated and bored. If you instead can run a set of automated tests to ensure that your change is good, the thing that you are working on can be implemented faster. The shorter the feedback loop, the better.

If you work in this modify-test fashion, you are likely leaving your editor and pressing a button to run your tests after you have finished an edit. In the book, Feathers suggests that this cycle can be shortened by running the tests continuously. In particular, the tests could be run as soon as you type a key in your IDE. That sounded interesting to me so I decided to implement a simple application for use in the Timeline project that do something similar.

The application is a small GUI application that looks like in the pictures below. When you start it, it will run all tests (using the console based test script) and display the output. If all tests passed the top part will become green, otherwise it will become red. The special thing with this application is that it monitors the file system for changes and whenever it detects a change, it runs the tests again. So as soon as you hit save in your editor, the tests will run again automatically. That way you never have to leave your editor to find out how the change you made in the code affected the system. (Of course this relies on writing tests as well as code.)

The application is running the tests on start-up. It will also re-run them every time it detects a change in a file.

The application ran the tests and they all passed.

The application ran the tests and some of them failed. You can quickly edit your code to try to fix the errors, and when you save, you find out if you fixed them or not.

I will start using this tool when working on Timeline and see how it affects my productivity and code quality.


Can I connect a microphone to line-in?

In Questions on January 23, 2010 at 11:55 AM

These are a few notes from reading articles on the web trying to answer this question.

A simple sound card usually has line-in, line-out, and mic connections. Line (line level) refers to the strength of the signal. Signals from microphones (or pickups from guitars) are typically weaker than line level and have to be amplified.

The mic input on a sound card probably has some amplifier but I was not able find out exactly how this worked. There also seems to be a difference between “computer microphones” and more advanced microphones. If you use a more advanced microphone you probably plug it into a mixer which has a preamp. The output from the mixer can then be connected to the line-in on the sound card.

Or is the only difference between a “computer microphone” and a more advanced microphone the connector? It feels like a more advanced microphone requires a better preamp than the one that (presumably) sits behind the mic input on sound cards.

Furthermore, the difference between a sound card and an audio interface only seems to be that an audio interface is a more advanced sound card: better AD/DA converters, lower sampling latency, and better sampling rates and bit depth. It is also common for audio interfaces to be external. Maybe because they often provide more inputs and outputs.

If you know anything about how the mic input on regular sound cards works I would be happy to read your comments about it.

Unit testing revisited

In Programming, Timeline on January 4, 2010 at 9:57 PM

Every time I make a new release of Timeline I get a little nervous. Nervous that the program will not work or do something unexpected. One obvious activity that helps find bugs in the program is testing. Usually when I work on a new feature I try it out as I go and make sure it works. The problem is that I can’t say with confidence that other features still work: features I haven’t touched for this release or haven’t used in a long time.

One solution is to test all features before every release. That is a tedious job. Especially when you make releases often as we do (once a month). I have experimented a little with unit testing but find it quite difficult. We only use it in a few places to ensure correctness of a few functions. A podcast and an article pushed me intro trying unit testing again and also working in a test driven development fashion.

The podcast

In FLOSS Weekly 87: Extreme Prgramming With Kent Beck topics such as extreme programming (XP), test driven development (TDD), pair programming, and design patterns are discussed. It does a great job of demystifying these buzzwords and makes you understand the core ideas behind them.

In particular I like the fact that they go back and talk about a well designed program as one that has low coupling and high cohesion. Later they talk about how techniques such as TDD help achieve that.

The real eye-opener for me after listening to this show was that the purpose of writing unit tests is not only to test the correctness of a function: it is also designing your code in such a way that it can be tested. And if it can be tested it probably has low coupling and high cohesion which in turn makes it a well designed program. Kent mentions in the show that having the correctness of a function tested is just “a really nice side effect” of writing unit tests.

The article

Now I had a slightly more positive attitude towards unit testing and I wanted to try it out in practice by refactoring some code for Timeline. One thing that is typically difficult to test automatically is GUIs. In Timeline there is at least one GUI component that is quite large and contains much logic. I would be really happy if we can test it automatically somehow.

Browsing the net for answers I came across this excellent article: The Humble Dialog Box by Michael Feathers (found via How can I unit test a GUI?). It describes a totally different approach to designing GUIs that really fascinated me. You remove almost all logic from the GUI and instead put it into another object which can much more easily be tested.

The experiment

I decided to try the idea with a humble dialog box on the category editor in Timeline. It is a very simple dialog which makes it suitable for trying this approach.

For those of you interested, you can read the source code for this dialog before and after (source code for test).


Although the overall length of the code increased I think the separation between the GUI and the controller (the logic that was previously in the GUI) is slightly more readable. Most of the code fore the GUI is now extremely simple. So the increase in code size is not such a big issue I think. It also feels quite nice to be able to test the simple logic of this dialog.

I am still not convinced that unit testing is the answer to all problems regarding ensuring high quality. And maybe that is not the case either. After all it is just one means to get high quality code. I think doing code review is another good means to that same end. I might try this approach again on a more advanced dialog.

A side note

The Flawed Theory Behind Unit Testing (from Michael Feathers’ Blog) expands on the idea that unit testing is just a means to an end where the end is high quality code. From the post:

In the software industry, we’ve been chasing quality for years.  The interesting thing is there are a number of things that work.  Design by Contract works.  Test Driven Development works.  So do Clean Room, code inspections and the use of higher-level languages.

Go read the whole article if you are interested in knowing what it is that makes the above mentioned things work.