the ‘bee log

Reading Chris Donnan’s blog during the morning cup I read about the CLR Add-In model in the .NET Framework around Orcas. Thought I’d toss one into the echo chamber as I have a tendency to harp on about extensibility and plug-in frameworks. You can learn about it here and here.

I wonder if p&p’s ObjectBuilder has influenced the design of this. I might be jumping the gun, but it looks like Dependency Injection will be a first class facility of the framework, another pattern made implicit.

How robust will it be? Will there be ObjectBuilder-style support for policies and strategies used for use in complex object graph build-up? Good to see that extensions are loaded in separate AppDomains with sandboxed security (a necessity for applications with third party add-ins).

Questions abound. An exciting new feature to check out for sure…

Some time ago I read a good article on some common TDD anti-patterns by James Carr (which lives right here.) Great, yeah, those are some anti-patterns. So what about patterns?

I wouldn’t say what follows are necessarily TDD patterns; they’re simple techniques for structuring your unit tests. TDD is a great design methodology and it’s absolutely essential to have a robust test portfolio as a refactoring safety net. That said, you are incurring more care and feeding debt simply because you now have more code to maintain.

A well chosen strategy for testing unit tests can ease this burden…

Test Method per Feature

The word feature could easily be substituted for requirement, use case, or user story. This strategy is useful for keeping features granular. As you generally want to keep your unit tests fairly small, this will force you to keep your features fairly small. Agile practices advocate keeping your units of work fairly tiny, e.g. limiting the size of your backlog items or users stories. Having a test method per feature is one way keeping size of test, feature, and business requirement in lockstep.

Test Methods as Examples

Peter Provost and Brad Wilson mentioned in a talk I attended that they had taken to calling TDD example driven review (if I am remembering correctly). The idea is that your tests become specifications of how to use the classes of your app in consumer code. A nice advantage of this approach is that tests become great starting points for developers new to a particular codebase, a kind of developer documentation. You’re feeding two birds with one seed, and that’s always a wonderful thing.

This tactic makes a lot of sense when applying the TDD practice; remember it is fundamentally a design methodology that produces tests as a positive side-effect that aid in refactoring (feeding back into the design). In some regards I wish TDD had called Design By Test, DBT… but that’s another post.

This strategy works well with the test method per feature strategy above. You’d start your test fixture with a comment block that enumerates the list of features encapsulated by the unit under test. As you go through the list, follow the usual red-green-refactor process of creating test methods, writing the implementation, and tweaking the design to satisfaction. As you go, you remove list items from the comment block.

I like this strategy very much. When doing tests as examples I like to prefix my test class with Example.

Test Fixture per Feature

In this scenario you might have a fairly beefy feature that can benefit from multiple tests or you have a feature that is distributed across several units (classes). Generally your test fixtures (classes) will have a one-to-one mapping to a corresponding class (the class under test), but it is occasionally beneficial from an organization and maintenance perspective to break out more complex features into their own fixture.

Test Fixture per Asset

In a domain model adhering to DDD patterns you’d have a test for each Aggregate, Service, Repository, and stand-alone Factory. We use this strategy at Xclaim for our domain model layer. This brings up a larger issue of asset-based development that’s well beyond the scope of this post. I will briefly mention that I like to conceive of the systems I build as “Lego Kits”, and look to conceptually differentiate the red bricks from the green bricks from the mini-figs.

Test Library per Layer

Model your test libraries by architectural layer. This could mean a single test library for multiple assemblies: as long as those assemblies serve the same architectural layer (e.g. data access layer, presentation layer).

Test Method per Defect

In this strategy, you would create a test method when an end user or the test team reports a defect. Typically this will happen after you’ve debugged and diagnosed the defect in question. The idea here is to ensure that the defect doesn’t rear its ugly head again and that you’ve given yourself some “refactoring insurance” as you evolve the codebase.

Inline Tests

