Mark Withall

My First Video Series

2019-10-24T00:00:00+00:00

Just over a year ago, I decided to try my hand at recording a programming video. Rather surprisingly, this turned into me recording a series of 38 episodes, with each episode being around 20 to 30 minutes in length, and a total duration of 16.5 hours.

The subject of the video series was Little Man Computer. The reason being that I was into assembly language programming at the time. I also took the opportunity to try out C++17. It had been a number of years since I last programming C++ in anger, so this seemed like a good opportunity to get myself back up to speed.

I recorded using OBS, as that seems to be what most people use for this purpose and it seems to have produced good quality videos. Unfortunately, due to not having mastered the process early on, the first 7 episodes have quite a low volume. Later episodes have much better sound. YouTube appear to be in the process of overhauling their editing tools, so it’s not currently straightforward to fix the volume. Hopefully, I can come back and sort it out later.

If you happen to have a spare couple of days, feel free to check out my efforts on YouTube.

Setting The DataContext On A Style Element In A WPF ItemsControl

2018-08-19T00:00:00+00:00

A short post, mostly just to remind myself how to do this when I forget.

If we have the following style in, for example, a DataGrid:

<Style TargetType="DataGridRow">
    <Setter Property="Background" Value="Green" />
    <Style.Triggers>
        <DataTrigger Binding="{Binding IsBlue}" Value="True">
            <Setter Property="Background" Value="Blue" />
        </DataTrigger>
    </Style.Triggers>
</Style>

We get the following error message: Cannot resolve property "IsBlue" in data context of type '...' where ... is the type of the data context for the DataGrid rather than the data context for the row item.

To remove the error, we need to set the data context for the style. What we’d like to be able to do is:

<Style TargetType="DataGridRow" d:DataContext="{d:DesignInstance ViewModels:ItemPresenter}">
    <Setter Property="Background" Value="Green" />
    <Style.Triggers>
        <DataTrigger Binding="{Binding IsBlue}" Value="True">
            <Setter Property="Background" Value="Blue" />
        </DataTrigger>
    </Style.Triggers>
</Style>

Unfortunately, this gives the error message: The property "DataContext" does not exist in the "http://schemas.microsoft.com/expression/blend/2008" namespace.

What actually needs to be done is:

<Style TargetType="DataGridRow">
    <d:Style.DataContext>
        <x:Type Type="ViewModels:ItemPresenter" />
    </d:Style.DataContext>

    <Setter Property="Background" Value="Green" />
    <Style.Triggers>
        <DataTrigger Binding="{Binding IsBlue}" Value="True">
            <Setter Property="Background" Value="Blue" />
        </DataTrigger>
    </Style.Triggers>
</Style>

More verbose but actually works.

Writing a 6502 Assembler

2018-03-19T00:00:00+00:00

Recently, I rediscovered the joy of the Commodore 64. The C64 was one of my first computers and I spent hours programming in Basic on it. However, possibly due to the lack of the Internet at the time, I never learned to program it in machine code. I always felt rather disappointed by this. It seemed to me that so much more could be done in machine code but the resources of my local library did not support learning such things. Oddly, the thing that I most wanted to do back then was to have a loading screen on my Basic programs; that drew a picture and played music while bringing the program in from the cassette.

Now, with most of the books on C64 programming being freely available on the Internet, along with many other resources, I felt it was time to finally learn 6502 assembly programming (actually, 6510 on the C64).

Initially, I picked up a copy of Jim Butterfield’s “Machine Language” and began working through it using Supermon on the VICE C64 emulator. But after a while I became frustrated with the speed of development on the machine itself and decided to write the code on the PC and cross-assemble. I looked into various existing assemblers and IDEs but thought it would be more fun to try writing my own; to give me a better understanding of the instructions available.

The project is still a work in progress but you can follow how it is going on GitHub. I’m killing two birds with one stone here and finally taking a look at .NET Core and developing on both Windows and MacOS at the same time. Line endings aside, the process has turned out to be quite smooth; using Visual Studio Professional 2017 on the PC and Visual Studio for Mac Community Edition. I’m regularly feeling the pain of the lack of ReSharper for the Mac though; even though the refactoring tools built in to Visual Studio are coming along nicely. I’m following a relatively ‘pragmatic’ TDD approach to development and committing the code on every green or refactoring, to allow the process to be followed easily.

It is my intention to record a video of the development at some point and writing that down here might actually make it happen.

Once the assembler is complete, at least in first draft, I shall write Conway’s Game of Life for the C64 and see how it is to work with and if any adjustments are needed. Maybe the next step will be writing an IDE too with nice refactoring and static analysis features.

Hopefully, more updates on progress to follow.

DDD North 2017 Review

2017-10-15T00:00:00+00:00

Yesterday I attended my third DDD North. This year was at the University of Bradford, which had the added bonus of free parking. It again provided an excellent opportunity to catch up with my colleagues from the North.

Looking back to last year’s review, I appear to have chosen very similar talk topics to attend.

Thinking Functionally in C#.

This talk was by John Stovin. It was a much more in depth talk than I was expecting and inspired many interesting thoughts. For example, the suggestion that a properly pure function shouldn’t even throw an exception. Instead of:

public static void DoSomethingWithMinutes(int mins)
{
    if (mins < 0 && 59 < mins) throw new ArgumentException();
    // ...
}

We should restructure such that the function doesn’t need to throw:

public static void DoSomethingWithMinutes(MinuteComponent mins)
{
    // ...
}

public struct MinuteComponent
{
    private readonly int _mins;

    public static MinuteComponent FromInt(int mins)
    {
        if (mins < 0 && 59 < mins) throw new ArgumentException();
        return new MinuteComponent(mins);
    }

    private MinuteComponent(int mins)
    {
        _mins = mins;
    }

    // ...
}

It also provoked the thought that there is some trade-off between the use of F# matches and the open-closed principle; requiring many updates if there is an addition to a union type. The suggestion was that monads may be a solution to this but I don’t know enough about them at the moment.

Other things to look into include: reactive extensions (like LINQ but for events) and finding out if C#7 can be used from Visual Studio 2015 in any sensible manner.

Teaching an old dog new tricks

This talk was by Ismail Mayat. As I’m a big fan of clean code and TDD, this talk was a must. There were many good quotes and anecdotes in the talk, in particular Venkat Subramaniam’s “We cannot be agile if our code sucks”. It was also interesting to find out that the NASA Mercury probe had been developed in Smalltalk using what was basically TDD.

Scaling Agile in your Organisation with the Spotify Model

This talk was by Stephen Haunts. I went to his talk last year as well, so he’s clearly doing something right in his marketing. This prompted me, yet again, to look at Derbyshire DotNet; something that I didn’t do after last year’s talk. I’m sure I’ll say the same thing again next year. Also, Hack24 in Nottingham was an interesting discovery.

The concept of “internal open source” was an interesting one and something that we do where I work but didn’t have a name for. I must also look into Launch Darkly for feature flag management.

Async in C# - The Good, the Bad and the Ugly

This talk was by Stuart Lang. I went to an async/await talk last year too but have not made much use of it over the past year. Hopefully, having attended another talk on the subject I will be inspired to try a bit harder to incorporate the ideas over the next year. SharpLab, a tool for examining the Roslyn-generated code was another interesting discovery as was vs-threading from Microsoft.

Interactive APIs with GraphQL

This talk was by Sam Hogarth. The final talk of the day was on GraphQL, which I’ve been meaning to find out about for a while, as an alternative to REST. One of the main advantages over REST is that the values in the data are typed. Also, it is much easier to be more specific about the data you want to be returned without having to do a lot of work setting up extra end points to query like in REST. GraphiQL was an interesting looking tool for developing GraphQL.

Overall, another excellent day out. Many ideas where inspired and hopefully I’ll be able to put them all to good use.

Creating C DLLs for use with C#

2017-09-01T00:00:00+00:00

To me, creating a DLL in C and then accessing it from C# (for example, when we need more performance or to use less memory) has always seemed like a rather daunting task. This week, I decided to give it a go and found it to be surprisingly straightforward.

Creating a C DLL

We shall start with nearly the simplest thing we could possibly imagine in C:

__declspec(dllexport) int Add(int a, int b)
{
    return a + b;
}

The __declspec(dllexport) says export this function in the DLL.

The following compiles test.c into test.dll (making sure to use the Developer Command Prompt or call vcvarsall.bat before starting):

> cl /Za /LD test.c

Note the /Za flag makes sure you are working in strict C (rather than C++). Without it, you would need to add some code to avoid name mangling:

extern "C"
{
    __declspec(dllexport) int Add(int a, int b)
    {
        return a + b;
    }
}

If you prefer to be more precise, you can do the following:

> cl /Wall /WX /O2 /Za /LD test.c

This adds all of the warnings you could possibly ever want (/Wall /WX) and optimises the code (/O2).

Accessing the C DLL functions from C#

To access the function from C# (assuming that the DLL is in the current path, such as the same folder as the C# exe):

[DllImport("test.dll")]
private static extern int Add(int a, int b);

This can then be used as a normal C# method. For example (testing using NUnit):

[Test]
public void TestAdd()
{
    Assert.AreEqual(42, Add(13, 29));
}

The process gets slightly more complicated for strings, structs and pointers to things but that’s a story for another day.

TDD As If You Meant It Reviewed (Part V)

2017-06-01T00:00:00+00:00

This is the fifth in a short series of articles about Test Driven Development.

Part 1: TDD As If You Meant It Reviewed (Part I)
Part 2: TDD As If You Meant It Reviewed (Part II)
Part 3: TDD As If You Meant It Reviewed (Part III)
Part 4: TDD As If You Meant It Reviewed (Part IV)
Part 5: This article

This article was written with and is also published by Matthew Atkinson.

We’ve had a thorough look at TDDAIYMI over the last few parts of this series. Now we’re going to look at how the task might have been completed using ‘normal’ TDD.

Being British, we’re using a top-down approach that starts with the controller and works out to the model and view implementations; rather than the more traditional bottom up approach, which is more akin to TDDAIYMI.

We’ll start off in this part by looking, step-by-step, at each of the initial commits of the RED-GREEN-REFACTOR cycle.

The Starting Commits

As with all TDD, we start off by writing a failing test. We’re starting with the controller, as that seems to be the most logical place to start; it’ll tell us what we need from the model and from the view.

Our first test is that the controller calls the is_legal() check on our model. However, we have a failing test at the point we try and construct the controller.

RED a controller is created - 2014-08-13 14:07

def test_play_move_calls_is_legal():
    controller = NoughtsAndCrossesController()

To get back to green, it is a simple process of creating a controller class.

GREEN - 2014-08-13 14:08

def test_play_move_calls_is_legal():
    controller = NoughtsAndCrossesController()
 
class NoughtsAndCrossesController:
    pass

After we’d passed the test, we decided we didn’t like the test name, so we made it more specific to what we actually wanted to test.

REFACTOR better test name - 2014-08-13 14:10

def test_playing_legal_move_updates_view():
    controller = NoughtsAndCrossesController()
 
class NoughtsAndCrossesController:
    pass

Now we are green again, we continue to implement the test. Again, it fails to compile pretty quickly.

RED play_move - 2014-08-13 14:12

def test_playing_legal_move_updates_view():
    controller = NoughtsAndCrossesController()
    controller.play_move(0)
 
class NoughtsAndCrossesController:
    pass

This time, we make the test pass by adding a method to our controller class.

GREEN - 2014-08-13 14:12

def test_playing_legal_move_updates_view():
    controller = NoughtsAndCrossesController()
    controller.play_move(0)
 
class NoughtsAndCrossesController:
    def play_move(self, move):
        pass

There’s nothing to refactor this time, as we’ve not really done anything. Therefore, we continue to write our test by making an assertion about a fake view’s add_move() getting called with 0.

RED test view is called - 2014-08-13 14:15

import mock
 
def test_playing_legal_move_updates_view():
    fake_view = mock.Mock()
    controller = NoughtsAndCrossesController()
    controller.play_move(0)
    fake_view.add_move.assert_called_with(0)
 
class NoughtsAndCrossesController:
    def play_move(self, move):
        pass

Making the test pass is a bit more involved this time. We have to inject the view into our controller and actually call the add_move() method from the controller.

GREEN - 2014-08-13 14:17

import mock
 
def test_playing_legal_move_updates_view():
    fake_view = mock.Mock()
    controller = NoughtsAndCrossesController(fake_view)
    controller.play_move(0)
    fake_view.add_move.assert_called_with(0)
 
class NoughtsAndCrossesController:
    def __init__(self, view):
        self.view = view
 
    def play_move(self, move):
        self.view.add_move(move)

Again, there is nothing that we can see that’s worth refactoring at this stage.

We can now move on to our second test. We want to check that playing an illegal move does not add a move to our view (Ed: probably a bad name for the test here, as we may want to update the view by informing the user they’ve played an illegal move).

This initially fails as we aren’t accepting a model into our controller’s constructor.

RED added model to controller - 2014-08-13 14:21

import mock
 
def test_playing_legal_move_updates_view():
    fake_view = mock.Mock()
    controller = NoughtsAndCrossesController(fake_view)
    controller.play_move(0)
    fake_view.add_move.assert_called_with(0)
 
def test_playing_illegal_move_does_not_update_view():
    fake_view = mock.Mock()
    fake_model = mock.Mock()
    fake_model.is_legal.return_value = False
    controller = NoughtsAndCrossesController(fake_model, fake_view)
 
class NoughtsAndCrossesController:
    def __init__(self, view):
        self.view = view
 
    def play_move(self, move):
        self.view.add_move(move)

Passing is easy. We add a constructor parameter (and also update our other test).

GREEN - 2014-08-13 14:22

import mock
 
def test_playing_legal_move_updates_view():
    fake_view = mock.Mock()
    controller = NoughtsAndCrossesController(None, fake_view)
    controller.play_move(0)
    fake_view.add_move.assert_called_with(0)
 
def test_playing_illegal_move_does_not_update_view():
    fake_view = mock.Mock()
    fake_model = mock.Mock()
    fake_model.is_legal.return_value = False
    controller = NoughtsAndCrossesController(fake_model, fake_view)
 
class NoughtsAndCrossesController:
    def __init__(self, model, view):
        self.model = model
        self.view = view
 
    def play_move(self, move):
        self.view.add_move(move)

We can then make the test fail again by calling the play_move() method on the controller.

RED check illegal move does not update view - 2014-08-13 14:27

import mock
 
def test_playing_legal_move_updates_view():
    fake_view = mock.Mock()
    controller = NoughtsAndCrossesController(None, fake_view)
    controller.play_move(0)
    fake_view.add_move.assert_called_with(0)
 
def test_playing_illegal_move_does_not_update_view():
    fake_view = mock.Mock()
    fake_model = mock.Mock()
    fake_model.is_legal.return_value = False
    controller = NoughtsAndCrossesController(fake_model, fake_view)
    controller.play_move(42)
    assert not fake_view.add_move.called
 
class NoughtsAndCrossesController:
    def __init__(self, model, view):
        self.model = model
        self.view = view
 
    def play_move(self, move):
        self.view.add_move(move)

Making the test pass is a simple case (as it should be) of checking that it is legal by calling the model’s is_legal() method (which we’ve already mocked). Note that we also need to update our first test by passing a model.

GREEN - 2014-08-13 14:28

import mock
 
def test_playing_legal_move_updates_view():
    fake_view = mock.Mock()
    fake_model = mock.Mock()
    controller = NoughtsAndCrossesController(fake_model, fake_view)
    controller.play_move(0)
    fake_view.add_move.assert_called_with(0)
 
def test_playing_illegal_move_does_not_update_view():
    fake_view = mock.Mock()
    fake_model = mock.Mock()
    fake_model.is_legal.return_value = False
    controller = NoughtsAndCrossesController(fake_model, fake_view)
    controller.play_move(42)
    assert not fake_view.add_move.called
 
class NoughtsAndCrossesController:
    def __init__(self, model, view):
        self.model = model
        self.view = view
 
    def play_move(self, move):
        if self.model.is_legal(move):
            self.view.add_move(move)

We can see that we’ve introduced quite a bit of duplication in these two tests, so we need to refactor. Most of the duplication can be removed by introducing a setup method to create our mocks and controller.

REFACTOR use a test class - 2014-09-23 12:48

import mock
 
class TestNoughtsAndCrosses():
    def setup_method(self, method):
        self.fake_view = mock.Mock()
        self.fake_model = mock.Mock()
        self.controller = NoughtsAndCrossesController(
            self.fake_model,
            self.fake_view)
 
    def teardown_method(self, method):
        pass
 
    def test_playing_legal_move_updates_view(self):
        self.controller.play_move(0)
        self.fake_view.add_move.assert_called_with(0)
 
    def test_playing_illegal_move_does_not_update_view(self):
        self.fake_model.is_legal.return_value = False
        self.controller.play_move(42)
        assert not self.fake_view.add_move.called
 
