First off if you are new to this and would like to learn more, I recommend you start with one or more of the following books:

They will get you started with Domain Driven Design and messaging. For the most part these books will get you up to speed so you can talk the talk. Once you’ve got a solid understanding of the vocabulary, you be were I think a lot of us are. How do we apply Eventing/Messaging to our domain models?

So here are a few links to help out:

First off is Mark Nijhof’s excellent series of posts that lead to his Fohjin Example Application. If your looking for public C# code to learn from this is it.

Second is Erik Rozendaal who wrote a lottery example to help train his coworkers. Erik’s code is written in Java.

Another Java implementation is the Axon Framework. I’ve not had a chance to check this one out yet. But the guys building it blog over at Girdshore.

Finally there’s Jérémie Chassaing blog and although he doesn’t have code to download his series of posts on cqrs has lots of code examples that he discusses.

Hopefully this is helpful. If you know of other code examples please let me know in the comments.

     My first child arrived at the end of November to change my life and steal my heart. And although taking care of her and mom occupies a lot of my time. I still want to make time to get more posts up this year.

     So thanks for stopping by and I hope I have something to share this year that is helpful, entertaining and at least a bit educational.

So when I started reading about messaging and Command Query Separation I became interested in how they could be implemented in an ASP.NET MVC style application. The biggest issue I faced was the fact that messaging is an asynchronous environment. You publish your message and can go off and do other things while waiting for a response. But in a controller action your command message seemed to be the summation of action call. For instance say you wanted to add an item to a shopping cart. You create an AddItemToCartCommand and publish it to the message bus. Now you need to wait for the response message that the item was added to the cart, or otherwise failed to be added (say the item was discontinued).  With most of the service bus implementations handling this situation seemed overly complex. So I coded up a spike to see how I could address the problem while trying to keep things simple and discoverable.  What is displayed below is working code and I will publish the implementation details in a follow up post. For now I want to focus on the syntax of how its used.

using System;

using iLude.Messaging.Core;

using iLude.Messaging.Engine;

using iLude.Messaging.Tests.Support.Messages;

using NUnit.Framework;

using NUnit.Framework.SyntaxHelpers;

namespace iLude.Messaging.Tests {

    [TestFixture]

    public class ExampleTests {

        private IServiceBus bus;

        [SetUp]

        public void Setup() {

            bus = new ServiceBus();

        }

        [Test]

        public void When_request_is_sent_should_receive_response() {

            var messageReceived = false;

            var timeoutCalled = false;

            bus.Subscribe(this).To<RequestMessage>().HandledBy((x, message) => x.ProcessRequest(message));

            using(IMessagingSession session = bus.GetSession()) {

                session.Publish( new RequestMessage { Body = "Hello World" } )

                    .WaitFor<ResponseMessage>(message => {

                        messageReceived = true;

                    }).OrTimeoutAfter(1.Seconds(), () => {

                        timeoutCalled = true;

                    });

            }

            Assert.That(messageReceived, Is.True);

            Assert.That(timeoutCalled, Is.False);

        }

        private void ProcessRequest(RequestMessage message) {

            bus.Publish(new ResponseMessage(message.ID));

        }

    }

}

First off lets look at the setup of a message handler.

bus.Subscribe(this).To<RequestMessage>().HandledBy((x, message) => x.ProcessRequest(message));

For this I could have gone the traditional interface route, but I decided against it for a number of reasons. Chief among those reason is that it limits future convention of configuration possibilities. Instead I opted to use a lambda function to specify the method I wished to be called to handle the message. In this case I also choose to pass in a specific instance that will be notified, But a generic override is also available so that only a class type need specified. The bus will then use an IOC container to fetch an instance of that type to handle the published message.

In this case the handling method is pretty simple.

private void ProcessRequest(RequestMessage message) {

    bus.Publish(new ResponseMessage(message.ID));

}

We receive a copy of the published message and sent out a response. The ResponseMessage is passed the original message id, which it will use as the correlative ID.

Now we can get to the meat and potatoes:

