The Freak Parade

Boo is an interesting, extremely flexible CLR language with an “open compiler architecture” - which means that you can easily extend its compiler to accommodate your needs. I bought a Manning Early Access Program (unfinished, unedited, and rough around the edges) book by Ayende Rahien called Building Domain Specific Languages in Boo that, despite the writing style, which conveys an accent and is so informal that it almost borders on the insane, has already proven quite useful. The book relies on an open source library, also by Ayende Rahien (of Rhino Mocks fame) called Rhino DSL. The library itself is small, simple and effective. In addition to DSL’s, Boo (which is a statically typed, compiled language) has an optional interpreter and seems like it could be effectively used as a runtime scripting language, in addition of course to being a full blown .NET language you could write your business objects or UI in.

Anyway, below are a few resources I have come across while researching this topic in support of creating a state machine DSL referenced in my previous post:

Scripting With Boo
Binsor : Castle IOC container configuration using Boo DSL from Ayende

DSL Support
Early Access Book: Building DSLs in Boo (Ayende)

Specter Framework - writing executable object specs using a Boo DSL

An interesting example of TDD using Specter
Article on DSL’s using BOO by Ayende

A list of open source apps written in boo

Martin Fowler is writing a book on DSL’s also

Using Boo as an embedded scripting language

Visual Studio Integration via BooLangStudio

SimpleStateMachine project using a Boo DSL for configuration

I have posted a CodePlex project here that implements a simple, customizable State Machine & miniature runtime. The point of this project was to replace Windows Workflow Foundation in one of our applications as the state machine engine. Windows Workflow foundation is a powerful, robust technology but turns out to be unsupportable overkill if all you are really after is defining and coordinating state transitions in your application. Plus, it can be rather difficult to unit test, even more difficult to version and extend once an application is deployed, and requires all sorts of baggage in the form of database infrastructure and GAC requirements, etc.

Anyway, this library does nothing else besides let you define a set of events, states, and transitions between states when triggered by events, and optionally allows for user defined actions to fire during the initialization or finalization of any or all states.

As for representing the actual state machines there are a few options: A visual designer such as WF provides. The WF designer itself is awful for representing state machines, even simple ones, as it was designed to suit sequential workflows as well and the two kinds of diagrams have different needs. It might be possible to create a visual designer that did the job well, but it would be a big task. Another option is to configure state machines in code using an object model or fluent interface. This would have worked, but it ends up looking pretty ugly after a while and you can’t change your state machines without deploying updated assemblies.

The approach I settled on was to use a DSL, using Boo and Rhino DSL, as described by Ayende Rahien in his (unfinished) book on the subject. The State Machine language itself was inspired by Martin Fowler, who appears also to be writing a book about DSL’s.

An example state machine definition looks like the sample below. It isn’t as snazzy and colorful as the visual designer version you get with WF, but in practice it is much more practical.

workflow "Telephone Call"

trigger @CallDialed
trigger @HungUp
trigger @CallConnected
trigger @LeftMessage
trigger @PlacedOnHold
trigger @TakenOffHold
trigger @PhoneHurledAgainstWall

state @OffHook:
	when @CallDialed             >> @Ringing

state @Ringing:
	when @HungUp                 >> @OffHook
	when @CallConnected          >> @Connected

state @Connected:
	when @LeftMessage            >> @OffHook
	when @HungUp                 >> @OffHook
	when @PlacedOnHold           >> @OnHold

state @OnHold:
	when @TakenOffHold           >> @Connected
	when @HungUp                 >> @OffHook
	when @PhoneHurledAgainstWall >> @PhoneDestroyed

state @PhoneDestroyed

is a trimmed down version of the .NET framework aimed at providing a leaner deployment package for systems that are just intended to run .NET client software. It ends up being around 23mb and should make it easier to deploy on the web to computers that might not have the latest version of .NET installed. Below is a link to a blog that has a link to a list of assemblies included in the profile :) 

