Making a Patch for Castle Windsor

So, I’ve decided to try turning AutoGen into a patch for the Castle project.  The first problem I’ve encountered is that TypedFactoryFacility is considered part of the MicroKernel.  Since AutoGen references Castle.DynamicProxy directly, it’s not really a goer to put it there.  This basically means that I need to add it to the extremely large facilities folder.  On the other hand, it gives me an opportunity to work directly with nant, which isn’t a bad thing.  It certainly makes you tidy up your references (and about time too… I had a reference to System.Data.  Needless to say, I didn’t have a depedency.)

The Castle project are pretty aggressive about warnings as errors, so I had to remove an unused field.  It was there for a future feature but, of course, YAGNI applies.  It was a speed-bump in any event.  I’m way too used to working with legacy code which seems to generate more warnings than executable code.  It seems that you need to disable signing when you’re nanting a sub-build.

None of this is that bad.  The tests, on the other hand, were a right royal pain.  Castle uses NUnit 2.2.8 (it’s really finicky about NUnit versions), the tests were written 2.4 style.  Cue a significant amount of hacking around.  Also awkward was the test requirement for the Common Service Locator.  There’s certainly an element of cargo-cult programming in what I’m doing right now: the build files are a maze.  I’ve got to admit, I’ve always had problems getting Castle to build (it appears that people on the mailing list appreciate this, but it’s not like it’s fixed) and so changing the build is a bit of a scary operation.

Anyway, the patch is now in donjon, so we’ll see what happens.

The Best Companies are Progressive

I couldn’t disagree more with what Max is saying here.  Now, I’ve worked at some pretty conservative companies, and pushed through process improvements everywhere I’ve been.  Believe it or not, one time the first thing I did was implement source control.  I’d say that reworking my department was part of my job description, but my job title is Architect.  Remaking a three thousand man company?  Not something I can do on my own.  For that, you need senior level management’s involvement.  If you can’t get it, that’s unfortunate, but if the change is worth making, it’s the job of those that can make it happen.

There do exist progressive companies that have extremely senior people with a hawk’s eye on process.  Google is the obvious case, where a set of coding standards and acceptance standards is implemented across the whole,huge, development community.  If you’re at a similarly sized organization, the chances are that you’ve got different processes in different areas: basically, the areas in which co-ordination is both possible and productive.  Again, I’m not saying you shouldn’t try to co-ordinate with your peers, but if it’s either unworkable or positively detrimental (“We want to standardize on SSADM.”) you can just walk away and don’t blame yourself.

It’s not the only one, though.  How about Starbucks?  It’s not always perfect, but the fact remains that every time you walk into one, you’re seeing an organization where process optimization is taken seriously by the CEO of a massive multi-national.

Of course, coffee shops is most of what Starbucks does, code is most of what google does.  There are plenty of organizations in which development isn’t the primary focus.  It’s still surprising when you discover that this is true of a dotcom, but it does happen.  Now, I do see way too many people who think that process re-engineering is somebody else’s problem, either someone more senior or someone in another department, but it’s always management’s problem.  Seriously, what manager can you think of who shouldn’t be responsible for what his reports are doing?

Technorati Tags:

Messing Around with Fluent Interfaces

I’ve recently been building a couple of very small fluent interfaces.  These have been focused on component testing, where some of their disadvantages aren’t as important.  Let me give an example:

public void PartialRecoveryFromTwoSessions() {
    When
        .SessionStartsAt("1 Jan 1990 21:25:00", s => s
            .MessagesProcessed(3, 5, 1))
        .And.SessionStartsAt("1 Jan 1990 21:35:00", s => s
            .MessagesProcessed(2, 6))
    .Then
        .RecoveryStartsFrom(4)
        .RecoveryWillSkip(5, 6);
}

Now, the great advantage of expressing your test in this fashion is that it’s quite easy for someone to look at the test and see what you mean.  However, there are a couple of disadvantages worth mentioning:

  • Although it makes your intent obvious, it doesn’t make it obvious that your intent has, in fact been satisfied.
  • Since you’ve just written a short testing framework, you really ought to write some tests for the framework itself.  That would probably involve mocking the object under test.
  • Writing this style in C# typically involves creating builder objects.  Personally, I try to avoid writing mutable objects wherever  possible, and builder objects are about as mutable as they come.
  • The overhead of creating an actual framework for testing rather discourages the practice of test-first development.

Despite this, the improved ability of the test to communicate intent makes it well worth doing.

How it works

Martin Fowler’s article gives you the abstract details of how this sort of thing works in C# and Java, but I thought it would be worth explaining the example I’ve built here.  You’ll note that there are a large number of violations of standard practice in this explanation.  That’s one of the major reasons I’m using this principally in testing code: I really don’t like the stylistic continuity from standard coding practices.

  • When is a property that creates a new CaseBuilder object.  This object also acts as the stub repository (this implementation doesn’t use a mocking framework, so all test doubles are actual physical objects).  Obviously, you’d never violate separation of concerns like that in production code.
  • SessionStartsAt is a method that creates a session and adds it to the repository.  It then returns the CaseBuilder to allow the method chaining.
  • To configure the session, you implement an action on the session.  This is a pattern I learnt from the Fluent NHibernate code base.  The advanatage of this is that you don’t need to worry about how to get back to the CaseBuilder object after you’ve finished configuring the session.
  • “And” does nothing, it just returns the builder object.  It’s only there for (natural language) readability.
  • “Then” actually performs the test and returns a CheckBuilder.  By returning a new type, you restrict what appears in auto-complete and prevent people from expressing logical nonsense in the tests.

If you need to customize how the test runs, you tend to need to insert another delegate into the system.  In general, though, I’m quite pleased with the technique.  There’s less than 300 lines for the framework outlined above, most of which is relatively trivial code of the form “set property, then return “this” “.

Technorati Tags: ,