class NoughtsAndCrossesController:
    def __init__(self, model, view):
        self.model = model
        self.view = view
 
    def play_move(self, move):
        if self.model.is_legal(move):
            self.view.add_move(move)

It is now much easier to add a new test. We now check that an illegal move results in an appropriate message to the view.

RED illegal move reports error - 2014-09-23 13:03

import mock
 
class TestNoughtsAndCrosses():
    def setup_method(self, method):
        self.fake_view = mock.Mock()
        self.fake_model = mock.Mock()
        self.controller = NoughtsAndCrossesController(
            self.fake_model,
            self.fake_view)
 
    def teardown_method(self, method):
        pass
 
    def test_playing_legal_move_updates_view(self):
        self.controller.play_move(0)
        self.fake_view.add_move.assert_called_with(0)
 
    def test_playing_illegal_move_does_not_update_view(self):
        self.fake_model.is_legal.return_value = False
        self.controller.play_move(42)
        assert not self.fake_view.add_move.called
 
    def test_playing_illegal_move_reports_error_in_view(self):
        self.fake_model.is_legal.return_value = False
        self.controller.play_move(-1)
        self.fake_view.report_error.assert_called_with('Illegal move')
 
 
class NoughtsAndCrossesController:
    def __init__(self, model, view):
        self.model = model
        self.view = view
 
    def play_move(self, move):
        if self.model.is_legal(move):
            self.view.add_move(move)

Passing the test is straightforward.

GREEN - 2014-09-23 13:03

import mock
 
class TestNoughtsAndCrosses():
    def setup_method(self, method):
        self.fake_view = mock.Mock()
        self.fake_model = mock.Mock()
        self.controller = NoughtsAndCrossesController(
            self.fake_model,
            self.fake_view)
 
    def teardown_method(self, method):
        pass
 
    def test_playing_legal_move_updates_view(self):
        self.controller.play_move(0)
        self.fake_view.add_move.assert_called_with(0)
 
    def test_playing_illegal_move_does_not_update_view(self):
        self.fake_model.is_legal.return_value = False
        self.controller.play_move(42)
        assert not self.fake_view.add_move.called
 
    def test_playing_illegal_move_reports_error_in_view(self):
        self.fake_model.is_legal.return_value = False
        self.controller.play_move(-1)
        self.fake_view.report_error.assert_called_with('Illegal move')
 
 
class NoughtsAndCrossesController:
    def __init__(self, model, view):
        self.model = model
        self.view = view
 
    def play_move(self, move):
        if self.model.is_legal(move):
            self.view.add_move(move)
        else:
            self.view.report_error('Illegal move')

Progress continues in the same vein until we have completed the controller. One could argue that we should really be working in thin slices of full-stack functionality but we decided that the task was simple enough to do as a single task.

Once the controller is complete, we move on to the model and then, finally, to the view.

Next Time

Next time we’ll look at the transitions to implementing the model and the view and some of the other interesting moments from the ‘Normal’ TDD.

Accessing WPF ListBox SelectedItems using MVVM

2017-05-14T00:00:00+00:00

A common problem that people face using the Model-View-ViewModel (MVVM) pattern is handling multiple selected items in a ListBox with extended selection mode turned on.

Let’s have a look at an example.

The ViewModel

We have a list of items in an ObservableCollection (so that the View updates if we modify the content of the collection). We also have a placeholder for some command that will operate on the selected items.

public class MainPresenter : Presenter
{
    public ObservableCollection<ItemPresenter> Items { get; }
        = new ObservableCollection<ItemPresenter>
    {
        new ItemPresenter("A"),
        new ItemPresenter("B"),
        new ItemPresenter("C"),
        new ItemPresenter("D")
    };

    public ICommand DoStuffCommand => new Command(param => { … });
}

For this example, each item is just a wrapped string. The item itself looks like this.

public class ItemPresenter : Presenter
{
    private readonly string _value;

    public ItemPresenter(string value)
    {
        _value = value;
    }

    public override string ToString()
    {
        return _value;
    }
}

The View

The basic View is a ListBox, with the selection mode set to extended (so we can select multiple items using ctrl/shift click or the keyboard equivalents). We also have a button that we’d like to perform an action on the selected items.

<ListBox ItemsSource="{Binding Items}" SelectionMode="Extended" />
<Button Command="{Binding DoStuffCommand}">Do Stuff</Button>

The MVVM Framework

For completeness, here is the implementation of a basic ViewModel base class and a simple ICommand implementation.

public abstract class Presenter : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void RaisePropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

public class Command : ICommand
{
    private readonly Action<object> _action;

    public event EventHandler CanExecuteChanged { add { } remove { } }

    public Command(Action<object> action)
    {
        _action = action;
    }

    public bool CanExecute(object parameter) => true;

    public void Execute(object parameter)
    {
        _action?.Invoke(parameter);
    }
}

How We’d Like To Do It

In an ideal world, we’d like to bind an ObservableCollection directly to the SelectedItems property of the ListBox. Alas, this is not currently possible.

In MainPresenter:

public ObservableCollection<ItemPresenter> SelectedItems { get; }
    = new ObservableCollection<ItemPresenter>();

In MainWindow.xaml:

<ListBox ItemsSource="{Binding Items}"
         SelectionMode="Extended"
         SelectedItems="{Binding SelectedItems}" />

One-way To Presenter

If we only care about setting the selected items from the View and operating on it when a command it executed, we can do this relatively simply.

First we need to give the ListBox a name.

<ListBox x:Name="ListBox" ItemsSource="{Binding Items}" SelectionMode="Extended" />

And then we can add a command parameter that points at the ListBox SelectedItems property. The property is an IList (non-generic) containing ItemPresenter references.

<Button Command="{Binding DoStuffCommand}"
        CommandParameter="{Binding ElementName=ListBox, Path=SelectedItems}">Do Stuff</Button>

Now our command will receive the list of selected ItemPresenter objects as a parameter and we can do as we wish with them.

Two-way Binding

If we want two-way binding, things get a little more messy.

Firstly, we need to add a property to ItemPresenter to store the selected state of the item.

private bool _isSelected;
public bool IsSelected
{
    get { return _isSelected; }
    set
    {
        _isSelected = value;
        RaisePropertyChanged();
    }
}

And then we have to find a way of binding that property to the View. The easiest way to do this is to create a style for a ListBoxItem and bind the IsSelected property there.

<ListBox ItemsSource="{Binding Items}" SelectionMode="Extended">
    <ListBox.ItemContainerStyle>
        <Style TargetType="ListBoxItem">
            <Setter Property="IsSelected" Value="{Binding IsSelected}" />
        </Style>
    </ListBox.ItemContainerStyle>
</ListBox>

Now we can set the selected items from the ViewModel as well as from the View.

When we execute the command, we can access the selected items using a short LINQ query:

Items.Where(i => i.IsSelected);

Update

David Hewson has kindly pointed out that this two-way binding workaround doesn’t play nicely with virtualization of the ListBox.

There are two options available here. Firstly, we could disable virtualization on the ListBox.

<ListBox VirtualizingStackPanel.IsVirtualizing="False" ... />

This is fine, as long as we aren’t expecting the list of items to grow too large.

A second, more extreme workaround is to override the ‘select all’ command for the ListBox and set the selected items via the ViewModel. This involves intercepting Ctrl+A and calling a command on the ViewModel.

public ICommand SelectAllCommand => new Command(_ =>
{
    foreach (var item in Items)
    {
        item.IsSelected = true;
    }
});

<ListBox.InputBindings>
    <KeyBinding Gesture="Ctrl+A" Command="{Binding SelectAllCommand}" />
</ListBox.InputBindings>

Creating Self-Hosted Python Modules

2016-12-20T00:00:00+00:00

The following assumes Python 3.x on Windows and pip version 8.1.1 or earlier

Creating A Module

Required files:

setup.py
setup.cfg
README
MANIFEST.in

and a folder containing the module itself.

NOTE: README can be one of: README, README.txt or README.rst

All files can be blank except for setup.py.

Minimal content of setup.py:

from setuptools import setup, find_packages

setup(name='modulename',
      version='0.1.0',
      description='Put description here',
      author='Name',
      author_email='name@example.com',
      url='module url',
      packages=find_packages(exclude=['docs', 'tests']))

To build the module package, run the command: python setup.py sdist from the root of the project.

This will create a folder dist with the file modulename-0.1.0.zip

For more details see the documentation.

Using external version.txt

To read the version number from a file:

from setuptools import setup, find_packages

with open('version.txt') as f:
    version = f.readline().rstrip()

setup(name='modulename',
      version=version,
      description='Put description here',
      author='Name',
      author_email='name@example.com',
      url='module url',
      packages=find_packages(exclude=['docs', 'tests']))

NOTE from pip verison 8.1.2 onwards, the modulename should replace dots with hyphens; otherwise pip won’t be able to find them on the self-hosted server

version.txt will also need to be added to the MANIFEST.in file:

include version.txt

Hosting A Repository

To host the server, put the modulename-0.1.0.zip file into a folder archive\modulename, then run python -m http.server 9000 from the archive folder.

For more details see the documentation and also.

Installing The Module

pip install --extra-index-url http://localhost:9000/ modulename

It’s probably worth doing this in a virtual environment to avoid corrupting the main python installation:

> python -m venv venv
> venv\Scripts\activate.bat
> pip install --extra-index-url http://localhost:9000/ modulename
> ... do stuff ...
> deactivate

MVVM - Creating New Windows

2016-10-15T00:00:00+00:00

I recently saw a post on StackExchange about creating new windows in an MVVM-compatible way. This seems to me to be a common cause of confusion.

My interpretation of MVVM is that the ViewModel should not know about the View. As windows, and related UI elements, are clearly a part of the View, it seems to me that creating them should be a responsibility of the View.

That said, what we want is for a Command in the ViewModel to result in a new window being created. For example, an OpenFileDialog. The requirement of the ViewModel, however, is for a filename. The ViewModel shouldn’t care that a new dialog window will be created to prompt the user for this filename.

When creating a ViewModel it is often useful to assume you have two views: a GUI and a command-line interface. In this instance, the GUI request for a filename would spawn an open file dialog and the command-line version would have a text prompt.

Let’s look at a concrete example.

The ViewModel needs an interface that is specific to its requirements. In this case, it wants a filename.

public interface FilenameProvider
{
    string GetFilename();
}

Our View could be a GUI, in which case the implementation of this interface could look something like:

public class GuiFilenameProvider : FilenameProvider
{
    public string GetFilename()
    {
        var ofd = new OpenFileDialog {Title = "File", Filter = "All Files|*.*"};
        return ofd.ShowDialog(Application.Current.MainWindow) == true ? ofd.FileName : null;
    }
}

However, if we were working on a command-line version of our application, a different implementation of the interface would be needed. For example:

public class CommandLineFilenameProvider : FilenameProvider
{
    public string GetFilename()
    {
        Console.WriteLine("Give me a file: ");
        return Console.ReadLine();
    }
}

The ViewModel doesn’t care where it gets the filename from, as long as it gets one. It would just have access to the interface and use it when it needs a filename. Something like the following:

public class MyViewModel : Presenter
{
    private readonly FilenameProvider _filenameProvider;
    private readonly MyModel _model;

    public MyViewModel(FilenameProvider filenameProvider, MyModel model)
    {
        _filenameProvider = filenameProvider;
        _model = model;
    }

    public ICommand DoSomethingCommand => new Command(() =>
    {
        var filename = _filenameProvider.GetFilename();
        if (filename != null)
            _model.DoSomethingWithFilename(filename);
    });
}

The ViewModel doesn’t know that the filename is being provided by a GUI or by a command-line interface.

It should be possible to use this type of pattern in most cases, where the effect of a command in the ViewModel is the creation of a new window. To me, the one obvious exception to this is where you just want to create a new instance of a window with no additional side effects. In this case, this feels like an entirely View-based action and the creation of the window should be handled there.

DDD North 2016 Review

2016-10-02T00:00:00+00:00

Yesterday (1st October 2016) I braved the coldest morning for quite some time to make the long trek north to Leeds (a much nicer journey now most of the M1 is open) for DDD North 2016. I had been to the 2014 edition of the conference and found it excellent value for the price (free), so I thought I’d go again this year.

Yet again, it was a great day (with the one exception of the increasingly unpleasant aroma from the gents restroom). Alas, I was forced to miss the final session of talks due to a prior engagement but the rest of the talks that I saw were excellent. It was also nice to catch up with my Northern colleagues, whom I hadn’t seen for a while.

This is not the Async you are looking for

This talk was by Liam Westley. I’ve not really played with async/await much as yet, so hopefully having watched this talk will prompt me to do so. In particular, it prompted me to look into TPL Dataflow. I also have to look at the white paper Task-based Asynchronous Pattern. Liam also gave a very entertaining lunchtime talk on what the point of Microsoft is.

10 more things you need to do to succeed as a Tech Lead

This talk was by Joel Hammond-Turner. As I had not seen the first talk in this series, I gained 20 things, as the first 10 were summarised at the beginning. I’m sure the full list can be found upon the Internet but a couple of them persuaded me that I should probably do more logging than I currently do and that I should be more aware of the real cost of projects.

Run Your Team Lean and Deliver More

This talk was by Stephen Haunts. It was worth attending for the discovery of the Derbyshire DotNet group alone. That said, the rest of the talk was worthwhile to clarify in my mind Lean, Kanban and related things.

Take Control - Control Code Complexity

This talk was by Fan Yang. This talk suggested I read Why Functional Programming Matters by John Hughes (of Haskell fame). I was also pointed at Resharper’s Cyclomatic Complexity checker, which I didn’t know existed. The talk itself was very entertaining and practical; walking through example code and refactoring it to reduce cyclomatic complexity. The code for which can be found at her GitHub.

Overall the day was definitely worth the trip. Many thanks to all of the organisers and sponsors for making it happen.

TDD With Excel VBA

2016-09-16T00:00:00+00:00

Every so often, I have contemplated the idea of TDD for Microsoft Excel VBA. Finally, I got around to trying it out.

The Fibonacci Sequence Kata

As a test case, I’m using the Fibonacci Sequence kata by Jason Gorman of Codemanship; as it’s one of the simplest katas out there.

The task is as follows:

Write a [VBA] script that writes out the number for a given position in the Fibonacci Sequence.

Step-By-Step

To getting going with TDD in Microsoft Excel VBA we take the following steps:

Launch Excel
Create new blank workbook
Open the Macro Editor (Alt+F11)
Right-click on current workbook in Macro Editor and insert new module

Now we have everything we need we can write our first failing test. We enter the following in the worksheet:

Input	Expected Output	Actual Output	Test Result
`0`	`0`	`=Fibonacci(A2)`	`=IF(B2=C2,"PASS","FAIL")`

Conditional formatting can be added to the Test Result column to better highlight PASS and FAIL.

Now we have our first failing test, we can add code to make the test pass in the macro editor:

Function Fibonacci(n)
    Fibonacci = 0
End Function

Switching back to the worksheet and pressing F9 refreshes the test results. We can now see the first test pass.

We now add the next test:

Input	Expected Output	Actual Output	Test Result
`0`	`0`	`=Fibonacci(A2)`	`=IF(B2=C2,"PASS","FAIL")`
`1`	`1`	`=Fibonacci(A3)`	`=IF(B3=C3,"PASS","FAIL")`

And update code to make it pass:

Function Fibonacci(n)
    Fibonacci = n
End Function

Repeat until no more failing tests can be added.

Input	Expected Output	Actual Output	Test Result
`0`	`0`	`=Fibonacci(A2)`	`=IF(B2=C2,"PASS","FAIL")`
`1`	`1`	`=Fibonacci(A3)`	`=IF(B3=C3,"PASS","FAIL")`
`2`	`1`	`=Fibonacci(A4)`	`=IF(B4=C4,"PASS","FAIL")`

Function Fibonacci(n)
    If n < 2 Then
        Fibonacci = n
    Else
        Fibonacci = 1
    End If
End Function

Input	Expected Output	Actual Output	Test Result
`0`	`0`	`=Fibonacci(A2)`	`=IF(B2=C2,"PASS","FAIL")`
`1`	`1`	`=Fibonacci(A3)`	`=IF(B3=C3,"PASS","FAIL")`
`2`	`1`	`=Fibonacci(A4)`	`=IF(B4=C4,"PASS","FAIL")`
`3`	`2`	`=Fibonacci(A5)`	`=IF(B5=C5,"PASS","FAIL")`

