Jeremy D. Miller -- The Shade Tree Developer

More signs of FubuMVC getting real

Jeremy D. Miller — Tue, 09 Feb 2010 14:52:00 GMT

Just launched last night: http://guides.fubumvc.com/. The main page has been around for a couple weeks now at http://fubumvc.com/.

It's not that much yet, but I think the existence of *any* documentation at this point is a good indication that we're serious about making the FubuMVC reboot take off.

If you're interested in getting involved, there's a TODO list that Chad & I are trying to keep up with ideas for extending FubuMVC at http://wiki.fubumvc.com/TODO and the developers list is at http://groups.google.com/group/fubumvc-devel.

StructureMap 2.6 (and 2.5.4) is Released!

Jeremy D. Miller — Thu, 04 Feb 2010 15:14:00 GMT

Time flies when you’re having fun. It’s been almost a year since I’ve made an official StructureMap release, so I guess it’s about time. This morning I uploaded the binaries for the 2.6 release. This release just adds some bug fixes and a couple minor additions to the 2.5.4 release that I made in December but didn’t really publicize. The release notes below are long, but that’s because they represent almost a year’s worth of development. As I said yesterday, StructureMap is most likely moving to GitHub with the documentation going as well. After a massive effort to write documentation early last year, huge chunks of it is already obsolete and there’s been a lot of addition since. I’m hoping that the move to the Wiki will make it easier to keep the docs up. In the meantime, I’ll try to blog a bit about the newer pieces starting tomorrow.

A tiny bit of history. This is the 11th StructureMap release since it debuted way back in June of 2004. Almost nothing is the same. We use it differently, the expectations are different, and very, very little of the original code survives today. At QCon San Francisco in 2008 I talked about what I’d learned from evolving this codebase over so many years and changes.

This release includes a lot of patches from the community, and I’d like to thank all of you for that – especially Frank Quednau and Andreas Ohlund for taking on some nastier things. Josh and Kevin Miller do yeoman duty answering StackOverflow questions (so I don’t have to).

What’s Changed?

New terse, “jQuery-esque” syntax for the Registry DSL. Let’s just write off “ForRequestedType<IFoo>().TheDefault.Is.OfConcreteType<Foo>()” as a well meant experiment, shall we? It’s still in the codebase, but it’s marked as [Obsolete]. Nobody liked it and I thought it was annoying in real life usage. Now, just do: For<IFoo>().Use<Foo>(); My whole goal was to reduce friction. Needs a big blog post
Changed the Registry DSL to make inline dependency configuration be more consistent. Definitely a blog post.
The “CreateProfile” syntax has gotten a lot of complaints for being inconsistent with the rest of the Registry DSL. I basically rewrote it to now be consistent with the “For<>().Use()” syntax in the main Registry DSL. Blog post coming soon….
Nested Container feature for short lived transactional requests. I built this for Dovetail usage, but I think it’s my preferred way to manage object scoping in certain circumstances. I mentioned it just a little bit in my NHibernate w/ StructureMap post a couple weeks back. Blog post coming soon…
The “Model” feature was completely redone. There’s a lot more power, and you can use it to pull services out of the Container and completely remove services from the Container as well. Sigh. Needs a blog post.
Convention based type registration got a lot of work. People are pushing this feature very hard and it had to grow. You can now use the Registry DSL to write conventions. This was improved farther in the latest code drop. Yeah, blog post coming…
Better support for registering services by Type objects for cases when you don’t necessarily know the Type upfront. Big request from several framework authors like Caliburn.
A helluva lot of new features to make working with open generic types easier. Jimmy Bogard blogged about some of it here. I’d like to show how StructureMap’s new features would make writing something like Davy Brion’s Agatha framework a snap. I use this stuff extensively inside of StoryTeller.
Added the lazy Func<T> feature from Autofac. A really great (and cheap) way to support lazily initialized components. Blog post coming.
Completely ditched all Reflection.Emit code. StructureMap now strictly uses dynamically constructed Expression’s that are pre-compiled into cached Func’s. I don’t know if that really makes much difference to users, but it makes StructureMap much, much easier to extend. The container does spin up faster with this mechanism. Makes me happy.
Supports IList<T> and List<T> arguments. It works just like Arrays. That’s been a while coming.
You can set the lifecycle from <AddInstance> if you happen to still use Xml configuration.
The “Lifecycle” code was completely reworked to eliminate shared code
Container.Dispose() was introduced. I’ve put a lot of effort into making StructureMap clean up after itself. Definitely a blog post coming.
ObjectFactory.Container. Slowly, but surely, I’d like to wean people away from using ObjectFactory too much in favor of scoped Container objects. I will NOT be further extending the ObjectFactory static methods to synchronize it with IContainer. Instead, I’m just exposing the ObjectFactory.Container property.
New abilities for IContext like BuildUp() (thanks to Kyle Malloy), getting all instances, and TryGetInstance
TryGetInstance() from Josh
Killed StructureMapConfiguration. Good riddance.
“Forwarding” requests for IFoo to whatever IBar is

Getting StructureMap off SourceForge, Thoughts?

Jeremy D. Miller — Wed, 03 Feb 2010 22:29:00 GMT

The original discussion for this topic is here: http://groups.google.com/group/structuremap-users/browse_thread/thread/6d579f4e9b508c66

All,

I've never liked SourceForge and it's a PITA for me to use even though it's gotten better over the years. I'd like
to move StructureMap off SourceForge and more importantly, get a real
Wiki site up so that we have at least a fighting chance of keeping the
documentation up to date. On the other hand, I get a significant
number of patches from you guys (thanks for that) and I'd also like a
better way of handling those submissions -- and making it easier for
*you* to get involved.

Right now, Josh and I are thinking about moving StructureMap to GitHub
(you knew that was coming) and trying to use the Wiki support on
Github for now. Granted, Git is weird as hell for those of us used to
SVN, but GitHub has some huge advantages for OSS community
development. I'd *love* to start managing StructureMap patches
through GitHub "pull" requests (or whatever the correct lingo is).

Any thoughts? Volunteers? ;)

Jeremy

FubuMVC Learns to Speak Spark

Jeremy D. Miller — Tue, 02 Feb 2010 17:59:00 GMT

From Robert the Grey, FubuMVC learns to speak Spark.

I've done the nearly solo OSS thing a couple times to mixed results. I'm painfully aware that good OSS projects have a deeper community of contributors than just one guy, and that's why I'm so thrilled to see this addition come into the nascent FubuMVC reboot from outside the Dovetail office.