using(IMessagingSession session = bus.GetSession()) {

    session.Publish( new RequestMessage { Body = "Hello World" } )

        .WaitFor<ResponseMessage>(message => {

            messageReceived = true;

        }).OrTimeoutAfter(1.Seconds(), () => {

            timeoutCalled = true;

        });

}

First we create a new MessagingSession that is disposable. This session is our Unit of Work. I use it to provide synchronization around this asynchronous operation. The operation is to publish a request message and wait for a response. If we receive one we process the anonymous function which sets messageReceived = true. Otherwise if we have not gotten a response after 1 second we should set timeoutCalled = true.  The publish method and its child methods return nearly instantly and execution in the current thread continues to the end of the using statement.

This is where the magic happens, in the session’s dispose method.

public void Dispose() {

    bus.Publish(request);

    if(resetEvent.WaitOne(timeout)) {

        action.DynamicInvoke(response);

    }

    else if(timeoutAction != null) {

        timeoutAction.DynamicInvoke();

    }

}

At this point the message has not yet been published by the session. When the session’s Dispose method is called it will publish the message to the bus and then blocks the thread using a ManualResetEvent to wait for a response. The session does this by subscribing to the message bus for the requested response message type. If it received a response message with the proper correlative ID it sets the ManualResetEvent. This unblocks the dispose method to invoke the anonymous function. Otherwise if the timeout expires the specified timeout function is called.

I would be very interested in hearing your thoughts on this idea. As I stated this is only a spike and I have not pushed it much beyond this stage. I am also very new to messaging and as such may be doing more than my fair share of bad practices.  So all feedback is welcome.

So not to long ago I set out to find the simplest example of a cross browser dropdown menu that I could find. I found many examples but none were exactly right for my needs. So I started playing around with some of the ideas and here’s what I came up with.

First things first. There are four major browsers on the market: IE, Firefox, Safari and Google Chrome. The last three browsers will just work but for that first one much gnashing of teeth and swearing can be directed its way. So to get everyone to play nicely we start with a strict doctype like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Strict XHTML will work as well. Now lets look at some HTML for the menu:

<div class="menu">

    <span>

        <a href="#">Lorem</a>

    </span>

    <span>

        <a href="#">Ipsum</a>

        <div>

            <a href="#">Dolor sit amet</a>

            <a href="#">Consectetur adipisicing</a>

            <a href="#">Eiusmod tempor</a>

        </div>

    </span>

    <span>

        <a href="#">Officia</a>

        <div>

            <a href="#">Nemo enim ipsam</a>

            <a href="#">Dolore magnam</a>

            <a href="#">Suscipit laboriosam</a>

        </div>

    </span>

</div>

An important note: DO NOT PUT LINE RETURNS AND INDENTS INSIDE THE ANCHOR TAGS! Once again our favorite browser IE will not function correctly if you do this. So keep your anchor tags all on one line.

Now here is the fun part for all of the latest browsers we only need some simple CSS to make the menu work. Lets take a look:

.menu span {

    float:left;

    margin-right:10px;

    position: relative;

    z-index: 100;

}

.menu a {

    text-decoration: none;

    display: block;

}

.menu span:hover div, .menu span div:hover {

    display: block;

}

.menu span div {

    border: 1px solid black;

    padding: 5px;

    background-color: white;

    display: none;

    position: absolute;

    white-space: nowrap;

}

Once you get a sample page put together with this play around with the margins, padding, borders and colors to get a feel for their effects on this basic look and feel. The floats, display and position attributes are the important ones that make this menu work.

Inevitably someone will say to you “Hey this doesn’t work in my browser!”. And your response  should be “Upgrade to a more recent version of IE before you are infected with anymore viruses and trojans you luddite!” But if that fails because of corporate policy or other brain dead arguments and you are forced to deal with the reality that some people still drive Ford Pintos there is a solution. JQuery to the rescue!

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>

<script type="text/javascript">

    $(document).ready(function(){

        if($.browser.msie && $.browser.version <= 6.0) {

            $(".menu span").hover(

                function() {

                    $(this).children("div").attr("style", "display: block");

                },

                function() {

                    $(this).children("div").attr("style", "");

                }

            )

        }

     });