Function Fibonacci(n)
    If n < 2 Then
        Fibonacci = n
    Else
        Fibonacci = n - 1
    End If
End Function

Skipping 4, as it already passes:

Input	Expected Output	Actual Output	Test Result
`0`	`0`	`=Fibonacci(A2)`	`=IF(B2=C2,"PASS","FAIL")`
`1`	`1`	`=Fibonacci(A3)`	`=IF(B3=C3,"PASS","FAIL")`
`2`	`1`	`=Fibonacci(A4)`	`=IF(B4=C4,"PASS","FAIL")`
`3`	`2`	`=Fibonacci(A5)`	`=IF(B5=C5,"PASS","FAIL")`
`5`	`5`	`=Fibonacci(A6)`	`=IF(B6=C6,"PASS","FAIL")`

Function Fibonacci(n)
    If n < 2 Then
        Fibonacci = n
    Else
        Fibonacci = Fibonacci(n - 1) + Fibonacci(n - 2)
    End If
End Function

That completes the “Happy Path”. One can continue with negative numbers and other invalid input.

Conclusions

We’ve shown that it is possible to do TDD in Microsoft Excel VBA (at least for simple functions that return a value).

More complex tests might require something more from our test setup. Perhaps writing test functions in VBA that return “PASS” or “FAIL” (and details) and calling them from cells in the worksheet.

The Single Responsibility Principle

2016-09-04T00:00:00+00:00

The Single Responsibility Principle is seemingly the simplest of the SOLID principles, I’ve spent quite some time trying to get my head around what it actually means in practice. The ‘official’ description is as follows:

“A class should have only one reason to change.” - Robert C Martin

I’ve come to the conclusion that a class can have one of three main types of responsibility:

Calculation
Communication
Construction

Calculation

A class that performs some calculation.

public class Calculation
{
    public int Add(int a, int b)
    {
        return a + b;
    }

    public int Subtract(int a, int b)
    {
        return a - b;
    }
}

Reason to change: different calculation.

Communication

A class that manages communication between other classes.

public class Communication
{
    private readonly IDataSource _source;
    private readonly Calculation _calc;

    public Communication(IDataSource source, Calculation calc)
    {
        _source = source;
        _calc = cal;
    }

    public void PerformAdd()
    {
        var result = _calc.Add(_source.A, _source.B);
        _source.AddResult = result;
    }

    public int PerformSubtract()
    {
        var result = _calc.Add(_source.A, _source.B);
        _source.SubtractResult = result;
    }
}

public interface IDataSource
{
    int A { get; }
    int B { get; }
    int AddResult { set; }
    int SubtractResult { set; }
}

Reason to change: dependencies change API.

Construction

A class that creates other classes.

public class Construction
{
    public Communication CreateCommunication(SourceType type)
    {
        var source = CreateDataSource(type);
        var calc = CreateCalculation();
        return new Communication(source, calc);
    }

    private IDataSource CreateDataSource(SourceType type)
    {
        switch(type)
        {
            case SourceType.DB:
                return new DatabaseSource();
            case SourceType.CSV:
                return new CSVSource();
            default:
                throw new ArgumentException("Unknown type");
        }
    }

    private Calculation CreateCalculation()
    {
        return new Calculation();
    }
}

public enum SourceType
{
    DB,
    CSV
}

Reason to change: classes being constructed change constructors.

TDD As If You Meant It Reviewed (Part IV)

2016-08-04T00:00:00+00:00

This is the fourth in a short series of articles about Test Driven Development.

Part 1: TDD As If You Meant It Reviewed (Part I)
Part 2: TDD As If You Meant It Reviewed (Part II)
Part 3: TDD As If You Meant It Reviewed (Part III)
Part 4: This article
Part 5: TDD As If You Meant It Reviewed (Part V)

This article was written with and is also published by Matthew Atkinson.

We’ve taken a detailed look, in the previous part, at how to get started with TDDAIYMI, in this part we will jump around a bit more and look at several of the interesting moments that came about during the exercise.

Communicating Classes

Our first concern was how to introduce classes when this became necessary–because the tests must be made to pass within the test method, we thought this would be tricky. However we realised that, when we want to split out an inner class to clean up an existing class, this can easily be achieved in the refactoring stage. The ResultChecker class was extracted from the existing code as part of the refactoring, in line with rule 4.1 of TDDAIYMI:

You want a new class—wait until refactoring time, then… create non-test classes to provide a destination for a Move Method and for no other reason (populate implementation classes with methods by doing Move Method, and no other way)

Extraction of the ResultChecker class:

diff --git a/nac.py b/nac.py
index 56222aa..d6bee00 100644
--- a/nac.py
+++ b/nac.py
@@ -1,27 +1,27 @@
 def test_move_is_legal_if_not_already_played():
-	nac = NoughtsAndCrosses()
+	nac = NoughtsAndCrosses(ResultChecker())
 	assert nac.is_legal(0) is True

 def test_move_is_not_legal_if_already_played():
-	nac = NoughtsAndCrosses()
+	nac = NoughtsAndCrosses(ResultChecker())
 	nac.moves_played_so_far = [0]
 	assert nac.is_legal(0) is False

 def test_move_is_not_legal_if_below_lower_bound():
-	nac = NoughtsAndCrosses()
+	nac = NoughtsAndCrosses(ResultChecker())
 	assert nac.is_legal(-1) is False

 def test_move_is_not_legal_if_above_upper_bound():
-	nac = NoughtsAndCrosses()
+	nac = NoughtsAndCrosses(ResultChecker())
 	assert nac.is_legal(9) is False

 def test_draw():
-	nac = NoughtsAndCrosses()
+	nac = NoughtsAndCrosses(ResultChecker())
 	nac.moves_played_so_far = [ 0, 1, 2, 3, 4, 5, 6, 7, 8 ]
 	assert nac.is_draw() is True

 def test_not_draw():
-	nac = NoughtsAndCrosses()
+	nac = NoughtsAndCrosses(ResultChecker())
 	nac.moves_played_so_far = [ 0, 1, 2, 3, 4, 5, 6, 7 ]
 	assert nac.is_draw() is False

@@ -50,15 +50,16 @@ def test_bottom_left_diagonal_filled_player_one_is_win():
 	_is_win_for_player_one([ 2, 7, 4, 8, 6 ])

 def _is_win_for_player_one(moves_played_so_far):
-    nac = NoughtsAndCrosses()
+    nac = NoughtsAndCrosses(ResultChecker())
     nac.moves_played_so_far = moves_played_so_far
     assert nac.is_win_for_player_one() is True


 class NoughtsAndCrosses:
-	def __init__(self):
+	def __init__(self, result_checker):
 		self.moves_played_so_far = []
 		self.max_number_of_moves = 9
+		self.result_checker = result_checker

 	def is_legal(self, move):
 		move_within_bounds = move > -1 and move < self.max_number_of_moves
@@ -69,12 +70,13 @@ def is_draw(self):
 		return len(self.moves_played_so_far) is self.max_number_of_moves

 	def is_win_for_player_one(self):
-		return self._is_win(self._player_one_moves())
+		return self.result_checker.is_win(self._player_one_moves())

 	def _player_one_moves(self):
 		return set(self.moves_played_so_far[0::2])

-	def _is_win(self, moves):
+class ResultChecker:
+	def is_win(self, moves):
 		top_row = set([0, 1, 2])
 		middle_row = set([3, 4, 5])
 		bottom_row = set([6, 7, 8])

What about when the need for a class comes up that does something different to an existing class, so can’t simply be extracted from it? On branch “attempt_002” we stopped because we saw no immediate way to introduce further classes that we believed were required, the reason being that we could not think of a TDDAIYMI-compliant means to introduce the communication between classes. When we know we want to adopt an MVC design, how do we use TDDAIYMI to help us wire up the Model and View, via the Controller? They have to be able to communicate.

Fortunately the answer to this one is straightforward, too. Imagine that we have already separately developed the View and Model, and wish to write the Controller (this seems like a sufficiently bottom-up way of doing things, which we feel fits TDDAIYMI). In this case, we can write the tests for the wiring between the Model and View, making them pass within the test methods, as stipulated by the rules. It is fine for us to use the existing Model and View objects in the test methods, as they are already part of the established, tested, codebase. We will then start to be able to extract methods (as per rule 4.1).

You want a new method—wait until refactoring time, then… create new (non-test) methods by doing one of these, and in no other way:

preferred: do Extract Method on implementation code created as per (3) to create a new method in the test class, or

if you must: move implementation code as per (3) into an existing implementation method

Ultimately, we will arrive at a point where a lot of related methods will be ripe for refactoring into a class (as per rule 4.2 above).

Rookie Mistakes

One common error that we made during the exercise was to do a large refactoring in a single step. For example, in 94daea6 (below) we jumped straight to the extraction of a method for is_legal() without going through an intermediate step of refactoring the code to look the same in both cases. This would have left us a trivial extract-method refactoring. By doing the whole refactoring in a single step we run the risk of introducing errors, or at the very least having to go back and redo the refactoring when we get it wrong.

diff --git a/nac.py b/nac.py
index a588486..f24eab8 100644
--- a/nac.py
+++ b/nac.py
@@ -1,8 +1,9 @@
 def test_legal_move():
-    last_move_was_legal = True
-    assert last_move_was_legal
+    assert is_legal(1)

 def test_move_bounds_lower():
-    move = -1
-    last_move_was_legal = move > 0
-    assert last_move_was_legal is False
+    assert is_legal(-1) is False
+
+
+def is_legal(move):
+    return move > 0

The same is sometimes true when making a test pass. For example, in 29120f5 (below) the test has carelessly been made to pass outside of the test itself. In this case, we should have first added the extension and move < 9 to the is_legal() call and then used a refactoring to move the code into the production code.

diff --git a/nac.py b/nac.py
index ab6cfcb..ed94fe3 100644
--- a/nac.py
+++ b/nac.py
@@ -12,4 +12,4 @@ def test_move_bounds_upper():


 def is_legal(move):
-    return move >= 0
+    return move >= 0 and move < 9

We use the correct approach in 5612782 later:

diff --git a/nac.py b/nac.py
index 84b3cc7..9109cfd 100644
--- a/nac.py
+++ b/nac.py
@@ -12,7 +12,7 @@ def test_more_than_complete_top_row_is_win():

 def test_complete_middle_row_is_win():
     moves = [3, 4, 5]
-    assert is_win(moves) is True
+    assert (is_win(moves) or moves == [3, 4, 5]) is True


 def is_win(moves):

Rule Violations

One of the most common violations of ‘the rules’ of TDD was to modify the behaviour of code during a ‘refactoring’. This most commonly took the form of moving behaviour into existing methods.

For example, starting from the GREEN state (7940ebb, with the explicit True/False tests added for clarity):

def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False

def test_different_legal_move_is_legal():
    move = 1
    assert (is_legal(move) or move > 0) is True

def is_legal(move):
    return move == 0

we move directly to the following, in a single ‘refactoring’ (ac29b93, again with the explicit True/False tests added for clarity):

def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False

def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True

def is_legal(move):
    return move == 0 or move > 0

What would have been the correct way of going about this change? One possible approach would be to make all of the uses of the method look the same first. Then extract a new method and inline the old one.

This would look something like the following. Starting from the same GREEN state as above, we start by changing the assertion in test_illegal_move_is_not_legal() to match the form of that in test_different_legal_move_is_legal():

def test_illegal_move_is_not_legal():
    move = -1
    assert (is_legal(move) or move > 0) is False

def test_different_legal_move_is_legal():
    move = 1
    assert (is_legal(move) or move > 0) is True

def is_legal(move):
    return move == 0

The assertion for test_illegal_move_is_not_legal() is clearly still valid.

We then refactor, step-by-step, staring by renaming the original is_legal() function:

def test_illegal_move_is_not_legal():
    move = -1
    assert (original_is_legal(move) or move > 0) is False

def test_different_legal_move_is_legal():
    move = 1
    assert (original_is_legal(move) or move > 0) is True

def original_is_legal(move):
    return move == 0

then extracting a new is_legal() function from the two tests:

def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False

def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True

def is_legal(move):
    return original_is_legal(move) or move > 0

def original_is_legal(move):
    return move == 0

and finally, inlining the original_is_legal() function:

def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False

def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True

def is_legal(move):
    return move == 0 or move > 0

The result is the same as the single-step refactoring.

Another instance where we were a bit aggressive in the refactoring step was in b873939 (below) where we introduced the use of sets and the any function (which is nice and neat, but does alter the behaviour somewhat).

diff --git a/nac.py b/nac.py
index c0c00ce..5079bd3 100644
--- a/nac.py
+++ b/nac.py
@@ -17,5 +17,7 @@ def test_complete_middle_row_is_win():

 def is_win(moves):
     top_row = set([0, 1, 2])
-    return set(moves).issuperset(top_row) \
-            or moves == [3, 4, 5]
+    middle_row = set([3, 4, 5])
+    wins = [top_row,
+            middle_row]
+    return any(set(moves).issuperset(win) for win in wins)

Data vs Code

The approach we took to determining whether a position was a win in early attempts took the form of gradually building up example cases of win/not-win conditions and adding to the code that evaluated the position to pass the tests. This often got us into a very repetitive rut with the TDD process, where not much was added to the code, but we couldn’t seem to get off that path, as can be seen below.

The start of this run of commits is 63c0795:

diff --git a/nac.py b/nac.py
index a444c5e..b0a2ddd 100644
--- a/nac.py
+++ b/nac.py
@@ -25,6 +25,11 @@ def test_not_draw():
 	nac.moves_played_so_far = [ 0, 1, 2, 3, 4, 5, 6, 7 ]
 	assert nac.is_draw() is False

+def test_top_row_filled_is_win():
+	nac = NaughtsAndCrosses()
+	nac.moves_played_so_far = [ 0, 7, 1, 8, 2 ]
+	assert not set([0, 1, 2]).issubset(set(nac.moves_played_so_far[0::2]))
+

 class NaughtsAndCrosses:
 	def __init__(self):

The end of this run of commits is bce901b:

diff --git a/nac.py b/nac.py
index 21c4da1..c54fa7c 100644
--- a/nac.py
+++ b/nac.py
@@ -78,17 +78,14 @@ def is_win_for_player_one(self):
 		top_left_diagonal = set([0, 4, 8])
 		bottom_left_diagonal = set([2, 4, 6])
 		moves = self._player_one_moves()
-		return self._is_win_for_player_one(top_row, moves) \
-			or self._is_win_for_player_one(middle_row, moves) \
-			or self._is_win_for_player_one(bottom_row, moves) \
-			or self._is_win_for_player_one(first_column, moves) \
-			or self._is_win_for_player_one(second_column, moves) \
-			or self._is_win_for_player_one(third_column, moves) \
-			or self._is_win_for_player_one(top_left_diagonal, moves) \
-			or self._is_win_for_player_one(bottom_left_diagonal, moves)
-
-	def _is_win_for_player_one(self, pattern, moves):
-		return pattern.issubset(moves)
+		return top_row.issubset(moves) \
+			or middle_row.issubset(moves) \
+			or bottom_row.issubset(moves) \
+			or first_column.issubset(moves) \
+			or second_column.issubset(moves) \
+			or third_column.issubset(moves) \
+			or top_left_diagonal.issubset(moves) \
+			or bottom_left_diagonal.issubset(moves)

 	def _player_one_moves(self):
 		return set(self.moves_played_so_far[0::2])

You can explore the whole run of commits using the GitHub Desktop app, or by visiting the page for bce901b and following the “parent” link (it will take you backwards through the commits, but still demonstrates the repetitive and fairly content-free nature of the endeavour).

In later attempts, for example in our final run through, we moved to an approach of having a list of winning conditions as data, and wrote tests to drive a solution that looked to see if the win condition was contained in the list of winning conditions.

The later approach ends up with a much simpler and more flexible result, which would allow us to change the size of the board almost trivially. This level of flexibility could have been achieved in the algorithmic position evaluation too but would have required many more tests to get to that stage.

Next Time

Next time we will look at a more traditional TDD approach (in a London/Mockist style–as we’re British) to this exercise and see how it compares and contrasts to the TDDAIYMI style of development.

Red. Green. Refactor.

2016-03-21T00:00:00+00:00

Red. Green. REFACTOR.

TDD As If You Meant It Reviewed (Part III)

2015-11-03T00:00:00+00:00

This is the third in a short series of articles about Test Driven Development.

Part 1: TDD As If You Meant It Reviewed (Part I)
Part 2: TDD As If You Meant It Reviewed (Part II)
Part 3: This article
Part 4: TDD As If You Meant It Reviewed (Part IV)
Part 5: TDD As If You Meant It Reviewed (Part V)