Dovetail is Hiring

Jeremy D. Miller — Fri, 29 Jan 2010 21:17:00 GMT

This is a different project than the one we hired for last time. If you've spoken to us before, please consider this position separately.

We're expanding the development team on our line of existing products. You'll be working on a small team that develops applications for large businesses using some of the latest technology. You will be involved in all aspects of solution development, including analysis, design, development, testing, documentation, and support.

We’re looking for a software developer with demonstrable C# (preferably .NET 2.0 or later) and HTML/CSS experience (ASP.NET MVC is a plus). Any experience with test-driven development or automated unit testing in general is a huge plus. Also, participation in the community (attendance of events, avid blog reader + commenter, or maybe you even have a blog yourself) will put you firmly in the running for this position. We’re looking for people that believe learning and continuous improvement are primary responsibilities of a software developer. We’re hiring motivated people for a terrific opportunity with a team of recognized .NET and agile community leaders.

Our practices and technologies include:

Test-driven development
Continuous integration
Behavior-driven design
Domain-driven design
HTML, CSS, Javascript (jQuery)
ASP .NET MVC
C# 3.0, .NET 3.5, Visual Studio 2008
SQL 2008
Oracle
NHibernate 2.x
StructureMap

Email us and tell us why you’d make a great addition to our team: tech-jobs@dovetailsoftware.com

This is a full-time, on-site position in our Austin, TX office. Please DO NOT contact us for outsourcing or tele-commuting.

Shrink your Views with FubuMVC Html Conventions

Jeremy D. Miller — Fri, 29 Jan 2010 17:00:00 GMT

Yesterday I was able to “push” into Github the work I’ve been doing for convention based Html generation in FubuMVC. What the hell is “convention based Html generation?” you ask? It’s simple in concept. Your team has policies, formal or informal, for how you build Html elements for the fields in a ViewModel. If your familiar with MvcContrib’s Opinionated Input Builders or MVC2’s Templates feature (very well described by Brad Wilson here), we’re doing the same thing conceptually but with much different mechanics. Right now, I’m focused on the very basic building block methods that appear on FubuMVC view’s (remember that we basically force all views in FubuMVC to be strongly typed with a single ViewModel):

InputFor( expression ) – write an Html element to edit a single property on the ViewModel. Instead of calling TextboxFor(x => x.Something) or DropdownListFor(x => x.Other) we can just say InputFor(x => x.Some.Property.On.The.ViewModel) and let the conventions figure out what to do from there. If we need to change the model property to something else, or change our conventions about how elements should be constructed, no big deal.
DisplayFor( expression ) – write an Html element to display the value of a single property value on the ViewModel. String fields are just displayed. Entity fields may be displayed as a link to more information on that link. Date fields are shown in short date format, etc.
LabelFor( expression ) – write an Html “label” element for the field. Out of the box, FubuMVC will just put in the field name, but that’s not all that useful. In our Dovetail project we have this tied into our localization subsystem to pluck out a localized header text for the desired property.

I’m dubious that the form auto-generation stuff that MVC2 does has much real world value, but it would certainly be possible to build on top of what we already have. In a follow up post I'll show more of the DSL-ey approach for creating simple forms that uses InputFor/DisplayFor/LabelFor as building blocks.

Example

In our system we have a small Entity class named Address (all systems of any complexity have an “Address” class, but they’re all different) with a property for the first line of the address called Address1:

        [Required, MaximumStringLength(250)]
        public string Address1 { get; set; }

Leaving the appropriateness of the approach aside (it’s working very well), we use attributes for our simple validation rules (and also use those to generate “not null” / string length types of rules in our database). On the client side, we use jQuery Validation to do input validation in the browser. jQuery Validation is very simple to use (as long as you color within the lines). All I need to do is add classes and some attributes to the <input> and <select> elements to declaratively apply validation rules.

In usage, we could build the input Html element for a field by just calling InputFor() like this:

    <dd><%= this.InputFor(m => m.Site.PrimaryAddress.Address1).Id("site-address1")%></dd>

In our Dovetail system the above call generates this Html:

    <input id="site-address1" class="required" type="text" 
        name="SitePrimaryAddressAddress1" label="Address 1" maxlength="250" value=""/>

Did you see what happened there? When we create an input element for the Address.Address1, the conventions:

Built a textbox element. If the property was a boolean, the conventions would build a checkbox instead. Likewise, if the property is a DateTime or DateTime? field the conventions would build a date picker.
Set a “name” attribute” that matches our naming convention so that model binding works smoothly from client to server and in automated testing scenarios. In our case we just take the “path” to a property from the ViewModel and tear out the “.” characters
Adds the "label” attribute with the localized header name for this field. This is used in conjunction with the jQuery validation to present a clean, localized validation summary on the screen
Recognizes the presence of the [MaximumStringLength] attribute and sets the “maxlength” attribute
Puts the property value into the “value” attribute. The example I used happens to come from a “New” screen, so the value is blank
Recognizes the presence of the [Required] attribute and adds the “required” class to the element

By the way, did you see how I overrode the “id” property of that textbox? I’ll talk more about that at the bottom, but that represents a huge advantage that FubuMVC’s model has over both MvcContrib and MVC2. You can happily modify or enhance the convention-generated Html input on a case by case basis.

Can I make my own Conventions?

One of the overarching principles of FubuMVC is to push the usage of Convention over Configuration as far as it can go while still allowing FubuMVC adopters to create and add their own conventions. The Html conventions are no different. When you register / configure conventions for the Html you can register either “Builders” that know how to generate the HtmlTag (I’ll explain HtmlTags later) for a certain class of properties:

    public delegate HtmlTag TagBuilder(ElementRequest request);
 
    public interface IElementBuilder
    {
        TagBuilder CreateInitial(AccessorDef accessorDef);
    }

or “Modifiers” that enrich HtmlTag’s:

    public delegate void TagModifier(ElementRequest request, HtmlTag tag);
 
    public interface IElementModifier
    {
        TagModifier CreateModifier(AccessorDef accessorDef);
    }

