This blog is different – I have actually kept at it. The idea has been to set realistic goals, in this case of a post every month. I have tried to learn something new every month and document it in a comprehensive manner and I think I am quite pleased with the result and the fact that it keeps me trying to grow and develop.

This month I have upped sticks and moved from my home in the UK to live in New Zealand. What I have learnt this month is that if you do something like this it pretty much takes up all your time, hence this somewhat cheating entry.

In order that I can do next months post I have a real deadline for sorting out broadband, and a house, oh and a job – there are some details to attend to.

Last year I decided to seek a peer review of the cake and who would be better to do that than mum. She said it was very nice but I had used so much fruit that the cake tended to fall apart, now that she mentioned it all my Christmas cakes have fallen apart. She said I needed to use more flour in the mix as this would get the cake to bind.

And she was right, this years cake is much better.

It just goes to show that no matter how good I think I am doing having another set of eyes can make the results even better.

Luckily this problem only seemed to afflict some projects in the solution so I could compare the projects that worked with my current project. It turned out that all the projects that worked specified CODE_ANALYSIS on the Build Tab.

The project that was causing the problem had used a check box on the Code Analysis tab labelled “Enable Code Analysis on Build (defines CODE_ANALYSIS constant)”.

Now you might presume given the label that checking the box would define CODE_ANALYSIS – I know I did, however when I looked into the project XML file it turns out it did not.

Projects that checked the cleckbox on the Code Analysis tab looked like this

<PropertyGroup
 Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>bin\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <RunCodeAnalysis>true</RunCodeAnalysis>
</PropertyGroup> 

and projects that used the old style CODE_ANALYSIS define on the build tab looked like this.

<PropertyGroup
 Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>bin\Debug\</OutputPath>
  <DefineConstants>TRACE;DEBUG;CODE_ANALYSIS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <RunCodeAnalysis>false</RunCodeAnalysis>
</PropertyGroup>

Notice that where we used the checkbox on the Code Analysis tab the CODE_ANALYSIS constant is not defined.

Sometime when I am trying to sort out bizarre little details like this I wonder if it really is a good use of my time. However later I was talking to another developer and he had run into the issue where SupressMessage was not working on the build server and his response had been to turn FxCop off for that project, when we turned FxCop back on there were hundreds of errors that now needed fixing – my conclusion was that it is worth the time to get to the bottom of this problem.

The behaviour that was required was that each LABEL to be highlighted would have the its FOR attribute value listed in a global array. Each LABEL needs to be wrapped in a SPAN with a specific CLASS (this was due to the CSS delivered by a design agency) and then the highlight prompt displayed.

In reality I would write the behaviour tests first however as I want to contrast different methods of testing I will list the code first.

function HandleOneLabel(label,labelForId) {
  // add the tip icon with a derived ID
  // prepend to get the vertical position right in IE8
  label.prepend("<span id='" + this + "_tip' class='tip'></span>");

  // display the correct prompt
  $(".normalPrompt", label).hide();
  $(".highlightPrompt", label).show();
}

function HandleAllLabels() {
  if (typeof allLabels !== "undefined") {

    jQuery.each(allLabels, function (index, value) {
      // find the label element for each label listed
      var label = $("label[for='" + this + "']");

      HandleOneLabel(label,this);
    });
  };
}

Testing HandleOneLabel seems relatively straightforward, for this project I was using jasmine as the testing framework so I wrote a test like this.

describe("HandleOneLabels", function () {

  var label;

  beforeEach(function () {
  });

  describe("When handling one label", function () {

    beforeEach(function () {
      label = jasmine.createSpyObj("label", [
        "prepend"
      ]);

      HandleOneLabel(label, 'TESTID');
    });

    it("should add the tip icon", function () {
      expect(label.prepend).toHaveBeenCalledWith(
          "<span id='TESTID_tip' class='tip'></span>");
    });
  });
});

This form of testing appears to work well because the HandleOneLabel can easily be called with a jasmine mock object.

However when I looked at the kind of testing that would be possible for HandleAllLabels then it would obviously be more tricky. In general for a lot of the pages in the site the structure of the JavaScript was to have a view with all the jQuery selectors and a controller with the logic however this code was global utility code and splitting it up into controllers and views just to make testing easier seemed wrong to me.

