MelGrubb.ToBlog()

Here is a screencast of my recent Code Generation talk at Quick Solutions. This is our first recorded screencast, so we're a little rough at first, but I think this is pretty good for our first attempt. For the curious, I was connected to a network projector while Alexei Govorine was shadowing the screen with his laptop, and running Camtasia Studio to do the capture. this worked out nicely in that it left my laptop free to run the slides and demos without having to be concerned with the recording duties. I tried capturing the screen myself earlier in the week, and found that Camtasia slowed down the demos slightly, and made some Powerpoint fades and transitions a bit choppy. Anyway, this is my first screencast, so enjoy, and if you're one of my non-programming friends, and have no idea what I'm talking about, that's okay... you don't have to watch the whole thing... muggle.

I’m giving a presentation on August 12th at QSI.  I think it’s a pretty cool one if I must say so myself.  Come learn about T4 templating and what it can do for you.  What it’s doing for me at the moment is pretty flippin’ sweet, so I want to share the love, so to speak.  Don’t forget to RSVP so as to ensure a decent pizza supply.

Title: Practical Code Generation with T4

Description: T4, Visual Studio's built-in, template-based code generation system was introduced in VS2005 and achieved limited public acceptance in VS2008. Now, with VS2010, it is set to become a first-class citizen in many .NET solutions. T4 templates can be used to automate many repetitive coding tasks, such as boilerplate framework code or proxy generation. In this session, we'll start with the basics of code generation and advance through using T4 templates and reflection to automate the creation of customizable artifacts at virtually every tier of a typical solution.

When: Wednesday, August 12, 2009
5:30 – 7:00 p.m.

RSVP:  Anji Morey @ amorey@quicksolutions.com by noon on Tuesday, August 11!

Where: QSI Training Center
440 Polaris Parkway, Suite 500

*Friends, clients, candidates and co-workers are welcome!
*Food & beverages will be served at 5:30 p.m.

I’ve heard a lot of developers bash one unit testing framework or another because of the lack of the RowTest attribute, which I beleive originated in MbUnit, at least as far as .net developers are concerned. If it came over from the Java world, well… that’s outside of my current scope and I don’t care. What bothers me is that some developers will use the presence or absence of the RowTest attribute as criteria for accepting or rejecting an entire testing framework, when in my opinion the attribute is totally unnecessary in the first place. You can achieve the same (or better) results using code that will work in ANY unit testing framework (barring the usual attribute naming differences, of course).

Let me start by saying that if you want to run TestA with three different sets of input, I presume it’s because those three sets of input are each supposed to provoke a slightly different response form the test, otherwise why bother? Perhaps you are explicitly testing the edge cases to make sure that everything works as expected on either side of a boundary without blowing up. Let’s assume that we want to test some method that takes a lower and an upper bound, and lets you know whether they are valid.  We write a test that looks something like the following, which takes a lower and upper bound, and a Boolean indicating whether the test should succeed or fail.

[RowTest]
[Row(0,1,true)]
[Row(1,1,true)]
[Row(1,0,false)]
public void RangeValidatorTest(int lower, int upper, bool expected)
{
    var target = new RangeValidator();
    Assert.AreEqual(expected, target.Validate(lower, upper));
}

 

The problem here is that nothing about the input data tells me why it’s special. What is different about row 1 as opposed to row 2? It’s a contrived example, sure, but stay with me. Now do the same thing without the RowTest attribute. I hear people complaining already: “But I don’t wanna write the same test three times”. <arnold>Stop whining!</arnold>

I’m not talking about wholesale copy and paste here. you just factor the guts into a non-test method.  It’s easy, you’ll see.

public void RangeValidatorTestHelper(int lower, int upper, bool expected)
{ 
    var target = new RangeValidator(); 
    Assert.AreEqual(expected, target.Validate(lower, upper));
}
 
[Test]
public void RangeValidator_accepts_lower_less_than_upper()
{ RangeValidatorTestHelper(0, 1, true); }


[Test]
public void RangeValidator_accepts_lower_equals_upper()
{ RangeValidatorTestHelper(1, 1, true); }
 
[Test]
public void RangeValidator_rejects_lower_greater_than_upper()
{ RangeValidatorTestHelper(1, 0, false); }

It’s a little wordier, sure, but I like wordiness, personally. Notice how the actual tests each have their own intelligent names now. I can read the test results without having to “parse in” the parameters to figure out what’s going wrong with a test now.

But hey, that’s just me.

I’ve used IoC containers on several projects now, and quite frankly never want to live without them again.  They make so many things easier for me that they have become part of my way of designing.  I like deciding in one place how a class will be instantiated.  I like the possibility of making a change in one place an having all the instances of a class become singletons, even though that kind of change is rare.  The one thing I don’t like is maintaining a “registry” class, and adding configuration for each and every class to it when I have a whole category of similar classes that should all behave in the same way.  Take, for example, service proxies.  Regardless of how their endpoints are configured, the code to register them with the IoC is going to look exactly the same for each one.