These ElementBuilder’s and ElementModifier’s can either be classes that you build yourself and “plug” in, or you can use the Html convention DSL shown below to create common, simple types of policies (think, if this attribute exists, add this class). A custom ElementBuilder might look like this:

    // This builder is only for creating the display tag
    // for a date time field on one of our "activity log"
    // models
    public class LogDateDisplay : ElementBuilder
    {
        // Does this builder apply to a property?
        protected override bool matches(AccessorDef def)
        {
            return def.ModelType.Closes(typeof (LogViewModel<>)) && def.Accessor.PropertyType.IsDateTime();
        }
 
        // Renders a date in long time format and also sticks the header
        // text into the title attribute
        public override HtmlTag Build(ElementRequest request)
        {
            string title = LocalizationManager.GetHeader(request.Accessor.InnerProperty);
            return new HtmlTag("span").Text(request.ToDisplay("{0:F}")).Title(title);
        }
    }

Alrighty, let’s move on to registering our conventions. From the top, I create a class to hold my project’s Html conventions like so:

    // HtmlConventionRegistry is the base class that provides the DSL
    // This is an example of "Object Scoping" from Fowler speak like
    // StructureMap's Registry and Fluent NHibernate's ClassMap
    public class DovetailHtmlConventions : HtmlConventionRegistry
    {
        public DovetailHtmlConventions()
        {
            validationAttributes();
            numbers();
 
            Profile("edit", x => x.Editors.Builder<EditInPlaceBuilder>());
 
            editors();
 
            Labels.Builder<LabelBuilder>();
 
            Displays.Builder<LogDateDisplay>();
            Displays.Builder<DisplayBuilder>();
 
        }
 
        private void editors()
        {
            Editors.Builder<ValueObjectDropdownBuilder>();
            Editors.IfPropertyIs<bool>().BuildBy(request => new CheckboxTag(request.Value<bool>()).Style("width", "auto !important").Attr("value", request.ElementId));
 
            Editors.Always.Modify((request, tag) =>
            {
                tag.Attr("label", request.Header());
                tag.Attr("name", request.ElementId);
            });
 
            // Ugly hack because of the hacky Edit in Place jQuery plugin we use, but
            // I'm gonna kill it some day
            Editors.IfPropertyTypeIs(t => t.IsDateTime()).Modify(x =>
            {
                if (!x.HasMetaData(EditInPlaceBuilder.EDITABLE_ATTRIBUTE_NAME))
                {
                    x.AddClass("DatePicker");
                }
            });
        }
 
        // Setting up rules for tagging elements with jQuery validation
        // metadata
        // I think that a lot of this gets added into the core Fubu as a
        // "jQueryValidationPack"
        private void numbers()
        {
            Editors.IfPropertyIs<Int32>().Attr("max", Int32.MaxValue);
            Editors.IfPropertyIs<Int16>().Attr("max", Int16.MaxValue);
            Editors.IfPropertyIs<Int64>().Attr("max", Int64.MaxValue);
            Editors.IfPropertyTypeIs(t => t.IsIntegerBased()).AddClass("integer");
            Editors.IfPropertyTypeIs(t => t.IsFloatingPoint()).AddClass("number");
        }
 
        // Declare policies for using validation attributes
        private void validationAttributes()
        {
            Editors.AddClassForAttribute<RequiredAttribute>("required");
            Editors.ModifyForAttribute<MaximumStringLengthAttribute>((tag, att) =>
            {
                if (att.Length < Entity.UnboundedStringLength)
                {
                    tag.Attr("maxlength", att.Length);
                }
            });
 
 
            Editors.ModifyForAttribute<GreaterOrEqualToZeroAttribute>(tag => tag.Attr("min", 0));
            Editors.ModifyForAttribute<GreaterThanZeroAttribute>(tag => tag.Attr("min", 1));
        }
    }

HtmlTags

The basis for FubuMVC’s Html conventions, and the big differentiating feature from the MVC2 and MvcContrib approach, is the usage of the “HtmlTags” library as a semantic model. All the Html generation in FubuMVC works by building up HtmlTag objects that represent an Html element graph (HtmlTag’s can have children). Think of the old TagBuilder class on steroids. A picture’s worth a thousand words, so let’s see some samples of HtmlTag in action:

            // Setting the inner text and adding a class
            HtmlTag tag = new HtmlTag("div").Text("my text").AddClass("collapsible");

            // adding "MetaData" for the jQuery MetaData plugin
            HtmlTag tag = new HtmlTag("div").Text("text");
            tag.MetaData("a", 1);
            tag.MetaData("b", "b-value");

        [Test]
        public void render_multiple_levels_of_nesting_2()
        {
            HtmlTag tag = new HtmlTag("html").Modify(x =>
            {
                x.Add("head", head =>
                {
                    head.Add("title").Text("The title");
                    head.Add("style").Text("the style");
                });
 
                x.Add("body/div").Text("inner text of div");
            });
 
            tag.ToCompacted().ShouldEqual(
                "<html><head><title>The title</title><style>the style</style></head><body><div>inner text of div</div></body></html>");
        }

The HtmlTag model has been hugely advantageous because:

It greatly simplifies Html construction. No ugly string bashing, class and attribute merging is handled internally by HtmlTag itself, and we’ve got plenty of convenience shortcuts. Compare this model to using user controls with tag soup or brute force string manipulation
Allows us to create an incremental model of “policies” to add classes and attributes to elements rather than having to make one big blob of code to create the Html (something that plagues both the MvcContrib and MVC2 designs)
The InputFor(), DisplayFor(), and LabelFor() methods all return the HtmlTag object created by the convention, and HtmlTag itself has fluent builders so that you can override or extend the Html created by the conventions on a case by case basis. We’ve gotten some great feedback and help with this feature from the MvcContrib guys, and this is their main complaint with using User Controls.
The conventional Html generation is pretty testable in basic xUnit tests without ever having to mess with WatiN or Selenium. That’s a huge plus in my book

HtmlTags is a separate library within FubuMVC that can be used independently (I use it in StoryTeller now).

Select Box Example

I’ve had this feature, and even the technical direction, in mind since last summer. I finally got to build it out for Dovetail usage because we needed to change the way we do configurable lists in our system. We keep list data in a database table where it’s easily editable and extensible (even to the point of adding cascading relationships after the fact for customizations). We need to validate certain fields against that list data, so we mark those fields like this:

        // There is no logic associated with Origin
        // other than externalized rules, so having it
        // be a string does no harm
        [Required, ValueOf(ListNames.Origin)]
        public string Origin { get; set; }

