Yearly Archives: 2014

Chess / Programming — 2 Comments
29
Oct 14

Shipped!

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 →

Programming — No Comments
14
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");
  exit(1);
}

ofp = fopen(outputFilename, "w");

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

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…

General — No Comments
23
Sep 14

Chartered…

Engineers IrelandAfter a fair amount of pushing, I finally applied for the Chartered Engineer (C.Eng) certification from Engineers Ireland (or the IEI if you’re old) late last year, managing to land in the middle of the largest group of applicants in a decade thanks to a change in the law regarding civil engineering requirements and a change in how you apply for the C.Eng title.

I mentioned the C.Eng a few years back on here, it’s not the most widely-recognised certification in the IT industry in Ireland (though abroad, it’s a different story as usual), it’s more common in the civil and mechanical engineering fields (though it’s not completely unheard of in IT anymore and the IEI is pushing it in that field). The basic idea is that it’s an accreditation from your peers in the industry to effectively say “yes, he knows the difference between gluteus maximus and distal humerus”. Or less facetiously, it’s saying that the holder has worked in industry long enough and with sufficient responsibility to prove they’re a safe pair of hands for a project. In that sense, it’s a nice thing to have in that it’s reassurance to non-engineers that you’re competent and to fellow engineers that you haven’t got the same year’s experience seventeen times over without ever progressing (there being a large conceptual gap between seventeen years of experience and seventeen years of working).

Qualifying is a little bit strenuous- and I’m simplifying here because they’ve just changed the format of the application process; for the full story read the regulations and the guidance notes and for the software world, the guidance notes for computer professionals, which is new and which I bloody well could have used at the start of all of this! Basically, it starts with you writing an EPR (Engineering Practice Report) which covers everything you’ve ever done professionally from graduation to application, specifically from the point of view of the IEI’s listed core engineering competencies (which aren’t technical competencies, but practice-oriented competencies). These boil down to (and I am seriously oversimplifying here): Knowing Stuff, Using The Stuff You Know, Running Stuff, Telling People Stuff, and Doing Good Stuff.

Okay, I think I turned the simplification dial up too high there 😀 The list I kept pinned to the wall while writing my EPR actually read:

  • Knowledge and CPD
  • Application of knowledge
  • Leadership (Technical, Managerial, Commercial)
  • Communications
  • Professional Standards

You have to read the docs above to get a better idea of what those categories translate to in the real world; there are quite a lot of sub-categories as well and it’d take pages to explain them all. And for every role you’ve had since graduation, you’re explaining what you did and how what you did demonstrated your competency in those areas — yes, in detail, and yes, it’s all strictly confidential because of NDAs and the like, and no you can’t see my EPR (but the essays were based off this and this), and no, all paper copies get shredded so there’s no library of these things). It’s like writing a CV only on steroids and for most engineers it feels even worse (seriously, you feel like you work in marketing by the end of the process). Your EPR also lists off how much CPD (Continuing Professional Development, aka training) you’ve done for the last few years – down to each of the hours spent. And that level of detail is a bit hard to sort out in the IT world, where formal CPD is (in Ireland at least) bloody rare and hard to come by, if not a fast way to get your boss thinking you’re incompetent (seriously, I’ve worked in places where taking time off to go do a training course would have red-flagged you on your return because you’ve been to college, didn’t you learn all you needed there?). In fact in the IT world, even figuring out what counts as CPD is tough (and there’s quite a lot that counts oddly enough). That’s a big part of what your sponsor is meant to be helping you with, by the way – more than half the time I spent talking to mine was on that one point alone. Yes, you need a sponsor, and he or she has to be a chartered engineer themselves (actually you need two, but the second generally doesn’t coach).

You also have to write two short essays on topics in your industry, but those are fairly small potatoes compared to the actual work covered in the EPR and the effort of writing the EPR itself (although you can no longer choose your own topic for the second essay, there’s a list now being provided for each application date). Once that EPR is done, it gets signed and sent in to the IEI. It gets reviewed and if it’s up to scratch, you get a call in for a Professional Interview, which is a strange beast – an interview normally centers on showing a potential employer you’re competent with technical tests and that’s straightforward enough, but this one is being interviewed by peers to see if the way you do the technical stuff is up to snuff. It’s a bit meta and I found it quite hard to gauge. You give a ten-minute presentation at the start on how your career to date covers the competencies, and you can include things you’ve done since the EPR was sent in because sometimes, as with me, significant projects get completed in the interim – normally there’s a few months of a gap, but in my case there was nearly ten months of a gap; that’s what you get for landing in a large group of applicants. Ten minutes doesn’t sound like much – and it really, really isn’t. In the end I chose five specific examples, one per competency, and butchered the original draft of what I was going to say until I felt like I’d left out all the really neat stuff, and left it all get filled in by the questions and answers that fill the remainder of the hour (and the presentation was just over nine minutes in the end).

And once that’s done you wait to hear back. If you fail, they’ll give you a rough idea of why and a timeframe for reapplying. If not, you get details of the conferral ceremony.

And I got the email this morning saying congratulations, you’re now a Chartered Engineer. So I’ve had worse days.

← Older Entries