A while back I ordered a Visual Signal Indicator from Delcom. I had great plans to make it flash when I received a call on Lync, and to generally help me keep track of the health of the project I was working on. I looked at the C# example code provided by Delcom and initially was hesitant to get started. I was already planning out how I would need to write a library that would simplify the madness of unravelling the various settings the example provided. All the commands were wrapped to Click events in a Windows Form app which led me to not get a start on the project as quickly as I had hoped.

Recently I have just started working on a new project and as we were blessed with a build server and a mostly working build I was reminded of this project that had been put on the back burner. This time I approached it with a far more pragmatic mindset and just wanted to get something working. I wasn’t looking to win any UI awards and I didn’t want to architect it any further than what I needed to get the job done.

This is what the light can do:

• Turn on any of three colours at various power levels
• Flash lights on a timing interval
• Make beeping sounds
• Accept input (the light itself is a button)

I still haven’t quite worked out exactly how the button works on the light, but I was able to easily set it so it would beep if I pushed the button thanks to a built in setting. This however wasn’t something that I especially needed anyway.

My needs however were simple. I had three colours to choose from, red, green and yellow. I also wanted to be able to make the light flash while a build was running and continue to show the colour of the previous build result.

A Redis interface to the light

Another technology I have been looking into recently is Redis. It’s a key value store which lets you hold some simple data structures. It also has an excellent publish/subscribe model which allows messages to be broadcast to interested clients.

After using this to store some configuration information for some tests to great success I thought about using Redis to provide an interface into the inner workings of my build light. By holding the desired state of the light in Redis all I would need is to signal that a change had been made and all would be well.

Rather than starting from scratch I chose to extend the existing example code as it was already working well. The work I needed to do involved automating the interaction with the UI, a task I was already familiar with and to do it within the application itself, a breeze. Working this way also provided full visibility into what settings were being sent to the light.

The changes I needed to make were:

• Opening a connection to the light on startup
• Ensuring that the light’s state on startup matched the state stored in Redis
• Applying styling to the On/Off/Flash lights to better indicate the current state
• Listening to a channel on Redis for changes to the light state
• Updating the light state as applicable

I decided to leave the buzzer and switch control as an exercise for another day as these were not essential to my plans (and the buzzer would likely annoy me).

I decided to use a Redis hash (a Dictionary) to store information about the desired state of the light. In Redis, hashes can have individual fields changed making it fairly easy to work with. I chose to set up the following fields for each colour light:

• state with 0 representing off, 1 on, and 2 flashing
• power representing the power level or intensity of the light
• onduty specifying a time interval for the light to be on when flashing
• offduty specifying a time interval for the light to be off when flashing
• offset specifying an offset when flashing so that the flashing of lights could be synchronised (e.g. flashing between red and green)

These all corresponded to appropriate controls in the example application.

The code for the solution can be found in my HIDVIWINCS repository on GitHub.

Getting the build status

Of course, this was only part of the battle. Fortunately obtaining the status of the latest build was reasonably straightforward. First, I set up an Enum to keep track of the light’s current colour.

1
2
3
4
5
6
7
8
9
10

namespace ConsoleBuildMonitor
{
  public enum LightColour
  {
    Off,
    Red,
    Yellow, // On my light it is yellow, on others, blue
    Green
  }
}

With this simple task out of the way I could set up individual methods to update the appropriate hashes in Redis. The library I used in the build monitor was Booksleeve, a slightly older version than the client I used in HIDVIWINCS. Setting the colour of the light was as simple as folows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

private static void SetLight(LightColour colour)
{
  var db = int.Parse(ConfigurationManager.AppSettings["RedisDatabase"]);
  using (
      var conn = new RedisConnection(ConfigurationManager.AppSettings["RedisHost"],
          int.Parse(ConfigurationManager.AppSettings["RedisPort"])))
  {
    conn.Open();
    conn.Hashes.Set(db, "red", "state", new[] {color == LightColour.Red ? (byte) 1 : (byte) 0 });
    conn.Hashes.Set(db, "blueyellow", "state", new[] {color == LightColour.Yellow ? (byte) 1 : (byte) 0 });
    conn.Hashes.Set(db, "green", "state", new[] {color == LightColour.Green ? (byte) 1 : (byte) 0 });
    conn.Publish(ConfigurationManager.AppSettings["RedisUpdateChannel"], "1");
  }

  this.lightColour = colour;
}