POKE 53280,0: Pete Brown’s Blog : What’s in the .NET Framework Client Profile?

This looks like a fantastic, flexible, simple to use template engine for .NET. I can’t imagine not finding a use for this in the near future. I haven’t dug any deeper, but LazyParser.NET may have significant promise as well.

ASP.NET without ASP.NET - SharpTemplate.NET pre-release on CodePlex

I just launched a new open source project on CodePlex, NSB Management Extensions. This purpose of this project is to provide endpoint management, such as endpoint heartbeat monitoring & node performance monitoring, which exists in the initial release, as well as some more advanced services such as service/endpoint repositories, event broker with server-side subscription rules, a processing pipeline for the MSMQ Transport, etc.

The project can be found here: http://www.codeplex.com/NSBManagement

I am currently in the process of writing some custom .NET Configuration classes, such as custom ConfigurationHandler implementations, ConfigurationElementCollection, etc. Configuration classes need to be tested just like any other code, especially if they contain any behavior beyond the simple mapping of an XML property to a class property. It turns out the .NET Configuration API makes this pretty easy:

    [TestFixture]
    public class ConfigurationTestFixture
    {
        [Test]
        public void TestCustomConfig()
        {
            var cfg = GetTestConfiguration();
            Assert.That(cfg, Is.Not.Null);

            var mySection = cfg.GetSection("mySection") as mySection;
            Assert.That(mySection, Is.Not.Null);
            Assert.That(mySection.CustomProp,Is.EqualTo("configuredValue"));
            ...

        }

        private System.Configuration.Configuration GetTestConfiguration()
        {
            var map = new ExeConfigurationFileMap()
                          {
                              ExeConfigFilename =

                              Path.Combine(AppDomain.CurrentDomain.BaseDirectory,

                              "TestApp.config")
                          };

            return ConfigurationManager.OpenMappedExeConfiguration(

                    map, ConfigurationUserLevel.None);
        }

For this to work you’ll need a configuration file with the appropriate XML to test your classes stored at the root of your test project with the Copy To Output Directory property set to Copy If Newer. You could use any path to create your ExeConfigurationFileMap, but for me putting the file at the root seemed the easiest solution.

In looking for a palatable way to add configuration file support to some components I’m writing I looked at a number of articles on the topic, all of which discussed some interesting aspect of the configuration. This article, however, covers it all. It is a little long, but well organized so you can find just the parts you need. If you ever engage in creating a configuration section for your .NET 2.0+ app, this is the reference.

http://www.codeproject.com/KB/dotnet/mysteriesofconfiguration.aspx

That being said, here’s a totally different approach to configuration using the XML Serializer. You would lose some validation capabilities, but you gain virtually unlimited flexibility in your object model and you can write whatever simple configuration model you like without worrying about the configuration namespace classes.

http://www.15seconds.com/issue/040504.htm

As working with VM’s becomes more important in more scenarios, tools like this could make a big difference.

Microsoft opens Offline Virtual Machine Servicing Tool beta

        Instrumenting Your App w/.NET 3.5

And… how to consume performance counters

Consuming (and publishing) Performance Counters

Here is are some extensions to SQL Server Management studio that look like they might be pretty useful. For some reason the “Run one script on multiple databases” feature catches my eye…

Get the software here: SSMS Tools Pack

From the website:

SSMS Tools PACK is an Add-In (Add-On) for Microsoft SQL Server Management Studio and Microsoft SQL Server Management Studio Express.
It contains a few upgrades to the IDE that I thought were missing from the Management Studio:

• Uppercase/Lowercase keywords.
• Run one script on multiple databases.
• Copy execution plan bitmaps to clipboard.
• Search Results in Grid Mode and Execution Plans.
• Generate Insert statements for a single table, the whole database or current resultsets in grids.
• Query Execution History (Soft Source Control).
• Text document Regions and Debug sections.
• Running custom scripts from Object explorer’s Context menu.
• CRUD (Create, Read, Update, Delete) stored procedure generation.
• New query template.