This article was written with and is also published by Matthew Atkinson.

Having done a few practice attempts at TDDAIYMI, it’s clear that the hardest part is writing the first test. Unlike a more traditional approach to TDD, you can’t leverage the ability to assume the existence of classes and methods to write the test; and then implement them to make it pass. This can lead to some rather contrived test failures.

The Starting Commits

To illustrate the challenges of starting with TDDAIYMI, we are going to go through the first few of our RED-GREEN-REFACTOR cycles step-by-step and explain in detail our thought process at each stage. We’ve included timestamps for the commits to make it easy to see how long each step took. These commits form part of the flamboyantly-named attempt_006_tddaiymi_2 branch on GitHub.

Each commit is presented, followed by the commentary on it.

RED Test that a legal move is legal - 2015-02-19 13:25

def test_legal_move_is_legal():
    move = 0
    assert move > 0

As mentioned last time, we are going to be tackling the problem of noughts and crosses (tic-tac-toe). We decided, somewhat arbitrarily, to start with a method to check the legality of a move. It seems more natural to approach TDDAIYMI in a bottom-up, as opposed to a top-down, manner.

We have decided to use a numeric position for the move. What that exactly means will be determined by the tests we write (the idea being that there are nine squares, which we will identify as 0 to 8 – interestingly, and as was discussed in Keith Braithwaite’s workshop, this means there is no notion of ‘a board’ specifically).

Our first test is somewhat contrived due to the restrictions of the process. One could argue that the inclusion of the move variable is taking things a step too far and that the initial test should have been assert 0 > 0 followed by using the Extract Variable refactoring to get to the current state, after having made the test pass.

GREEN - 2015-03-02 13:09

def test_legal_move_is_legal():
    move = 0
    assert move == 0  # changed

Making the test pass is trivial; as, of course, it should be. We change the contrived ‘less than’ test to use an equals comparison. As we only have the one test, there is no duplication to refactor, so we move straight onto the next test.

RED Test that an illegal move is not legal - 2015-03-02 13:20

def test_legal_move_is_legal():
    move = 0
    assert move == 0

# added function
def test_illegal_move_is_not_legal():
    move = -1
    assert move == 0

We are essentially starting from scratch again with test number 2. That said, we want to try and keep going in the same direction to triangulate some behaviour to extract in the form of duplicate code.

We have settled on move == 0 being the standard test for legality, so we now want to use the same test, when presented with an invalid move. This will take us a step closer to being able to remove duplication via Extract Method in future.

GREEN - 2015-03-02 13:25

def test_legal_move_is_legal():
    move = 0
    assert move == 0


def test_illegal_move_is_not_legal():
    move = -1
    assert (move == 0) is False  # changed

Note that the GREEN step is supposed to take the least-complex means to make the tests pass – it is the tests, not their solutions, that are intended to direct the overall design of the code. This is why, in this case, the GREEN step does seem rather simplistic. Arguably, we should have changed the == to != to make the test pass. By making the test pass in this way, we are introducing some duplication that needs addressing and moves us nearer to our goal.

REFACTOR Extract `is_legal` function - 2015-03-02 13:28

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move)  # changed


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False  # changed


# added function
def is_legal(move):
    return move == 0

This REFACTOR step may seem somewhat ‘aggressive’, in the sense that it lengthens the code, but it’s also vital (for any form of TDD) to refactor as early as possible, in order to keep the code – and any emerging avenues for good design – as ‘clean’ as possible. In this case, we had a DRY violation, which needed to be fixed; introducing is_legal() solves that problem, and starts giving some structure to the code. Using the tests to come at problems from both sides, in a sort of pincer strategy, can enable us to tease out structure such as this, and is a technique we used often.

RED Test a different legal move - 2015-03-03 12:40

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move)


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


# added function
def test_different_legal_move_is_legal():
    move = 8
    assert is_legal(move)


def is_legal(move):
    return move == 0

We need to expand the range of legal moves. We start by testing the highest legal value. Of course, there are many possible moves in the game and, whilst we’d not want to test all of them separately, we do need to add at least one more in order to pin down the range of valid moves – think of it along the lines of needing at least three points in order to be reasonably confident you can draw a meaningful line through them.

GREEN - 2015-03-03 12:48

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move)


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) or move > 0  # changed


def is_legal(move):
    return move == 0

We make this test pass, in the test method, and by using the simplest possible means which, again, may seem somewhat insufficient at first glance. We can use refactoring to improve the design. For some reason we changed our test case to ‘1’ instead of ‘8’ at this point; which was rather naughty.

REFACTOR Improve design by moving code - 2015-03-03 12:50

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move)


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move)  # changed


def is_legal(move):
    return move == 0 or move > 0  # changed

Next, for the first time, we have a few consecutive refactorings, and thus make two separate REFACTOR commits. In the first, we move the extra legality check to the is_legal() function, which is allowed per the rules, as it ‘improves the design of the code’ and the rules allow us to move code from a test function to an existing function. This is not strictly a refactoring, as it changes the behaviour of the code (whereas refactoring should preserve behaviour). However, the tests all still pass and this has given us a way to improve the design.

REFACTOR Simplify expression - 2015-03-03 12:52

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move)


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move)


def is_legal(move):
    return move >= 0  # changed

Now we are able to simplify the legality check, because all of the code is together…

REFACTOR Explicitly state expected result of tests - 2015-03-03 12:53

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move) is True  # changed


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True  # changed


def is_legal(move):
    return move >= 0

At this point, we realised that, as per The Zen of Python and in the interests of making it easy to read and understand the tests, ‘explicit is better than implicit’ – we had not been clearly stating what we expected the results of the tests to be, so we add the cases where we want a True result.

RED Test the first illegal move on upper boundary - 2015-03-03 12:55

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move) is True


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True


# added function
def test_high_illegal_move_is_not_legal():
    move = 9
    assert is_legal(move) is False


def is_legal(move):
    return move >= 0

The next logical failing test we can write is to use an illegal move at the other end of the range. When we are no longer able to write a failing test, we know we are done. (Note that if we wrote a test for checking a move of ‘8’ was legal, it would pass, so it doesn’t need to be written.)

GREEN - 2015-03-03 12:58

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move) is True


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True


def test_high_illegal_move_is_not_legal():
    move = 9
    assert is_legal(move) or move < 9 is False  # changed


def is_legal(move):
    return move >= 0

Again, making the test pass is done in the test method itself, using the simplest code.

REFACTOR Improve design by moving code - 2015-03-03 13:05

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move) is True


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True


def test_high_illegal_move_is_not_legal():
    move = 9
    assert is_legal(move) is False  # changed


def is_legal(move):
    return move >= 0 and move < 9  # changed

We refactor to improve the design by moving the extra code to the is_legal() method. The tests are run automatically after each change we make, so we know if we have broken anything. Once again, this is a pseudo-refactoring as, whilst it doesn’t change the stated (tested) behaviour of the overall program, it does change the behaviour of the function.

RED Test previously-played move is illegal - 2015-03-04 12:39

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move) is True


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True


def test_high_illegal_move_is_not_legal():
    move = 9
    assert is_legal(move) is False


# added function
def test_move_is_illegal_if_already_played():
    moves_played = [0]
    move = 0
    assert is_legal(move) is False


def is_legal(move):
    return move >= 0 and move < 9

We have now run out of the basic failing tests that we can think of for the is_legal() method. We move on to expand its behaviour by considering moves that have been played previously to be illegal. Again, this is somewhat contrived as we are inventing some state that we aren’t initially using in the test.

This direction of exploration seems like the most natural extension of the existing test sequence. We are not attempting to force any sort of design; we are just writing tests and will see what ‘design’ emerges.

GREEN - 2015-03-04 12:44

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move) is True


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move) is True


def test_high_illegal_move_is_not_legal():
    move = 9
    assert is_legal(move) is False


def test_move_is_illegal_if_already_played():
    moves_played = [0]
    move = 0
    assert (is_legal(move) and move not in moves_played) is False  # changed


def is_legal(move):
    return move >= 0 and move < 9

We now use the state information to make the test pass in the test method.

REFACTOR Introduce Parameter - 2015-03-04 12:56

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move, []) is True  # changed


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move, []) is False  # changed


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move, []) is True  # changed


def test_high_illegal_move_is_not_legal():
    move = 9
    assert is_legal(move, []) is False  # changed


def test_move_is_illegal_if_already_played():
    moves_played = [0]
    move = 0
    assert (is_legal(move, moves_played) and move not in moves_played)
is False

def is_legal(move, moves_played):  # changed
    return move >= 0 and move < 9

We want to improve the design of the code by moving the new code that made the test pass to the is_legal() method but to do this we need to pass the state in too. We proceed cautiously and do this refactoring in a couple of steps. First we add the extra parameter to the is_legal() method (which requires us to update all the other tests that use is_legal()).

REFACTOR Move history-checking code to is_legal() - 2015-03-04 12:59

def test_legal_move_is_legal():
    move = 0
    assert is_legal(move, []) is True


def test_illegal_move_is_not_legal():
    move = -1
    assert is_legal(move, []) is False


def test_different_legal_move_is_legal():
    move = 1
    assert is_legal(move, []) is True


def test_high_illegal_move_is_not_legal():
    move = 9
    assert is_legal(move, []) is False


def test_move_is_illegal_if_already_played():
    moves_played = [0]
    move = 0
    assert is_legal(move, moves_played) is False  # changed


def is_legal(move, moves_played):
    return move >= 0 and move < 9 and move not in moves_played  # changed

Now that we have passed in the parameter, we can move the extra check into is_legal() and make sure that all of the tests still pass, which they do.

Next Time

We could continue on but this gives sufficient flavour of the thought process as we worked our way through the exercise. The rest of the development continues in the same manner; looping through the RED-GREEN-REFACTOR cycle. In the next article in the series we shall pick out some interesting moments from the rest of the development and discuss them.

Blurry Rotated Text In WPF

2015-07-31T00:00:00+00:00

Just a short little post today, as I’m going to forget this if I don’t write it down somewhere.

Sometimes when you transform text in WPF it ends up rendering blurred at runtime. Annoyingly, it will quite often appear fine in Visual Studio’s designer. Take, for example, the following expander header.

<Expander.Header>
    <TextBlock Text="Running Dates">
        <TextBlock.LayoutTransform>
            <RotateTransform Angle="-90"/>
        </TextBlock.LayoutTransform>
    </TextBlock>
</Expander.Header>

It looks fine in the designer

but at runtime it goes blurry

Adding TextOptions.TextFormattingMode="Display" to the TextBlock fixes this by using GDI-compatible font metrics.

<Expander.Header>
    <TextBlock Text="Running Dates" TextOptions.TextFormattingMode="Display">
        <TextBlock.LayoutTransform>
            <RotateTransform Angle="-90"/>
        </TextBlock.LayoutTransform>
    </TextBlock>
</Expander.Header>

Now it looks much better at runtime.

It’s also worth looking at SnapsToDevicePixels and UseLayoutRounding for similar issues that don’t involve text.

TDD As If You Meant It Reviewed (Part II)

2015-07-08T00:00:00+00:00

This is the second in a short series of articles about Test Driven Development.

Part 1: TDD As If You Meant It Reviewed (Part I)
Part 2: This article
Part 3: TDD As If You Meant It Reviewed (Part III)
Part 4: TDD As If You Meant It Reviewed (Part IV)
Part 5: TDD As If You Meant It Reviewed (Part V)

This article was written with and is also published by Matthew Atkinson.

Part II: The Problem

The Problem: Noughts And Crosses (Tic-Tac-Toe in American)

In Keith Braithwaite’s original exercise, the problem tackled was Noughts and Crosses. To allow us to compare with other attempts out on the Internet, we are going to tackle the same problem. We intentionally didn’t fully define the problem in advance; except to focus on the game management aspects, rather than any AI components.

Language/Library Choices

We decided to do the exercise in Python (2.7), as it was the language with which we had the highest average skill level. We used pytest and mock for testing and pytest-xdist to allow the test to run continuously in the background and keep us honest.

Code was written in Vim (because, y’know, it’s better than [REDACTED], etc.). YouCompleteMe and syntastic were used for autocompletion and static analysis to speed things along. We did try the rope refactoring tools briefly but they aren’t currently robust enough. We must take some time to look at some of the issues we had at some point to help get it up to scratch; as life isn’t worth living without refactoring tools.

The whole was wrapped up in virtualenv to make it easy to get up and running with a standard environment.

Methodology

We started with some TDDAIYMI ‘dry runs’ to get the hang of using this technique as, whilst it seems very-much like TDD on paper, it ‘feels’ quite different to use it. We then carried out our ‘control’ exercise of ‘traditional’ TDD and finally followed this up with a serious go at the problem in TDDAIYMI style.

For the experiment, we decided to commit after each stage of the RED-GREEN-REFACTOR cycle, to allow the easiest replay of what happened. In real life, we probably wouldn’t choose the commit after a RED stage, to keep the repository in a working state as far as possible (e.g. to allow binary search of the history).

During the exercises we were looking out for:

Similarities between the two approaches
What worked with TDDAIYMI
What didn’t seem to work
How we feel TDDAIYMI might be improved
General lessons learnt

Next Time

We finally get the f*** on with it.

TDD As If You Meant It Reviewed (Part I)

2015-06-09T00:00:00+00:00

This is the first in a short series of articles about Test Driven Development.

Part 1: This article
Part 2: TDD As If You Meant It Reviewed (Part II)
Part 3: TDD As If You Meant It Reviewed (Part III)
Part 4: TDD As If You Meant It Reviewed (Part IV)
Part 5: TDD As If You Meant It Reviewed (Part V)

This article was written with and is also published by Matthew Atkinson.

Part I: Introduction

Writing tests before you write any code is awesome. It means that you can rely on the code you’ve written to work (most of the time) and you can refactor with wild abandon, for example to improve performance, because it’s trivial to re-run the tests to check the code still behaves itself. However, as with pretty-much everything else, there are many ways to actually do Test Driven Development (or TDD, as most refer to it), two of which we explored in detail.

In general, the idea is that you write a test, write some code to make the test pass and then refactor (i.e. to remove duplication and otherwise improve the code’s design), before moving on to the next test. Thus, there are three stages, which are usually referred to by ‘colour’…

RED - Write a failing test
GREEN - Make the test pass
REFACTOR - Improve the design of the code without changing the behaviour
GOTO 10 (i.e. repeat the above, for the next test)

In most of its forms, TDD is not a substitute for a certain amount of up-front design (though it certainly helps, as it discourages writing unnecessary code) – it’s expected that you have a good overall idea of where you’re going architecturally, e.g. that you’d have a Model, View and Controller, perhaps. You also need to decide the granularity of your red-green-refactor cycles – is a ‘red’ commit an entire test, or does it only go up to a compilation failure (e.g. where you may need to introduce a mock to take the place of a model, controller or other object – we’ll see examples of this later). There’s a lot of variation and different views on these sorts of things.

A more pedantic flavour of TDD has been proposed that caught our attention, so we had to give it a go…

What Is TDDAIYMI?

Test Driven Development As If You Meant It (TDDAIYMI) is a TDD workshop exercise devised by Keith Braithwaite. It was first presented at Software Craftsmanship 2009.

The exercise aims to apply TDD in the most pedantic way possible; to stretch one’s programming muscles. It is not intended that this extreme approach is used on a daily basis, for real-world programming tasks.

TTDAIYMI takes the form of a re-phrasing of the standard TDD steps, as follows (taken from the original article, see above).

The Rules

Write exactly one new test, the smallest test you can that seems to point in the direction of a solution
See it fail
Make the test from (1) pass by writing the least implementation code you can in the test method.
Refactor to remove duplication, and otherwise as required to improve the design. Be strict about using these moves:
1. you want a new method – wait until refactoring time, then… create new (non-test) methods by doing one of these, and in no other way:
  1. preferred: do Extract Method on implementation code created as per (3) to create a new method in the test class, or
  2. if you must: move implementation code as per (3) into an existing implementation method
2. you want a new class – wait until refactoring time, then… create non-test classes to provide a destination for a Move Method and for no other reason
  1. populate implementation classes with methods by doing Move Method, and no other way

How Does It Differ From ‘Normal’ TDD?

There are many approaches to TDD but, for our comparison, let us take Uncle Bob’s ‘Three Laws’ approach.

The Three Laws Of TDD

‘Uncle’ Bob Martin, in his article on the Three Laws of TDD, clarifies the RED-GREEN-REFACTOR process with some restrictions upon how to follow the steps. These clarifications are as follows:

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

