dave^2 = -1

Dodgy .NET memory measurements using counters

2008-07-25T10:56:00.006+10:00

There are a few profilers around that can measure CLR memory usage: Microsoft's free CLR Profiler 2.0, JetBrains' dotTrace, Redgate's ANTS Profiler etc. However these don't seem to help me much when I'm trying to get some data about specific allocations (say, plotting the size of a list with varying numbers of objects). This could just be my inexperience with the tools, but I think it is more to do with the complexities of memory management for managed code.

I've also been playing around with taking measurements by programatically accessing the relevant counters, like the Private Bytes counter in the Process category, in the effort to take a number of snapshots before and after some simple allocations and plug them into a spreadsheet.

  privateBytesCounter = new PerformanceCounter("Process", "Private Bytes", name, true);
  var currentMemoryInKB = privateBytesCounter.NextValue()/1024.0;

The name is the relevant instance that appears within perfmon. You need to watch out for invalid characters, but with some care you can derive this value from AppDomain.CurrentDomain.FriendlyName (you might need to strip off the ".exe" extension in addition to getting rid of any funny characters).

My aim was to work out the size of some specific objects, but I haven't had too much success with this approach as it's giving me some funny values. A couple of gotchas: You have to watch the timing of the calls getting counter data (don't sample too fast), and if you are measuring a single allocation you can also change the results by forcing a garbage collection prior to measuring (GC.Collect()).

I think it's time for me to invest in a good CLR book and get better acquainted with .NET's memory model. :)

Brackets, braces, parentheses, and other such creatures

2008-07-25T00:40:00.020+10:00

I've been fairly busy the last couple of weeks finishing up my current job and preparing for my new one (a really exciting role with a team practising Scrum, TDD etc.), so I haven't been able to dedicate much time to the three potentially bloggable projects I am working on at the moment. The other day I found Part 13 of a series of coding challenges posted to dev102.com, and thought I'd give it a go as a quick little exercise.

Note: potential spoiler ahead, in the event you were intending to work through this yourself. That's not to say my solution is even vaguely correct, but if you want to do it completely off your own bat then have a go before you have all my mistakes to help you :)

The problem

This aim of this challenge was to determine whether any given string has a legal bracket structure. Basically, make sure all the '(', '[', '{', and '<' have matching ')', ']', '}' and '>'. We also need to take nesting into account, so that "({)}" is incorrect, and "({}<{}>)" will pass.

Part of the challenge is also to "Provide the most efficient, elegant and simple solution". I'm not even going to attempt that, but I'll try and get something vaguely efficient and, much like this author, simple.

Some quick planning

Shahar Yair (who posted the challenge) notes "I think that this is a well known problem". I think (although without a good googling I can't be sure due to my limited cranial capacity) one of the common implementations is to use a stack, and push brackets on as you find them, and pop them off when you close them. If you have an empty stack at the end your string is ok. If a closing bracket doesn't match the bracket on the top of the stack then you have a problem. The beautiful image below (crafted in that great image editor, MS Word) shows the basic idea: pushing on open brackets and popping them off once they get closed.

In terms of efficiency, the worst case for this is when you have a valid string, as you will have had to checked every character at least once (to see if it is a bracket). Using a stack will let us make a single pass through the string.

With this basic plan in mind, let's start writing some tests. We're not doing real TDD here I guess, as we have an end implementation in mind, but I still feel more comfortable working with the protection of some tests. It will hopefully cut down the amount of silly mistakes I normally make :).

Starting small

Here are a few easy tests to start off with (I'm using XUnit.NET here. I'm kind of growing attached to the simplicity of it :)):

public class When_matching_brackets {
    BracketMatcher matcher = new BracketMatcher();
    [Fact]
    public void Empty_string_should_pass() {
        should_pass(String.Empty);
    }
    [Fact]
    public void Null_string_should_pass() {
        should_pass(null);
    }    
    private void should_pass(String input) {
        Assert.True(matcher.IsValid(input));
    }
    private void should_fail(String input) {
        Assert.False(matcher.IsValid(input));
    }    
}
public class BracketMatcher {
    public bool IsValid(string input) { return true; }
}

We can pass these by just returning true. Let's write a test that will make this fail:

[Fact]
public void Single_bracket() {
    should_fail("(");
}

We can cheat again to pass this:

public class BracketMatcher {
    public bool IsValid(string input) { 
        if (input == null) return true;
        return input.Length < 1;
    }
}

To drive the next bit of our algorithm we can add another failing test:

[Fact]
public void Matched_brackets() {
    should_pass("()");
}

We could dodgy this up again, but let's start writing something a bit more realistic -- but only a little.

public class BracketMatcher {
    public bool IsValid(string input) {
        if (input == null) return true;
        int openBrackets = 0;

        foreach (var c in input) {
            if (c == '(') { openBrackets++; }
            else if (c == ')') { openBrackets--; }                                
        }
        return openBrackets == 0;
    }
}

This passes, but it is obviously going to incorrectly return true for an input like ")(". We'll use this to write our next test. What we are doing here is slowly building up a number of cases that should have a specific result, and writing a minimal (and trivial) implementation to make the test cases pass. The actual time spent doing this is quite short. I doubt anyone would spend any more than a few minutes typing this out. What we gain is momentum, and a test suite for when the time comes to refactor. Maybe it's just me, but if I were going straight to an implementation, I'd generally make great progress for a while but stuff up a sign or an end case or similar, and then spend and inordinate amount of time manually tracing through the code to find where I had gone wrong. The slow-and-steady approach here means less initial speed, but no speed bumps later, and usually a faster* trip overall.

* Caution: unsubstantiated anecdote! YMMV

Skipping ahead to our first major refactoring

After plugging away for a little while I've got the following test cases:

public class When_matching_brackets {
    BracketMatcher matcher = new BracketMatcher();

    [Fact]
    public void Empty_string_should_pass() {
        should_pass(String.Empty);
    }

