Tom Fosdick

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

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.

Reading Time: < 1 minute

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!

Reading Time: < 1 minute

My television offended me last night. No, not a television programme the actual TV. We haven’t quite got the networking in the house finished so I put a video file I onto a memory stick and shoved it into the telly’s USB port.

“Invalid File Format”

It told me. So I fetched a laptop, plugged that into a spare HDMI port and guess what – it played the file fine.

This may seem like a trivial issue but it does highlight just how exposed we as programmers are to the user. Errors are a particular area of concern because the marketing people will agonise for hours about exactly what the splash screen should look like, but they rarely have any input at all on what error messages should say.

Being able to provide the user with error messages that are useful and informative can greatly improve the user perception of the product – so when you’re writing error messages just have a think about how a user will react if they see it. Exception.ToString() might not be terribly useful to them, for instance.

Reading Time: 3 minutes

Beautiful design is great, but more often than not it doesn’t pay the bills. Pragmatism is one of the things I try to instil in the SEED students. There’s a time for complicated diagrams with lots of lines and boxes, there’s a time to elegantly partition the layers, but there’s also a time to ‘it it wiv an ‘ammer.

I was recently dealing with some simple comms routing. I needed to store information about an address composed of 3 parts;

• Sector – a byte in storage this identifies the organisation to send the message to.
• Node – 10 bits denoting the unit to send to, e.g a Fire Station or Fire Appliance (Engine)
• Port – a byte indicating the application to send to, e.g. the printer

The information that I needed to associate with this address was actually an email address that it translated to. So it’s an obvious tree structure, right? What’s more you can use an XmlSerializer to save and load the relationships – this is important because it needs to be maintained by a human. So let’s look at the XML.

<Sectors>
  <Sector SectorNumber="0">
    <Nodes>
      <Node NodeNumber="0">
        <Ports>
          <Port PortNumber="0">
            <EmailAddresse>postmaster@localhost</EmailAddress>
          </Port>
        </Ports>
      </Node>
    </Nodes>
  </Sector>
</Sectors>

Oh dear, that’s not very good. There could easily be a couple of hundred entries which would mean that the sector you’re editing might not be in view, similarly the node. It’s all a bit untidy really.

Also lookup isn’t simple, you need to do it in 3 stages, find the Sector, then find the Node, then find the Port. So the XML is untidy and the code is untidy. But the design is good, yes?

There’s a better way. I realised that 8 bits + 10 bits + 8 bits is 26 bits and a standard csharp integer is 32 bits. So we can just have one object that has Sector, Node and Port properties but has a "lookup" value that is an int and is made up from the parts of the address.

    [XmlElement]
    public class AddressRelation
    {
        [XmlAttribute]
        public byte Sector { get; set; }
        [XmlAttribute]
        public short Node { get; set; }
        [XmlAttribute]
        public byte Port { get; set; }
        [XmlAttribute]
        public string EmailAddress { get; set; }
        
        //so that we can get a lookup code, for comparison
        public static int GetLookupCode(byte Sector,short Node,byte Port)
        {
            return Sector << 24 | Node << 8 | Port;
        }

        public int GetLookupCode()
        {
            return AddressRelation.GetLookupCode(Sector, Node, Port);
        }
       
        //this makes serialization much easier
        public static AddressRelation CreateFromLookupCode(int LookupCode,string email)
        {
            return new AddressRelation() 
                { Sector = (byte)(LookupCode >> 24), 
                    Node = (short)((LookupCode >> 8) | 0xffff), 
                    Port = (byte)(LookupCode | 0xff) };
        }
    }

That’s great. When we call “GetLookupCode()” we get an int that uniquely represents that address. We can easily compare that with other objects.
Note that I didn’t override GetHashCode() or the equality operator because although the addresses might be the same, the emails may be different.
If you’re wondering what >> and << do then you need to look up bit shifting and bit masking…
They serialize nicely, too.

<AddressRelations>
    <AddressRelarion Sector="0" Node="0" Port="0" EmailAddress="postmaster@localhost0" />
    <AddressRelarion Sector="0" Node="0" Port="1" EmailAddress="postmaster@localhost1" />
    <AddressRelarion Sector="0" Node="0" Port="2" EmailAddress="postmaster@localhost2" />
</AddressRelations>

But how do we use it? Well actually the easiest thing to do is to load it into a dictionary, which should make the uses of some of the extra methods in the data class clearer…

    [Serializable]
    [XmlRoot(Namespace = "www.tomfosdick.com/blogstuff",
     ElementName = "AddressStore",
     IsNullable = true)]
    public class AddressLookup2
    {
        [XmlArray("AddressRelations")]
        public AddressRelation[] AddressRelations
        {
            get
            {
                return addressLookup
                    .Select(x => AddressRelation.CreateFromLookupCode(x.Key, x.Value))
                    .ToArray();
            }
            set
            {
                addressLookup = value
                    .ToDictionary(k => k.GetLookupCode(), v => v.EmailAddress);
            }
        }

        private Dictionary<int, string> addressLookup = new Dictionary<int,string>();

        public string GetAddress(byte sector, short node, byte port)
        {
            string result;
            if(addressLookup.TryGetValue(AddressRelation.GetLookupCode(sector, node, port),out result))
                return result;
            return null;
        }
    }

The advantage of using a Dictionary here and of the way I’ve shuffled the parts of the address into an int means that this will always be serialized in order, Sector most significant then Node then Port. So editing the XML by human hand will be easy – even if one is added out of sequence when the file is next machine written it will be sorted again.

The code is neat, concise and fast. The design is a bit mucky, it’s not clean and elegant but in all other ways – some of which are far more important than the cleanliness of design – this wins.