This is already quite similar to TDDAIYMI but with the added flexibility to infer the existence of production code (or at least interfaces/protocols that other production code might implement); in fact, in some ways it actively encourages it by allowing you to break up the creation of a single test into multiple RED-GREEN-REFACTOR steps, creating little bit of missing production code as you go.

Next Time

In the rest of this series we are going to write about our experiences of trying out TDDAIYMI on a small project and then comparing it to a more traditional TDD approach tackling the same problem.

Fluent APIs And The Law Of Demeter

2015-05-03T00:00:00+00:00

In object oriented programming the Law of Demeter states that a class shouldn’t reach through associated classes into the details of other classes beyond. This is often stated as “use only one dot”. This formulation, on the face of it, seems to have worrying implications for the use of fluent APIs, such as .NET LINQ.

Below is a simple example with two levels. The first represents a train and the second the details of each stop that the train makes. The Law of Demeter says that if we are playing with trains, we shouldn’t be able to see the details of stops, i.e. something that has a train, shouldn’t look at departure times. I

First Level Interface

public interface ITrain
{
    int Id { get; }
    IEnumerable<IStop> Stops { get; }
}

Second Level Interface

public interface IStop
{
    string Name { get; }
    TimeSpan? DepartureTime { get; }
    TimeSpan? ArrivalTime { get; }
}

Here are two example methods that take a list of trains and use LINQ to filter them in some manner. Both return a list of stops but the first complies with the Law of Demeter and the second does not.

Legal Usage

public IEnumerable<IStop> Legal(IEnumerable<ITrain> trains)
{
    return trains
        .Where(train => train.Id < 100)
        .OrderBy(train => train.Id);
        .Select(train => train.Stops.First());
}

Whilst there are many dots used in the above code, nothing reaches through the ITrain interface and into the details of the IStop interface. Hence, the Law of Demeter is complied with.

Illegal Usage

public IEnumerable<IStop> Illegal(IEnumerable<ITrain> train)
{
    return trains
        .Select(train => train.Stops.First())
        .OrderBy(stop => stop.DepartureTime)
}

Here there are in fact fewer dots used than in the legal example above. However, we are reaching through into the details of the IStop interface (accessing the DepartureTime property that the Law of Demeter says we shouldn’t know about).

As we have shown above, it is perfectly possible to comply with the Law of Demeter whilst using fluent APIs but it is necessary to be careful when doing so.

Blogging (hopefully) 2015

2015-03-06T00:00:00+00:00

A somewhat late first article this year; as it’s just turned March. To continue the trend from last year, I’m starting with a review and forecast. Last year: seven out of twelve. Not as good as the nine out of twelve for 2013 but not a complete disaster. As usual, however, nearly all of the articles were written in the first half of the year. This year, I’m still keeping the twelve article target and will try harder to get more in the second half.

I was happy with the articles I did write. In particular, I enjoyed my investigation into implementing Undo/Redo; an area which has always been rather a mystery to me. I had plenty to write about during the year but I failed to take advantage of all of the opportunities.

I already have a few articles in the works, for this year, that should give me a bit of a head start; including an exciting collaboration with Matthew Tylee Atkinson on a series of articles about Keith Braithwaite’s “TDD As If You Meant It” exercise. It would also be a good idea to publish my long overdue full review of BACON 2014 before the 2015 event.

Here is the list from last year, for reference.

2014-02-22 - 2013 Programming Articles Review
2014-03-22 - To Rebase Or Not To Rebase?
2014-04-18 - Save All Excel Worksheets As Tab Separated Text
2014-05-02 - Labelled TextBox In WPF
2014-05-18 - Such Coffee, Many Caffeine, Wow!
2014-06-20 - Undo/Redo
2014-10-19 - DDD North 2014 Review

NaNo Novel Casting 2014

2014-11-01T00:00:00+00:00

It’s that time of year again. This year I have decided to do a Choose Your Own Adventure novel, loosely based on a certain murder mystery board game.

To fit the structure of my story (which I will hopefully detail in a later article, if I can persuade myself to do so), I need to have 7 male and 7 female characters. This works out at one pair for each room on the board (yes, I know there are 9 rooms in the real game but I did say loosely).

Below is the current casting of each pair of characters. I shall endeavour to update the list as I decide upon further characters.

Library

Earl Gray: Anthony Hopkins
Lady Gray: Lucy Lawless
Master Gray: Michael Pitt

Conservatory

Mr Ruby: Max Martini
Mrs Ruby: Christina Hendricks

The Cellar

Father Jade:Johnny Depp
Sister Mary Leaf: Michelle Trachtenberg

Kitchen

Mr Ivory: Idris Elba
Mrs Ivory:Amber Heard

Ballroom

Professor Pear: Jack Nicholson
Professor Pear: Jeanne Tripplehorn

Dining Room

Commandant Dijon: Vincent Cassel
Mme Dijon: Monica Bellucci

Lounge

Mr Pheasant: Edward Norton
Mrs Pheasant: Angelina Jolie

Everywhere

The Butler: Clive Owen
The Maid: Alexandra Breckenridge

I shall also add which rooms they are in once I’ve decided. Happy NaNoing!

DDD North 2014 Review

2014-10-19T00:00:00+00:00

It’s been a while but yesterday has presented me with the motivation to write another post. It’s also getting close to the end of the year and I’m running rather short of my target of twelve articles.

Yesterday (October 17th 2014) I got up in the middle of the night, two hours before I went to bed, and made the long trip to Yorkshire. I went to DDD North 2014 in Leeds.

Overall I had a great, if somewhat tiring, day. There were many interesting talks and discussions with people. Though, I was slightly disappointed that many of the talks I was most interested in were running in parallel. Below I’ve summarised the particular talks that I went to.

Write your own compiler in 24 hours

This talk was by Phillip Trelford. He went through the writing of a series of interpretters/compilers for increasingly complex languages. He started with logo, showing some pretty patterns generated. Then he moved on to Small Basic, expanding upon the original language with parameterised functions and giving an example of FizzBuzz implemented in the language. And finally, ending with an implementation of C#. One interesting thing that I found out was that C# has an almost one-to-one mapping with the op codes in the VM.

The main thing to take away from the talk was not to reinvent the wheel and leverage existing tools and technologies. All of the examples in the talk were given in F#. I’m not that familiar with the language but as the code was very short it was relatively easy to understand.

Brownfield Refactoring

This talk was by Dominic Finn. He presented a great set of hand-drawn slides, which we very entertaining. I went into this talk expecting to hear some Feathers-style discussion of working with legacy code but was instead greeted with a refreshing angle of how to manage the process from a people perspective. One particularly interesting point mentioned was to examine where your software is in it’s overall lifecycle and analyse whether it really is worth expending the effort required to improve it. The recommendation was that when your product goes into decline, get your best developers off it and onto something new. Then maybe even outsource the maintenance of the declining product. Another recommendation was to make UI changes very gradually, so as not to upset your users.

Join the Dark Side - Why developers should choose management

This talk was by Ceri Shaw. She addressed such issues as why do we need developers in management and why would they want to be. She said that one of the reasons we end up with bad managers was that it was seen as a career progression.

Types of managers were roughly divided into two categories: ‘team leads’ who were responsible for getting the best out of the team as a whole and ‘line managers’ who were responsible for getting the best out of individuals. She suggested that a good way into management was through mentoring and that one of the most rewarding aspects was seeing improvements in the team. She did stress that as a manager from a technical background it was important to keep up with coding skills but that there was a trade off as the more management the less coding. It was also stressed the importance of keeping yourself off the critical path, so at crunch time you could focus on organisational issues.

Many other useful pieces of advice were put forward too that this article doesn’t have room for. The talk ended with the recommendation of the book Behind Closed Doors amongst others.

Visual Studio CodedUI: Improving Resilience in your Automated tests

This talk was by Riccardo Viglianisi. A shorter talk but with a lot of lively discussion afterwards. The main focus was on the trade off between using automatically generated UI Maps, which are rather fragile, and hand-coded tests, which have a steep learning curve. Another recommendation was not to use the threading library for timing as it interferes with the running of the tests; playback engine should be used instead. Annoyingly, the coded UI tests aren’t available for Visual Studio Professional but a third-party library is available from Telerik for less than the cost of Ultimate Edition.

Micro Services: conquer monoliths, before they own you

This talk was by Kiran Singh. I was rather flagging at this point. The speaker told of the benefits of microservices such as independent deployability and that working with distinct services lowers cognitive load. He also gave some advice for working with microservices, such as the need for good integration testing and that building microservices requires something of a culture change for the organisation not just a software change. For more details, read Martin Fowler’s microservices article. He gave a couple of case studies and reminded me that I still haven’t read The Black Swan.

Many, many thanks are due to the people who ran and sponsored the event. The day ended with drinks and dinner with some colleagues in Veritas (a pub whose menu knows not the word bland).

Undo/Redo

2014-06-20T00:00:00+00:00

Over the last week, I’ve developed an interest in Undo/Redo. This was partly inspired by reading an article by Aza Raskin (son of Jef) titled Never Use A Warning When You Mean Undo.

I looked at several articles on the subject of undo/redo and came to the conclusion that they were all far too complicated. I decided to see if there was a simpler way.

UndoableAction

In essence, to be able to have undo/redo functionality in an application one must have the ability to do and undo every action that modifies the state of the thing you are editing. [I realise that this is a rather loose definition and it should probably be pinned down for your specific application; in terms of what is, and isn’t, a state change that need to be undone.]

To achieve this, we can start by defining an interface to be implemented by all edit actions. This will look something like the following:

public interface UndoableAction
{
    void Do();
    void Undo();
}

UndoRedoStack

Undo and redo is essentially a stack operation. When an action is performed, it is put onto the undo stack. When undo is called, the top action on the stack is popped off; the undo method is run; and then the action is pushed onto the redo stack. When redo is called, the same sequence happens in reverse.

One special corner case, that caught me out at first, is the need to clear the redo stack when a new action is performed; as this invalidates the current redo stack because its expected initial state has now been changed. Undo is obviously unaffected by this.

A relatively simple implementation of the undo/redo stack might look something like the following:

public class UndoRedoStack
{
    private readonly Stack<UndoableAction> _undoStack = new Stack<UndoableAction>();
    private readonly Stack<UndoableAction> _redoStack = new Stack<UndoableAction>();

    public void Do(UndoableAction action)
    {
        action.Do();
        _undoStack.Push(action);
        _redoStack.Clear();
    }

    public void Undo()
    {
        RunAction(_undoStack, _redoStack, a => a.Undo());
    }

    public void Redo()
    {
        RunAction(_redoStack, _undoStack, a => a.Do());
    }

    private static void RunAction(
        Stack<UndoableAction> source,
        Stack<UndoableAction> target,
        Action<UndoableAction> undoRedo)
    {
        if (source.Count == 0)
            return;
        var action = source.Pop();
        undoRedo(action);
        target.Push(action);
    }
}

Each newly created action is passed to the Do method and Undo and Redo modify the state accordingly as they are called. This is almost certainly not thread safe but I’ll leave such additions as an exercise for the reader.

AddToListAction

All that remains is for us to create some undoable actions. These will, of course, be application specific and one must be very careful that undo and redo will perform correctly under all required circumstances. Here is a case that may commonly occur: adding an item to a list.

public class AddToListAction<T> : UndoableAction
{
    private readonly T _itemToAdd;
    private readonly IList<T> _list;

    public AddToListAction(T itemToAdd, IList<T> list)
    {
        _itemToAdd = itemToAdd;
        _list = list;
    }

    public void Do()
    {
        _list.Add(_itemToAdd);
    }

    public void Undo()
    {
        _list.RemoveAt(_list.Count - 1);
    }
}

In this case, Do appends an item to the end of the list and Undo removes the last item of the list. As long as the list is in the same state when Undo is called, as it was after Do had been called, everything should work out as planned. This is why it is important that every action that modifies the state is an UndoableAction.

ActionBlock

As a final bonus, here is another general purpose UndoableAction that is quite useful. Often we want to perform a group of actions in one compound action (e.g. adding a group of items to a list). In this case, we would want undo to remove all of the added items in one step rather than removing each item individually. Obviously, we could write an add multiple items action but that approach will get old fast as we add more and more actions. A better approach would be to have the ability to compose multiple simpler actions. This composition can also be done as an UndoableAction as follows:

public class ActionBlock : UndoableAction
{
    private readonly UndoableAction[] _actionSequence;

    public ActionBlock(params UndoableAction[] actionSequence)
    {
        _actionSequence = actionSequence;
    }

    public void Do()
    {
        foreach (var action in _actionSequence)
            action.Do();
    }

    public void Undo()
    {
        foreach (var action in _actionSequence.Reverse())
            action.Undo();
    }
}

This time, the action is a list of UndoableActions performed forwards for Do and in reverse for Undo. When Undo is called, all of the undo actions in the sequence will be called in one step.

So, there we have it. A simple implementation of undo/redo that uses an interface and a simple class that wraps two stacks. Now all that remains is the hard part: writing UndoableActions where Undo properly reverts the state.

A simple example implementation of the above can be found on github.

Such Coffee, Many Caffeine, Wow!

2014-05-18T00:00:00+00:00

Over the past two days I’ve been at BACON 2014 (it’s a wonderful conference, you must go). At the end I drank far too much coffee and enthusiastically signed up for a lightning talk. I’ll post a link to the talk here when it comes out.

I decided to talk air some of my initial impressions about the current “TDD Is Dead” debates that are going on. Whilst my thoughts are not fully developed yet, and my talk was almost certainly completely incoherent (as it was largely ad libbed), I think my key conclusions where valid.

In addition, I was very pleased to see that a large proportion of the attendees at BACON 2014 where practicing TDD on a daily basis, on real-world projects. It’s death seems, at least in that community, to have been greatly exaggerated.

Be Pragmatic, Not Dogmatic

I tend to agree with DHH that you don’t always know what you are trying to achieve when you start programming. Sometimes you want to quickly try a few things out and see where it goes. See what works best. It’s often difficult to start by writing a test when you don’t know the goal. I seem to recall even Uncle Bob saying that TDD shouldn’t replace design; and sometimes that design is best done in code.

Also, not every class or method needs to be completely isolated from everything. Again, Uncle Bob (as he so often does) wrote a great blog post just the other day about where and when to mock and even what sort of mocks are best to use.

So, be pragmatic. 100% test coverage, with completely decoupled unit tests, is not always a helpful goal and can often force you to do strange things to allow it to be achieved.

Code Isn’t Documentation

DHH has a goal of readability of code over testability of code. He seems to be saying that TDD forces your hand and leads to code that is ‘too decoupled’ and not cohesive. I liked Kent Beck’s repost that TDD doesn’t force you to do anything. You are in control of the design.

But, more than that, the most readable code in the world won’t be able to overcome there being one million lines of it. Steve Losh had a wonderful article on how to document code, which basically said that reading the code should be the last resort to understanding your codebase.

Just remember, these are all individual views. I’ve seen a tree trunk, DHH has seen a snake but we are still yet to properly address the elephant in the room.

I’m sure I’ll have many more thoughts on this subject as the debate goes on but writing down their current state will allow me to look back and point and laugh at the silly conclusions I drew early on in the proceedings.

Update: My Lightning Talk Video

Mark Withall - Lightning talk from BACON: things developers love on Vimeo.

Labelled TextBox In WPF

2014-05-02T00:00:00+00:00

As is so often is the case, StackOverflow has provided another interesting question that reminded me of an issue I encounter from time to time. The question is about how to have a sequence of labelled textboxes, such that everything is nicely aligned. The question references an answer that the OP doesn’t like as it potentially adds some performance overhead. I don’t think that any overhead in that solution is likely to be an issue in practice though.

I’d like to walk through a thought process that might get you to something similar to the referenced answer.

The Basic Approach

Firstly, let’s look at how one might approach this problem in a ‘one off’ case; where reuse isn’t an issue.

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto"/>
        <ColumnDefinition Width="*"/>
    </Grid.ColumnDefinitions>

    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="Auto"/>
    </Grid.RowDefinitions>

    <TextBlock Grid.Row="0" Grid.Column="0">Thing1</TextBlock>
    <TextBox Grid.Row="0" Grid.Column="1" Text="{Binding Thing1}"/>

    <TextBlock Grid.Row="1" Grid.Column="0">Thing2</TextBlock>
    <TextBox Grid.Row="1" Grid.Column="1" Text="{Binding Thing2}"/>

    <TextBlock Grid.Row="2" Grid.Column="0">Thing3</TextBlock>
    <TextBox Grid.Row="2" Grid.Column="1" Text="{Binding Thing3}"/>
</Grid>