    [Fact]
    public void Null_string_should_pass() {
        should_pass(null);
    }

    [Fact]
    public void Single_bracket_should_fail() {
        should_fail("(");
    }

    [Fact]
    public void Single_bracket_within_string_should_fail() {
        should_fail("abc(");
    }

    [Fact]
    public void Matched_brackets_should_pass() {
        should_pass("()");
    }

    [Fact]
    public void Matched_brackets_within_string_should_pass() {
        should_pass("This is (a test).");
    }

    [Fact]
    public void Matched_brackets_with_single_brace_should_fail() {
        should_fail("This {is (a test).");
    }

    [Fact]
    public void Matched_brackets_and_braces_should_pass() {
        should_pass("This {is} a (test).");
    }

    [Fact]
    public void Correct_number_but_wrong_nesting_of_brackets_and_braces_should_fail() {
        should_fail("This {is a (test}).");
    }

    private void should_pass(String input) {
        Assert.True(matcher.IsValid(input));
    }

    private void should_fail(String input) {
        Assert.False(matcher.IsValid(input));
    }
}

The last test (emphasised) is failing with the following implementation (which passes all the other tests), because it fails to take bracket nesting into account:

public class BracketMatcher {             
    public bool IsValid(string input) {
        if (input == null) return true;
        
        var bracketCount = 0;
        var braceCount = 0;
        foreach (var c in input) {                
            if (c == '(') {
                bracketCount++;
            } else if (c == ')') {
                bracketCount--;
            } else if (c == '{') {
                braceCount++;
            } else if (c == '}') {
                braceCount--;
            }
        }
        return bracketCount == 0 && braceCount == 0;
    }
}

You can also see I have duplicated the counters for braces and brackets, and we'll only be adding to this problem when it comes time to add the other bracket types. Let's refactor to remove this, and get in the stack idea we talked about earlier.

public class BracketMatcher {                  
    public bool IsValid(string input) {            
        if (input == null) return true;

        var bracketStack = new Stack<char>();
        foreach (var c in input) {                
            if (c == '(') {
                bracketStack.Push(c);
            } else if (c == ')') {
                if (bracketStack.Pop() != '(') return false;
            } else if (c == '{') {
                bracketStack.Push(c);
            } else if (c == '}') {
                if (bracketStack.Pop() != '{') return false;
            }
        }
        return bracketStack.Count == 0;
    }
}

This passes all our tests, but it's still ugly. The pushes and pops obscure the algorithm we are using. Sure, you can pick it out by tracing through a few cases, but it would be nicer to get the gist of it by inspection alone. We also have some duplicated if (bracketStack.Pop() != '(') return false; style code happening, but now we are at least passing all our tests, we can continue to work toward removing the ugliness without breaking what we have.

public class BracketMatcher {
    private static Dictionary<char, char> bracketPairs
        = new Dictionary<char, char> { {'(', ')'}, {'{', '}'} };

    public bool IsValid(string input) {
        if (input == null) return true;

        var bracketStack = new Stack<char>();
        foreach (var c in input) {
            if (bracketPairs.ContainsKey(c)) {
                bracketStack.Push(c);
            } else if (bracketPairs.ContainsValue(c)) {
                char lastBracket = bracketStack.Pop();
                if (bracketPairs[lastBracket] != c) return false;
            }
        }
        return bracketStack.Count == 0;
    }
}

This version is a bit of an improvement: we have removed the duplication by adding a dictionary of bracket pairs. It still isn't exactly intention revealing though with those key/value checks and pushing and popping. I'll go out on a limb here though, and suggest that it's much better than the implementation we opened this section with.

Finishing up

A few more tests, and a refactoring later, and here's what I ended up with:

public class BracketMatcher {
    private static readonly Dictionary<char, char> bracketPairs
        = new Dictionary<char, char> { {'(', ')'}, {'{', '}'}, {'[', ']'}, {'<', '>'} };

    private Stack<char> bracketStack;

    public bool IsValid(string input) {        
        if (input == null) return true;
        clearOpenedBrackets();
        foreach (var c in input) {
            if (isOpenBracket(c)) {
                recordBracketOpening(c);
            } else if (isCloseBracket(c)) {
                if (!canCloseLastOpenBracket(c)) return false;
                closeLastOpenedBracket();                    
            }
        }
        return areAllBracketsClosed();
    }

    private void clearOpenedBrackets() {
      bracketStack = new Stack<char>();
    }

    private bool areAllBracketsClosed() {
      return bracketStack.Count == 0;
    }

    private void closeLastOpenedBracket() {
        bracketStack.Pop();
    }

    private bool canCloseLastOpenBracket(char bracket) {
        if (areAllBracketsClosed()) return false;
        char lastOpenBracket = bracketStack.Peek();
        char closingBracket = bracketPairs[lastOpenBracket];
        return bracket == closingBracket;
    }

    private void recordBracketOpening(char bracket) {
        bracketStack.Push(bracket);
    }

    private bool isOpenBracket(char c) {
        return bracketPairs.ContainsKey(c);
    }

    private bool isCloseBracket(char c) {
        return bracketPairs.ContainsValue(c);
    }
}

I think IsValid(...) is actually reading pretty well here. The intent of the operation is fairly clear from a quick read through, with no implementation details like pops and pushes scattered around the code. The implementation itself is pushed to fairly simple helper methods.

The canCloseLastOpenBracket(...) method is a bit ugly, but it is only four lines, has descriptive variable names, and is tucked away in a private method. It's also a bit inefficient, as we are doing an unecessary Peek() before Pop()ing the value off the stack. I rewrote the code several ways, but any approach that combined the Pop() with matching the brackets tended to obscure what the code was doing. I've had a minor method-count explosion, but they are all small and self-explanatory (less lines that commenting the previous version in any event ;)).