Then to make the light flash I simply needed to make sure that the state was set appropriate for the current light.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

private static void Flash()
{
  var db = int.Parse(ConfigurationManager.AppSettings["RedisDatabase"]);
  using (
      var conn = new RedisConnection(ConfigurationManager.AppSettings["RedisHost"],
          int.Parse(ConfigurationManager.AppSettings["RedisPort"])))
  {
    conn.Open();
    conn.Hashes.Set(db,
        this.lightColour == LightColour.Red ? "red" : this.lightColor == LightColour.Green ? "green" : "blueyellow",
        "state", new[] {(byte) 2});
    conn.Publish(ConfigurationManager.AppSettings["RedisUpdateChannel"], "1");
  }
}

It is worth noting that the message sent on the update channel doesn’t actually matter at this point in time as it is simple the receipt of the message that triggers an update to the light’s status.

Finally the code required to check the build status is reasonably straightforward:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

private static void ExecuteLoop()
{
  var buildStatus = new Dictionary<string, BuildStatus>();
  using (var collection = new TfsTeamProjectCollection(new Uri(ConfigurationManager.AppSettings["TfsProjectCollectionUrl"])))
  {
    collection.Authenticate();
    var bs = collection.GetService<IBuildServer>();
    var re = new Regex(ConfigurationManager.AppSettings["BuildPattern"]);
    var ls =
        bs.QueryBuildDefinitions(ConfigurationManager.AppSettings["TfsProject"])
            .Where(d => re.IsMatch(d.Name)).ToList();
    do
    {
      foreach (var b in ls)
      {
        var latestBuild = bs.QueryBuilds(b).OrderBy(x => x.StartTime).LastOrDefault();
        if (latestBuild == null) continue;
        if (!buildStatus.ContainsKey(b.Name) || buildStatus[b.Name] != latestBuild.Status)
        {
          switch (latestBuild.Status)
          {
            case BuildStatus.Failed:
              SetLight(LightColour.Red);
              Log.Error("Build {Build} Failed ({RequestedFor}) - {BuildId}", b.Name,
                latestBuild.RequestedFor, latestBuild.BuildNumber);
              break;
            case BuildStatus.PartiallySucceeded:
              SetLight(LightColour.Yellow);
              Log.Warning("Build {Build} Partially Succeeded ({RequestedFor}) - {BuildId}", b.Name,
                latestBuild.RequestedFor, latestBuild.BuildNumber);
              break;
            case BuildStatus.InProgress:
              Flash();
              Log.Information("Build {Build} In Progress ({RequestedFor}) - {BuildId}", b.Name,
                latestBuild.RequestedFor, latestBuild.BuildNumber);
              break;
            case BuildStatus.Succeeded:
              SetLight(LightColour.Green);
              Log.Information("Build {Build} {Status} ({RequestedFor}) - {BuildId}", b.Name,
                latestBuild.Status, latestBuild.RequestedFor, latestBuild.BuildNumber);
              break;
            default:
              Log.Information("Build {Build} {Status} ({RequestedFor}) - {BuildId}", b.Name,
                latestBuild.Status, latestBuild.RequestedFor, latestBuild.BuildNumber);
              break;
          }

          buildStatus[b.Name] = latestBuild.Status;
        }
      }

      Task.Delay(5000, _cancellationToken).Wait(_cancellationToken);
    } while (!_cancellationToken.IsCancellationRequested);
  }
}

The code required to integrate the light to the build monitor was actually the simplest bit of code in the whole thing. Indeed I haven’t shown the most complex part of the code because it still needs work, but it handles restarting the loop if it fails and shutting the whole thing down cleanly.

Importantly it means that the monitoring tools are well separated from the actual control of the light. They no longer need to even exist on the same computer. Indeed during my initial testing I had Redis hosted on one computer, the light on another and I was using a Redis client on a third.