I looked around and found an interesting project called jasmine-javascript that provided a framework for testing jQuery and JavaScript together.

I was (and I guess I am still) considering the validity of this approach, after all the separation into views and controllers is a good model, however I did like the way the tests mapped very well onto the desired behaviour. The tests looked like this (the multiline string literal labelHtml is laid out over multiple lines for readability)

// this is planted in the ASPX file in the real web site
var allLabels = [];

describe("HandleAllLabels", function () {

  var labelHtml = "<label for='TESTLABEL'>
       <span class='highlightPrompt'>highlight prompt</span>
       <span class='normalPrompt'>normal prompt</span>
       <span id='TESTSPANID'>always here</span>
       </label>";

  beforeEach(function () {
  });

  describe("When handling all labels", function () {

    var labelAfterProcessing;

    beforeEach(function () {

      allLabels = ['TESTLABEL'];
      setFixtures(labelHtml);

      HandleAllLabels();
      labelAfterProcessing = $("label[for='TESTLABEL']");
    });

    describe("When adding the info tip", function () {

      var tipIcon;

      beforeEach(function () {
        // the tip icon should be the 1st child - for a bug in IE8
        tipIcon = labelAfterProcessing.children(":first");
      });

      it("tip icon has the correct ID", function () {
        expect(tipIcon).toHaveId("TESTLABEL_tip");
      });

      it("should have the correct class", function () {
        expect(tipIcon).toHaveClass('tip');
      });

      it("should have the correct element type", function () {
        expect(tipIcon).toBe("SPAN");
      });
    });

    describe("When setting up the prompt", function () {

      it("should hide the normal prompts", function () {
        var normalPrompts =
          labelAfterProcessing.children(".normalPrompt");

        expect(normalPrompts.length).not.toEqual(0);
        normalPrompts.each(function (index) {
          expect($(this)).toBeHidden();
        });
      });
      it("should show the highlight prompts", function () {
        var highlightPrompts =
          labelAfterProcessing.children(".highlightPrompt");

        expect(highlightPrompts.length).not.toEqual(0);
        highlightPrompts.each(function (index) {
          expect($(this)).toBeVisible();
        });
      });
      it("should leave other prompts alone", function () {
        var otherPrompt =
          labelAfterProcessing.children("#TESTSPANID");

        expect(otherPrompt.length).not.toEqual(0);
          otherPrompt.each(function (index) {
            expect($(this)).toBeVisible();
          });
        });
      });
    });
});

jasmine-jquery enables me to inject test HTML into the code under test by using setFixtures call, it also enables the tests to access the HTML after the code has been run and assign it to labelAfterProcessing as well as providing a host of convenient jQuery matches such as toBe, toHaveId, toHaveClass etc.

As it happens things are never as straightforward as they might be and it turns out that the match toBeHidden does not work correctly in IE8 (one of our target browsers) so I did need to rewrite one of the test like so

      it("should hide the normal prompts", function () {
        var normalPrompts =
          labelAfterProcessing.children(".normalPrompt");

        expect(normalPrompts.length).not.toEqual(0);
          normalPrompts.each(function (index) {
          // bug in IE8 with the current version of jQuery
          //expect($(this)).toBeHidden();
          expect($(this).attr("style").toLowerCase())
            .toContain("display: none");
        });
      });

I got to TiddlyWiki for small screen devices by downloading AndTidWiki, this in turn was based on iTW. The thing is that its based on TiddlyWiki v2.4.1, the current version is v2.6.4 and now includes jQuery.

I took a little time and also had help from Andrew and we have put together a Powershell script that will take a release copy of the TiddlyWiki from the published archives and will add in the modifications that were made to the base TiddlyWiki by bidx (for iTW) as well the the modification that I made to use an alternative pipe symbol on HTC android phones. The effect of this is that it is now possible to generate a TiddlyWiki for phones that is based on the latest version of TiddlyWiki. Run the scripts and then just copy the HTML file to your phone.

While I was doing it I also made another modification to automatically dismiss the popup div that is displayed as a successful save confirmation. The popup is all well and good but I found it annoying to have to dismiss it every time I pressed “Done”, the modification leaves the popup there for five seconds and then dismisses it.