Container.RegisterType<IFooService, FooServiceProxy>();
Container.RegisterType<IBarService, BarServiceProxy>();
Container.RegisterType<IBazService, BazServiceProxy>();
...

I’ve done some reflection-based “registration” of classes before for things like validators and workflow classes, and it saved me a lot of time.  The idea is simple.  Reflect over an assembly, looking for all the classes that fit a certain pattern, and add them to a list of some kind.  This is usually done at application startup, so whether you’re afraid of some fictional “performance hit” associated with reflection or not, it’s only going to happen once per run anyway, and it saves a lot of tedious typing.  It also automates the addition of new classes to the pattern so you don’t forget and leave anyone behind.

I’ve now written something similar to handle registration of similar classes with an IoC container.  This requires a base interface and a base type.  We then reflect over the assembly containing the base type, and register all classes that implement an interface derived from the provided base interface.  In other words, given IService and ServiceBase, automatically register IFooService/FooServiceProxy.  The method looks like this:

private static void RegisterTypes<TBaseContract, TBaseClass>()
    where TBaseClass : TBaseContract
{
    var baseContractType = typeof(TBaseContract);
    var baseType = typeof(TBaseClass);
    var implementationTypes = baseType.Assembly.GetTypes()
        .Where(t => t.IsSubclassOf(baseType) && !t.IsAbstract);
    foreach (var implementationType in implementationTypes)
    {
        var contractType = implementationType.GetInterfaces()
            .Where(i => (i != baseContractType) 
                && baseContractType.IsAssignableFrom(i) 
                && !i.IsGenericType)
            .SingleOrDefault();
        if(contractType != null)
            Container.RegisterType(contractType, implementationType);
    }
}

Have you ever been at a party and two drunk and/or stoned guys are sitting in the corner discussing the meaning of life or the nature of existence?  Would you have any interest in reading a transcript of that conversation?  I didn’t think so.  Now imagine that the two guys are Albert Einstein and Stephen Hawking, and the discussion is about the nature of pan-dimensional existence.  Okay so now you’re more interested in the transcript, right?  The only problem is that now you can’t understand a word of it.  That’s kind of what reading Anathem is like.

I wanted to like it, I really did, but to be honest it takes up twice the space it ought to.  There’s little enough actual plot in this novel that I could retell it in less space than this review takes, but the narrative is so tangled up in its own contemplative navel-gazing that I had to continuously stop myself from yelling “Get to the friggin’ point, would you?”  At the same time, standard plot elements and devices are given only the most cursory treatment. Should the main character have a love interest?  No, we’ll just let him decide “I think I like Ala” before yanking her away so that he can spend the rest of the novel pining over a girl that he had previously never even gave a second thought to, nor made it to second base with.

My main irritation with Anathem is the author’s heavy-handed use of invented language to immerse the reader in the world in which the non-action takes place.  Plenty of authors have used invented language to gently remind the reader that they are no longer in Kansas, but Anathem spent so much time positively pummeling me with its Oz-club that it became a distraction.  It’s okay to make up a few new names and/or terms here and there, but when the reader spends most of the novel saying “Now what the hell was a ‘mobe’ again?” you’ve overdone it.

Fortunately the made up language becomes more sparse throughout the middle of the story but at the same time, that’s when everything stops happening, and it degenerates into the literary equivalent of a particularly uneventful road-movie.  It’s like the whole Tom Bombadil section of Lord Of The Rings, but ten times as long.  Chapter after chapter of absolutely nothing of any interest happening, but described in excruciating detail.  I would have given up on it, but by this point finishing the novel had become personal, although I found myself "fast-forwarding” through some of the dinner conversation “messals” in which page after page is spent discussing many different wordings and explanations for what could easily have been explained just once, and more succinctly.

I’ll always appreciate Neal Stephenson for writing Snow Crash and In The Beginning… Was The Command Line, but loyalty only stretches so far, and mine is now soap-bubble-thin.  The ideas were fascinating, but so much time was spent on philosophical dead-ends that the whole thing cries out for editing.  Did I need to witness a conversation about the most mathematically pure way to divide a cake into eight equal pieces?  No, I really didn’t.  (To be fair, this conversation was an appendix, but you can’t just drop footnotes and not expect me to read them.)  The intricacies of how the concent’s clock is wound, and how it works the gates genuinely added to the sense of life at Saunt Edhar’s, but plenty of other orthogonal offshoots could have been left by the wayside, resulting in a tighter, more focused work.