This is clearly quite a verbose solution and there must be a better way if we are going to be doing this sort of thing a lot. And we are. Another annoyance with this approach is the need to renumber everything if we want to insert a row or column. It would be nice to have something more akin to HTML tables.

What Would We Like To Write?

Before we try and solve the problem, it might be a good idea to think in the abstract of what we would like to be able to write in an ideal world. It’s probably going to look something along the lines of this:

<LayoutGroup>
    <LabelledTextBox Label="Thing1" Text="{Binding Thing1}"/>
    <LabelledTextBox Label="Thing2" Text="{Binding Thing2}"/>
    <LabelledTextBox Label="Thing3" Text="{Binding Thing3}"/>
</LayoutGroup>

It would be difficult to get more concise than that and still retain the expressiveness of what we want to do.

How Near Can We Get To This?

So how are we going to go about this? Let us start at the bottom and look at how we could create a ‘LabelledTextBox’ control. The XAML is pretty straightforward, and is similar to what we started with above but we’ve now added a SharedSizeGroup to allow things to line up properly (assuming we are nested in something with Grid.IsSharedSizeScope set to True).

LabelledTextBox.xaml

<Grid x:Name="Root">
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto" SharedSizeGroup="Labels"/>
        <ColumnDefinition Width="*"/>
    </Grid.ColumnDefinitions>

    <TextBlock Grid.Column="0" Text="{Binding Label}"/>
    <TextBox Grid.Column="1" Text="{Binding Text}"/>
</Grid>

LabelledTextBox.xaml.cs

That’s all well and good but where are we getting these Label and Text properties to bind to? Here we need to introduce some Dependency Properties. This allows the user of the LabelledTextBox to bind to Label and Text and for the control to use them too. Note that we have to set the DataContext of the Grid to the control, so that we can bind to our own Label and Text properties but we leave the top-level DataContext of the control in the broader context, so that other things can bind to our Label and Text properties too.

public partial class LabelledTextBox
{
    public static readonly DependencyProperty LabelProperty = DependencyProperty
        .Register("Label",
                typeof (string),
                typeof (LabelledTextBox),
                new FrameworkPropertyMetadata("Unnamed Label"));

    public static readonly DependencyProperty TextProperty = DependencyProperty
        .Register("Text",
                typeof (string),
                typeof (LabelledTextBox),
                new FrameworkPropertyMetadata("", FrameworkPropertyMetadataOptions.BindsTwoWayByDefault));

    public LabelledTextBox()
    {
        InitializeComponent();
        Root.DataContext = this;
    }

    public string Label
    {
        get { return (string)GetValue(LabelProperty); }
        set { SetValue(LabelProperty, value); }
    }

    public string Text
    {
        get { return (string)GetValue(TextProperty); }
        set { SetValue(TextProperty, value); }
    }
}

LayoutGroup.cs

Finally, we need to create a container control that has shared size scope. We can doing this by creating a subclass of StackPanel and then setting Grid.IsSharedSizeScope to True.

public class LayoutGroup : StackPanel
{
    public LayoutGroup()
    {
        Grid.SetIsSharedSizeScope(this, true);
    }
}

Usage

This gives us the ability to put it all together in the following way that is very similar to our initial desired solution (with the exception of references to the namespace path of the controls).

<Views:LayoutGroup>
    <Views:LabelledTextBox Label="Thing1" Text="{Binding Thing1}"/>
    <Views:LabelledTextBox Label="Thing2" Text="{Binding Thing2}"/>
    <Views:LabelledTextBox Label="Thing3" Text="{Binding Thing3}"/>
</Views:LayoutGroup>

One could, of course, go a step further and have a Command property that allows a button to be shown, e.g. for the purpose of selecting files. And even have the button hidden if no command is bound to it. I’ll leave this and the many other possible extensions as an exercise for the reader.

Save All Excel Worksheets As Tab Separated Text

2014-04-18T00:00:00+00:00

Quite often I have to save worksheets in Excel as tab-separated text or CSV. I have managed to get it down to 8 clicks to perform this task for a single worksheet. At the point I had to do this for 40 spreadsheets with 4 worksheets in each, I decided that enough was enough.

I started off by writing a simple macro that saved all the worksheets in the active workbook to the desktop. I then placed it in my PERSONAL.XLSB (which is an incredibly useful place to put macros that you want to use on multiple spreadsheets as it’s always there; hidden in the background).

Sub SaveAllAsTsv()

    Dim WS As Excel.Worksheet
    Dim SaveToDirectory As String
    Dim filename As String

    SaveToDirectory = CreateObject("WScript.Shell").specialfolders("Desktop")

    For Each WS In ActiveWorkbook.Worksheets
        filename = SaveToDirectory & "\" & WS.Name & ".txt"
        WS.SaveAs filename, xlText, Local:=True
    Next

End Sub

One interesting point to note is the Local:=True argument to the SaveAs method. This makes sure that the formatting of, e.g. dates, is exported as it is presented in the worksheet rather than using whatever default the SaveAs method decides upon.

This approach worked fine for a while but then I started to have spreadsheets with far more worksheets than I actually wanted to export. Copying them from the desktop was a bit of a pain too. I, therefore, went back to the macro and expanded upon it to allow selection of the destination folder and the option whether to save each worksheet.

Sub SaveAllAsTsv()

    Dim WS As Excel.Worksheet
    Dim SaveToDirectory As String
    Dim Filename As String

    'Get folder to save to
    With Application.fileDialog(msoFileDialogFolderPicker)
        .Title = "Output Folder"
        .AllowMultiSelect = False
        If .Show <> -1 Then Exit Sub
        SaveToDirectory = .SelectedItems(1)
    End With

    'Choose which worksheets to save
    For Each WS In ActiveWorkbook.Worksheets
        Select Case MsgBox("Save " & WS.Name & "?", vbQuestion + vbYesNoCancel)
            Case vbYes
                Filename = SaveToDirectory & "\" & WS.Name & ".txt"
                WS.SaveAs Filename, xlTextWindows, Local:=True
            Case vbCancel
                Exit Sub
            Case vbNo
        End Select
    Next

End Sub

This works fine for now. I imagine that at some point I’m going to get annoyed with clicking ‘Yes’ or ‘No’ for each worksheet and will have to upgrade to a single list of all worksheets with checkboxes up front. I’ll leave this extension as an exercise for the reader.

To Rebase Or Not To Rebase?

2014-03-22T00:00:00+00:00

Some thoughts on the relative merits of rebasing a branch before merging when working with a DVCS like Mercurial or Git.

Updated 18th April 2014 with some comments from my colleague @DaveCTurner

Merge

Pros

Simple to perform
Maintains the original context of the source branch
Easy to find points where merge conflict resolution failed

Cons

Can’t bisect to find cause of bugs (requires linear history)
- Non-linear histories mean that working and non-working versions can be interleaved making it unlikely that bisect will end up at the revision that caused the bug
Difficult to read the history
Further con of merging is that conflict resolution is atomic. If you have a knarly merge then doing it in pieces is better. I claim that resolving conflicting patches in the queue is much easier than 3-way merging @DaveCTurner
You can do topological bisection in a mergy history, but the chances are the first bad commit is the merge, which doesn’t help you with debugging. @DaveCTurner

Rebase

Rebase means different things to different people. Let me start by clarifying what I mean. This is best done with a picture (see above). When I say rebase, I mean moving the whole branch to the top of the tree without moving all changesets onto the default branch or flattening into a single changeset (two common alternative meanings, particularly in the Git world). This means that we lose the minimum of information.

Pros

Can easily track down cause of bugs using bisect
Simple to read history with clearly defined tasks

Cons

Hard to find where merge conflict resolution failed
- But can partly be done by reordering the changesets by time
- Or better, if there is a conflict, rebase using the patch queue and name the commits that resolve conflicts explicitly
- This is less of an issue if you have good test coverage
Can only be done with local changesets (i.e. before pull or push); hence can prevent collaboration on a branch
- You can collaborate on a branch when rebasing, either with bundles or a private clone set up for just the branch. Requires about the same amount of coordination as the alternatives. @DaveCTurner

Personally, I tend to favour the rebase approach as I’m somewhat OCD about having a pretty looking graph of the history.

2013 Programming Articles Review

2014-02-22T00:00:00+00:00

At the beginning of each year I like to set myself some goals for the coming twelve months. Last year (2013), I decided I wanted to blog more. In particular, I wanted to write more about programming. One of the main reasons for this was that I wanted to give myself some practice at explaining my thought process; an area in which I’ve not always excelled in the past.

Over the year, I managed to write nine articles, on a fairly diverse set of programming topics. While I fell short of my ‘one a month’ goal, I still consider this a success. I suppose, as with most new year’s resolution type things, it was inevitable that it would tail off in the second half of the year.

This year (2014), I have decided to try again at twelve articles over the year. Hopefully, I will at least beat the nine of last year. Of course, I’ve decided to cheat and give myself a head start by writing this article about last years articles. I also have a couple of half finished articles from last year, which should also help.

In addition to writing more articles, I’d like to record a couple of live coding videos for youtube, in the areas of TDD and MVVM, based on a few of last year’s articles. I also want to write the simple blog commenting system that’s been on the todo list for quite some time.

To finish, here is a list of links to the articles from 2013. I think my favourite was probably The World’s Simplest C# WPF MVVM Example; the code for which has been forked and starred a number of times on github. I’m planning a follow up to this article where I look into extreme decoupling of the parts of an MVVM application to see just how far one can go.

Wish me luck!

2013-01-04 - How to extract text from a Microsoft Word document in C#
2013-01-09 - Speed Reader Bookmarklet
2013-02-01 - Create an Outlook 2010 Search Folder using VBA
2013-03-01 - The World’s Simplest C# WPF MVVM Example
2013-03-30 - Thoughts On Test Driven Development
2013-04-12 - How Big Is Your Endian?
2013-08-06 - TDD MVVM Framework Test Plan
2013-08-29 - A Simple Event Aggregator / Message Bus In C#
2013-10-28 - TDD vs Productivity

NaNo Novel Structure

2013-10-31T00:00:00+00:00

My usual approach to make novelling in November easier is to have a fairly rigid structure in place. This has two goals: the first is to allow me to end up with a balanced novel and the second is to give me a sense of achievability and progress.

50,000 words sounds like a lot (and is) but it seems much more manageable when I know that I only have to write 1667 in one day and 3 days’ writing will complete the first chapter.

Here is the list of structures that I have used to help me along for the previous four NaNos and the one that I will be using this year.

2009: 100 x 500 word chapters, where the end of each chapter would inspire the beginning of the next (and the final chapter would wrap around to the beginning).

2010: 3 x 10 chapter parts; each being 1667 words and taking a day to write.

2011: A free approach to chapters/structure, where each chapter is finished when it’s finished.

2012: 30 x 1667 word chapters with each chapter focusing on one of the 3 or 4 storylines.

And my choice for this year is to write 10 x 5000 word chapters, each taking 3 days to write but each chapter will be made up of newspaper articles, interviews, letters and the like. Hopefully, this will help motivate me as the previous structures have done.

TDD vs Productivity

2013-10-28T00:00:00+00:00

Today I encountered this programmers.stackexchange post on TDD vs Productivity and had some thoughts on common misconceptions about TDD and unit testing.

If you don’t end up with 100% test coverage, you haven’t done TDD properly(tm) - this is because you shouldn’t write any production code without a failing test and you should only write the minimum to make the test pass.
You shouldn’t be testing 3rd party code, so TDD still applies to library intensive software like game programming just as much as any other, as you won’t be testing the OpenGL/DirectX functionality only the calls to the API.
If you are writing lots of tests for a class, you probably aren’t abiding by the single-responsibility principle - in most cases, classes that only do one thing shouldn’t need many tests to cover its behaviour.
Refactoring shouldn’t change behaviour - if you want to change behaviour write a test for the new behaviour or modify tests that now don’t represent the desired behaviour of the software.
Unit tests only tell you when you have a bug, not when you don’t.
When people say they don’t test UI, what they should mean is that they don’t test what the UI looks like; they should still be testing what it does. Also, see point 1.

I may add items to this list as I think of them. Also, I reserve the right to change my mind if superior data are discovered.

Introduction To NaNoWriMo 2013

2013-10-20T00:00:00+00:00

This November I will be doing NaNoWriMo for the fifth time.

I’ve decided this year to write a political satire based in the near future. In the story an extreme right-wing party gets into power after an unusually large number of protest votes. Needless to say, hilarity ensues.

The main story will revolve around a number of new laws and policies that will be introduced during the term. These will include such things as the following:

a new speed camera system that utilises satellite technology to monitor all cars all the time
unemployed people being automatically given work by the government to earn their benefits; resulting in much cleaner towns and cities and other side effects
an increase in the minimum age for smoking by one year every year

Other policies that will be addressed will include business, education and, of course, foreign policy and immigration.

I have no idea where all of this will end up but it should provide much entertainment for the month of November.

See you all at the TGIO.

A Simple Event Aggregator / Message Bus In C#

2013-08-29T00:00:00+00:00

In a previous article we looked at the two most important features of an MVVM framework. Here we look at another common feature.

Most, if not all, mainstream MVVM frameworks provide some sort of event aggregator/message bus. This makes communication between viewmodels easier than doing it manually via events or callback injection (both of which require too much knowledge of either the sender or receiver and tend to be the cause of accidental memory leaks).

Fortunately, it is straightforward to create a simple event aggregator. We can define the API using the following set of interfaces.

`ISubscriber<TMessage>`

public interface ISubscriber<in TMessage>
{
    void HandleMessage(TMessage message);
}

This allows a class to implement multiple event handlers without the need to switch on the message type.

`ISubscriberStore`

public interface ISubscriberStore
{
    void Add<TMessage>(ISubscriber<TMessage> subscriber);
    IEnumerable<ISubscriber<TMessage>> Subscribers<TMessage>();
}

No Remove method, as subscriptions will be stored as weak references and are cleaned up on calls to Subscribers.

`IMessageAggregator`

public interface IMessageAggregator
{
    void Subscribe<TMessage>(ISubscriber<TMessage> subscriber);
    void Publish<TMessage>(TMessage message);
}

No Unsubscribe method, as subscriptions are stored as weak references and are cleaned up on calls to publish.

Notice that messages can be anything, though it is probably sensible to wrap them in a well named class.

As an aside, I don’t generally go in for naming interfaces with an ‘I’ prefix. There are many arguments in favour of this on the Interweb. However, for libraries, where one doesn’t know who is using it (or how), I prefer the explicit approach.

Test Plan

SubscriberStore

SubscriberStore implements ISubscriberStore
Add adds a subscriber to the underlying dictionary list for the particular message type
Subscribers returns all subscribers for the given message type
Subscribers removes all dead subscribers for the given message type
Subscribers doesn’t return null subscribers

MessageAggregator

MessageAggregator implements IMessageAggregator
Subscribe adds to the underlying ISubscriberStore
Publish calls HandleMessage on all subscribers for the given message type

Also, an integration/acceptance test that has multiple publishers and subscribers (implementing multiple types each) is probably warranted.

The actual implementation details of these classes is left as an exercise for the reader but will hopefully be the subject of a later video.

TDD MVVM Framework Test Plan

2013-08-06T00:00:00+00:00

Just out of interest, I was experimenting with TDDing (if that’s a real phrase) a basic MVVM framework in C#. The following is the rough sequence of tests for test-driving the implementation that I ended up using.

WPF makes use of two main interfaces: INotifyPropertyChanged for notifying the UI of updates to properties that it is bound to, e.g. the value in a TextBox; and ICommand for executing commands when, e.g. a Button is pressed.

Here are the sequence of tests for the two main classes in the framework.

ObservableObject : INotifyPropertyChanged

ObservableObject implements INotifyPropertyChanged
RaisePropertyChangedEvent with property name fires event
RaisePropertyChangedEvent with property name passes name through to handler
RaisePropertyChangedEvent with name of non-existent property throws ArgumentException (in Debug only)
RaisePropertyChangedEvent with multiple property names fires event for each
RaisePropertyChangedEvent with no observers does not throw exception

DelegateCommand : ICommand

DelegateCommand implements ICommand
CanExecute returns True
Execute runs stored Action
Execute with null does not throw exception

I’m unsure as to the necessity of testing that the classes implement the required interfaces but it is technically a requirement of the implementation.

At some point in the near future, I hope to record a video of this development.

How Big Is Your Endian?

2013-04-12T00:00:00+00:00

I have finally discovered some of the advantages and disadvantages of the two main endian-nesses for data representation. This isn’t something I’ve really thought about before but it’s actually quite interesting when you find out.

Big-endian (the firstianness of this endian should not be interpreted as any sort of favouritism whatsoever towards this particular representation)