We have put the all the scripts that you need to generate your own Tiddlywiki in a repository called TiddlyWiki4Phone on bitbucket – enjoy.

What is the difference between hardware and software? If you play with hardware enough you will break it, if you play with software enough you might just get it to work.

I like using tiddlywiki, I’ve used it as a super todo.txt for a long time. I stumbled on an implementation for Android which in turn was based on iTW for the iPhone. The iTW tiddlywiki has been tweaked to only display one tiddler at once and the render and toolbar has been optimised for a small screen.

I got it and downloaded it and all was well it worked straight out of the box on my HTC Wildfire. I just wanted to put a few notes into it to get started, this worked fine and then I tried to edit a table, ahhhh problem.

Like a lot of Wiki markup languages tables are constructed out of the pipe symbol and then I found a problem – the stock HTC keyboard does not have a pipe symbol, you can get alternate keyboards but these seem to involve “rooting” the device – it seemed a bit of overkill to me. If I went to the symbol page of the keyboard input and pressed the 1/2 button to go the the second page of symbols there is a ¦ symbol which is not the same as a pipe |. Annoyingly there are even blank unused keys on the second page of symbols.

Anyway it did give me an opportunity to have a go at starting to modify the TiddlyWiki. This is what I did, I found the section of code in the TiddlyWiki HTML file that was responsible for formatting a table, in a blank AndTidWiki file its at line 3185 but looking for “table” soon finds it – it looks like this

//--
//-- Standard formatters
//--