We might be able to simplify this in a number of ways, like putting the required closing brackets on the stack to make the matching more straightforward, but the other approaches I tried all seemed to compromise readability to some extent, so I ended up sticking with the verbosity of this version. I'm sure you can do better (leave a comment!), but for now it's passing the tests thrown at it and I can live with how it reads. Which means we're as good as done. :)

Speaking of done, here's the test suite it passes:

public class When_matching_brackets {
    BracketMatcher matcher = new BracketMatcher();

    [Fact]
    public void Empty_string() {
        should_pass(String.Empty);
    }

    [Fact]
    public void Null_string() {
        should_pass(null);
    }

    [Fact]
    public void Single_bracket() {
        should_fail("(");
    }

    [Fact]
    public void Single_closing_bracket() {
        should_fail(")");
    }

    [Fact]
    public void Single_bracket_within_string() {
        should_fail("abc(");
    }

    [Fact]
    public void Matched_brackets() {
        should_pass("()");
    }

    [Fact]
    public void Matched_brackets_within_string() {
        should_pass("This is (a test).");
    }

    [Fact]
    public void Missing_a_brace() {
        should_fail("This {is (a test).");
    }

    [Fact]
    public void Pairs_of_matched_brackets_and_braces() {
        should_pass("This {is} a (test).");
    }

    [Fact]
    public void Incorrect_nesting_of_brackets_and_braces() {
        should_fail("This {is a (test}).");
    }

    [Fact]
    public void Valid_nesting_with_multiple_types() {
        should_pass("<Hello (World), ({how} are) you today>?");
    }

    [Fact]
    public void Multiple_pairs() {
        should_pass("(Hello) {World}, <how> are (you) today?");
    }

    [Fact]
    public void Multiple_lines_with_valid_brackets() {
        should_pass(@"(Hello {World,
                        How are you}
                        ?)");
    }

    [Fact]
    public void Multiple_lines_with_invalid_brackets() {
        should_fail(@"(Hello {World,
                        How are you)
                        ?)");
    }

    [Fact]
    public void Valid_example_from_problem_statement() {
        should_pass("([](<{}>))");
    }

    [Fact]
    public void Invalid_example_from_problem_statement() {
        should_fail("({<)>}");
    }

    [Fact]
    public void Matching_square_brackets() {
        should_pass("[asdf]");
    }

    [Fact]
    public void Single_square_bracket() {
        should_fail("[");
    }

    [Fact]
    public void Single_angle_bracket() {
        should_fail("<");
    }
    [Fact]
    public void Matching_angle_brackets() {
        should_pass("<>");  
    }

    private void should_pass(String input) {
        Assert.True(matcher.IsValid(input));
    }

    private void should_fail(String input) {
        Assert.False(matcher.IsValid(input));
    }
}

Was a bit of fun for a half hour or so :) Please feel free to leave a comment if you have any suggested improvements (or better yet, some failing tests!).

Getting results from Oracle procedures for TSQL people

2008-07-18T09:34:00.004+10:00

I haven't used Oracle since Uni, and the small amount of PL/SQL I've had to do over the last year hasn't been enough to get me passed the awkward SQL Server developer-trapped-in-a-PL/SQL world phase yet. (Although I am enjoying it much more now I've got a real IDE in Toad, compared with the ancient, clunky piece of rubbish I was using before.)

In SQL Server, anything you SELECT inside a procedure will be returned to the caller, which makes it really easy to call an SP in Query Analyzer or similar and see what's happening. Oracle is, well, different. You need to explicitly return cursors over results, and unless you call it the right way all you'll get is a handy "PL/SQL procedure successfully completed" message.

Here's a quick example of how TSQL people can get results out of Oracle with a minimum of fuss. First, say we have a simple procedure that takes a postcode (aka ZIP code) and returns matching results:

CREATE OR REPLACE PROCEDURE GetSamplesByPostcode 
(
    pi_postCode IN NUMBER,
    samples OUT SYS_REFCURSOR
) 
IS
BEGIN
    OPEN samples FOR
    SELECT *
    FROM SAMPLE s
    WHERE s.PostCode = pi_postCode;
END GetSamplesByPostcode;

We can then call this within SQL*Plus or Toad, by turning on autoprint, and by using a bind variable to get the results out:

SET AUTOPRINT ON
VAR sample_cur REFCURSOR;
BEGIN
    GetSamplesByPostcode(2000, :sample_cur);
END;

This will print the relevant results returned by the bound sample_cur variable, and give Toad users a nice grid view of the results too.

Check the Oracle docs for more on bind variables.

If you want to get at the data using .NET, check out the Oracle .NET Data Provider documentation, or MSDN for an overview on using the Microsoft .NET Oracle Provider.

Full disclosure: Bought off with a ReSharper licence

2008-07-04T11:00:00.000+10:00

In the interest of full disclosure, I recently got sent a free ReSharper 4.0 Personal Licence from JetBrains. I really don't know why. The explanation in the email I received was very generic: "for donating so much of your time... whether in the form of plugin development, quality verifying, promoting or educating about ReSharper".

I emailed them back and asked why I got included in the list for a free licence, but haven't received a response. All I've done for ReSharper/JetBrains is left them a comment or two, downloaded the R# 4.0 nightlies and maybe even tried to submit one of those automated bug submission thingoes (which I think failed due to the proxy at my work). I have blogged a couple of times on ReSharper, although never anything high-traffic. So I'm at a loss to explain why.

I haven't used the licence yet (was hoping to find out why I got it first), but I guess you can probably disregard anything positive I've ever said about R# now I'm owned by them after being sent free swag. In fact, just assume from now on that I have absolutely no integrity whatsoever. Luckily astute readers are already way ahead of me on that... :)

And no, I can't give it to you instead because the licence is non-transferable :P

Write out the fields of a JavaScript object

2008-07-02T14:04:00.006+10:00

I've found myself writing this bit of code a few times now, so thought I'd dump it here for future copy-and-paste.