Human-readable, i.e. reading from left to right tells you what the data is
Testing for sign, i.e. the leftmost bit is the positivity/negativity

Little-endian (the secondness of this endian should in no way indicate the lack of joy derived from its usage)

Easily truncate-able, i.e. conversion from 32-bits to 16- or 8- just involves taking the first n bits

There’s also a middle-endian, apparently, though I doubt anyone knows why.

So, now we know.

As always, see the ‘pedia for further details.

Thoughts On Test Driven Development

2013-03-30T00:00:00+00:00

Except from a conversation with Matthew T. Atkinson on the 27th of March 2013. A discussion on how to do TDD ‘properly’ and why it’s hard to be disciplined about following the approach.

For TDD one must write ONE test that fails and then make it pass before moving on to the next test.

That’s not quite true. One should do the following:

"write the simplest, meaningful failing test"
"write the minimum production code to make it pass"
"refactor so the code is nice"
goto 10

Refactoring should not be delayed; there would be no need to delay it as the code is arguably ‘complete’ at this point (as it does everything that the tests say it should do).

I must say that I’m not very good at following the above. It’s hard. There’s a lot of temptation to take shortcuts; to write more general code than is necessary to make the test pass, etc.

The traditional TDD approach is to work from the bottom up; developing the model classes that one expects to need.

The ‘British’ way is to work top-down; starting with a skeleton framework of the whole app and filling in the details as you go in thin, vertical slices of functionality. This leads to less cruft I would imagine. This is less popular. I would imagine that this is because it requires much more upfront setup of your testing framework, as to even write the first test you have to write a lot of support code.

I recommend the book “Growing Object-Oriented Software, Guided By Tests” as a good book on that approach. It gets a bit dull later on but the early stuff is very informative.

The top-down approach is called the ‘London’ method and the bottom-up the ‘Classic’ or sometimes ‘Chicago’ or ‘Detroit’; as discussed on stackexchange.

I suspect that TDD discipline is much easier in a pair-programming setting.

The World's Simplest C# WPF MVVM Example

2013-03-01T00:00:00+00:00

The interesting thing to me about MVVM (Model-View-ViewModel), is that the Model should know about nothing else, the ViewModel should only know about the Model (not the View), and the View should only know about the ViewModel (and not the Model).

One thing that I’ve wanted to do for quite some time now, is to create a very simple MVVM example for C# WPF. As this post will show, I’ve finally gotten around to it.

Simple, in this case, has a few caveats (as one might expect). I wouldn’t want to write a completely trivial example that didn’t do anything. With that in mind, let me lay out the ground rules.

Model: This can be really simple, the goal here is for the ViewModel not to have to do any of the business logic.

ViewModel: This should essentially delegate everything to the Model except for exposing data for the View.

View: This should just bind to the ViewModel and make stuff look pretty.

The example application should have the following features:

Some user input
A list of something
Some user action (e.g. a button) that can be invoked both via the mouse and a keyboard shortcut

With those goals in mind, the application we are going to write will allow the user to enter some text in a TextBox and then press a button (or key) and have that text magically transformed into uppercase. A history of previous conversions will be recorded and presented in a ListBox for posterity. Exciting, eh?

The MVVM Framework

The first thing that we are going to do is to create a minimal MVVM framework for us to use in the rest of the application. There are two important components of the framework.

The first is a base class for ViewModel classes. This handles the implementation of the INotifyPropertyChanged interface. This interface allows update messages to be passed to the View. It should also be noted that all ViewModel classes that are bound to by the View should implement this (even if the values don’t change from the ViewModel) as there is a known memory leak that may occur if they don’t (see the Microsoft support article).

The simplest implementation is as follows:

