Oct 14


Okay, so it’s just a small chunk of a larger project that I’ve been messing about with for fun, but still, it’s nice to see work head out into the world.

A while ago, I started taking the chess games I was playing in the club and on chess.com and feeding them into SCID-vs-PC to run analysis engines on them; and because I’m a bit of a luddite in some ways, I wanted to be able to print off a report on them so I could sit down at the table with a cup of tea and a chessboard and play through a game while reading the engine’s analysis of it. If you don’t play chess yourself, the reason you’d do this is so you can see what moves and sequences of moves the computer thinks you should have played, and whether or not they were good lines for a human player to take – if the computer is saying “Oh, if you just played this sequence of seventeen moves perfectly you could have gained a half-pawn advantage here”, then you can pretty much ignore it unless you’ve been playing for decades and could actually do that in a game under time pressure (hint: I can’t 😀 ). On the other hand, if it says “Yeah, if you’d made this move, you’d have had checkmate in one move”, you probably want to see that so you remember the tactic in case you ever see it again 😀

Now SCID-vs-PC couldn’t print directly itself but it had a LaTeX report output function so I tried that, and found it relied on a LaTeX package called chess12 which was for LaTeX 2.09, even though LaTeX2e replaced Latex 2.09 in 1994 and chess12 itself hadn’t been touched since 1992. Turns out to be quite hard to get that old a setup to work, so effectively the LaTeX output was useless. But SCID-vs-PC is an open source project in a language I’ve been working in for decades and I did more than my fair share of LaTeX writing in college and afterwards (academia uses LaTeX pretty extensively because only a masochistic sociopath would entrust their thesis or research papers to Microsoft Word), so I figured it couldn’t be too hard to fix. And it wasn’t – I was able to get it to use a newer LaTeX chess package called skak, and to add in some nice graphing using ps-tricks as well as formatting things better on an A4 page using koma (all of which are standard LaTeX packages for all the sane distributions out there). But it has seriously renewed my belief that C++ is not a great language to do string processing in 😀

Anyway, the first version of the report code just shipped in the latest SCID-vs-PC version (4.13). I still have a few more ideas to bolt in there, particularly around the analysis graph and the detection of analysis scores in the PGN files (which seem to have different formats from just about every possible engine). And we already have some pretty serious refactoring in mind because the code’s a bit of a mess when it comes to output. But for now, if you load your game up in SCID-vs-PC and spit it out in LaTeX format, then run it through the standard latex-dvips-pstopdf chain (for some reason the latex2pdf tool chokes at the moment, that’s on the list of things to fix), you’ll get something like this:

Bodley 2014 Round 2

Round 2


Continue reading →

Oct 14

Boilerplate proven important!

BoilerplatePretty much every developer I’ve ever met (and I’d guess that it’s a really common trend in the IT industry as a whole) thinks of boilerplate code (the non-algorithmic stuff, the stuff that double-checks input values and checks called functions for returned error codes, that kind of thing) as being “the boring stuff”. We mostly tend to skip over it (or at least cover it very quickly) in college courses to focus on the algorithmic stuff because of time pressure and the need to teach the meat of things. But in yet another excellent EBSE result picked up on by NeverWorkInTheory (and if you work as a developer, you really ought to be reading that blog regularly), the actual worth of that simple boring boilerplate code comes through:

  • [A]lmost all (92%) of the catastrophic system failures are the result of incorrect handling of non-fatal errors explicitly signaled in software.
  • [I]n 58% of the catastrophic failures, the underlying faults could easily have been detected through simple testing of error handling code.
  • A majority (77%) of the failures require more than one input event to manifest, but most of the failures (90%) require no more than 3.
  • For a majority (84%) of the failures, all of their triggering events are logged.
  • Almost all catastrophic failures (92%) are the result of incorrect handling of non-fatal errors explicitly signaled in software.

That’s a massively important result to have proven, to the point where it’s now going to seem blindingly obvious to everyone in retrospect! 😀 Sure, you knew boilerplate was important, but: we call it boilerplate. As in boring, humdrum, same-old-same-old, don’t-waste-too-much-time-on-it, we’ll-come-back-and-add-it-in-later code. Some of the more recent methodologies like TDD try to address this, but leaving aside the point that they’re not used everywhere, and the point that they’re not always completely adhered to, be honest with yourself for a moment, in private — before you read that paper, did you actually know with any solidity just how important boilerplate code was or how many catastrophic failures it could so easily have averted (and pragmatically, how much money it could have saved for how little investment)? Did you budget developer time explicitly to writing it (instead of cut-n-pasting it out of a reference text somewhere)? Did you test the boilerplate code explicitly?

Quick example for how pervasive this is – go search for “how to open a file in C”. Dirt simple task, several tutorials and reference pages. Go on, take a look (if you don’t like C, pick some other basic operation in your favorite language). Pick out some sample code at random. Some of it is obviously boilerplate-averse:

FILE *fp;
fp=fopen("c:\\test.txt", "w");
fprintf(fp, "Testing...\n");

Okay, that’s obvious, but what about this?

FILE *ifp, *ofp;
char *mode = "r";
char outputFilename[] = "out.list";

ifp = fopen("in.list", mode);

if (ifp == NULL) {
  fprintf(stderr, "Can't open input file in.list!\n");

ofp = fopen(outputFilename, "w");

if (ofp == NULL) {
  fprintf(stderr, "Can't open output file %s!\n",

Looks better, but what happens if the logging system won’t let you write to stderr? Those fprintf() calls will fail but we don’t check their return values at all, let alone call ferror() there. Could that cause a catastrophic failure? Well, maybe not on its own, but since it would not report an error properly, it could contribute to one.

Maybe we’re being unfair here, these are tutorials after all, but that’s kindof the point – we always skip the boilerplate and assume it’ll be written in later but how many projects have you seen where chunks of code were obviously either adapted from this kind of reference or tutorial code without having the checks added in; or were entirely typed using the Control, C and V keys? And how many times have you seen the boilerplate get called every time?

I’ll admit, I always had boilerplate filed under “yeah, that’s kinda important” without any numbers being attached to it and the rider that not all of it was as important as the rest and you didn’t always need all of it in all cases (and okay, for prototype code, I still think that but I also think prototype code shouldn’t ever get into production and I’ve learnt to my detriment that it does on far too many occasions…). I’m going to be rethinking that particular attitude that after reading that paper. I’d quietly recommend you do the same…