Photos and videos of the build light in action!

▶

So I’ve been working on some on some Project Euler problems to make sure I’m as ready as possible for some upcoming job interviews. If you aren’t already aware of Project Euler go and check it out.

I have been using a mixture of C# and F# to solve the problems. I have been wanting to expand my F# knowledge for some time now, so my strategy so far is to re-implement re-usable components that I had written in C# into F#. Because I’m a huge fan of recursion many of these re-implementations were extremely straightforward as I was already following a common functional pattern.

Eventually I came across Problem 57. The problem involves evalutating an expanding formula into the appropriate fractional result. Nb: Code found in this post provides a partial solution to this problem.

These are the first four iterations as described in the problem:

1 + 1/2 = 3/2 = 1.5
1 + 1/(2 + 1/2) = 7/5 = 1.4
1 + 1/(2 + 1/(2 + 1/2)) = 17/12 = 1.41666...
1 + 1/(2 + 1/(2 + 1/(2 + 1/2))) = 41/29 = 1.41379...

So I am essentially working with a tree of operations. Each iteration can be based on the one preceding it. The problem requires that each of these is able to be reduced to a single fraction. Therefore the pieces that I need are:

• A data structure to hold the expression
• A function to reduce the expression to a fraction
• A function to determine the next iteration of the expression

I won’t be looking at the last of these three pieces here (I’ll leave that as an exercise for you).

Also, it would be kind of nice if I had a function to show me a string representation of my expression so that I could easily check I’m on the right track (because that is generally easier than trying to understand an object graph plus I already had a string representation to target).

So when it came to picking the data structure I was reminded of discriminated unions in F#. These allowed you to define different but related structures. The relationship could then be used to enable pattern matching to deal with a specific case.

The expressions that I needed to support were quite simple, add, divide and of course a constant value. In this case I’ll throw caution to the wind and use an integer.

1
2
3
4

type Expression =
  | Constant of int
  | Add of Expression * Expression
  | Divide of Expression * Expression

Here my constant values are stored in a Constant object which is itself an expression. Add and Divide are both comprised of a pair of expressions. Expression is a recursive type and can either have constant leaf nodes of branches which perform an operation.

I could have made a simplification as in the values I was constructing the left operand of Add and Divide would always be a constant, but this more flexible structure generally felt better.

I could now easily construct the first iteration like so:

1

let root = Add(Constant(1), Divide(Constant(1), Constant(2)))

This is rather verbose and difficult to read and is only going to become more difficult as we increment the value. So the next thing I’m going to do is create a function which will create a string version of the expression so that I can review it by hand.

Now when I am thinking about the string function (I’m going to call it stringify) I can think of the various types:

• Constant will just be a ToString() call on the value.
• Add and Divide will be recursive and call the stringify function of both expressions and separate the results with the appropriate operator.
• Also we want to surround the denominator in brackets if the denominator is not just a constant.

Putting these into practice becomes extremely straightforward (ignoring that I haven’t used a StringBuilder).

1
2
3
4
5
6

let rec stringify v =
  match v with
  | Constant(x) -> x.ToString()
  | Add(x, y) -> (stringify x) + "+" + (stringify y)
  | Divide(x, Constant(y)) -> (stringify x) + "/" + y.ToString()
  | Divide(x, y) -> (stringify x) + "/(" + (stringify y) + ")"

What struck me as awesome was the amazing simplicity of this code. Using pattern matching I was able to easily address my special case for including brackets and give the other cases in a straightforward manner as well. The F# compiler even helped by ensuring that I matched all possible patterns (it uses wizardry known as type inference to determine that v is an Expression type).

I could then execute my stringify function on root to check that everything worked as intended. The delightful part at this point was that it did. The next step was to reduce one of these expressions down to its smallest possible form. This too would prove to be trivial. Here’s the code I came up with:

1
2
3
4
5
6
7
8
9