function writeObj(obj, message) {
  if (!message) { message = obj; }
  var details = "*****************" + "\n" + message + "\n";
  var fieldContents;
  for (var field in obj) {
    fieldContents = obj[field];
    if (typeof(fieldContents) == "function") {
      fieldContents = "(function)";
    }
    details += "  " + field + ": " + fieldContents + "\n";
  }
  console.log(details);
}

This just dumps all the object's fields into the debugging console provided by the Firebug extension for Firefox (the console.log(...) call). If you don't have Firebug, you can easily create a custom console object to provide an alternative log method. For example, put this snippet at the top of the script to use window.alert(...) when console is undefined:

if (!console) {
  var console = {log: function(details) { window.alert(details); }}
}

There are probably better ways of doing this, but I find this handy so I can quickly mash writeObj(myObject) into the console and get a list of all the object's fields. For more fun with simple JavaScript reflection have a look at my earlier post on the subject.

@ prefix for C# names

2008-06-23T11:03:00.001+10:00

Who'd have thought I'd learn something over Twitter (during an uncharacteristic period of uptime)? Nothing overly useful mind you, just an interesting bit of trivia. :)

Besides "yuck", what would you think when you saw the following C# code?

class @class {
  public string @someValue;
  public int @int;
}

[Test]
public void TestAtClass() {
  @class myclass = new @class();
  myclass.@int = 10;
  myclass.@someValue = "test";
}

Prior to today I'd have thought that it wouldn't compile, but after seeing a tweet from Brad Wilson that mentioned you could use @ to prefix variable names I thought I'd give it a try, and sure enough the C# compiler is happy. Brad's tweet was about using @ to prefix reserved words so you can get names like @class.

Bit evil perhaps, but all those @'s might make some Rubyists feel a bit more at home in C# ;-)

Yet another way of raising events from mocks

2008-06-21T23:16:00.008+10:00

Update 2008-06-26: This is now in the Rhino Mocks trunk, so it should be available as part of the 3.5 release.

I've been playing around with raising events from mocks for the last couple of nights, and think I've finally come up with an approach that works for me. Finding a nice way of raising these events is particularly tricky for mock object frameworks, as the C# compiler is really picky about how you can use event references. For example, let's look at a very useful interface:

public interface IDoSomething {    
    event EventHandler SomethingDone;
}

Outside of a class that implements IDoSomething, the only time we can reference SomethingDone is when we are adding or removing listeners (x.SomethingDone += someEventHandler; or x.SomethingDone -= someEventHandler;). (C#'s lack of real support for System.Void is partly to blame here, as both these operations are void.)

To raise an event on a mock object, it would be lovely to be able to code something like this:

var mock = mocks.DynamicMock();
mock.Raise(mock.SomethingDone, mock, EventArgs.Empty);

Unfortunately due to the aforementioned constraint, the emphasised part of the code will give a compiler error stating "The event 'IDoSomething.SomethingDone' can only appear on the left hand side of += or -=".

There are a few workarounds for this. Let's start with the standard Rhino Mocks approach. (I'm using Rhino Mocks 3.5 beta and xUnit.net here -- feel free to translate from [Fact] to [Test] if you use NUnit, MBUnit et al.)

[Fact]
public void Raise_event_old_style() {
    var mock = mocks.DynamicMock<IDoSomething>();
    mock.SomethingDone += null;
    IEventRaiser eventRaiser = LastCall.IgnoreArguments().GetEventRaiser();
    mocks.ReplayAll();

    var wasCalled = false;
    mock.SomethingDone += (sender, e) => wasCalled = true;
    eventRaiser.Raise(mock, EventArgs.Empty);

    mocks.VerifyAll();  
    Assert.True(wasCalled);
}

Rhino Mocks records the expectation that an event handler is added, then uses LastCall to ignore the argument and gets an IEventRaiser for the last event referenced. That IEventRaiser can be used later on to raise our event. Phil Haack has a helpful post which explains a bit more about this approach.

When I first saw this I must admit it seemed like a lot of noise that obscured what I was really trying to do. This got worse when I started playing around with the new Arrange - Act - Assert syntax and I didn't want to go through the whole replay / verify cycle. So I started looking at the Rhino Mocks implementation of IEventRaiser, the EventRaiser class. This class lets us do this:

[Fact]
public void Raise_event_using_string_for_event_name() {
    var mock = mocks.DynamicMock<IDoSomething>();
    var wasCalled = false;
    mock.SomethingDone += (sender, e) => wasCalled = true;

    var eventRaiser = EventRaiser.Create(mock, "SomethingDone");
    eventRaiser.Raise(mock, EventArgs.Empty);
    
    Assert.True(wasCalled);
}

Here we can specify the relevant event using a string. This works nicely and is easy to read, but causes problems when refactoring and means we don't get intellisense or compiler assistance. Ayende has written about this approach, comparing it with the LastCall.GetEventRaiser() approach we used last time.

I wasn't overjoyed about either of these, and while searching around for other options I found another of Ayende's posts (I think his blog is about 30% of the web... great stuff :)), asking for feedback on a more natural syntax for raising events from mocks. This looked a bit like this:

mock.MyEvent += EventRaiser.Raise(this, EventArgs.Empty);

I quite liked this, but there were a few complaints in the comments about subscribing to and raising the event at the same time. The post was from about 12 months prior to me writing this and, as I'm using a recent Rhino Mocks build and couldn't find it, it looks like nothing came of this. Let's look for a compromise that also fits in nicely with our Arrange - Act - Assert approach. First we'll see what we can get working based on the first, LastCall.GetEventRaiser() approach used:

[Fact]
public void Raise_event_with_new_arrange_act_assert_syntax() {
    //Arrange
    var mock = MockRepository.GenerateMock<IDoSomething>();
    var wasCalled = false;
    mock.SomethingDone += (sender, e) => wasCalled = true;
    
    var eventRaiser = 
        mock
        .Stub(x => x.SomethingDone += null)
        .IgnoreArguments()
        .GetEventRaiser();
    
    //Act
    eventRaiser.Raise(mock, EventArgs.Empty);

    //Assert
    Assert.True(wasCalled);
}