Anytime a property is decorated with the [ValueOf] attribute we know that we need to build a dropdown list to edit that field. All the information that we absolutely need to know to construct that dropdown is available on the property itself, so it made perfect sense to move to convention based Html construction instead of all the repetitive “put list data on ViewModel in Controller, transmit to View, fill options in View code” work we were doing before. We cache the list data in a static class called ValueObjectRegistry that can give us list data. Using ValueObjectRegistry and the Html Conventions gave us this:

    // Builds a <select> tag and fills in the list values 
    // for any property in our system that is "marked" as being
    // a list field
    public class ValueObjectDropdownBuilder : ElementBuilder
    {
        protected override bool matches(AccessorDef def)
        {
            return def.Accessor.HasAttribute<ValueOfAttribute>();
        }
 
        public override HtmlTag Build(ElementRequest request)
        {
            string defaultValue = request.Value<string>();
 
            if (defaultValue.IsEmpty())
            {
                request.ForListName(name =>
                {
                    ValueObject @default = ValueObjectRegistry.FindDefault(name);
                    if (@default != null) defaultValue = @default.Key;
                });
            }
 
            return new SelectTag(tag =>
            {
                request.EachValueObject(vo => tag.Option(vo.LocalizedText(), vo.Key));
                tag.SelectByValue(defaultValue);
            });
        }
 
        public static HtmlTag Build(string listName)
        {
            return new SelectTag(tag =>
            {
                ValueObjectRegistry.GetAllActive(listName).Each(x =>
                {
                    tag.Option(x.LocalizedText(), x.Key);
                });
 
                var defaultVO = ValueObjectRegistry.FindDefault(listName);
                if (defaultVO != null)
                {
                    tag.SelectByValue(defaultVO.Key);
                }
            });
        }
    }

Now that we have ValueObjectDropdownBuilder hooked into our Html conventions, all I need to do on the view is just say: “InputFor(x => x.Case.Origin)” and let the conventions handle everything.

Any questions?

Url Resolution in FubuMVC

Jeremy D. Miller — Mon, 25 Jan 2010 04:34:00 GMT

Continuing the thread from my earlier update on the “Fubu Reboot.” In an MVC web application (I think this really could apply to WebForms as well, but not to the same extent) you frequently need to resolve the Url that points to a specific subject. In our application at Dovetail, we have the route pattern: “sites/edit/{Id}” for the page that edits a “Site” object. When we place links in the views for a given “Site” object, we need to replace “{Id}” in the route with the value of the Site.Id property. In another circumstance, we have the routing pattern “query/for/{QueryName}/{QueryParam1}” for a controller action that takes in this object as its single argument:

    // The [RouteInput] attributes are *a* way to direct Fubu to 
    // make these properties by automatically scanned as part of the 
    // route pattern.
    // This should only be necessary in exception cases
    // My hope is that conventions take you 90% of the way home
    public class QueryForRequest
    {
        [RouteInput]
        public string QueryName { get; set; }
 
        [RouteInput("")]
        public string QueryParam1 { get; set; }
    }

At many, many times in our application we need to determine the Url string that points to a particular subject or occasionally to a controller action. At the same time, it would be very, very nice to keep the individual controllers and views ignorant of exactly what those Url patterns happen to be in order to make them easier to change. In FubuMVC, that’s all done with the IUrlRegistry interface that is automatically placed into your IoC container:

    // This service is injected into your IoC tool of choice as a singleton
    // to give you access to url's in a type safe way
    // Please note that this implementation in no way, shape, or form
    // locks you into a rigid url structure
    public interface IUrlRegistry
    {
        string UrlFor(object model);
        string UrlFor(object model, string category);
        string UrlFor<TController>(Expression<Action<TController>> expression);
 
        string UrlForNew<T>();
        string UrlForNew(Type entityType);
 
        // Not sure these two methods won't get axed.  They could just be extension methods in Dovetail code
        string UrlForPropertyUpdate(object model);
        string UrlForPropertyUpdate(Type type);
 
        string UrlFor(Type handlerType, MethodInfo method);
    }

In the FubuMVC model, we’re basically assuming that controller actions (Fubu actions don’t have to be on special Controller classes, btw) take in 0 or 1 objects as their single input. Taking another step, if you make the input model types unique per controller action, FubuMVC can actually use that type to “know” what controller action receives that type. Therefore, when I need the Url string that points to a particular Site object, I just pass in that Site object to the UrlRegistry.For(object) method. In the more complex case of the QueryForRequest object above, I do the exact same thing – even though QueryForRequest clearly points to a different Route. For controller actions that don’t take in any input arguments (think HomeController.Index()), you can still use UrlRegistry.UrlFor<HomeController>(x => x.Index()).

For those of you familiar with ASP.Net MVC’s model, here’s some other facts:

The lookup of a Url for a Controller Type / Method combination makes no, let me repeat that, no assumptions about the Url pattern. SomethingController.Method1() does not imply that the Url is “something/method1.” FubuMVC is literally hashing the exact Route pattern for each Controller action and looks up the exact Url at runtime.
The call to UrlFor() is completely independent of whether or not the Route in question was registered as part of the main application or as part of an Area/Slice. Unlike MVC2, when you’re determining the Url to a certain controller action or input object, you do not have to worry about where I think the MVC team thoroughly screwed up their Area support and I’d surely hope they scrap it for something better in MVC3. If you’re using the MVC framework today, I’d strongly recommend you use the bits in MvcContrib instead of MVC2 for areas.
No magic strings of any kind. Anywhere.

Lastly,

