Welcome.

legit | 17 January 2009

You have either just stumbled on this blog from somewhere else on the internet or you’ve found it from my previous location: codingnotes.wordpress.com.  But you are in the right place, and I welcome you.  As I have had some free time recently due to currently being unemployed and searching for my first Career job I have been getting my personal website up and running and so this is the new location of my Coding Notes blog. I don’t have anything in depth to post on today so I thought I would just point out that first if you have a bookmark or an rss feed pointing to the wordpress.com location you should update it to this location (codingnotes.alephcipher.com).

Secondly, I would like to point anyone interested in software life cycle models over to the Songbird teams blog. They have written, along with many other excellent posts, a series on their path of moving from a waterfall development model to an agile model.  It is really interesting to hear the differences that it made and to see an example of their new development process.

Check out the first three parts of the “Songbird path to agility” series here: part i, part ii, part iii.

I hope you enjoy them as much as I have, and I look forward to posting on more topics shortly (I’d love to hear any comments or suggestions in the comments).

- Legit

The Zune Bug and the if/else Statement

legit | 12 January 2009

For those that haven’t heard, the Microsoft Zune’s OS recently ran into trouble relating to 2008 being a leap year.  The Operating System got stuck and was unable to operate for an entire day due to a bug in the code, thankfully without a patch the Zune started right back up the next day happy as ever.

Over at “Freedom to Tinker” they wrote up a nice overview of the bug (including code):

On December 31, some models of the Zune, Microsoft’s portable music player, went dark. The devices were unusable until the following day. Failures like this are sometimes caused by complex chains of mishaps, but this particular one is due to a single programming error that is reasonably easy to understand. Let’s take a look.

Here is the offending code…

Read the full post here “Debugging the Zune Blackout“.  This particular bug represents the problem of not covering all of the cases involved in a particular if/else; in this case the else was left out.  The problem could have been solved by breaking out of the while when it was a leap year but not over 366 days.

This reminded me of the Gaurded Command Language(PDF) written by Dijkstra in 1975 (wikipedia article).  In this theoretical language Dijkstra presented the If statement with a unique twist.  The if statement consisted of several boolean conditions and their subsequent code to be executed.  So for a very simple example:

if
  if A then AX
  if B then BY
  if C then CZ
fi

The twist comes on evaluation of the if statement, unlike most modern languages (I don’t know of any that aren’t like this) in which when none of the statements in an if/else are evaluated to true the program simply continues executing, Dijkstra’s Guarded Command Language was different.  Three basic rules existed for the if statement:

1. All of the boolean conditions are evaluated.
2. If one or more are true then one (and only one) is arbitrarily chosen to be executed.
3. If however, none of the boolean conditions are true the program aborts (crashes).

This is certainly much more strict than modern languages, thankfully, but it presents the nice idea that unless all of the cases of a given circumstance are covered then the program will not be capable of continuing.  Furthermore by preventing the continuation of the program when no true conditions exist the language makes it easier to debug because the problem does not cascade down into some other section of code but rather crashes exactly where the problem originates (the if).

On a more philosophical level the Guarded Command Language deals with if’s in this way:  When a child is asked by their mother if they want an ice cream cone and the mother only expects the answers ‘yes’ or ‘no’ then the mother is ill-equipped to deal with the scenario that the child may say ‘later’.  Granted we humans are smart and can on the fly deal with situations like this (ie. the mother wouldn’t “crash”) it presents the problem that when dealing with programming in a highly logical environment the fact that when not all possible answers to a problem exist it means that something is not being dealt with, which can cascade down into other problems.

The Zune bug presents a nice example of this, and while it is fairly small its an interesting and yet important issue involved in programming.