Here we are specifying a fairly useless stub so we can get an IEventRaiser. We are still using ye olde x.SomethingDone += null trick (albeit with a lambda to neaten it up), but we are pretty much stuck with that if we want strong typing on this as discussed at the beginning of this post.

I think this looks a bit more cohesive now we are using the lambda. We have one statement that is fairly obviously getting an IEventRaiser, rather than a null event handler floating around on its own confusing poor people like me :). Beyond aesthetics, this cohesion can let us pull out this functionality and start getting closer to a neater syntax. For now we'll just whack this in a .NET 3.5 extension method, but we could probably find a better home for it (it can go in a standalone class but the final syntax doesn't read quite as well to me).

public static class EventRaiserExtensions {
    private static IEventRaiser GetEventRaiserFromSubscription<TEventSource>(
        this TEventSource mock, Action<TEventSource> eventSubscription) {
        return mock
            .Stub(eventSubscription)
            .IgnoreArguments()
            .GetEventRaiser();
    }
    
    public static void Raise<TEventSource>(this TEventSource mock, Action<TEventSource> eventSubscription, object sender, EventArgs args) {
        var eventRaiser = GetEventRaiserFromSubscription(mock, eventSubscription);
        eventRaiser.Raise(sender, args);
    }

    public static void Raise<TEventSource>(this TEventSource mock, Action<TEventSource> eventSubscription, params object[] args) {
        var eventRaiser = GetEventRaiserFromSubscription(mock, eventSubscription);
        eventRaiser.Raise(args);
    }        

    public static void Raise<TEventSource>(this TEventSource mock, Action<TEventSource> eventSubscription) {
        var eventRaiser = GetEventRaiserFromSubscription(mock, eventSubscription);
        eventRaiser.Raise(mock, EventArgs.Empty);
    }    
}

The emphasised bit of code is the stub call we did last time, but this time pulled out into one method. The main bits are the Raise<TEventSource> extension methods, which combine all the steps and give us an easy syntax for calling an event on a mock based on an event subscription delegate. So our example now looks like this:

[Fact]
public void Suggestion_for_raising_events() {
    var mock = MockRepository.GenerateMock<IDoSomething>();
    var wasCalled = false;
    mock.SomethingDone += (sender, e) => wasCalled = true;

    mock.Raise(x => x.SomethingDone += null, mock, EventArgs.Empty);

    Assert.True(wasCalled);
}

The implementation itself might need work, but I reckon that syntax is pretty neat considering the limitations of C#. Of course, you're welcome to think otherwise, so please leave a comment expressing your outrage and/or contempt :).

Disclaimer: I am fairly new to Rhino Mocks (have tended to stick to manual test doubles) and especially to Arrange - Act - Assert (it's only in beta at present), so this might fail pretty hard in other circumstances. Still, I thought I'd post the syntax in case it gave more knowledgable people some good ideas :)

Subversion 1.5.0 released

2008-06-20T09:20:00.002+10:00

Just saw that Subversion 1.5.0 has been released. There are quite a few new features, but the main ones of interest to me are:

basic merge tracking (to be improved in 1.5.1)
changelist support for working with common file groupings
sparse checkouts for working with large repos (say, one that includes multimedia assets)
improvements to svn:externals
The usual performance improvements

See the svn 1.5 release notes for a run down of the main changes, or the CHANGES file for a complete list.

Oh yeah, and the usual, major version, working copy and repository format provisos apply... while the API is backwards compatible and svn 1.5 server and tools work with older repo versions, working copies are a different story. Older client tools will not work with svn 1.5 working copies, nor with 1.5 repositories. Your existing working copies will automatically upgrade to the 1.5 format when you access them with the new tools. Read this for more information.

You'll also need to upgrade your repository format to 1.5 to take full advantage of the new features like merge tracking (although you'll get a number of the improvements with older repo formats as well).

Certified binaries will be coming out over the next couple of days at CollabNet (other binary maintainers listed here). The TortoiseSVN crew is pretty much ready to go too.

DI and cross-cutting concerns

2008-06-19T10:39:00.003+10:00

Just came across some great guidance from Casey Charlton on the ALT.NET mailing list. My last post on dependency injection mentioned the benefit of documenting class dependencies via the constructor used for DI. But what about cross cutting concerns like logging? From Casey's mailing list post:

"Constructor properties shouldnt be used for cross cutting concerns like logging ... Put ILogger as a public property on the class, use the nulllogger as the default value, register the logging facility in Windsor, and all will magically happen"

I like this -- unique dependencies in your constructor, others set via property-injection. I'm also pretty keen on the idea of AOP for doing a lot of basic logging, but I haven't had a good look at this in .NET yet. The ALT.NET thread has a bit more of a discussion on logging.

Attempting to understand Dependency Injection

2008-06-12T23:40:00.016+10:00

Watching Rob Conery and Jeremy Miller work through Dependency Injection for the MVC Storefront project really helped me to piece together a few ideas that had been rattling around in my generally deserted cranium. Dependency injection (DI) is sometimes dismissed as "just" a tool for unit testing and mocking dependencies. But I think DI, and DI containers, offer a bit more to software design than simply providing a way to use mocks for interaction testing. So as usual I'm polluting the blogosphere with my ramblings in an effort to solidify my understanding. Let's work through an example and see what we can find.

Here is how we could write a class to send invoice reminder emails without any thought given to design or testability:

public class InvoiceReminderService {
  public void SendReminders() {
    var emailService = new EmailService();
    var invoiceRepository = new InvoiceRepository();  
    var invoicesDueForReminderEmail = invoiceRepository.GetInvoicesDueForReminders();
    foreach (var invoice in invoicesDueForReminderEmail) {
      var reminderMessage = createReminder(invoice);
      emailService.Send(reminderMessage);
    }
  }
  //...
}