The Url resolution is static typed. That’s valuable to help prevent coding mistakes and Intellisense is also nice. Honestly, my favorite part is how much more traceable it makes the code rather than relying on strings. One quick CTRL-B shortcut takes you the the controller action behind the Url. In the case of finding the Url for an object, it’s one more bounce with CTRL-ALT-F7 (one of my favorite R# shortcuts). In real usage, we have convenience methods on our view types to get at action urls, as well as consuming the IUrlRegistry in our FormFor() and ActionUrlFor() type HtmlHelpers.

Now that we mostly rely on IUrlRegistry.For(object), IUrlRegistry is relatively easy to mock in most tests. If your tests have to rely on an Expression in IUrlRegistry.UrlFor<T>(x => Method()), I'd go for some sort of hand rolled stub.

Ok, this may be vague, so please ask question. Also, this stuff isn’t locked down, so we can actually change it to suit. And I won’t even get all paternalistic on you telling you that “UrlFor() doesn’t really mean UrlFor()” if you don’t like the API.

A Train of Thought: January 2010 Edition

Jeremy D. Miller — Sun, 24 Jan 2010 23:09:00 GMT

One of my New Year’s resolutions was to resuscitate my blog. It’s very obvious that the “conversation” has moved onto Twitter in the last couple years and my blogging output among many others has fallen off dramatically. Instead of pushing little throwaway blurbs to Twitter and forgetting all about it, I thought I’d try the old way. So here’s a bunch of throwaway blog comments…

On Entity Framework 4

I think EF4 looks worlds better than EF1 did. There, are you happy Keith? I still don’t like EF4 in comparison to you know what, but the remaining issues are much smaller than with the very seriously flawed v1 release.

At this point, from the outside looking in, it looks like something that I could use if I ever got into a shop that couldn’t use OSS tooling or if it’s a project that doesn’t really need a rich domain model. EF4 is still missing too many important features that my team depends on with NHibernate, but that gap has closed dramatically. Specifically, if EF vNext supports “rich” POCO model (EF4’s “POCO” support only does anemic domain models and that is important to my team), closes the gap with Fluent NHibernate’s conventions and auto mapping support, and has the right plugin points for interceptors and NH’s “UserType’s,” then I have a real decision to make going forward in regards to persistence.

Context Matters

Well, duh, Jeremy. I’ve been in a lot of discussions over the last decade about the “best” way to develop software. I think a lot of heated discussions could be headed off if we’d first lay down the context in which we arrived at our own opinions – and probably stop using absolute terms in any case. If you’re arguing with me that NHibernate is the wrong tool because you’re writing reporting applications, just say “I write reporting applications.” And when I say “I think NHibernate is the best tool for persisting domain models,” I should probably talk about that specific context. And definitely, when you say “Linq to Sql rocks!” you better follow that up with “for applications with simplistic domain models.”

I apparently work in a magic fairy land where my development team is free to choose any tool that we deem best for us regardless of whether or not that tool is bundled into Visual Studio or not. I also work in a very small team that’s perfectly co-located and mostly staffed with experienced developers so I can happily consider introducing new concepts. Many of you labor in a world where your choices are are circumscribed by corporate policies or the infamous centralized architecture team. The point is that what’s best for me may be radically different than it is for somebody working in a typical large corporate IT department that doesn’t allow any non-Microsoft tools. It’s to the point where I want a new rule in place for any new debates - “are we talking about the best way to do things or the best way we can do things within your specific set of constraints.” Both topics are interesting, but let’s get the ground rules out first.

You obviously need to limit your technologies and approaches to your existing context, but don’t forget that can also change your context to better fit the way you want to work. My friend Rod Paddock wrote an article a couple months back called Can a Fish Use a Bicycle? about how Agile techniques and philosophy are independent of tools and universally applicable. Rod specifically mentions some technologies that are not normally associated with Agile development. I’m not going to directly disagree with Rod, but let’s just say that I think Agile techniques work much better in some contexts than others. Agile techniques work best when the lines of communication between team members are better, so co-locate the team whenever possible and tear down the cubicle walls. TDD/BDD works best with technologies where it’s easier to isolate little bits of the code – so choose those technologies when you can. Incremental delivery works best when you’re using technologies where it’s efficient to make a series of small changes to the existing codebases. If you can, change the way you work to better utilize the tools and techniques.

Oh, and even if you do work within certain constraints, I still think it’s a good thought experiment to consider how you would solve problems if you could use anything.

My tool is better because it has feature XYZ and your tool doesn’t!

Here’s an embarrassing moment from my career. Like many, many VB6 developers I had a big inferiority complex towards the “grown up” Java developers and was studying at night to learn Java. I immediately saw that Java didn’t have an equivalent to the old ADO Recordset* object and I couldn’t imagine how you could possibly code efficiently without it. I even tried to write a Recordset equivalent for a couple nights. Sounds pretty silly, doesn’t it? I equated “productivity” with using that stupid old RecordSet object in VB6 and didn’t pay attention to the idiomatic ways that the Java guys got things done. I should have been learning (early) Hibernate or TopLink and putting time into grokking OOP instead of complaining that I couldn’t do the old data centric style of development I knew from VB in Java.

I see the same kind of shortsighted comparisons coming out over the past couple years. The Entity Framework people are saying that EF is better than NHibernate because it has a designer cooked into VS.Net. I would completely scoff at that because I don’t believe designers offer any productivity gains over the code centric way that I model and configure persistence. On the other hand, I’d say that I think NHibernate is far superior to Entity Framework because Fluent NHibernate is far more powerful than EF’s new Code Only configuration model – but the mainstream .Net world still equates productivity to visual tooling integrated into Visual Studio and wouldn’t buy that argument. Either way, there’s danger in comparing two tools that use different mechanisms to achieve the same ends. Same thing applies to the “but MVC doesn’t have controls / data binding!” line of thought.

* For you young’uns that grew up with .Net, in the VB6 days we didn’t have ORM’s or anything like the System.Collections namespace and we used the ol’ ADODB.Recordset class as a Swiss army knife in our code. It worked as well as you’re imagining it did.

What is it that they know that you don’t know?

When you see somebody clinging hard to a position that you think is absolutely nuts, and you don’t think the other person is a bozo, you have to find out two different things:

What does he know that I don’t know that leads him to that position?
What doesn’t he know that would change his seemingly crazy position?

Note to self, I should probably follow this one a little bit more.

“Same ol’Stuff, Different Name”

Last year my son and I went up to Ft Worth to visit my favorite uncle who’s spent thirty odd years working in software as a systems analyst. He said something to me that absolutely shook me to the core. Paraphrasing, he said that “the problem with getting older is it’s harder to grasp new ideas. More experienced people will tend to try to understand new ideas by their similarities to their old ideas, and by doing this they completely miss the parts that *are* different.” Think on that one for a minute.

I’ll give you a couple examples. I, and many other experienced TDD practitioners, blew off Behavior Driven Development for a few years because it really just seemed to be “Test Driven Development done well, but with ‘should’ instead of ‘assert’ in the tests.” I was wrong. I only saw the similarities to what I already knew and not the very important, but subtle, differences that make BDD shine. I don’t particularly follow BDD to the letter, but the way BDD shifted test/spec organization to “context” instead of TDD’s class/method-centric organization is hugely advantageous in practice. My development work has gone better since I finally saw the differences from TDD to BDD.

Another example. I worked with an older fellow several years ago who told me that he finally got TDD when he realized that “it was just what I’ve been doing all these years with a new, fancy name.” I don’t know what “the way he’d always done it” was, but he most certainly was not doing Test Driven Development in any way that actually helped him build software. He was not using tests to drive the design. He was putting a pretty elaborate design together first, then trying to retrofit some integration tests on at the backend. It worked as badly as it always did. He completely focused on the word “test” and missed the “driven” part that would have helped him design a better code structure.

I came behind this guy and tore my hair out trying to extend and reshape that codebase for the next year. My team’s efforts were very clearly frustrated and retarded by the poor design that could have been prevented if the previous team had understood Test Driven Development. I wrote about my experiences with this system and the very real pain points we hit as the basis for Orthogonal Code.

Why you should learn “Shiny Objects”

There’s a huge undercurrent of cynical grumpiness in software development about new things. You know what I mean, the ol’ “bah, that’s just the new shiny object the ‘cool’ uber elitist geeks are playing with.” You can’t learn everything in software and we’re terrible about self identifying way too much with the tools we do use, so it’s easy to get defensive when people start to get excited about something that you don’t use. While chasing every little fad will definitely make you tired, I think you really, really need to pay attention to the new shiny objects – especially when smart people you respect are the ones being excited. My point is, if you see a lot of people speaking very favorably about a new thing, pay attention to it because it might be something that’s advantageous to you.

I’ve largely ignored Git and distributed version control systems over the last couple years. After all, Subversion wasn’t really my pain point and I still don’t think the move from SVN to Git is fractionally as big a deal as moving from VSS or CVS to Subversion was 5 years ago. However, we started using it for FubuMVC development and now that I’ve gotten just a taste of Git’s branching workflow I can see obvious advantages.

Lots of Useful Systems have been built without your “Shiny Object!”

I see some derivation of “lots of good, useful systems have been built without TDD/SOLID/CI/BDD/DDD/XP/OOP/Mock Objects/etc!” Well, yeah. You can build a system with almost any Turing complete language, but so what? Do you still use Fortran? Using that line to blow off a new or different idea is completely unproductive. The real question is “could using this new thing help us do even better?” The most successful project I worked on did not use any of those acronyms, but I fully believe that if I had to do that little project again today I could build it much, much faster with fewer resources and much less stress. Success was good. Success with lower stress would have been much better.

Aha! Your Shiny new object is not a Silver Bullet!

“Silver Bullet” is the most overused phrase in all of software development. Ha, ha, you use TDD and you still have some bugs/design flaws, therefore TDD isn’t a silver bullet and I won’t use it! No, you’re not going to get a 10X productivity gain from any tool or technique, but a 5-10% increase in productivity is a worthwhile investment in my book. At this point, if you use the phrase “well, it’s not a Silver Bullet” you’re either being sloppy in your thinking or just very cliched.

Diversity in Our Ecosystem is Good

I’m seeing a lot of people in the .Net community moaning the fact that there are just too many darn tools out there that seem to do the same thing. Our FubuMVC project in specific has been blasted as just “Not Invented Here” syndrome gone amuck. IoC tools are everywhere and they *do* have a lot of overlap (for the record, StructureMap was released before all the others – but I mostly neglected it for years). It’s an absurd argument. Diversity is good. I’ve taken features from AutoFac and Ninject before and even one from Unity a couple years back. Windsor is adding a pretty significant diagnostics feature inspired by StructureMap. Diversity is a good thing. More people innovating means more innovation. Bad ideas get junked when better ones appear. Not every system is exactly the same. Different approaches to the same old problems can frequently lead to new opportunities.

Why don’t you just jump ship to some other platform?

I hear this one all the time and it’s a good question in a way. I like and/or use very, very little of the tooling from Microsoft beyond the CLR, C#, and the bare bones of Visual Studio. I’m unapologetically a “Fowlbot” (arguably “ALT.NET” is simply the moniker for people who share roughly that same set of preferences and happen to work with .Net) and I have a certain aesthetic to software development that’s completely different than the prevailing philosophy of mainstream .Net. I started this section, but I don’t particularly have a great answer other than inertia. Switching to Java isn’t an answer (coding in Xml) and I haven’t particularly had opportunities to move to Ruby or Python. I’m very entrenched with OSS development in .Net and our customers really want tooling in .Net as opposed to Ruby. I do think there’s been a lot of improvement in the .Net space over the past three years that’s even unique to .Net. Our OSS tools are improving dramatically (finally) and it’s kinda fun to be a part of that.

Okay, how about this one: I’m very happy with what I’m doing at the moment. Let’s call that good enough and move on…

Let’s shelve WebForms v. MVC for now

I think the WebForms vs. MVC (paradigm here, not ASP.Net MVC) argument has exceeded its usefulness. I think there’s plenty of misconceptions from the WebForms world towards MVC that could be dispelled (how to do screen synchronization without databound controls, why it’s more than just the testability concern where MVC shines), but all of the real arguments both pro and con are out there for anybody who cares enough to use Google to find them. We’re at the point where I think everything’s been said and written. I really don’t see people with entrenched positions changing their mind at this point, so can we put this argument on the backburner permanently and just agree to disagree? Let’s put the energy we’re wasting arguing with the pro-WebForms folks and put it into making a better MVC ecosystem for .Net. Besides, there are so very few examples out there on the web that even show how MVC can be productive. Go fill that gap and leave the WebForms people alone for now.

“Lazy loading can destroy performance”

Saw this statement while doing research for this post from somebody in the pro-EF camp who was apologizing for EF1’s insane strategy for “lazy loading.” Guess what? Sometimes not doing lazy loading can destroy performance. Case by case basis, folks. To all you EF folks, you’ve just entered a brave new world. You might want to learn from the experiences of the previous ORM tools – and understanding when and where to use lazy or eager fetching is key.

If your API is confusing, change it!

Jeremy D. Miller — Thu, 21 Jan 2010 14:36:00 GMT

http://ayende.com/Blog/archive/2010/01/21/when-the-design-violates-the-principle-of-least-surprise-you.aspx

The MVC team really needs to go back and iterate on their validation design and rethink it -- and frankly, they need to have the courage to challenge their approach and maybe even to break backwards compatibility with the preview/CTP/beta/whatever they are's if that's what it takes to make a better solution.

As an API designer, if your users are having consistent trouble with using part of your API, then your API is wrong. Don't try to beat it with just documentation or "user education." Go. Change. Your. API. To something that does work and makes your support queue slow down.

The dumbest thing I ever did in StructureMap was something called the "StructureMapConfiguration" static class where everything had to be done in a certain, non-obvious order. The best thing I ever did in StructureMap was to deprecate, replace it with a better API, it then kill it. I get worlds of support questions, but at least *that* issue went away.

How Dovetail is using TopShelf

Jeremy D. Miller — Wed, 20 Jan 2010 21:40:00 GMT

If you haven't looked at the TopShelf project from my buddy Dru Sellers for quickly standing up windows services, you might want to. My coworker Kevin Miller has a couple blog posts up about how he's using TopShelf:

Slide Deck from Advanced Presentation Patterns at CodeMash

Jeremy D. Miller — Thu, 14 Jan 2010 11:54:00 GMT

Since I had the request for this, the slide deck that I used yesterday at CodeMash in my marathon talk on Advanced Presentation Patterns is here. There's more links, but I'd first like to thank everybody who attended yesterday and especially those masochists of you who stuck out all four hours. It was a great crowd, lots of good questions that made my job much easier.

As I told many, many people who asked yesterday, I'm still writing the book, I'm not doing very well, but maybe the CodeMash session yesterday gets me back to usefulness.

Now, links!

My book Wiki for Presentation Patterns (more content coming soon)

Build Your Own CAB -- the original source for much of this work

Prism -- Microsoft P&P's guidance on "composite" applications

Caliburn -- Open Source Framework for WPF clients

A Brief Tour of Responsibility Driven Design -- Read this if you design software or want to. Seriously.

Patterns in Practice: A Retrospective

Jeremy D. Miller — Mon, 11 Jan 2010 12:43:00 GMT

For most of the past two years I’ve written the “Patterns in Practice” column in MSDN magazine. The January issue contained my last article and I thought it’d be good to write a little retrospective on the series. It’s probably been a good opportunity for me and it seemed to be mostly well received (it’s not as much fun as blogging because you just don’t get as much immediate feedback, good or bad). CodeBetter has always been frequented by a self-selected group (you can’t call it an echo chamber because of the way we argue) of developers who were already learning about Agile practices and the old software design concepts passed down to us from the “Gang of Four,” the Smalltalk world, and Uncle Bob’s SOLID writings from the 90’s. The MSDN column has been nice in that it allowed me to write about some of these design concepts for a more mainstream audience who might not have as much exposure to these ideas. Whether that worked or not, or made the slightest bit of impact, who knows? It did pay for the down payment on my new car last year (and a root canal), so it’s all good to me;)