</script>

Basically we are checking if the browser is IE 6 and if so we add the display:block to the child divs of the any span tags. Exactly like the same thing the CSS does. But since IE 6 doesn’t allow :hover on anything but anchor tags (and even that seems flaky to me), we do it this way.

I’ll leave you with the completed page all together for your copying and pasting pleasure!

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>

    <title></title>

    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>

    <script type="text/javascript">

        $(document).ready(function(){

            if($.browser.msie && $.browser.version <= 6.0) {

                $(".menu span").hover(

                    function() {

                        $(this).children("div").attr("style", "display: block");

                    },

                    function() {

                        $(this).children("div").attr("style", "");

                    }

                )

            }

         });

    </script>

    <style>

    .menu span {

        float:left;

        margin-right:10px;

        position: relative;

        z-index: 100;

    }

    .menu a {

        text-decoration: none;

        display: block;

    }

    .menu span:hover div, .menu span div:hover {

        display: block;

    }

    .menu span div {

        border: 1px solid black;

        padding: 5px;

        background-color: white;

        display: none;

        position: absolute;

        white-space: nowrap;

    }

    </style>

</head>

<body>

<div class="menu">

    <span>

        <a href="#">Lorem</a>

    </span>

    <span>

        <a href="#">Ipsum</a>

        <div>

            <a href="#">Dolor sit amet</a>

            <a href="#">Consectetur adipisicing</a>

            <a href="#">Eiusmod tempor</a>

        </div>

    </span>

    <span>

        <a href="#">Officia</a>

        <div>

            <a href="#">Nemo enim ipsam</a>

            <a href="#">Dolore magnam</a>

            <a href="#">Suscipit laboriosam</a>

        </div>

    </span>

</div>

</body>

</html>

Suggestions, comments and questions are always welcome…

As I stated, my first dealings with Ayende were back around 2003 or so when the company I worked for tasked me with developing a new webmail program. The previous version had been written in java and functioned but lacked many features that our customers were asking for. At the time the company had the grand idea of the “standard language”, and following the “no one ever got fired for buying Microsoft” logic mandated that C# was to be that language.

One of the major hurdles I ran into was the lack of a performant pop3/mime library. Many were tried but most relied on regular expressions to parse the messages and this would bring the server to its knees if more than one or two users attempted to open their mailbox at the same time. So off I went to write a mime parser. 

At the same time I was also submitting patches to Monorail to get the NVelocity engine working on mono. Hammett gladly accepted those patched and even gave me commit privileges. But both he and Ayende endlessly encouraged me to create tests for the functionality I was patching. Sadly I knew nothing of how to write a unit test or even how to run one if I were to write one.  And so patches were created and applied and mime parsers were written and used all without a single unit test.

At first my world was a fairly happy place, but then came the spammers. One of a spammers favorite tricks is to mess with the headers of an email in an attempt to create a header that is read by the client but which can slip past spam detection software. Having a homegrown mime parser deal with these types of emails can quickly takeover ones life. And since the parser had been written fairly quickly and I’m a self taught programmer the parser had, shall we say, a significant amount of technical debt!

I was about to take the road so often traveled and start over from scratch on a new mime parser. But this time I decided that after reading up on TDD I would start this attempt writing tests. So I downloaded Nunit and TestDriven.Net and started coding.

At first it was awkward. But very soon I fell into a rhythm and within a few hours had a basic working parser and a fair number of tests to go with it. I created tests that called the new parser in the same way the existing code called the old one.  Then I began working with the library of spam messages I had build up for debugging the current engine, creating a unit test for each message. I would compare the output of my parser against the output of another known parser to assure that I was getting the correct data into the correct places in my object model. Soon I was even parsing messages that several of the known parser would fail on. And as new messages came in that failed with the old parser I was able in a matter of minutes to create a new unit test for that message on the new parser.

Sometimes a message would cause the tests to fail, and so I would make changes and get the tests to pass. Then I would rerun the entire test suite and find that the changes I’d made to would cause an old message to be parsed incorrectly. And so further changes were made until all the tests passed. And it was at one of those times that I became a TDD believer. I realized the incredible value that TDD brought to my development.  I had created a zero friction environment to code this parser in.