Here we have dependencies on InvoiceRepository, for getting invoices due for reminder emails, and EmailService, for sending out the emails over SMTP. These dependencies could be instantiated at many different places all over our code base. Without worrying about design principles or testability, let's simply pull out these dependencies and rely on constructor injection to instantiate them.

public class InvoiceReminderService {
  private EmailService emailService;
  private InvoiceRepository invoiceRepository;

  public InvoiceReminderService(InvoiceRepository invoiceRepository, EmailService emailService) {
    this.invoiceRepository = invoiceRepository;
    this.emailService = emailService;
  }

  public void SendReminders() {
    var invoicesDueForReminderEmail = invoiceRepository.GetInvoicesDueForReminders();
    foreach (var invoice in invoicesDueForReminderEmail) {
      var reminderMessage = createReminder(invoice);
      emailService.Send(reminderMessage);
    }
  }
  //...
}

Here we've just created a constructor that takes the required dependencies and adds them to private fields. SendReminders() has been updated so that it is no longer responsible for instantiating the dependencies. I can then instantiate an InvoiceReminderService by creating the dependencies and passing them to the constructor, or I can use a DI container (I'm using a pre-release build of StructureMap 2.5 for this post) to automatically create my dependencies for me:

var invoiceReminderService = ObjectFactory.GetInstance<InvoiceReminderService>();

By default our DI container looks at the greediest constructor (the one with the most parameters) to see what dependencies it needs to create. Because InvoiceRepository and EmailService are both concrete classes (i.e. not interfaces or abstract), we don't need to give StructureMap any additional information, it can simply instantiate the required objects and pass them through to the InvoiceReminderService constructor.

So what has this accomplished? Well, SendReminders() is now a lot clearer without the dependencies in the way. And we also have an easy way to tell exactly what the dependencies of the class are (the constructor). We are also skirting dangerously close to having a testable class that could easily be modified to follow the Dependency Inversion Principle (DIP) (by extracting interfaces from our dependencies and relying on those instead of on concrete classes) and the Open/Closed Principle (OCP) (by allowing us to change the behaviour of our class by providing different implementations for the dependencies).

But the main, obvious thing this has accomplished is that our class is no longer responsible for instantiating its dependencies. I guess you could almost link this back to the Single Responsibility Principle (SRP) -- we are limiting this class' responsibilities and given it one less reason to change. Why is this good? Well, let's imagine our EmailService class is used by a number of classes throughout our application. We want to change our EmailService so that it no longer sends emails directly via SMTP. Now it simply queues up the email in a database, and another process is responsible for firing off emails from the queue. To create an EmailService without a DI container I now need to do this to every class that builds an EmailService:

emailService = new EmailService(new EmailRepository());

Or we can just let my DI container handle it for me, and keep our original ObjectFactory call unchanged. This reduces the friction experienced whenever we need to factor out a new class to provide new functionality or to avoid an SRP violation.

//No change need here, even though the EmailService constructor has changed...
var invoiceReminderService = ObjectFactory.GetInstance<InvoiceReminderService>();

(Yes, this is slightly circular logic as I am assuming we using DI for the new EmailRepository class too, but the logic is equally valid if we want to change the constructor to include a connection string or some other parameter. The point is that we can vary the instantiation without affect dependent classes.)

Now I'm not suggesting for a moment that you want to globally replace new with a DI container, but for me the realisation that DI containers were all about abstracting the responsibility of dependency creation, rather than simply providing a testing seam, was a bit of an A-HA! moment. Of course, I am a bit slower than your average developer, so sometimes the things like this take me a while :-)

From abstracting dependency creation to SOLID designs

Now there are still a number of SOLID design principles the code above is violating. This doesn't mean we need to instantly refactor to be compliant (you're never going to be, they are general guidelines that can be somewhat contradictory when taken to the n'th degree), but it is something we can look at.

First up is the DIP. We are depending on concrete types rather than abstractions. This also limits our options of altering the behaviour of the class via its dependencies to subclassing those dependencies, which is a minor strike against the OCP. This is easily fixed by extracting interfaces from the dependencies:

public class InvoiceReminderService {
  private IEmailService emailService;
  private IInvoiceRepository invoiceRepository;

  public InvoiceReminderService(IInvoiceRepository invoiceRepository, IEmailService emailService) {
    this.invoiceRepository = invoiceRepository;
    this.emailService = emailService;
  }
  //...
}

StructureMap will auto-wireup these dependencies, but if we are using our EmailService implementation that depends on an extracted IEmailRepository interface, then we'll need to tell StructureMap's configuration about it, either at compile time in code or using a configuration file:

public static class Bootstrapper {
  public static void ConfigureIoC() {            
    StructureMapConfiguration.AddRegistry(new DiSampleRegistry());
  }  
}
public class DiSampleRegistry : Registry {
  protected override void configure() {
    ForRequestedType<IEmailRepository>()
      .TheDefaultIsConcreteType<EmailRepository>();                
  }
}

We are now looking at a more traditional DI design. Our InvoiceReminderService is now completely independent of the specific implementations of its dependencies. All the code in the class is cohesive -- working at one responsibility with minimal background noise. This project doesn't even need a reference to the DLL containing the dependency implementations. This means we are fine changing implementations (although not interface contracts!) and we know our InvoiceReminderService is safe. If you were given this class to reuse, or simply to maintain, you wouldn't have to go pulling in a whole bunch of concrete dependencies. As a result and as a nice bonus, we have some good seams for running automated tests. We can easily stub or mock these dependencies and isolate the behaviour under test.

Aside: DI containers are an obvious way to get plugin and provider-style implementations, by loading specific implementations of an interface at runtime. I'm focusing on more general design effects here -- if you're looking for a plugin/component/provider model you'll obviously be designing more explicitly for loose coupling and will choose your approach based on that.