Some folks are going to argue that “software quality” doesn’t matter* because it’s really all about whether or not you’re building the right system with the right business plan. Let’s assume right now that you’ve got the right business plan, good requirements, and even decent collaboration from your business partners (and manna streaming down from the ceilings whenever you get hungry at work because that’s just as likely as the preceding list). You’ve still got to execute the project – and you probably aren’t going to build it all in one quick pass. You’re going to build it incrementally. You’re going to make mistakes, fix mistakes, and iterate (even if you’re working a theoretical waterfall). Bad designs and bad code will slow your team down and delay your all important time to market. Let’s be realistic here, you never have the perfect requirements. Your business partners with the vision will need to iterate and refine their vision, and the entire product team is better off if the development team is technically able to efficiently deliver features that weren’t even imagined at project inception. You can succeed with bad code, but all things being equal, I think you maximize your business’s chances of succeeding by taking software quality very seriously.

First off, let’s make the assumption that your software design really does matter. It matters not because of ALT.NET or Software Craftmanship or Design Pattern purity, but because “good” code structures help development teams be productive now and over time while “bad” code structures bind a team up with “code viscosity.” Let me be very clear here, I’m defining software quality as the structural qualities of code structure that enable a team to be productive within that codebase for an extended amount of time.

I’ve been studying software design seriously for over a decade and building software for longer than that. I’ve seen the exact same team founder in one codebase and generally succeed in another codebase. I’ve worked in some codebases that felt like I was as light as a feather and functionality flowed into the system as fast as I could type. I’ve worked in other systems where I wanted to tear my hair out because of how much work it took to do even simple seeming things. Why were some codebases good and others pure frustration? Offhand, I’ll give you five qualities or themes that separated the good codebases from the bad (not an exhaustive list of course):