Write your tests in the same project as your production code. Yes, this is one way to go, but I don’t like this strategy; it’s too mixed up and hard to manage. If you were to go this way you’d probably want to strip test classes from your automated builds (at least when building in release mode). This requires hand tuning (e.g. you couldn’t ms-build or nant build right from a project/solution file. Even though I’m not a fan, I thought I’d include this strategy as someone out there might be using it and have some insight on benefits/techniques.

—

This is by no means an exhaustive list, but I thought I’d try and start a conversation:

• What tips do you have for structuring your test libraries?
• Are stale unit tests an issue in your shop?

When using NHibernate sometimes your mapping files get a little out of hand, especially if you’re putting all your mappings into a single file.

We initially started out with a one-to-one relationship between a mapping file and what DDD calls a Module. In DDD a Module is a grouping of related classes around which you want to exert - at least - conceptual control over the dependencies inside and out. In my mind it’s the next order of magnitude above the Aggregate Root pattern… more cell wall than nucleus wall.

Anyway, this model of having a mapping file per 3-8 related classes became kind of cumbersome for me. When you’re opening an XML file that can be a few hundred lines long, and it’s easy to lose your place when tracking a relationship mapping or just going through a class that has a dozen or so properties in it. Of course, one of the best practices mentioned in the NHibernate documentation is to “place each class mapping in its own file.” I switched to that model and have noticed a nice improvement in map discoverability and workflow; I can now CTRL+TAB between a few screens that have related mappings. I guess it pays to read, eh?

This weekend I was adding a couple of features to our Domain Model for contact management. It became sensible at a certain point in the design to introduce an inheritance relationship between a few of the classes. I decided to use an abstract base class and the “table per subclass” strategy offered by NHibernate. This is done by defining the base class in the usual class mapping then adding joined-subclass mappings. For a while I couldn’t figure out how to break out the mappings for the subclasses until I noticed:

It is possible to define subclass and joined-subclass mappings in separate mapping documents, directly beneath hibernate-mapping. This allows you to extend a class hierarchy just by adding a new mapping file. You must specify an extends attribute in the subclass mapping, naming a previously mapped superclass. Use of this feature makes the ordering of the mapping documents important!

The provided sample mapping:

<hibernate-mapping>
<subclass name=”Eg.Subclass.DomesticCat, Eg”
extends=”Eg.Cat, Eg”
discriminator-value=”D”>
<property name=”name” type=”string”/>
</subclass>
</hibernate-mapping>

I was unsure what the part “makes the ordering of the mapping documents important!” of the documentation meant, so I tried it in one of our Domain Models. Using embedded mappings (”Embed As Resource”) it worked without a hitch. My suspicion is that the load order matters when you are loading your mapping files programmatically and external to your assembly via NHibernate’s Configuration.AddFile().

From the book Ancient Mathematics by S. Cuomo:

Another stunning example of the accuracy that could be achieved by Greek builders is linked to the name of Eupalinus of Megara. The so-called Eupalinus tunnel, built c. 550-530 BC, is part of a water-supply system for the city of Samos, and runs for some 1036 m under a mountain. Excavations have revealed that the tunnel was made by two teams of workers, who started to dig at the two opposite sides of the mountain and managed to meet in the middle.

I like to attach this idea to our solution architecture: the system is the tunnel and we’re building it from two ends: a Web Services “feature farm” and Composite UI client apps (both Smart and Web). Of course the two big segments have to meet in the middle, but each side of the mountain may have different soil/rock composition and pose it’s own set of challenges/techniques/methods. The method we employ is our own kind of TBM. Man, I want one of those.

One could consider your typical feature a kind of “tunnel”. At some level it can go from a user gesture like filling out a form, clicking a button, or setting up a workflow schedule (where they enter the tunnel), through a series of web services (distribution, infrastructure), to a domain model (your destination, let’s say grandma’s house), and possibly back again.

I really, really like Virtual Server 2005 R2. It has made a noticeable difference in the overall capability and disaster-preparedness of our shop, and it moves me toward that happy place where infrastructure doesn’t matter.

We’ve created five images to run specific servers for narrowly defined tasks such as: internal applications the development team uses, CC.NET builds, a customer beta installation of our application suite, system integration jobs we maintain, and debugging deployments of web services that we reference from our presentation layer apps, etc.

The backup story is simple; each image defines a backup “point” that the main server harvests and pushes to a storage location on our network then it’s archived and processes with other backup artifacts. For lazy backup we can just copy the image (though this isn’t the most efficient). I have been considering a hybrid model whereby we capture the whole server image periodically in addition to backing up the content — database, code, app config — which we already do. Because we have such small, narrowly defined servers some of the images really don’t have content that changes very often, so an image backup would make sense; they’re just there to run the application for various audiences or have minimal configuration information (ccnet.config).

I won’t lie: it takes a bit of hardware to run this kind of setup… you need some of the heavier metal, for sure. We’re running on a Dell PowerEdge w/ 8G of memory, 2 Dual Core XEON, loaded redundancies, NBD support, etc. It wasn’t crazy-expensive but it wasn’t cheap either. You could probably do fine with one of the many clone-type AMD boxes and a DIY mentality to IT support or an internal IT support capability that’s ready and willing. So you need one box with a bunch of memory and probably a hot-spare or, at very least, a machine that could run your critical images in the event of a device failure.

What’s cool is that it gives us the flexibility to quickly add a new server. We could, say, prototype a very targeted demo installation for a client/prospect in a minimum amount of time. Creating a baseline image for pilot projects, proofs-of-concept, and pre-sales is one of the big use cases we envision. We can research and experiment with various beta products that we don’t necessarily have the extra machines for. Another awesome thing would be to use FinalBuilder (which we use to make build and deployment scripts) to start/stop/resent/control images on the fly. A road we’ll go down to test our installation process and to run functional / regression test suites inside ephemeral Vista/XP baseline images.

All sorts of options…

Sure you could do it on one or a few servers, but I’ll guarantee they develop hairball problems that will ultimately take you away from more abstract and valuable pursuits. Sure you could buy a separate server or scrounge old workstations for more purposeful servers, but isn’t it just easier to maintain one machine with a hot-spare?

1. Peter points out a cool fact about the Vista Remote Desktop Client supporting multiple monitors. See his blog for specifics. It seems that the new Remote Desktop Client also supports this option in XP and Server 2003. Good for the laggards (me) amongst us.

2. This reminded me of the Facetop project. It is an experimental collaboration app that combines video conferencing, desktop sharing, and mouse replacement by way of USB camera. You can think of it as Sony’s EyeToy meets pcAnywhere. Some of the researchers posted an article on how it could support distributed Pair Programming. I’m not aware of a commercial product coming out of the research, but for those of us unfortunate enough to bare the yoke that is VPN / “Ask for Remote Assistance,” it’s nice to imagine a brighter day…

For some time now I’ve been (casually) following the emerging thought around the “Attention Economy“. Originally I became aware of this thru the now defunct, much missed Gillmor Gang podcast.

The central idea of Attention is that the gestures you make on the web (links you click on, searches you make, bookmarks you accumulate) accumulate value and previously were stored in vendor silos. That is, when you spend a significant amount of time on MSDN or Google Search, those sites capture your Attention Metadata… you don’t keep it, it’s lost to you, and effectively owned by a third party.

So what’s the value of keeping and owning your this data yourself? One possible application is that given this repository of data you might, say, upload it to a service that will provide targeted offers or aid in discovery of new sites, resources, products, etc. based on your clickstream (Attention Metadata). This represents a significant change in the way advertising currently works. Namely, the model changes from push to pull. You carry on through your day and have the agency to decide when to pull advertising (that’s mostly relevant to you) in to your Attention. The whole “User In Control” philosophy…

Cruising over to the AttentionTrust site, I discovered that they’ve released their Attention Recorder. This is a bit of client software implemented as a FireFox extension. It extends the FireFox toolbar with a button that lets you start/stop recording your Gestures.

Once you have this installed you then sign up for a service that will store the information collected and provide some basic analytics (I chose Root Vaults.)

I’m still kind of wondering where the killer app is here. I think, by-and-large, it’s in theory. Regardless I’m starting to collect and own my data anyway. I imagine someday there will be a collection of applications that make use of this information and when there are, I’ll be able to take advantage. If nothing else, it’s kind of interesting to be able to reflect upon where you’ve been on the web and what’s grabbing your interest over time.

The Smart Client stuff p&p has been pumping out (CAB, SCSF, etc.) has a new home on CodePlex. This is a big deal because CodePlex handles community a lot better with better forums & a reasonable RSS feed (IMHO). Check the announcement over here… or just go to the site at http://www.codeplex.com/smartclient/.

(I’ve updated my SCSF Resources Page to point to the new locations.)