But there was more to it than just the tests. The code I was writing was cleaner and had far better separation of concerns. The changes I needed to make were easier to make. The other principles that Ayende and other members of the Castle Project were talking about, like SRP and IOC, were much easier to implement and the value of those patterns were much clearer.  This one project by no means made me an expert, but it certainly showed me that there was more value to these principles than I had previously thought. And that encouraged me to continue learning about those principles. That learning has continued to this day I firmly believe that I am a much better programmer for it.

In my next post I’ll try and address why any of this matters and how Jeff’s response is shortsighted at least and incredibly destructive at worst.

So today when I opened my Google Reader I was confronted with Jeff Attwood’s latest post where discusses technical debt and he states:

After six solid months working on the Stack Overflow codebase … We have to stop working on new features for a while and pay down some of our technical debt.

What I hear is that he and his team must stop delivering software and start thinking about code quality.  His reasons for needing to do this are:

…that accumulated technical debt becomes a major disincentive to work on a project. It’s a collection of small but annoying things that you have to deal with every time you sit down to write code. But it’s exactly these small annoyances, this sand grinding away in the gears of your workday, that eventually causes you to stop enjoying the project.

Back in the day I was granted commit rights to the Castle Project which is where I came to know Oren “Ayende” Eini. I’ve never heard him say it but its my belief that he eats, lives and breaths the SOLID principles ( I didn’t say sleeps them, because everyone knows Oren doesn’t sleep! ).  He shares the prize with Hammett for introducing me to TDD and starting me on the long path to SOLID Zen.  Ayende sums up the solution to Jeff’s problem here:

If you have an environment that has friction in it, there is an incentive for the developers to subvert the design in order to produce a quick fix or hack a solution to solve a problem. Creating a zero friction environment will produce a system where there is no incentive to corrupt the design, the easiest thing to do is the right thing to do.

By reducing the friction in the environment, you increase the system maintainability

TDD and SOLID are not “bureaucratic programming”. They are refined wisdom of many master craftsmen to help reduce friction and keep you focused on that pesky “revenue generation” code.

public static bool Contains<T>(this IEnumerable<T> enumerator, Predicate<T> predicate)

{

    if(enumerator == null)

        throw new ArgumentNullException("enumerator");

    if(predicate == null)

        throw new ArgumentNullException("predicate");  

    foreach(T item in enumerator)

    {

        if(predicate(item))

            return true;

    }

    return false;

}

This allows you to do this:

if(tags.Contains(x => x.Name == "Coolest Blog Ever")) {

    // we found a matching tag

}

else {

    // no tag found  

}

Nothing special I know, but hopefully it helps someone out.

The Controls collection cannot be modified because the control contains code blocks (i.e. <% … %>).

Looking around the closest reason I can find for why the head tag has the runat=”server” attribute is a comment from Phil to this answer on StackOverflow.com where he states:

the head runat="server" (aka HeaderControl) makes it easy to reference .css and .js files in the head section. It will rewrite the Href value.

Ok valid point, but I’m not sure its needed just to do that.