Orthogonality. It’s a fancy word that just means being able to do or change or exercise one thing at a time. It also means being able to understand or learn about one thing at a time in a system.
Reversibility. Technical or requirement decisions don’t have to be locked in stone.
Feedback. I think the best way to be successful building software is to assume that everything you do is wrong. We need rapid feedback cycles to find and correct our inevitable mistakes.
Iteration. Your first idea is never your best idea. Your business partners will need to refine their vision. You need to be able to respond to both negative and positive feedback.
Minimal Duplication. Less duplication means easier change, less chance of making silly errors, and quicker iteration to get to the best product

These are the main themes in Patterns in Practice that I think are important. Many of the design concepts like Design Patterns, the SOLID Principles, the GRASP Patterns, Code Smells, or the tools in Responsibility Driven Design are nothing but heuristics to help guide you to designs that exhibit the qualities I enumerated above or detect the absence of these qualities.

If you ask me what the essence of a good software

The Open Closed Principle. The “O” in SOLID. Think about this question for a minute, what’s generally more productive for your team, writing all new code or breaking into the middle of existing code to make changes? Which is more risky in terms of bugs and introducing cute new regression bugs? Do you like having to trace through existing code to find the place to break in to change it, or starting from a fresh slate? If you answered my loaded questions correctly, you sir or madam, are interested in learning about the Open Closed Principle as a design goal. If you think the OCP just means having interfaces and plugin points for everything, then you need to read this article because that’s not the point.
Object Role Stereotypes. I’ve said many times that I think Responsibility Driven Design is one of the most valuable, yet overlooked design techniques you can possibly add to your design toolbox. In the article on the Open Closed Principle I also mentioned the all important “Single Responsibility Principle” that more or less states that a class should have one and only one reason to change. Great, but what’s a responsibility? Object Role Stereotypes are a fantastic mental tool to help you understand and delineate the responsibilities within a design problem. The research that I did in writing this article led to some significant architectural changes to StructureMap that opened up a lot of opportunities for extending and improving StructureMap.
Cohesion And Coupling. An explanation of what Orthogonality is and the practical impact of it on your code. If you’re starting from ground zero in software design, I think the first two concepts you need to understand are cohesion and coupling. Arguably, almost every design concept and tool in the whole Patterns in Practice series is about increasing cohesion and minimizing harmful coupling in your code. It’s very important that you understand the impact of coupling in your code. Know when it’s harmful coupling you should eliminate or relatively harmless coupling that would do more harm than good to abstract away. A lot of harm is done in software development today due to zealous attempts to reduce coupling.
Design For Testability. It’s all about rapid feedback cycles and the ability to iterate. How quickly can you go from doing something in your code to knowing that something was done correctly so you can turn your back on it? It’s arguably just another way to think through the orthogonality of your architecture.
Convention Over Configuration. A design concept made popular in Ruby on Rails but increasingly important in .Net circles. It’s a way to shrink your codebase down and to eliminate unnecessary duplication of “facts” in your system. Makes iteration cheaper.
Persistence Patterns. I wasn’t particularly inspired by this topic, but hey, it’s valuable stuff to know if you’re going to use ORM’s. NHibernate or Entity Framework users really need to understand these concepts to avoid some ugly pitfalls. At a minimum, make sure you understand what lazy loading and virtual proxies are all about. Besides, it’s nice to understand what’s going on under the covers. Once in a while you may want to use these patterns in your own code.
The Unit Of Work Pattern And Persistence Ignorance. I continued the discussion on Persistence Patterns and tried to explain what and why “Persistence Ignorance” is important and the real impact of persistence framework on your development efforts. Judging from the recent blog posts from the Entity Framework on their new EF4 POCO implementation, they probably didn’t do more than skim this issue. Okay, maybe that’s not fair, but if you read this article you might understand why I don’t think Entity Framework has really arrived as a viable option for me despite the dramatic improvements from EF1 to EF4.
Incremental Delivery Through Continuous Design. I can’t believe Howard let me get away with this one because I was specifically not to proselytize Agile development. I tried to discuss the business value of being able to deliver incrementally and flexibly, then discussed the specific design issues supporting incremental delivery.
Functional Programming for Everyday .NET Developers. I learned a lot from writing this one. I think that adding some functional programming techniques to my day to day coding has been very beneficial to my efforts. In a lot of ways, FP usage can help reduce duplication by giving you a more fine grained mechanism for composition than OOP does and passing first class functions around often increases encapsulation of classes. Continuation Passing Style is close to a daily technique for me now.
Internal Domain Specific Languages. Don’t assume that DSL means Oslo or whatever Whitehorse ended up becoming. If you are interested in exploring the usage of Fluent Interfaces in your own architecture without a meltdown, here’s some design patterns to help you get started. I think I could easily argue that articles 1-8 contained some bit of material that could help the average software team. This one was just what *I* wanted to write about, so there.