config.formatters = [
{
 name: "table",
 match: "^\\|(?:[^\\n]*)\\|(?:[fhck]?)$",
 lookaheadRegExp: /^\|([^\n]*)\|([fhck]?)$/mg,
 rowTermRegExp: /(\|(?:[fhck]?)$\n?)/mg,
 cellRegExp: /(?:\|([^\n\|]*)\|)|(\|[fhck]?$\n?)/mg,
 cellTermRegExp: /((?:\x20*)\|)/mg,
 rowTypes: {"c":"caption", "h":"thead", "":"tbody", "f":"tfoot"},
 handler: function(w)
 {
  var table = createTiddlyElement(w.output,"table",null,"twtable");

And I replaced it with this, which just modifies the regular expressions to accept either a pipe or the double vertical bar

 match: "^[\\|¦](?:[^\\n]*)[\\|¦](?:[fhck]?)$",
 lookaheadRegExp: /^[\|¦]([^\n]*)[\|¦]([fhck]?)$/mg,
 rowTermRegExp: /([\|¦](?:[fhck]?)$\n?)/mg,
 cellRegExp: /(?:[\|¦]([^\n\|¦]*)[\|¦])|([\|¦][fhck]?$\n?)/mg,
 cellTermRegExp: /((?:\x20*)[\|¦])/mg,

Basically its a very simple edit – I just made the pipe and the HTC double vertical bar work interchangeable and I could use either – pipe is easier on a PC keyboard and the ¦ the only option at the moment on the phone.

For the last five years I have been using Juice and it has provided sterling service as a podcast downloader, however it appears to have been dormant for the last six years since the run in with Apple. Sometimes Juice gets confused and downloads podcasts that it has already downloaded. Also, I download to a flash drive which means that I can use my main computer or my netbook to keep up to date with my podcasts, I use a portable version of Juice from the utterly wonderful folk over at portable apps, however it does not seem to play well with Windows 7 and can sometimes get confused about where to store its downloads.

PodcastUtilities has now reached the stage where I can stop using Juice and move over to using my own app. If anyone else would like a downloader then head over to BitBucket and give it a whirl.

The main advantages of PodcastUtilities

· Portable
Podcast Utilities is a “portable” application, in that it does not need to be installed and can be run from any drive type, local network or removable flash drive

· Configurable
Almost any synchronisation solution can be configured, for example copy 3 of this podcast, all of these podcasts, in this order, and leave a certain amount of space on the device. The number of concurrent downloads can easily be configured.

· Lightweight
The application does not use large amounts of memory in a system tray icon all the time its not being used, it only uses system resources when its being run.

· Scriptable
Podcast Utilities lends itself to being run as a scheduled task or from a script. The API is “headless” and can easily be called and used from other applications

· Open Source
The source is open and available

· Free
There is no cost to using Podcast Utilities for any use.

· No need for an iTunes account
Podcasts promoted on iTunes can be downloaded however there is no need to have an iTunes account.

It made me think that when I have seen poor tests we end up with fragile tests that effectively just give us twice as much code to maintain. I do not think this should be used as an excuse to not write tests rather I think we should think about what we are trying to achieve.

Tests, especially BDD tests, should test the behaviour not the implementation. As an artificial example if we had a method that discovered if a given list of numbers contain any two numbers that are adjacent. That is when it is called with 4,7,9,6 it will return true, if called with 4,7,9 it will return false.

An obvious method of implementing this behaviour would be to sort the numbers and then look for adjacent numbers.

Tests I would expect to see

The first two tests that string to mind, one a positive and one a negative, could be something like this.

public abstract class ItemFinderTests : WhenTestingBehaviour
{
  protected ItemFinder _selctor1;
  protected IList _numbers;
  protected bool _result;

  protected override void GivenThat()
  {
    base.GivenThat();
    _selctor1 = new ItemFinder(new SystemDotNetSorter());
  }
}

public class WhenFindingAdjasentNumbers : ItemFinderTests
{
  protected override void GivenThat()
  {
    base.GivenThat();
    _numbers = new List() {7,3,6};
  }

  protected override void When()
  {
    _result = _selctor1.HasAdjasentNunbers(_numbers);
  }

  [Test]
  public void ShouldFindAdjasentNumbers()
  {
    Assert.That(_result,Is.True);
  }
}

public class WhenNotFindingAdjasentNumbers : ItemFinderTests
{
  protected override void GivenThat()
  {
    base.GivenThat();
    _numbers = new List() {3,6};
  }

  protected override void When()
  {
    _result = _selctor1.HasAdjasentNunbers(_numbers);
  }

  [Test]
  public void ShouldNotFindAdjasentNumbers()
  {
    Assert.That(_result, Is.False);
  }
}

There are other tests that could and in fact should be written, for example testing empty lists and lists with one or two items in

Tests I would not expect to see

In these tests I have mocked the object that supports ISorter, the object that is used to sort the list. In the previous tests I used a real concrete implementation. In some cases it is desirable to isolate tests from the underlying operating system or environment however in this case I’m not sure there is a great deal of benefit, in mocking the sorter, however I do not think that mocking (or not mocking) the sorter is a problem in itself.

public class ItemFinderTests2 : WhenTestingBehaviour
{
  private ItemFinder _selctor1;
  private IList _numbers;
  private bool _result;
  private ISorter _sorter;
  private IList _sortedNumbers;

  protected override void GivenThat()
  {
    base.GivenThat();

    _numbers = new List() {7,3,6};
    _sortedNumbers = new List() {3,6,7};

    _sorter = GenerateMock();
    _sorter.Stub(s => s.Sort(_numbers)).Return(_sortedNumbers);

    _selctor1 = new ItemFinder(_sorter);
  }

  protected override void When()
  {
    _result = _selctor1.HasAdjasentNunbers(_numbers);
  }

  [Test]
  public void ShouldSortTheNumber()
  {
    _sorter.AssertWasCalled(s => s.Sort(_numbers));
  }

  [Test]
  public void ShouldFindAdjasentNumbers()
  {
    Assert.That(_result, Is.True);
  }
}

When I see tests like this I think that we should not be writing tests that ensure that there are particular lines of code in the method we are testing. We do not care that the method uses the supplied sorter (or calls its sort method) only that it returns the correct result.

In general when we write code to satisfy BDD or TDD tests we are attempting to write the minimum amount of code that is needed to support the test and I think that we should also write the minimum amount of code in the tests that will test the behaviour we are expecting. Writing more than this gives us more code to maintain and more brittle tests.

So the obvious solution, to me, was to write something that would do the job. It also give me an opportunity to collaborate with Andrew on software which is fun, and I learn things and it gets written faster. It also gave us an opportunity to use Mercurial as hosted by Bitbucket while collaborating. We were both keen to explore working on a open source project.

Around Christmas we started working on utilities to handle synchronisation. This month we have opened to PodcastUtilities project to everyone. PodcastUtilities are utilities that will provide portable, configurable,  lightweight, scriptable utilities to download and synchronise podcasts. The initial codebase handles synchronisation.