Programming

Power-user Configuration Files Should Be Programs

Every program of any complexity needs to be configured. The traditional answer is to put this in some sort of text file, or something else that is fundamentally static data that must be read in and parsed. (That is, for the purposes of this discussion the Windows Registry is a static text file.)

If you are programming in a language that can take a program in at run-time, like Python, Ruby, or Perl, and you are targeting an advanced audience, the configuration file should actually be a program. In the degenerate case, the programming language can easily look like a configuration file, but then, if you need the full power of programming, it's sitting right there.

Update Dec. 24th: Similar thoughts w.r.t. build tools. I think declaration-based systems tend towards "demoware"; any arbitrary task can be made to look good in the demo of a declarative system, but it seems inevitable that before you can even blink, you need a scripting language. And ultimately, as with ant vs. rake, it's simpler just to pull in the full scripting language that to fall prey to Greenspun's Tenth Rule in your "simpler" declarative language.

NonMockObjects 0.2.0 Released

I've released NonMockObjects 0.2.0.

This release adds easy support for obtaining many variants of an object, which allows you to easily test that all combinations of some parameters have a certain invariant.

For instance, my Entry objects for this weblog can optionally contain a title, a link for the title, and a summary. The only constraint on that set is that a link affects a title, so you really need a title for the link to make sense, although it is permissible to have a link without a title in the database. By setting up my Entry creation function to indicate that each of those can either be None or contain a certain concrete string, I can obtain all 8 combinations of an entry with:

    for entry in data.variations_entry():