Not all beer and Skittles?

That's the DI theory, as far as I can tell. But as always there is no silver bullet. It is now tougher for us to navigate from the InvoiceReminderService to the current implementations of its dependencies (as we've abstracted them away). We are also looking at a potential interface explosion. Why extract an interface for virtually every class you write? That's two units of code for every responsibility. And we now have a DI container to learn and troubleshoot when debugging. If we're happy with tight coupling between this class and its dependencies, then why go to these lengths? If you want to run unit tests why not just use TypeMock to break into tightly coupled dependencies? Or at the very least provide default implementations in the class' default constructor (a.k.a. the poor man's dependency injection, see Nikola's post for an interesting variation on this approach):

public class InvoiceReminderService {
  private IEmailService emailService;
  private IInvoiceRepository invoiceRepository;

  public InvoiceReminderService() {
    this.invoiceRepository = new InvoiceRepository();
    this.emailService = new EmailService();
  }

  public InvoiceReminderService(IInvoiceRepository invoiceRepository, IEmailService emailService) {
    this.invoiceRepository = invoiceRepository;
    this.emailService = emailService;
  }  
  //...
}

And how much of all this is just working around limitations of statically typed languages? To me these are all quite reasonable questions (some of these raised by Kevin Berridge in some nice posts here and here, as well as a couple of posts from Jacob Proffitt starting here).

As always the key seems to lie in achieving a balance. The benefits of a loosely coupled design always need to be traded off with any additional complexity of that design. After watching the MVC Storefont DI screencast and having a play around with StructureMap I can see a lot of very obvious benefits to DI containers, but at the same time it's not something to dive into without having an vague idea of the theory and problems it aims to solve (which is why I've spent so much time reading about DI containers, but generally sticking to poor man's DI until I had a pressing reason to move to a container). After all, we don't go around blindly applying the GOF patterns to every situation under the sun... right? :-)

Some interesting DI reads

As opposed to this post, here are a few interesting takes on DI.

Frederik's Case for Dependency Injection, which looks at DI as evolved from interface-based design.
Nikola Malovic on transparent dependencies and DI frameworks.
Kevin Berridge on the DI-slippery slope: here and here
Jacob Proffitt's war on dependency injection
Nate Kohari's response to Jacob
Ayende's views DI in response to Jacob and Nate: here and here.
Jeremy Miller on the Dependency Injection Pattern, and the pros and cons of DI.

Nothin' but .NET heading down under

2008-05-28T13:35:00.003+10:00

I left a comment on JP Boodhoo's blog recently, and asked if there was any chance of him running a Nothin' But .NET course in Sydney, Australia. I got an email response from him a short time later:

"As far as the course in Australia!! I will be there next year [2009] to give a course in Sydney!!"

I've been really keen to attend this course for ages now, but the commute to Canada each day was pushing it a bit :). In case you don't know what the course is all about, here's a review (and links to other reviews) from Kyle Bailey's old blog. To quote a bit of the blurb from a recently scheduled course:

Nothin’ But .Net is a five day boot camp that will focus on pragmatically applying .Net within the context of developing a working N-Tiered application. Registrants will learn about advanced features of .Net (2.0/3.0/3.5) as they are applied to the task of building a complete application from the UI layer all the way down to the mapping layer.

Core Concepts Overview

Expanding the capabilities of developing with VS.Net - Enter ReSharper (a productivity add-in for Visual Studio .Net)

There’s more to life than generated code

Automation for the developer

Generics ( they’re not just for collections )

Back to basics - Rules Of Good Object Oriented Design

Dependency Injection

Object Relational Mapping in .Net

Applying the dependency inversion principle

Domain Driven Design

Passive View/Supervising Controller,MVC

Creating layered architectures

Driving out functionality and design through testing

Taking Control Of Databinding

Behavior (Test) Driven Development

Core design patterns applied

Pragmatic Productivity Tools For Developers

It sounds awesome. Hope to see a few like-minded Aussie developers there! In the mean time, if anyone knows of any current course in Sydney that covers any of this stuff please leave a comment or email me, as I'd try and attend that too during the looonnnggg wait 'til JP visits in 2009.

This free advertisement was brought to you courtesy of an excited coder. :-)

BDD test naming with AutoHotKey

2008-05-28T09:14:00.014+10:00

Update 2008-05-29: JP has posted a much better version of this script (with suggestions from a few of his readers). I've updated the script on this post to work more like JP's version, but you're probably best off grabbing it from his post, or searching his site for his latest version.

Was having a chat earlier with my good mate JP Boodhoo... er, well, more accurately, I left a comment on his blog and he was nice enough to email me back. Anyway, JP has started trying AutoHotKey rather than his previous macro for BDD-style test naming.

I thought I'd post an extremely over-engineering version of this AutoHotKey script, which has a toggle-approach similar to the Emacs Everywhere script I posted earlier.

Once you have AHK installed, you can just extract the ZIP below and double click the .AHK file to load the script. The script will let you toggle "test-naming mode" (i.e. replacing spaces with underscores) using Ctrl + Shift + U. You can cancel out of test naming mode by pressing ENTER, ESCAPE or starting the method signature by typing a '('. Pressing Ctrl + Alt + U will insert a new test template before switching on test naming mode (although you might be better off using R# templates for this). All this is simply to make it easier to type out tests like this:

[Test]
public void Test_naming_mode_turns_spaces_to_underscores() {}

Version 2 of the script can be downloaded here:

TestNamingMode-v2.zip

Feel free to change the hotkeys and the dodgy icons :). I haven't had a good test of it yet so use at your own risk.

If you're happy with how it works you can add it to your Startup programs and have BDD-style test naming goodness whenever you like. Hope_this_helps! :-)

Change log