let rec reduce v =
  match v with
  | Constant(c) -> Constant(c)
  | Add(Constant(a), Constant(b)) -> Constant(a + b)
  | Divide(Constant(a), Divide(Constant(b), Constant(c))) -> Divide(Constant(a * c), Constant(b))
  | Add(Constant(a), Divide(Constant(b), Constant(c))) -> Divide(Constant((a * c) + b), Constant(c))
  | Add(a, b) -> Add(reduce a, reduce b) |> reduce
  | Divide(Constant(_), Constant(_)) -> v
  | Divide(a, b) -> Divide(reduce a, reduce b) |> reduce

Here I looked at the sort of smaller patterns I was dealing with and repeatedly called reduce until I achieved a desirable pattern. Again, the simplicity of each pattern and its resulting reduction really drove home the incredible benefit provided by pattern matching.

Pattern matching is a technique that I really miss when I use languages like C#. For this reason alone I would really like to see F# become more widely adopted so it may be finally possible to use it in projects where we are currently confined to a single language.

I have written a number of code generating tools over the years, especially focussing on the generation of SQL from some sort of structure. Looking at how easily I was able to solve the problem above using F# I wish that I had some of these techniques at my disposal then.

Finally, I made a slight modification in the code above which will prevent it from being used verbatim to solve the Euler problem.

I’ve already alluded to the fact that I love working on the console and in Windows, PowerShell is my console of choice. I get to throw all sort of things through it’s object based pipeline and play with them in fun and exciting ways.

I also have added to my path a large number of the GnuWin32 tools which are sometimes better at dealing with raw text like sed and occasionally grep instead of PowerShell’s Select-String. By having these utilities in my path I can better deal with being stuck in pure cmd.exe.

Anyway, one of my favourite utilities is Clip.exe. It comes out of the box in Windows 7 and presumably Windows Vista. I rolled my own for Windows XP although I believe that it may be available as part of a resource kit. In case it isn’t immediately obvious, what Clip.exe does is takes whatever is fed to Standard Input and saves it to the clipboard. Very useful indeed.

The clipboard is a great place for storing some data temporarily and I quite frequently find that I want to process it in various ways. I have a bunch of command line utilities that are perfect at this, but I have to save the contents to a file and pass that file to the utility. That sounds like busy work. Fortunately the GnuWin32 utilities and PowerShell both read from standard input. What I need is a tool that does the opposite of Clip.exe and writes the contents of the clipboard to standard input. What I need is Paste.exe. So I wrote it.

A simple compile…

$ csc .\Paste.cs

And after copying to my Utilities folder (which is in my path) I’m good to go.

An added bonus is that I handle files copied in Windows Explorer. These will be returned as a list of filenames.

By default I add an extra Environment.NewLine and the end of the content as it tends to make the whole thing neater in the console. If this is causing you hassles use the -r switch which will paste the contents in their raw form.

Paste in Action

I use paste to quickly view the clipboard contents:

$ paste

To strip formatting in the clipboard:

$ paste | clip

To filter clipboard contents:

$ paste | grep -i batman

As subjects of a PowerShell ForEach-Object:

$ paste | % { $_.Length }

If you find a common pattern, share it in the comments below.

Lately there has been some peculiar activity on the iTunes Australia store. Some of my favourite shows are becoming available only a day after being aired in either the USA or Britain. For the record, these shows are:

• Doctor Who
• Game of Thrones
• Mad Men

Both Game of Thrones and Mad Men have season passes available for just over $30. Oh, and that’s HD. A quick look and you are looking at about $50 for a Blu-Ray of season 2.

So suddenly we have an influx of shows that are timely and cheap (relatively speaking). Sure, they encumbered with the iTunes DRM and you have to use iTunes but I like to think that this is a good sign. It seems like Australia has become a test bed for online distribution.

Aside from the DRM (and the fact that you are restricted to Apple devices) there is one glaring omission, communication. The scheduling of when shows will be available is largely hidden until they are released. So right now I’m going on faith that the prompt deliveries will continue for the remainder of the season but obviously have no guarantee that they will. Even if some insight was given into when the next episode will be released that would be an excellent start.