First, outside of ContentPlaceHolder tags in the masterpage anywhere else I see runat=”server” it’s considered code smell. There are just far too many ways that server/user controls can mess with the final rendered page by adding viewstate, mangled id’s and a host other issues. There is too much black magic going on for my tastes. Better to use Html helper methods to do the magic and display that methods results using <%= %> code blocks. This way we know that the method can only output its results in a specific location in the view and if we find an issue with that output we know what code is responsible for it. Controls have access to the entire page and can do things that I may or may not want them to do and those changes can be very difficult to trace back to the code responsible.  ( Yes I know there are ways to get access to the Page instance from helpers but I’ve got a solution to that too: DON’T DO IT!

So what we need are some helpers for linking in our javascript and stylesheets. The MvcContrib project has helpers to do this but the method names are inconsistent and I wanted some more control over the conventions used.

   1: public static class IncludeExtensions {

   2:     public static string IncludeCSS(this HtmlHelper html, string cssFile)

   3:     {

   4:         string cssPath = cssFile.Contains("~") ? cssFile : ("~/content/css/" + cssFile);

   5:         string url = html.ResolveUrl(cssPath);

   6:         return string.Format("<link type=\"text/css\" rel=\"stylesheet\" href=\"{0}\" />\n", url);

   7:     }

   8:  

   9:     public static string IncludeJS(this HtmlHelper html, string jsFile)

  10:     {

  11:         string jsPath = jsFile.Contains("~") ? jsFile : ("~/content/js/" + jsFile);

  12:         string url = html.ResolveUrl(jsPath);

  13:         return string.Format("<script type=\"text/javascript\" src=\"{0}\" ></script>\n", url);

  14:     }

  15:  

  16:     public static string ResolveUrl(this HtmlHelper html, string relativeUrl)

  17:     {

  18:         if(relativeUrl == null) { return null; }

  19:         if(!relativeUrl.StartsWith("~")) { return relativeUrl; }

  20:         return (html.ViewContext.HttpContext.Request.ApplicationPath + relativeUrl.Substring(1)).Replace("//", "/");

  21:     }

  22: }

and now I can have the following in my site.master file:

   1: <head>

   2:     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

   3:     <%= Html.IncludeCSS("site.css") %>

   4:     <%= Html.IncludeJS("jquery-1.2.6.js") %>

   5:     <asp:ContentPlaceHolder ID="HeaderContent" runat="server" />

   6: </head>

Here is the head section of my login view:

   1: <asp:Content ContentPlaceHolderID="HeaderContent" runat="server">

   2:     <title>Login</title>

   3:     <script type="text/javascript">

   4:         $(document).ready(function() {

   5:             $("input#username").focus();

   6:         });

   7:     </script>

   8: </asp:Content>

No runat attributes, mystery errors or work arounds. Just clean easy to follow markup.

Please let me know what you think.

Now I may have a bit of a unique view on the subject as I’m a developer and my brother is an Mechanical Engineer for Conway & Owen.  So please bear with me. Mike’s post asks if a plumber would rip out his work if they found a better way after they already started. The fact that he mentions a plumber, I would speculate, causes most people to think of plumbing a single family home. This type of plumbing is the  software development equivalent of FizzBuzz. Which is to say that it takes some skill and understanding to do it correctly but overall its not a difficult problem.

Now compare plumbing a single family home to plumbing a modern office high rise, cruise ship or nuclear submarine and I think you are starting to compare apples to apples when comparing them to designing today’s business systems. Where your home plumbing contractor can walk in to most homes and plumb them with little planning, weeks and months of planning and design go into figuring out how to hook up the mechanical systems of such buildings and vessels.  And like software engineers sometimes mechanical engineers have to throw away large sections of your CADD designs when they see a better way.  But like us they have engineering principles similar to our  SOLID Principles that guide them and allow them to strip away the minimum possible to implement their changes.  But even after things are built you sometimes need to make changes and upgrades. I’m reminded of a television show I watched not to long ago about one of the passenger cruise lines performing and engine replacement on one of their ships.  They literally had to cut a hole in the side of the ship and remove all the piping and bulkheads between the engine and the outside so that they could get the old diesel engine out and the new, more efficient one back into the same place.  The new engine was smaller and had different requirements for intakes and exhaust and the amount of work to remove all that piping and then reinstall it and make it work with the new engine was impressive to say the least. Now compare that with having to do something similar to a complex software system. The problems are not always equivalent but I would have to say they seem like that would be very similar.  

Anyway to pose and answer to Mike’s question I think that mechanical engineers work in ways that are very similar to they way we as software engineers work. Sometimes they throw it all out and start over too.

• Lucene.Net – Text Analysis
• Lucene.Net – Custom Synonym Analyzer

In those articles Andrew provides a nice tool to test lucene’s analyzers. The tool loads the analyzers from the lucene dll and allows you to select from the provided analyzers and see how they process entered text. I’ve made a few minor updates to the code so that it can load analyzers from dll’s selected at runtime, so that you can test them and see their output. You can get the updated project source code here:

• AnalyzerViewer.zip