2008-05-29: Uploaded v2, synching with JP's version 2, adding test templates, and made test mode exit after typing '(' for test method signature
2008-05-28: Updated hotkeys to match JP's version
2008-05-28: Original post

Top-down vs. bottom-up design

2008-05-27T12:39:00.002+10:00

I've been having a think about top-down (a.k.a. outside-in) design during my recent iterative development exercise. In the series I've been putting off testing from the client layer down, primarily because GUIs have a reputation for being hard to test and harder to test-drive, and I wanted to make some early, easy progress on the core logic of the game.

I started to think that this approach might be a mistake. I'm dealing with the model that I think we'll need, not one demanded from the primary client of the model -- the GUI. Chad and Ben mentioned in their recent screencast that bottom-up implementation tended to lead to mistaken assumptions about infrastructure required by the top layers. I saw a similar point made on the BDD mailing list by Pat Maddox. Pat wrote (emphasis mine):

"I find an outside-in style of development to be very helpful... It forces you to think of your objects at a high level, so your design is driven by real need, and then you apply your design skills as you go on. When I use a pure bottom-up style, I write more speculative code and go down the wrong path far more often than I'd like. That's not to say that it's a problem inherent with that style, but rather a problem that I've personally experienced, and have more or less solved by using an outside-in approach."

This is opinion is echoed in an unrelated post to the TDD mailing list by Olof Bjarnason:

"I've been using TDD [bottom-up] for 2 years now, and it's been mostly a _great_ experience. The thing that bothers me most with "classic TDD" is that sometimes I build too much functionality in my classes, which isn't used in the end application after all. Even whole objects are wasted in the worst case."

The view here is that bottom-up design can lead to speculation and waste. By having a design driven directly by the overall, required behaviour, you only implement (and test) things that directly serve that behaviour. This can help eliminate speculative implementations of lower-level behaviour based on what you think the overall required behaviour will be.

Not so fast...

Sounds great! So what about inside-out / bottom-up / middle-out design? Ron Jeffries recently stated on the TDD mailing list that he generally prefers to start with the model (unless the project is simply to build a viewer). Maybe there's a bit more to it?

Digging further into that thread on the TDD list, there are a number of great points of view on the topic. Some TDD-ists argue that bottom-up design lets you build in small, easy steps, and refactor your way to the required behaviour that you would otherwise start with in top-down design. Others state that this leads to waste -- writing code and tests that just get refactored away. Which resulted in a couple of great quotes on the difference between refactored code and waste:

"I suppose we could also call the scaffold we use when constructing a large building as waste, or the safety harnesses as waste." -- John Roth to TDD list

"The analogy with scaffolding for a house is an excellent one - there is a lot of "stuff" constructed when building a house, *just* to support the construction - it is then discarded." -- Casey Charlton to TDD list

Top-down design can also lead to a "mockist" approach to TDD, where you need to mock all the required dependencies to implement the high level behaviour. This isn't necessarily a bad thing, but over-reliance on mocking can result in fragile tests. Martin Fowler has a great article on the pros and cons of "classic" and "mockist" TDD.

Enough rambling already!

While planning for part 3 of my recent development exercise I was coming to the conclusion that top-down was the way to go. After looking into it some more I was reminded of a whole host of advantages of bottom-up design. Even more importantly it reminded me that there is no silver bullet, and there are times when either, or a mix of both, approaches are fine. All this started to sound familiar, so firing up Google I noticed that I had read something to this effect in Jeremy Miller's excellent (as usual) post on the topic (search for "Bottom Up versus Top Down", although the whole post is worth reading).

I think the most important conclusion I've reached during this ramble is that if you are working in iterations to deliver a complete slice of the application (top and bottom) then you're never going to go too far wrong. Any "waste" from a bottom-up approach will be minimal as you'll be working toward and implementing the top almost immediately. And you'll still end up with higher-level behaviour specified with unit tests. Likewise starting top-down you'll still get the advantages of designing in small steps, particularly as you drive down into the design.

Disable theming for an empty ASPX

2008-05-21T16:21:00.006+10:00

I recently added an ASPX page whose sole purpose in life is to redirect in various ways (yes, I could use a handler, no I didn't in this case). It had no content other than the usual <%@ Page ...%> declaration. No head, body, or html tag. I got the following error message:

Using themed css files requires a header control on the page. (e.g. <head runat="server" />).

So naturally I added <%@ Page EnableTheming="false" ...%>, and ... got the same error. Bit of Googling later and found this post from Damien White (which in turn references a Rick Strahl post). End result is that EnableTheming seems a bit useless (at least for this case):

<%@ Page Language="C#" Theme="" ... %>

Setting Theme to nothing works, EnableTheming="false" doesn't. Bit odd. I know this is old news, but given the trouble I had searching for a solution I thought an extra search result floating around wouldn't hurt anyone.

ReSharper 4.0 beta

2008-05-20T07:32:00.007+10:00

Update 2008-05-22: The real beta release has just been announced. It is the same build (804) as the beta candidate, which pretty much answers my question below on the difference between the two :).

R# 4.0 beta candidate has been released. I'm not quite sure of the difference between a beta and a beta candidate, but I'm assuming its better than a standard nightly build :)

You can get it here, build 804. I've had a pretty good experience with most of the "works here" builds, so am looking forward to firing this up today :)

LINQ To SQL crippled prior to RTM

2008-05-20T06:58:00.005+10:00

I was reading Frans' post on the marketing hype around Entity Framework this morning. He left an interesting comment there, quoting Matt Warren's post on writing an extensible LINQ to SQL DataContext. Here's a snippet from Matt's original post (emphasis mine):

"If only LINQ to SQL had a public provider model, I could simply plug a new one in and use it to intercept all interaction with the database. Oh, double irony, as there is no such provider model, at least not a public one. Grin.

LINQ to SQL was actually designed to be host to more types of back-ends than just SQL server. It had a provider model targeted for RTM, but was disabled before the release. Don’t ask me why. Be satisfied to know that is was not a technical reason. Internally, it still behaves that way."

Cue conspiracy theories! :)