The next issue is the overall experience. I have a setup with a Mac Mini and an Apple TV connected to my television. It’s a shame that I kind of need both. The Mac Mini has been delegated as the storage server and it can hold all my iTunes downloads. However the full screen experience is somewhat lacking and generally requires fiddling around with a trackpad and keyboard. The Apple TV on the other hand delivers a fantastic (if somewhat limited) full screen experience as you would expect. However there is no way to reliably cache your shows on it so as to avoid disturbances due to issues involved in communicating with Apple’s servers. The device itself has a substantial buffer, but to buffer an entire show generally involves starting it, hitting pause and waiting for it to download completely without looking at anything else in the meantime.

So this is where the Mac Mini comes into its own. I can open up iTunes and download the shows I have purchased and share them with my Apple TV through the Home Sharing feature. Unfortunately the Apple TV interface for Home Sharing isn’t as slick as the regular TV interface, but once you get going it doesn’t really matter. The Apple TV also serves as a great way to browse the iTunes store and purchasing items is really easy.

And with this ease comes a small snag. It appears (and has been confirmed by a support request with Apple) that when you purchase a season pass on an Apple TV you cannot set up iTunes to automatically download new episodes as they become available. You can still download these episodes manually though, so the limitation won’t stop you from downloading your purchase shows, but it does make it just a little bit harder.

The workaround of course is to perform the actual purchase via iTunes on the machine that you want to download the episodes to. So unfortunately for the moment the keyboard and trackpad attached to my Mac Mini are there to stay.

Fortunately iTunes does send an email when a new episode of a show you’ve subscribed to is released, so this acts as a prompt to kick off the manual download.

I love the command line. Very rarely do I ever not have a console window open. Consequently I tend to do all my source control activities from the command line. However I’m not a command line bigot. I know when the console has reached its limit and I have to resort to a more graphical tool. With Mercurial this hits hard when doing complicated diffs and of course the dreaded three way merge. Fortunately Mercurial has been configured out of the box to recognise my merge tool of choice so when Mercurial finds a conflict during a merge it can show me a GUI based tool that will help me get on with my work.

But what about the times when I want to review the changes that I’ve made? This is especially important when I’m about to push changes and inflict my work on other developers. It’s also a great opportunity to spot issues which may result in broken builds.

For small changes I still stick with the console and run:

$ hg diff

This gives me a fairly simple diff of my changes. I can make this even better by enabling the color extension which will spruce up my command line output by adding colour to a myriad of different commands, but importantly for this case, diff. By marking insertions in green and deletions in red I can get a very quick overview of the changes I have made. To enable this extension I just add the following to my mercurial.ini file.

1
2

[extensions]
color =

However a basic diff is somewhat limited. It generally won’t take the filetype into consideration and a small change to a big line can be difficult to spot. Fortunately there are a number of great diff tools out there. The one I use is Beyond Compare 3 (you’ll need the Professional version if you want its excellent three way merge feature). It isn’t free, but for a tool I use every day I feel that it has been worth it many times over.

These instructions should work with any diff tool capable of understanding command line parameters and able to compare two folders.

To integrate our graphical diff tool with Mercurial we’ll turn to another extension, Extdiff. This extension helps you use a graphical diff tool to compare two different changesets (or a changeset with the current work in progress). Importantly it also makes sure that if you make any changes to the working copy they will be propagated back when you are done. So if your diff tool is good at moving changes from one file to another and editing files in place you can very easily clean up your changes. Enabling the extension is straightforward.

1
2
3

[extensions]
color =
extdiff =

This has however only enabled the extdiff command in Mercurial. If we want to configure our diff tool of choice we have to make one final change.

1
2
3
4
5
6

[extensions]
color =
extdiff =

[extdiff]
cmd.vdiff = C:\Program Files (x86)\Beyond Compare 3\BCompare.exe

Here I’ve added the extdiff section and created a new command vdiff which will use Beyond Compare as my diff tool. So now to use Beyond Compare to view my changes I just need to run the following:

$ hg vdiff

I can create as many of these commands as I like if I want to enable different diff tools. It is also possible to parse arguments to the diff tool. For instructions check out the Extdiff documentation page on the Mercurial wiki.