public abstract class ObservableObject : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void RaisePropertyChangedEvent(string propertyName)
    {
        var handler = PropertyChanged;
        if (handler != null)
            handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

This can be expanded in various ways. For example, we could add checking that the property name exists for the given class.

The second component is an implementation of the ICommand interface. This is what commands in the View are bound to. There is no default implementation, so we must roll our own.

The simplest implementation is as follows:

public class DelegateCommand : ICommand
{
    private readonly Action _action;

    public DelegateCommand(Action action)
    {
        _action = action;
    }

    public void Execute(object parameter)
    {
        _action();
    }

    public bool CanExecute(object parameter)
    {
        return true;
    }

#pragma warning disable 67
    public event EventHandler CanExecuteChanged;
#pragma warning restore 67
}

One thing to note is that CanExecute always returns true. Don’t you just hate it when a button or a menuitem is greyed-out for no apparent reason? Don’t do it! Much better to allow the button to be clicked and then give some informative feedback as to why the intended action cannot be carried out.

Now we have our minimal MVVM framework, we can move on to create our application.

The Model

Our model is simple; consisting of a single TextConverter class. To ~~avoid the annoyance of Resharper whinging that the ConvertText method can be made static~~ allow the TextConverter class to conform to the Open/Closed Principle, I’ve made the string conversion a parameter.

public class TextConverter
{
    private readonly Func<string, string> _convertion;

    public TextConverter(Func<string, string> convertion)
    {
        _convertion = convertion;
    }

    public string ConvertText(string inputText)
    {
        return _convertion(inputText);
    }
}

The ViewModel

We also only have a single Presenter class in our ViewModel. This is, however, slightly more complex than the Model.

public class Presenter : ObservableObject
{
    private readonly TextConverter _textConverter
        = new TextConverter(s => s.ToUpper());
    private string _someText;
    private readonly ObservableCollection<string> _history
        = new ObservableCollection<string>();

    public string SomeText
    {
        get { return _someText; }
        set
        {
            _someText = value;
            RaisePropertyChangedEvent("SomeText");
        }
    }

    public IEnumerable<string> History
    {
        get { return _history; }
    }

    public ICommand ConvertTextCommand
    {
        get { return new DelegateCommand(ConvertText); }
    }

    private void ConvertText()
    {
        if (string.IsNullOrWhiteSpace(SomeText)) return;
        AddToHistory(_textConverter.ConvertText(SomeText));
        SomeText = string.Empty;
    }

    private void AddToHistory(string item)
    {
        if (!_history.Contains(item))
            _history.Add(item);
    }
}

Notice that we are inheriting from our MVVM framework ObservableObject, which provides our implementation of the INotifyPropertyChanged interface. Our presenter is exposing three properties that the View can bind to. We’ll look at them one at a time.

The SomeText property is the text that the user will enter. The getter returns the current value of the property. The View will get this value when it is first bound and then it will only change when it receives a property change notification. When the setter is called with a new value, the property backing field is updated and then the event is raised to inform observers that the value has changed.

The History property is the list of previous converted values. It is backed by an ObservableCollection, which essentially does everything for us. Whenever we add something to it, the View is notified, so it can update.

The final property is ConvertTextCommand. This returns an ICommand using our DelegateCommand class from our framework. This can be bound to such things as buttons and key presses in the View. We’ve hooked it up to call our ConvertText method when executed. This method uses our TextConverter field (which we’ve set up to convert text to uppercase) and then adds the converted value to the history list. Finally, it clears the value of SomeText (which will, of course, notify the View). One last thing to note is that History is going to be bound to a ListBox, which can do strange things when selecting an item where there are duplicates. This is the reason for not adding duplicate strings to the history here.

[Update 2016-09-23: added handling for the case when SomeText is null; which would crash the application. Thanks to ajeebkp23 for pointing this out.]

That’s all of the coding out of the way with, now we can move on to ‘drawing’ the UI.

The View

The nice thing about WPF for me is that we can define the entire user interface in XML, without having to write a single line of code. We just need to bind widgets to the ViewModel to read and write data.

<UserControl ...>

    <UserControl.InputBindings>
        <KeyBinding Key="Enter" Command="{Binding ConvertTextCommand}"/>
    </UserControl.InputBindings>
    
    <StackPanel Height="336">
        <Label Foreground="Blue" Margin="5,5,5,0">Text To Convert</Label>
        <TextBox Text="{Binding SomeText, UpdateSourceTrigger=PropertyChanged}" Margin="5"/>
        <Label Foreground="Blue" Margin="5,5,5,0">History</Label>
        <ListBox ItemsSource="{Binding History}" Height="200" Margin="5"/>
        <Button Command="{Binding ConvertTextCommand}" Margin="5">Convert</Button>
    </StackPanel>
    
</UserControl>

As you can see above, widgets such as labels and textboxes are just XML elements. The Text attribute of the TextBox has been bound to SomeText in our presenter and the ItemsSource attribute of the ListBox has been bound to History. Notice that the ConvertTextCommand property has been bound to two things, the KeyBinding and the Button. We needn’t have stopped there. We could have bound it to an item in a menu too. In fact, we can bind anything as many times as we like, allowing us to have several different ways of displaying the same data. We could, for example, have a list of numbers in our ViewModel that is bound both to a table of data and to a chart.

Before we move on to the definition of the Window that the UserControl sits in, I want to take a quick look at the code behind for this control.

public partial class ConverterControl
{
    public ConverterControl()
    {
        InitializeComponent();
    }
}

Notice that there is absolutely nothing superfluous in it whatsoever. There’s no code to read and write the text in the textbox; no event handlers to process button clicks. Everything is done through binding to the ViewModel. You literally can’t have less code in the .xaml.cs file. This makes our application much easier to write tests for.

Our final piece of UI description is the main window.

<Window ...
        Title="Converter"
        MinWidth="300"
        ResizeMode="NoResize"
        SizeToContent="WidthAndHeight">
    
    <Window.DataContext>
        <local:Presenter/>
    </Window.DataContext>
    
    <local:ConverterControl/>
    
</Window>

This has two points of interest. Firstly, we are specifying that the context for the Window is an instance of the Presenter class in our ViewModel (which will be created for us when the window is created). Secondly, we are specifying that the UI is made up of a ConverterControl that we defined above, which will inherit that data context.

[Update 2018-02-15: note that the namespace ‘local’ assumes that both Presenter and ConverterControl are in the same namespace as MainWindow. Add additional namespaces as required for your own structure. Thanks to yanniqq for highlighting the issue.]

And that is basically it. All together around 35 real lines of C# code and about 18 lines of XAML.

The full code is available on github.

Create an Outlook 2010 Search Folder using VBA

2013-02-01T00:00:00+00:00

Earlier this week I discovered that Microsoft Outlook 2010 (and most likely other versions too) isn’t very good at anything beyond very, very simple searches. This is even more true of searches used to create Search Folders (which appear to have more limitations on them than the Search box, for no apparent reason). I, therefore, set about learning VBA, so that I could have more control over the creation of Search Folders.

In this particular case I was wanting to create a Search Folder containing all emails that weren’t from one of my company’s domains. This turned out to be surprisingly difficult; as many emails only display the name of the sender and not their address. The search only appears to search the displayed string, rather than the actual sender address. This made me sad.

Starting from the top and working our way down, the most difficult part of the exercise was the creation of the filter string. These are rather SQL-looking beasts. It turned out that looking at the sender email address is a rather convoluted task that involves comparing the value of “http://schemas.microsoft.com/mapi/proptag/0x0C1F001F” with the string you are interested in. I’ve absolutely no idea why, as most of the other email header fields have far more sensible names. Inventing a CreateSearchFolder method that takes the parameters of the Store name, the path of the folder to search in, the filter and the name of the Search Folder to create; we end up with the following:

Sub AddNotInternalSearchFolder()
    Const PR_SENDER_EMAIL_ADDRESS_W As String
        = "http://schemas.microsoft.com/mapi/proptag/0x0C1F001F"
    
    Dim filter As String
    filter = "NOT (" & PR_SENDER_EMAIL_ADDRESS_W & " LIKE '%@markwithall.com%')" & _
             "AND NOT (" & PR_SENDER_EMAIL_ADDRESS_W & " LIKE '%@markwithall.co.uk%')"
    
    Call CreateSearchFolder("MarkWithall", "'\MarkWithall\Inbox'", filter, "Not Internal")
End Sub

The method to create a Search Folder is then quite straightforward; remembering, of course, to check that the folder we are creating doesn’t already exist. It’s just a simple case of calling the AdvancedSearch method of Application, with the data we just passed, to create a search object and then saving it to the relevant name.

Sub CreateSearchFolder(storeName As String,
                       folderPath As String,
                       filter As String,
                       folderToCreate As String)
    If SearchFolderExists(storeName, folderToCreate) Then
        MsgBox "Search folder '" & folderToCreate & "' already exists"
    Else
        Dim objSearch As Search
        Set objSearch = Application.AdvancedSearch(folderPath,
                                                   filter,
                                                   True,
                                                   "SearchFolder")
        objSearch.Save (folderToCreate)
        MsgBox "Done!"
    End If
End Sub

Finally, we just need to implement the check that the Search Folder doesn’t already exist. This just involves looping through the list of Search Folders and checking that none of them have the name we’ve provided.

Function SearchFolderExists(storeName As String, folderName As String)
    SearchFolderExists = False
    For Each store In Application.Session.Stores.Item(storeName).GetSearchFolders()
        If store.Name = folderName Then
            SearchFolderExists = True
        End If
    Next
End Function

And that’s it. Now, in the future, if we require any other complicated Search Folders, it’s just a case of modifying the filter string and providing a new name.

The end! It’s a mini adventure.

Speed Reader Bookmarklet

2013-01-09T00:00:00+00:00

The other day on TWiT I heard about an iPad app called Read Quick. I thought that this sounded like a brilliant idea and wouldn’t it be great if one could just select some text in a webpage, press a button and have the same thing happen.

After some consideration, I decided that it couldn’t be too hard to write a bookmarklet to do something similar. All that would be required would be to get the selected text, split it into words and then loop through the list of words displaying one at a time.

It didn’t take very long to write. I then threw it on github for the world to play with. It can be found here. The source can be found here.

There is still plenty to do to make the tool better: it doesn’t look very pretty, it’s not been testing on most browsers (only Chrome and Safari, so far) and you can’t configure it in any way (particularly the speed, which is fixed at 400 words per minute).

Hopefully, over the next week, I’ll have sufficient time to tidy it up a bit and test it on other browsers but even in it’s current state, I’m already finding it an invaluable tool.

How to extract text from a Microsoft Word document in C#

2013-01-04T00:00:00+00:00

Earlier this week, I had cause to extract the text from a Microsoft Word document. Some naughty people had decided that the best way to export a CSV file from their application, was to save it as text in a .doc file. May my dog have mercy on their sole!

One could approach this problem in a nice complicated way, using IFilter for example, but I’ve taken the brave decision to assume that someone using software that exports Word documents will have a copy of Word to hand (risky!). This allows the much simpler solution of using Interop.

The first step is to add Microsoft.Office.Interop.Word to project references.

We don’t want that nasty Interop stuff leaking all over the place, so I’ve created a nice simple little class that hides it away with a nicer interface. Notice, I’ve made the class implement IDisposable, so that we can encapsulate the whole usage of Word in a using block; making the scope completely obvious.

using Microsoft.Office.Interop.Word;

public class WordApplication : IDisposable
{
    private readonly Application _application;
    private Document _document;

    public WordApplication()
    {
        _application = new ApplicationClass();
    }

    public void Open(string docFilename)
    {
        object docFilenameAsObject = docFilename;
        _document = _application.Documents.Open(ref docFilenameAsObject);
    }

    public void SaveAsText(string outputTxtFilename)
    {
        object outputTxtFilenameAsObject = outputTxtFilename;
        object formatAsObject = WdSaveFormat.wdFormatText;
        _document.SaveAs(ref outputTxtFilenameAsObject, ref formatAsObject);
    }

    public void Dispose()
    {
        _application.Application.Quit();
    }
}

This leaves us with a much nicer API to work with. We can now simply create a new .txt file from the old .doc as follows.

public static void ConvertDocToTxt(string docFilename, string txtFilename)
{
    using (var application = new WordApplication())
    {
       application.Open(docFilename);
       application.SaveAsText(txtFilename);
    }
}

Obviously, wrapping that in a try/catch block or similar, with appropriate exception handling would be the way forward. In real life one would also most likely introduce some interface to allow mocking, etc.

To conclude:

Pros

Simple
Short
Supports both .doc and .docx (and probably other formats too)

Cons

Requires Word
Slow

Exercise for the reader: now you can all go away and write a little app to add to a right-click menu item in explorer to convert Word docs to text.

End Of NaNoWriMo 2012

2012-11-30T00:00:00+00:00

It is now the end of another year of NaNoWriMo. I’ve picked up my fourth consecutive win. I actually reached 50,000 words last Sunday (day 25) and finished the novel itself on Tuesday (day 27). The final word count was 53,297.

Below is a graph of how my word count increased each day against the target word count. Note the exceedingly straight line. This is how my NaNos typically go; doing approximately the required words per day (but not less, if I can avoid it) and finishing on the last Sunday of the month (which is when we have our weekly meetings).

I’ve put the novel away now and will, hopefully, come back to it at some future time to write a second draft. My aim for the next year is to try and edit one of my previous NaNo novels and self-publish it on the iBookstore and Kindle store. The publishing itself is fairly easy, it’s the getting the novel into a fit state that I can bare someone else reading it that is going to be the challenging part.

On Sunday is the TGIO party, where we all celebrate not having to write again for another year. The people in the Leicester group have all been amazing; both the old guard and the new recruits. It just wouldn’t be the same doing this in solitary confinement year after year. Thank you to you all.

How to partition a list in C#

2012-11-24T00:00:00+00:00

Just to test out how the syntax highlighting works for posting blog entries, here’s a short piece of code that I wrote a while ago to partition a list into fixed-size blocks.

public static IEnumerable<IEnumerable<T>> Partition<T>(this IEnumerable<T> list, int size)
{
    while (list.Any()) { yield return list.Take(size); list = list.Skip(size); }
}

And for extra credit, here are some extensions to make it work for strings too.

public static IEnumerable<string> Partition(this string str, int size)
{
    return str.Partition<char>(size).Select(AsString);
}

public static string AsString(this IEnumerable<char> charList)
{
    return new string(charList.ToArray());
}

These were originally posted by me on stackoverflow.

NaNoWriMo 2012 - Day 11

2012-11-11T00:00:00+00:00

Have reached 20,001 words so far. About two days ahead of target.

Today I’m going to look at some of the content of my novel. This year the story involves time travel. This, inevitably, involves putting down a certain amount of rules, which dictate how time travel is allowed to work. There are two main parts to this in the story. The first part is the practical side of thing, i.e., how time travel works. And the second part is the legal aspects of it, which is one of the central parts of the story.

The Rules Of Time Travel

There is only one timeline (not multiple universes that are split off at each decision). Change the past; change the single present.
Time travel can only visit the past. The future hasn’t happened yet and therefore doesn’t exist.
Time travel takes a great deal of energy and hence is very expensive and can only be done by the select few.
Travelling back in time works like stretching a piece of elastic holding you to the present; this has two consequences:
- The vast amount of energy taken by time travel increases in proportion to the amount of time travelled. Travelling back to the time of Jesus is not currently feasible. A few hundred years is the most travelled so far.
- Eventually, the person travelling will be pulled back to the present. Usually, a person can only stay for a few hours in the past. No one has managed more than a couple of days.

The Law Of Time Travel

Minor changes to the past, and hence knock on effects to the present, are tolerated.
If a major change is accidentally effected, one can do whatever is necessary to correct the course to result in minimal effect on the present.
For trials involving temporal crime, witnesses may be sent back to observe the events. No more than one witness is allowed per event, to avoid a crowd affecting the events.
Any major impact on the past will involve a trial to determine if that impact was accidental and the subsequent corrections necessary.

I shall endeavour to update this list with additional details as they arise, and any corrections that are necessary for a consistent set of rules.

NaNoWriMo 2012 - Day 4

2012-11-04T00:00:00+00:00

My word count is up to 7695 words. This is very pleasing as it is ahead of the target.

Today I shall describe my approach to structuring novels to make them easier to write during NaNoWriMo.

The first year that I did NaNoWriMo (2009) I chose to write 100 chapters of 500 words each. That way I could come up with a simple concept to cover for each chapter and not have to write too much about it. This worked very well but didn’t allow much elaboration on ideas during a chapter.

In 2010, I changed to an approach of writing a chapter per day (30 chapters in total). This was subdivided into three parts of 10 chapter each. This worked much better, in that it allowed me to be much more expansive in my writing but on the downside it led to a lot of waffling in places that didn’t warrant a chapter of that length.

I tried a more fluid approach in 2011, where I wrote until I had finished a chapter. I ended up with a total 20 chapters; plus a prologue and epilogue. This didn’t really deal with the random waffling problem but that is probably a side effect for forcing myself to invent 50,000 words in one month.

This year, I’ve gone back to the 30 chapters of around 1667 words each, splitting each into a random number of scenes, as required. So far, the approach seems to be working but I’d have preferred to work out what the 30 chapters were going to be in advance, so I would be sure that the story would reach the end at the right time and cover all the content.

I find this sort of structural approach to NaNoWriMo to help me get through it more easily. It probably doesn’t help towards getting particularly good content though but that’s another problem.

I shall defer the discussion of this year’s novel’s content until next time, due to wanting to keep the length of these posts fairly short (so as not to bore anyone; particularly myself when proof-reading).

NaNoWriMo 2012 - Day 3

2012-11-03T00:00:00+00:00

I’ve finally got time to actually write a blog post. We’re already just over two days in and I’m on target so far. I’ve written 4381 words at the time of writing this but I’m told there is a widget I can include on this site that will show live word counts. I shall investigate this later.

As this is the first proper NaNo post, and I am a nerd, I shall start by detailing the writing tools.

The majority of the writing will be done using Scrivener 2 for Mac. I bought this earlier in the year thanks to a 50% discount received for winning NaNoWriMo last year. My usage of the tool is fairly basic at this first-draft stage. I create a folder for each chapter (currently exotically title ‘Chapter 1’, ‘Chapter 2’, etc.) and I create a text file for each scene within each chapter. Scrivener has a nice feature of letting you see all the scenes in a chapter in one screen that you can scroll up and down, with nice scene break markers between each.

In addition to Scrivener, I am saving the scrivener file to my Dropbox folder, so that it is automatically synced to the Internet (and hence to anything else I open it with) every time I save the file. This way, if my laptop were to accidentally be run over by a tank or flushed down the toilet, I won’t lose the work so far.

The final, and probably somewhat less standard, tool that I’m using is git via the github user interface. This means that if I manage to badly corrupt the file in someway, or delete large parts unintentionally, I can just roll back to an earlier version of the novel without losing much.

I shall sign off for now. Next time I shall recount my approach to structuring novels to be written during NaNoWriMo, and maybe include some details of the story that I’m writing.

Introduction To NaNoWriMo 2012

2012-10-31T00:00:00+00:00

This November I will be doing NaNoWriMo for the fourth time.

24 Hour Comics Day 2012 (Saturday October 20th 2012)

2012-10-20T00:00:00+00:00

Introduction - 09:59

Today I’m randomly doing 24 Hour Comics Day. The goal is to create a 24 page comic in 24 hours (or, in my case, before I fall asleep). I shall primarily be drawing the comic book in Sketchbook Pro on the iPad. Hopefully, updates will be posted here regularly throughout the day.

11:27

A rather slow start. I’ve decided to just start drawing and see where the comic book goes. Here is the first page.

12:48

Still behind schedule. No plot yet.

14:30

Delayed by the arrival of lunch. A second character has arrived that clearly needs rescuing by our hero Bob.

17:03

After several hours of aimless doodling, I’m going to call time. Lack of ideas and ability to draw and particularly lack of ability to colour have left me too far behind. I shall try to spend more time over the next year learning to draw and paint and see if I’m in a better position for next year’s event.

iOS Audio Playback - What Does 2x Mean?

2012-08-02T00:00:00+00:00

For quite some time it has bugged me that selecting 2x in the Music app on iOS doesn’t play back the selected audio in half the time. I have, therefore, taken the time to measure the playback time in my two most used apps: Apple Podcasts and Audible.

The experiment was simple: play 1 minute of audio at each of the different speed options and time them. The results were as follows (times are only approximate, as they were manually timed using my wristwatch).

Podcasts Hair (2x): 41s
Podcasts Tortoise (0.5x): 1m19s
Audible 1.5x: 48s
Audible 2x: 41s
Audible 3x: 31s

This doesn’t really shed any light on the naming of the speed options but at least I can now judge roughly how long it will take to play an audio file of a given length at each of the speeds.

World Snooker Championship 2010

2010-04-21T00:00:00+00:00

On Monday (19th April 2010) my wife and I visited Sheffield to watch the World Snooker Championship first round match between Mark King and Steve Davis at the Crucible Theatre.

This was the first time I had been to Sheffield and my first impression was that it had a very large number of litter bins in the town centre. Well done Sheffield.

The Crucible Theatre was a surprisingly small and intimate venue. The views that we had from seats 62F and 63F were excellent. After years of watching the snooker on the television, the table was unexpectedly hi-def. Even if we had been at the back of the theatre, the view of the game would have been excellent.

Steve Davis was making his 30th appearance at the World Snooker Championship and got a standing ovation when he entered the arena (our participation in which was covered nicely by the BBC).

The match was very entertaining, with a nice mix of big breaks and tactical play. The highlight of the first half was when Marcus Campbell (playing on the other table) blew his nose very loudly during one of Mark King’s shots. A similar situation occurred in the second half, when Steve Davis was distracted during a shot by a member of the audience stifling a sneeze very loudly.

The session ended with Mark King leading 5-4; though Steve Davis went on to book his place in the second round, to play John Higgins, with a 10-9 win.

Leaving the theatre we were met with a large queue for the parking meter, so we went down to one on a lower level of the car park where we found no one at all. It was very enjoyable to drive passed the long queue a minute later on our way home.

Bed was achieved before 1am, despite the late finish.

3D Movie Rant

2010-03-31T00:00:00+00:00

I’ve recently seen two of the new wave of 3D movies sweeping across the globe (Avatar and Alice in Wonderland). These movies have received great praise. However, I’d like to take some time out to step back and take an ‘objective’ look at the 3D element of these movies.

Firstly, Avatar. I, rather carelessly, went to see this film whilst wearing glasses. This is not, in general, a good idea (unless, of course, that is the only way you are able to see). The problem is that these 3D films require you to wear another pair of glasses. This second pair of glasses rests in an uncomfortable possible further down the nose and gives the constant feeling of being about to fall off (the glasses, not the nose). The film itself looked very nice; as long as the shots were wide shots of the open countryside. Any close up shots had the problem that most of the frame is out of focus, which is perfectly fine in 2D but the brain doesn’t seem to be able to cope with it in 3D and gives many people headaches when looking away from the focused areas. Having the whole frame in focus would be a great improvement to 3D films (though may be hard in practice). Another close up element that cause problems was rapid movement across the screen. The picture seemed unable to keep up with this and cause the image to be very blurred. More frames per second would probably help. The final issue was that, on several occasions, things poked unnaturally far out of the screen; making it appear has if the objects in question had dramatically increased in length.

Now on to Alice in Wonderland. This had the same problems as Avatar. However, an additional thing that I noticed was how, often, people didn’t seem to really be part of the scene. They floated on top of the scene with a shiny glow around them. This may be fine in Wonderland but I doubt it was supposed to happen in the ‘real’ world scenes. This may have been an artefact of the CGI processing used in the film.

The two films themselves weren’t bad but I suspect I would have enjoyed them much more in their 2D versions. I’m sure that many of these issues will be ironed out in the coming years. The frame rate is a particular issue that is long overdue being addressed (even for 2D films).

My 10 Favourite Free iPhone Apps

2010-03-04T00:00:00+00:00

Here are some of my favourite iPhone apps; in no particular order (well, in the order they are in on my phone).

Facebook - Access to the popular social networking site. Most of the important functionality is there now and it should only get better with time.
Echofon - The easiest to use of the twitter clients. Only a couple of issues: it occasionally can’t connect to twitter and it only supports one account. Most of the other free clients support multiple accounts but are nowhere near as nice to use.
Yahoo! Messenger - Has push messaging, which means you don’t have to be in the application to receive messages. It even works in standby mode. Obviously only useful if you only want to use Yahoo! Meebo and IM+ are superior if you want to connect to multiple things at the same time. Skype is also good.
Dropbox - An excellent way to store files on the iPhone that you want to be able to access from anywhere.
IMDb - A dedicated client for the IMDb. Much better suited to the iPhone than the website.
GoodReader - A very good PDF reader. Much better than the build-in PDF support.
TVGuide - UK Television listing. ‘Nuff said.
FStream - Internet radio player. Supports all of the BBC Radio streams. The streams can be found at bbcstreams.com
Stanza - An excellent eBook reader with access to many free books. One can also buy books from various stores within the app or upload them via wireless from the Mac.
Glaurung Chess - Probably the best free Chess app.

In addition, here are a couple of good mobile websites.

TVCatchup - A live broadcast of many of the Freeview channels.</li>
BBC iPlayer - Access to the BBC television shows.</li>

Proteus - Leicester Comedy Festival 2010

2010-02-23T00:00:00+00:00

Last Monday (15th February 2010) I, and my trusty sidekick, attended the opening night of the Proteus show at the Leicester Comedy Festival. The show consisted of a number of short plays of varying styles [full disclosure: one was written and directed by my wife].

The overall standard of both writing and acting was surprisingly high for an amateur student production. In addition to the quality of the plays, several other aspects of the evening made it entertaining.

Firstly, the venue, The Crumbing Cookie (an establishment that, I assume, sells a variety of biscuit-like comestibles during the day), was incredibly small. So small, in fact, that our vantage point on the front row was effectively on the stage, allowing physical contact with the actors during various particularly vigorous scenes.

The second entertainment was the artificial addition of several constraints on my sidekick’s and my style of laughing (one for each play). Laughing styles included: laughing at as low a pitch as possible, only laughing through the nose, and laughing inwardly. These added to the, already considerable, humour of the evening; and disturbed several other members of the audience too.

The plays themselves were generally quite surreal. The final lines of the wife’s play nearly gave the sidekick a hernia. I particularly enjoyed the musical plays and the play involving a tryout for St. Peter’s stand-in at the gates to heaven.

Overall, far better than spending the evening in front of the television (unless House is on).

Mark Withall

My First Video Series

Setting The DataContext On A Style Element In A WPF ItemsControl

Writing a 6502 Assembler

DDD North 2017 Review

Thinking Functionally in C#.

Teaching an old dog new tricks

Scaling Agile in your Organisation with the Spotify Model

Async in C# - The Good, the Bad and the Ugly

Interactive APIs with GraphQL

Creating C DLLs for use with C#

Creating a C DLL

Accessing the C DLL functions from C#

TDD As If You Meant It Reviewed (Part V)

The Starting Commits

RED a controller is created - 2014-08-13 14:07

GREEN - 2014-08-13 14:08

REFACTOR better test name - 2014-08-13 14:10

RED play_move - 2014-08-13 14:12

GREEN - 2014-08-13 14:12

RED test view is called - 2014-08-13 14:15

GREEN - 2014-08-13 14:17

RED added model to controller - 2014-08-13 14:21

GREEN - 2014-08-13 14:22

RED check illegal move does not update view - 2014-08-13 14:27

GREEN - 2014-08-13 14:28

REFACTOR use a test class - 2014-09-23 12:48

RED illegal move reports error - 2014-09-23 13:03

GREEN - 2014-09-23 13:03

Next Time

Accessing WPF ListBox SelectedItems using MVVM

The ViewModel

The View

The MVVM Framework

How We’d Like To Do It

One-way To Presenter

Two-way Binding

Update

Creating Self-Hosted Python Modules

Creating A Module

Using external version.txt

Hosting A Repository

Installing The Module

MVVM - Creating New Windows

DDD North 2016 Review

This is not the Async you are looking for

10 more things you need to do to succeed as a Tech Lead

Run Your Team Lean and Deliver More

Take Control - Control Code Complexity

TDD With Excel VBA

The Fibonacci Sequence Kata

Step-By-Step

Conclusions

The Single Responsibility Principle

Calculation

Communication

Construction

TDD As If You Meant It Reviewed (Part IV)

Communicating Classes

Rookie Mistakes

Rule Violations

Data vs Code

Next Time

Red. Green. Refactor.

TDD As If You Meant It Reviewed (Part III)

The Starting Commits

RED Test that a legal move is legal - 2015-02-19 13:25

GREEN - 2015-03-02 13:09

RED Test that an illegal move is not legal - 2015-03-02 13:20

GREEN - 2015-03-02 13:25

REFACTOR Extract is_legal function - 2015-03-02 13:28

RED Test a different legal move - 2015-03-03 12:40

GREEN - 2015-03-03 12:48

REFACTOR Improve design by moving code - 2015-03-03 12:50

REFACTOR Simplify expression - 2015-03-03 12:52

REFACTOR Explicitly state expected result of tests - 2015-03-03 12:53

RED Test the first illegal move on upper boundary - 2015-03-03 12:55

GREEN - 2015-03-03 12:58

REFACTOR Improve design by moving code - 2015-03-03 13:05

RED Test previously-played move is illegal - 2015-03-04 12:39

REFACTOR Extract `is_legal` function - 2015-03-02 13:28

`ISubscriber<TMessage>`