#if Programmer Is Forgetful

Reading Time: 2 minutes

Here’s a trick that I use quite a lot…

#if DEBUG
    DumpCallStack();
#else
    #error REMOVE BEFORE RELEASE - Tom added this looking for bug 1223
#endif
Lily the Cat
You Really Don’t Want To Upset Her…

Why on earth would anyone want to do that? Well sometimes when you’re looking for a bug you add either debugging code or experimental code that you think might fix the issue. This code is often not of production quality. Then you find the actual bug and it’s nowhere near the new code, or you have to go off and do something else. You then forget about the code that you’ve added, it gets checked in and eventually makes it out into a release. Then you end up with Ariane 5 when it hits the customer site…

So why not just wrap it in #if DEBUG?

There are 2 reasons;

  1. Because over time you end up with a hell of a lot of #if DEBUG and your actual code gets difficult to read.
  2. More importantly because your debug version starts to radically depart from the release version. Consider the above – generating a stack trace is a relatively expensive operation and ultimately this writes it to a file. This quite substantially alters the way the timings in the code and the write to file has some (limited) synchronisation effects. This could actually mask problems.

Ultimately the more similar the debug version is to the release version the maintainable the code is and the more chance there is of a problem being spotted before the code gets to the customer. Experimental code and any form of debug code that could cause the debug version to function significantly differently to the release version should be removed.

Linux Equilibrium

Reading Time: < 1 minute

Somewhere in YorkSEED Software is fairly heavily Microsoft orientated. It’s no secret that I’m a fan of Linux, indeed I started my career as a *nix developer. In 2000 though I was looking for my next career move and there just weren’t enough opportunities in the *nix world, so I jumped ship and became a Windows developer. Since then Linux has had to take a back seat.

However I recently ordered a new NAS and a Raspberry Pi. This means that I currently have;

  • My main workstation (Windows 7)
  • A backup workstation (Windows 7)
  • A SQL Server (Windows 2008 Server R2)
  • A Windows 8 Test Machine
  • A Windows 7 Test Machine
  • A Windows 7 laptop

But I also have;

  • A Linux dev / test machine (running Gentoo)
  • An Android smartphone (HTC Wildfire S running Cyanogen)
  • A (Linux based) ADSL router
  • A backup (Linux based) ADSL router
  • A (Linux Based) NAS
  • A Raspberry Pi

For the first time since 2000 I have got as many Linux machines as I have Windows, possibly more as there are other pieces of hardware that I have which could also be Linux based – I’m looking suspiciously at my TV for starters…

The downside of all this is that I think I may have just blown any pretence I might have had that I am not a geek. Hom hum, I can live with that!

Acts of Technological Faith

Reading Time: < 1 minute
Boiler Mainboard
Boiler Mainboard

We’ve all visited the temple of the Great God Rebootus – praying that a magic key sequence or just turning it off and back on again will solve our problem.

When my boiler stopped working last night though the Great God Rebootus didn’t come through for me. So before I phoned the plumber I thought I’d just give another ancient ritual a shot – it works surprisingly often.

It’s called Reseatum Konnectorum – the basic procedure is to unplug and reconnect every connector you can find. Corrosion, vibration, there are all sorts of reasons why something that was once a good connection can go bad. It’s well worth giving it a shot, especially when you’re facing a big bill just for calling someone out to look at it.

So I now have a working boiler again. Fingers crossed it will continue to do so!