The Future

I’m thoroughly burnt out on this for now and I’m distressingly behind on my book and mired in OSS project obligations. I’m not touching it again for at least 6-9 months. If I do start it up again, I think I want to focus on really basic concepts of OOP. It’s my belief from 12+ years of development experience that the mass majority of developers, even “experienced” developers, cannot use object oriented programming or functional programming to their advantage. I betcha that most .Net developers can give me a textbook glossary of OO terms like inheritance and polymorphism, but most of them probably don’t use these concepts in a way that helps them get work done. It’s also my belief that most developers just never move beyond brute force procedural programming techniques. If there ever is a next article, I’m tackling the “Anti-If” campaign with some basic Design Pattern usages to streamline your code by eliminating if/then branching code.

* Okay, I think you could argue with me that code quality doesn’t matter on small projects or projects that would be easier to rewrite later when and if they do need to change. The only problem with that statement is that I’ve seen truly awful messes happen when those “throwaway” systems uncontrollably grew over time into big monsters. My advice is to strive to reach a level of “unconscious competence” to where you naturally write high quality code and designs without going out of your way.

"Hello, World" in FubuMVC

Jeremy D. Miller — Fri, 08 Jan 2010 15:57:00 GMT

It's raw and unformed (Fubu, not the blog post), but here's the first "Hello, World" sample for the Fubu Reboot from Dovetail's very own Tim Tyrell.

One of the things the Fubu team is definitely talking about is some app starter kits ala Rails "rails [project name] create" that lays down a basic structure. Another "getting started" feature that doesn't exist is a set of OOTB conventions so you can get going with:

public class MyFubuRegistry : FubuRegistry

{

public MyFubuRegistry()

{

UseBasicConventions();

}

Call for FubuMVC Contributors

Jeremy D. Miller — Thu, 07 Jan 2010 16:39:00 GMT

Chad just put up a post on how you can get involved with the FubuMVC project. We've got the website and Wiki going and the mailing list, but we're not hugely organized yet. At this point I feel like there's enough working to say that the project has a lot of promise down the road.

Writing Internal DSL's in MSDN

Jeremy D. Miller — Thu, 07 Jan 2010 03:37:00 GMT

My latest and last (for the moment anyway) article for MSDN just went up today. This time I tackled the design patterns and strategies for building Internal Domain Specific Languages. At least in the .Net space, the mainstream folks seem to hear "DSL" and only think about big efforts to create business facing languages with external DSL tools like Oslo -- probably because that's been their first exposure to the idea of DSL's. That stuff is valuable in places, but don't overlook the value in creating small mini-languages inside your everyday programming language for developer related tasks.

Mini-language or Internal DSL's may be a misnomer in this case. All you're really attempting to do is to create a more usable form of API that ends up being more readable and quicker to specify than the standard "push button" API. You see more and more examples of these little internal DSL's in open source tools like Fluent NHibernate, StructureMap, Windsor, and AutoMapper. Now even Microsoft is dabbling in mini-languages with the "Code Only" configuration option in Entity Framework 4 (which at a glance seems determined to replicate every single mistake that Fluent NHibernate made early on).

I'd hoped to include much more writing on this topic in my blog, but I'm a bit burnt out at the moment. At some point in the next month I'd like to write up my lessons learned with the StructureMap Registry DSL and how it's evolved over the past three years to improve its usability, the problems users have had, dumping the "English like" syntax in favor of something terser, and how I build the DSL stuff. Also, I'd like to explain the "Object Scoping" pattern that got cut from this article. Lastly, I've got a little Internal DSL we use at Dovetail for user action routing that I think would make a good, approachable example. I'm on a bit of a New Year's Resolution to spit out more (any) blog content.

Lastly, I'd like to write up a retrospective on the whole Patterns in Practice column I've been writing for the past two years.

The pattern names for the article and much, much more information were drawn from Martin Fowler's online draft for his DSL book at http://martinfowler.com/dslwip/. I'd heartily recommend perusing the site if you're interested in DSL development at all.