This is how developers might punish your database…

2015-09-08 by mookid8000 Leave a comment

…or “Twisted use cases for SQL Server”, as I also like to call it 🙂

It’s the title of a presentation that I’m doing at this year’s SQL Saturday in Copenhagen on the 19th of September.

The presentation is about how development teams need not despair when faced with the classical and almost ubiquitous constraint that data must be stored in SQL Server…

I’ve created the following state diagram to illustrate what the presentation is about:

sql-server-yes-no

When they said to put data in SQl Server, did they tell you HOW to put data in SQL Server? They didn’t? Cool… let’s talk about that 🙂

Topshelf and IoC containers

2014-02-27 by mookid8000 Leave a comment

To top off my previous post with an example on how almost any kind of application can be hosted as a Windows Service, I’ll show an example on how Topshelf can be used to host an IoC container.

As most developers probably know, an IoC container functions as a logical application container of sorts, helping with creating stuff when stuff needs to be created, and disposing stuff when stuff needs to be disposed, keeping whatever needs to be kept alive alive for the entire duration of the application lifetime.

This way, when we have this Topshelf-IoC-container framework in place, we can use it to activate all kinds of applications.

I’ll show how it’s done with Castle Windsor, but I think it should be fairly easy to port this solution to any other IoC container.

Create a service class that holds the container

First, let’s create a class that implements the Start/ Stop methods of ServiceControl – this class will initialize its Windsor container when it starts, and dispose it when it stops.

I’ve added some logging for good measure – when you’re a backend kind of guy, you come to appreciate a systematic and consistent approach towards logging in your Windows services, and I’m no exception.

class RobotService : ServiceControl
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    readonly WindsorContainer _container = new WindsorContainer();

    public bool Start(HostControl hostControl)
    {
        try
        {
            Log.Info("Initializing container");

            _container.Install(FromAssembly.This());

            return true;
        }
        catch (Exception exception)
        {
            Log.Error("An error occurred during intialization: {0}", exception);

            return false;
        }
    }

    public bool Stop(HostControl hostControl)
    {
        try
        {
            Log.Info("Disposing container");

            _container.Dispose();

            return true;
        }
        catch (Exception exception)
        {
            Log.Error("An error occurred during container disposal: {0}", exception);

            return false;
        }
    }
}

class RobotService : ServiceControl

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

readonly WindsorContainer _container = new WindsorContainer();

public bool Start(HostControl hostControl)

{

try

{

Log.Info("Initializing container");

_container.Install(FromAssembly.This());

return true;

}

catch (Exception exception)

{

Log.Error("An error occurred during intialization: {0}", exception);

return false;

}

public bool Stop(HostControl hostControl)

{

try

{

Log.Info("Disposing container");

_container.Dispose();

return true;

}

catch (Exception exception)

{

Log.Error("An error occurred during container disposal: {0}", exception);

return false;

}

Use Topshelf to activate the service class

Now we can have our RobotService activated as a Windows Service by adding the following C# spells:

class Program
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    static void Main()
    {
        AppDomain.CurrentDomain.UnhandledException += (o, ea) => Log.Fatal("Unhandled exception: {0}", ea.ExceptionObject);

        HostFactory.Run(f =>
        {
            f.UseNLog();
            f.Service<RobotService>();
        });
    }
}

class Program

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

static void Main()

{

AppDomain.CurrentDomain.UnhandledException += (o, ea) => Log.Fatal("Unhandled exception: {0}", ea.ExceptionObject);

HostFactory.Run(f =>

{

f.UseNLog();

f.Service<RobotService>();

});

}

Please note that Topshelf needs a little extra help with logging unhandled app domain exceptions, so I’ve added a little bit of Log.Fatal at the top.

Add components to the container to actually do something

Now, just to show some real action, I’ve added a single Windsor installer that looks like this:

public class TestInstaller : IWindsorInstaller
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<IDisposable>()
                .Instance(CreateAndStartTestTimer(interval: TimeSpan.FromSeconds(1)))
                .Named("TestTimer")
            );
    }

    Timer CreateAndStartTestTimer(TimeSpan interval)
    {
        var timer = new Timer(interval.TotalMilliseconds);
        timer.Elapsed += (o, ea) => Log.Info("woooH0000! It's going great!!1");
        timer.Start();
        return timer;
    }
}

public class TestInstaller : IWindsorInstaller

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

public void Install(IWindsorContainer container, IConfigurationStore store)

{

container.Register(

Component.For<IDisposable>()

.Instance(CreateAndStartTestTimer(interval: TimeSpan.FromSeconds(1)))

.Named("TestTimer")

);

}

Timer CreateAndStartTestTimer(TimeSpan interval)

{

var timer = new Timer(interval.TotalMilliseconds);

timer.Elapsed += (o, ea) => Log.Info("woooH0000! It's going great!!1");

timer.Start();

return timer;

}

As you can see, it will start a System.Timers.Timer, configured to periodically log a cheerful statement to the log and shove it in the container to be disposed when the application shuts down. It shouldn’t take too much imagination to come up with more useful and realistic tasks for the timer to perform.

This is actually all there is to it! Of course it can be customized if you want, but what I’ve shown is the only stuff that is necessary to create a full-blown Windows Service that manages the lifetime of application components and logs its work in a way that makes the service monitorable, e.g. by Microsoft SCOM and/or Splunk or whichever way you like to throw your logs.

As a public service, I’ve put this small example project in a GitHub repository for your cloning pleasure. Also, if you have any comments, please don’t hesitate to send them my way. Pull requests are also accepted 🙂

Updated guide to Topshelf

2014-02-24 by mookid8000 6 Comments

I have written about Topshelf several times before, but the API has gone through a few changes over the last couple of years – and since my Topshelf posts are, for some reason, constantly (according to my stats) being (re)visited, I thought it would be in order to show the most current version of Topshelf in action…

Oh, and if you’re reading this and you don’t know what Topshelf is – it’s a library that helps you to quickly make your C# console application into a Windows Service that can easily be F5-debugged as well as installed as a proper Windows Service.

This is how you do it:

Create a new console application

Just do it. Name it something cool, like RobotsOnFire.

Pull in Topshelf with NuGet

Either reach out for your mouse and clickety click a few dozen times… me? I prefer to go

install-package Topshelf -ProjectName RobotsOnFire

1	install-package Topshelf -ProjectName RobotsOnFire

in the Package Manager Console, and this is how I avoid getting a tennis elbow even before I’ve written one line of code.

Remove unnecessary using directives and other redundant crap

This looks stupid – it makes you look like a person who doesn’t care:
before

This looks good – it reaks of the finicky meticulousness that is you:
after

Now, modify your Program class

into something like this:

class Program : ServiceControl
{
    static void Main()
    {
        HostFactory.Run(f => f.Service<Program>());
    }

    public bool Start(HostControl hostControl)
    {
        return true;
    }

    public bool Stop(HostControl hostControl)
    {
        return true;
    }
}

class Program : ServiceControl

{

static void Main()

{

HostFactory.Run(f => f.Service<Program>());

}

public bool Start(HostControl hostControl)

{

return true;

}

public bool Stop(HostControl hostControl)

{

return true;

}

and then press F5, and then you’ll be looking at something like this:

Wow! That was easy, right?! In order to actually do something in your Windows Service, you start a thread or a timer or something similar in the Start method and make sure that what you started is stopped again in the Stop method. In other words, the Start and Stop methods must not block – otherwise, Windows Service Control will not start the service properly.

Since this bad boy is an ordinary Console Application on the surface, it can be F5-debugged and run by executing RobotsOnFire.exe. But in addition to that, you can do this (in an elevated command prompt):

install

which results in Robots On Fire turning up as a Windows Service in Windows:

services

Now, let’s uninstall it again:

uninstall

and then let’s customize a couple of settings:

class Program : ServiceControl
{
    static void Main()
    {
        HostFactory.Run(f =>
        {
            f.Service<Program>();
            f.SetServiceName("ServiceName:RobotsOnFire");
            f.SetDisplayName("DisplayName:RobotsOnFire");
            f.SetDescription("This is my Robots On Fire Windows Service");
        });
    }

    public bool Start(HostControl hostControl)
    {
        return true;
    }

    public bool Stop(HostControl hostControl)
    {
        return true;
    }
}

class Program : ServiceControl

{

static void Main()

{

HostFactory.Run(f =>

{

f.Service<Program>();

f.SetServiceName("ServiceName:RobotsOnFire");

f.SetDisplayName("DisplayName:RobotsOnFire");

f.SetDescription("This is my Robots On Fire Windows Service");

});

}

public bool Start(HostControl hostControl)

{

return true;

}

public bool Stop(HostControl hostControl)

{

return true;

}

which, after installing it again, will show up like this:

where-do-the-settings-go

Topshelf has many additional things that can be customized – e.g. you can perform actions in connection with installing/uninstalling the service, make it install to be run under various system accounts, and – this is one of the cooler things – you can declare a dependency on e.g. a local SQL Server, a local IIS, or any other locally running Windows Service – this way, services will always be started/stopped in the right order, ensuring that e.g. your MSMQ-dependent service is not started before the Message Queueing service.

I am not usually that judgmental

2013-05-06 by mookid8000 Leave a comment

but I did write a blog post called “I judge developers by how many toolbars are showing in their IDE”, which could also have been called “if you reach for the mouse, you are n00b scum to me”.

I wrote the original blog post on how to strip some of the disturbing elements off of Visual Studio and get started using the keyboard for navigation because I was frustrated when I saw colleagues helplessly wiggle the mouse around and try to click small pathetic buttons among hundreds of other buttons in huge menu bars in integrated development environments…

So, today I got a tip from Brendan J. Baker who suggested I install the “Hide Main Menu” VSIX and get an auto-collapsing menu bar! Pretty cool, actually – it shows up again when you hit Alt, just like you expect it to after having used the keyboard for navigating Sublime all day.

The menu bar might not take up a lot of space, but it’s still 30 px in the expensive direction, at the entire width of the screen, holding a BUNCH OF YELLED WORDS – but most of all, it’s clutter!

Thanks, Brendan – you made my Visual Studio even more clean and good looking 🙂

Bring back the types!

2013-03-07 by mookid8000 4 Comments

When you’re working with C# and reflection, you might end up in a situation where you have “lost” the type. For example, if you’ve deserialized an incoming message of some kind, you might have code that needs to do this:

void HandleTheMessage(object message)
{
    // ... nasty reflection code in here
}

void HandleTheMessage(object message)

{

// ... nasty reflection code in here

}

Usually, when you want to do different stuff depending on the type of an object, you just call that object and let it do what it deems reasonable. That’s a good object-oriented way of delegating behavior to objects, totally anti-if campaign compliant and all. But in cases where the object you need to act upon is an incoming DTO, it’s usually not a good approach to put logic on that DTO.

This is a good time to do a “handler lookup” [1. I don’t know if there’s a better name for this pattern. I tried to ask Twitter, but I mostly got “it’s usually not a good idea to do that” – well, most patterns are usually not a good idea: all patterns should be applied only in cases where they make sense </stating-the-obvious>] in your IoC container for something that can handle an object of the given type. It goes like this: Given message: T, find handler: IHandle<T> and invoke handler with message.

In C#, that might look like this:

void HandleMessage(object message)
{
    var messageType = message.GetType();
    var handlerType = typeof(IHandler<>).MakeGenericType(messageType);
    var handlerInstance = container.Resolve(handlerType);

    handlerInstance.GetType()
        .GetMethod("Handle")
        .Invoke(handlerInstance, new object[] { message });
}

void HandleMessage(object message)

{

var messageType = message.GetType();

var handlerType = typeof(IHandler<>).MakeGenericType(messageType);

var handlerInstance = container.Resolve(handlerType);

handlerInstance.GetType()

.GetMethod("Handle")

.Invoke(handlerInstance, new object[] { message });

}

That’s not too bad I guess, but working at this untyped level for longer than this turns out to be cumbersome and hard to read and understand. It wouldn’t take more than a few lines more of invoking things via reflection before the dispatch of the message has turned into a mess! And then add the fact that exceptions thrown in method invocations made with reflection will be wrapped in TargetInvocationExceptions.

Consider this alternative approach where I use reflection to invoke a private generic method, closing it with the type of the message:

static readonly MethodInfo OpenDispatchMethod
    = typeof(TheClassWeAreIn).GetMethod("Dispatch", BindingFlags.NonPublic | BindingFlags.Instance);

void HandleMessage(object message)
{
    var messageType = message.GetType();
    var closedDispatchMethod = OpenDispatchMethod.MakeGenericMethod(messageType);
    closedDispatchMethod.Invoke(this, new object[] { message });
}

void Dispatch<TMessage>(TMessage message)
{
    // whee, we can work with TMessage in here!
    var handler = container.Resolve<IHandle<TMessage>>();
    handler.Handle(message);
}

static readonly MethodInfo OpenDispatchMethod

= typeof(TheClassWeAreIn).GetMethod("Dispatch", BindingFlags.NonPublic | BindingFlags.Instance);

void HandleMessage(object message)

{

var messageType = message.GetType();

var closedDispatchMethod = OpenDispatchMethod.MakeGenericMethod(messageType);

closedDispatchMethod.Invoke(this, new object[] { message });

}

void Dispatch<TMessage>(TMessage message)

{

// whee, we can work with TMessage in here!

var handler = container.Resolve<IHandle<TMessage>>();

handler.Handle(message);

}

This way, the Dispatch method can have the bulk of the logic and it does not need to bother with the reflection API. Nifty!

Domain events salvation example

2012-12-13 by mookid8000 3 Comments

One of the immensely awesome things that Udi Dahan has – if not invented, then at least brought to my attention – is the awesome “domain events – salvation” pattern.

If you’re familiar with the onion architecture, you’ve probably more than once experienced the feeling that you had the need to pull something from your IoC container some place deep in your domain model. In my experience, that often happens when you have a requirement on the form “when something happens bla bla, then some other thing must happen bla bla” where “something” and “some other thing” aren’t otherwise related.

An example could be when a new account (a.k.a. a customer that we mean to do business with) is registered in the system, we should make sure that our credit assessment of the account is fresh enough that we dare do the businesss.

I’ve found that the “domain events – salvation” provides a solution to that problem. Check this out:

public class Account
{
    public void Register()
    {
        // ... do stuff that marks this account as registered

        DomainEvents.Raise(new AccountRegistered(this));
    }
}

public class Account

{

public void Register()

{

// ... do stuff that marks this account as registered

DomainEvents.Raise(new AccountRegistered(this));

}

“Whoa, what was that?” you might ask… that was a domain object that did some stuff, and in the end it raised a “domain event”, telling to the world what just happened. And yes, that was a domain object calling out to some static nastiness – but I promise you, it isn’t as nasty as you may think.

I’d like to assure you that the Account class is fully unit testable – i.e. it can be tested in isolation, just like we want. And that’s because we can abstract the actual handling of the domain events out behind an interface, IHandleDomainEvents, which is what actually gets to take care of the domain events – something like this:

public class DomainEvents
{
    public static IHandleDomainEvents Current = new DevNullDomainEventsHandler();

    public static void Raise<T>(T domainEvent)
    {
        Current.Handle(domainEvent);
    }
}

public class DomainEvents

{

public static IHandleDomainEvents Current = new DevNullDomainEventsHandler();

public static void Raise<T>(T domainEvent)

{

Current.Handle(domainEvent);

}

and then IHandleDomainEvents can be implemented in several flavors and “injected” into the domain as a static dependency, e.g. this bad boy for testing:

public class TestDomainEventsHandlers : IHandleDomainEvents
{
    readonly List<object> raisedDomainEvents = new List<object>();

    public IEnumerable<object> RaisedDomainEvents { get { return raisedDomainEvents; } }

    public void Handle<T>(T domainEvent)
    {
        raisedDomainEvents.Add(domainEvent);
    }
}

public class TestDomainEventsHandlers : IHandleDomainEvents

{

readonly List<object> raisedDomainEvents = new List<object>();

public IEnumerable<object> RaisedDomainEvents { get { return raisedDomainEvents; } }

public void Handle<T>(T domainEvent)

{

raisedDomainEvents.Add(domainEvent);

}

which can be used by installing a new instance of it in the setup phase of each test, and then running assertions against the collected domain events in the assert phase.

The coolest part though, is the production implementation of IHandleDomainEvents – it may look like this:

public class CastleWindsorDomainEventDispatcher : IHandleDomainEvents
{
    readonly IWindsorContainer container;

    public CastleWindsorDomainEventDispatcher(IWindsorContainer container)
    {
        this.container = container;
    }

    public void Handle<T>(T domainEvent)
    {
        var subscribers = container.ResolveAll<ISubscribeTo<T>>().ToList();

        try
        {
            subscribers.ForEach(s => s.Handle(domainEvent));
        }
        finally
        {
            subscribers.ForEach(s => container.Release(s));
        }
    }
}

public class CastleWindsorDomainEventDispatcher : IHandleDomainEvents

{

readonly IWindsorContainer container;

public CastleWindsorDomainEventDispatcher(IWindsorContainer container)

{

this.container = container;

}

public void Handle<T>(T domainEvent)

{

var subscribers = container.ResolveAll<ISubscribeTo<T>>().ToList();

try

{

subscribers.ForEach(s => s.Handle(domainEvent));

}

finally

{

subscribers.ForEach(s => container.Release(s));

}

thus delegating the handling of domain events to all implementors of ISubscribeTo<TDomainEvent>. This way, if I have registered this guy in my container:

public class EnsureCreditAssessmentIsFresh : ISubscribeTo<AccountRegistered>
{
    public EnsureCreditAssessmentIsFresh(ILookMaADependency lookMaADependency)
    {
        this.lookMaADependency = lookMaADependency;
    }

    public void Handle(AccountRegistered accountRegistered)
    {
        // possibly initiate new credit assessment in here...
    }
}

public class EnsureCreditAssessmentIsFresh : ISubscribeTo<AccountRegistered>

{

public EnsureCreditAssessmentIsFresh(ILookMaADependency lookMaADependency)

{

this.lookMaADependency = lookMaADependency;

}

public void Handle(AccountRegistered accountRegistered)

{

// possibly initiate new credit assessment in here...

}

I can kick off a new credit assessment workflow when a new account is registered, and everything is wired together in a way that is semantically true to the domain. Also, my domain object suddenly get to pull stuff from the container (albeit in an indirect fashion), without even knowing about it!

Thoughts on how to integrate with 3rd party libraries when you’re a library author

2012-12-10 by mookid8000 1 Comment

When building .NET systems for clients, it’s just awesome how much free open source that’s available at your fingertips – and with tools like NuGet around, it’s become extremely easy to rapidly pull in various colors and sizes of Legos to snap together and build on. Except, sometimes those Legos don’t snap 🙁

Different types of libraries and frameworks are more or less susceptible to Lego-snap-issues, depending on their place in the stack. That is, libraries with many incoming references are inherently problematic in this regard, the ubiquitous examples being logging libraries and serialization libraries.

When I built Rebus, one of my solemn goals was to make Rebus dependent on .NET BCL ONLY. All kinds of integration with 3rd party libraries would have to be made via small dedicated adapter projects, because this way – in the case where there’s a conflict with one of your own dependencies – only that single adapter would have to be either built against your version of the problematatic dependency, or switched for something else.

Serialization with Rebus

Rebus serializes message bodies by using an ISerializeMessages abstraction. And since Rebus’ default transport message serialization format is JSON, and I didn’t feel like re-re-re-inventing any wheels, I decided to pull in the nifty JSON.NET package in order to implement Rebus’ JsonMessageSerializer that is part of the core Rebus.dll. But that clearly violates Rebus’ goal of having no dependencies besides what’s in the .NET framework – so how did I solve that?

Simple: ILmerge JSON.NET into Rebus! Simple solution, very effective.

Maybe there’s something I’m being ignorant about here, but I don’t get why projects like e.g. RavenDB keeps having issues with their JSON.NET dependency. Why didn’t Ayende just merge it from the start?

Update January 7th 2013: Well, it appears that they did just that for RavenDB 2: RavenDB-220

Logging with Rebus

And then there’s logging – in order to log things good, all Rebus classes must be given access to a logger – and I like it when the logger is named after the classes it is being used from, which always turns out to be a piece of really useful information when you’re trying to track down where stuff went wrong some time in the past.

Ideally, I wanted a syntax that resembles the Log4Net one-liner, that you’ll most likely encounter if you come across code that uses Log4Net for logging – each class usually initializes its own logger like this:

static readonly ILog Log 
                = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);
// couldn't fit it in one line - sorry ;)

static readonly ILog Log

= LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);

// couldn't fit it in one line - sorry ;)

thus retrieving a static readonly logger instance named after the calling class. So, originally I started out by copying the Log4Net API, providing adapters for console logging, Log4Net logging, etc.

That worked perfectly for a while, but later on, since I spent so much time writing integration tests for Rebus, I also wanted the logging mechanism to be swappable at runtime – i.e. I wanted it so that Rebus could have its logger swapped from e.g. a ConsoleLogger to a NullLogger in a performance test, where all the console output would otherwise interfere with the measurements.

Therefore, my logging “abstraction” is a bit more involved. But it accomplishes all goals: All classes can have a static logger instance, named after the class, swappable at runtime, without introducting dependencies on external stuff, and with very little (read: an acceptable amount of) ceremony (too much for my tastes actually, but I accept this one because of the goodness it brings).

Check out what a class must do in order to get a Rebus logger:

public class SomeClassThatMustLogStuffTheRebusWay
{
    static ILog log;

    static SomeClassThatMustLogStuffTheRebusWay()
    {
        RebusLoggerFactory.Changed += f => log = f.GetCurrentClassLogger();
    }

    // ... all the usual class stuff down here
}

public class SomeClassThatMustLogStuffTheRebusWay

{

static ILog log;

static SomeClassThatMustLogStuffTheRebusWay()

{

RebusLoggerFactory.Changed += f => log = f.GetCurrentClassLogger();

}

// ... all the usual class stuff down here

}

As you can see, the logger is set when the Changed event is raised – and by taking control of the add/ remove operations of the event, I can ensure that the logger is set when each subscriber first subscribes. This way, the logger is immediately initialized by the currently configured static IRebusLoggingFactory, and in the event that the factory is changed, all logger instances are changed.

The Changed event is implemented like this:

public static event Action<IRebusLoggerFactory> Changed
{
    [MethodImpl(MethodImplOptions.Synchronized)]
    add
    {
        ChangedHandlers.Add(value);
        value(Current);
    }
    [MethodImpl(MethodImplOptions.Synchronized)]
    remove { ChangedHandlers.Remove(value); }
}

public static event Action<IRebusLoggerFactory> Changed

{

[MethodImpl(MethodImplOptions.Synchronized)]

add

{

ChangedHandlers.Add(value);

value(Current);

}

[MethodImpl(MethodImplOptions.Synchronized)]

remove { ChangedHandlers.Remove(value); }

}

The last thing is to provide a meaningful name to the logger – i.e. I wanted the name of the calling class to be used, so the call to GetCurrentClassLogger() had to do some StackFrame trickery in order to fullfil the promise made by its title. The implementation is pretty simple:

public ILog GetCurrentClassLogger()
{
    var stackFrame = new StackFrame(1);

    return GetLogger(stackFrame.GetMethod().DeclaringType);
}

public ILog GetCurrentClassLogger()

{

var stackFrame = new StackFrame(1);

return GetLogger(stackFrame.GetMethod().DeclaringType);

}

As you can see, it just skips one level on the call stack, i.e. it gets the calling method, and then we can use the standard reflection API to get the type that has this method. Easy peasy!

This was an example on how two of the more troublesome dependencies can be dealt with, allowing your library or framework to be effectively dependency-free.

Announcing: Rebus

2012-02-26 by mookid8000 3 Comments

Preface

Friends and acquaintances might know that I’ve spent the last 6 months or so of my pastime, hacking on something I call Rebus. To cut a long story short, I can tell you that I am a happy NServiceBus user who became very sad when NServiceBus went from being free to requiring a commercial license – not because I think NServiceBus isn’t worth spending money on, but because I think it hurts the adoption of NServiceBus.

Speaking for myself, I have already refrained from using NServiceBus in a couple of smaller projects, where it would otherwise have been an awesome addition.

I seriously considered forking the 2.0 version of NServiceBus, which is licensed under Apache v. 2.0, but I was overwhelmed by the sheer size of the project. This led me to re-implement my favorite features of NServiceBus as Rebus, trying to focus and stay lean along the way.

And here it is: Rebus

Rebus – the core – depends on .NET 4 only. And since .NET 4 has MSMQ, ADO.NET, and binary serialization, you get to send and receive messages transactionally and persist your stuff in SQL Server without anything but Rebus core.

3rd party integration (like e.g. MongoDB, NewtonSoft JSON serializer, etc) is provided through small, dedicated add-on projects. This granularity makes it easier to manage your own dependencies.

Update: And since JSON serialization was deemed to be the preferred form of message serialization, it has been ILMerged into Rebus core since right after this announcement. Therefore, JSON serialization is included in the box and is the default.

There’s currently two ways to get started with Rebus:

Instantiate RebusBus manually, filling in the ginormous constructor with implementations for how you want the bus to run.
Use the configuration API.

Let’s try the configuration API – with the following snippet of XML in your app.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
    <section name="rebus" type="Rebus.Configuration.RebusConfigurationSection, Rebus" />
  </configSections>

  <rebus inputQueue="myService.inputQueue" workers="5">
    <endpoints>
      <add messages="AnotherService.Messages" endpoint="anotherService.inputQueue"/>
    </endpoints>
  </Rebus>

  <log4net>...</log4net>
</configuration>

<?xml version="1.0" encoding="utf-8" ?>

</configSections>

</endpoints>

</Rebus>

</configuration>

and the following piece of code in your app:

var myAdapter = new MyFavoriteContainerAdapter(myFavoriteContainer);

Configure.With(myAdapter)
    .Logging(c => c.Log4Net())
    .DetermineEndpoints(c => c.FromRebusConfigurationSection())
    .Transport(c => c.UseMsmqAndGetInputQueueNameFromAppConfig())
    .Serialization(c => c.UseJsonSerializer())
    .CreateBus()
    .Start();

// IBus is in the container now :)

var myAdapter = new MyFavoriteContainerAdapter(myFavoriteContainer);

Configure.With(myAdapter)

.Logging(c => c.Log4Net())

.DetermineEndpoints(c => c.FromRebusConfigurationSection())

.Transport(c => c.UseMsmqAndGetInputQueueNameFromAppConfig())

.Serialization(c => c.UseJsonSerializer())

.CreateBus()

.Start();

// IBus is in the container now :)

you should be up and running with a Rebus bus.

That was a small teaser – there’s more blog posts on the way, I promise 😉

So, what’s the state of this?

Well, that’s actually the whole point of this blog post – I’m currently in a situation where I really feel like putting Rebus to some serious use, but I cannot justify foisting it on a client until I have a big project to prove its worth. And I cannot prove its worth in a big project until I have a client I can fob it on.

That’s where you come in! 🙂

You:

You’re building something – it’s not totally mission critical, as in human lives depend on it, but it’s still something.
You want some nifty service bus technology to help you build a loosely coupled architecture that will allow your project to flex and bend and integrate with stuff in many years to come.
You wanted to use NServiceBus because it’s cool, but you can’t afford the cost up front.
You’re reading this blog post, or someone you know read it and is now telling you about it…

If that’s you, then you should meet Rebus!

Rebus:

Absolutely free to use and abuse.
Very very similar to NServiceBus, allowing you to migrate to NServiceBus some time in the future if Rebus is not enough for you.
Pretty simple.
Comes with unlimited[1. Within reason, of course – I have a day job, a wife, and two kids, so I’m not answering emails 24/7 – but I’ll go to great lengths to help you get a smooth adoption of Rebus – because that’s just how much I care :)] support from its author.
Did I mention it was free?

A match made in heaven?

If you have the slightest bit of interest in what I’m suggesting, please contact me – either via email or on Twitter – and then we’ll talk about what Rebus can do for you. Oh, and please don’t hesitate to contact me – even if you’re NOT planning on using Rebus, I’d like to know why you picked NServiceBus, MassTransit, or Rhino Service Bus instead.

If you’re just eager to try it out, feel free to Install-Package -Pre one or more of Rebus’ NuGet packages.

I judge developers by how many toolbars are showing in their IDE

2012-02-16 by mookid8000 11 Comments

Usually, I try not to be judgmental about stuff. I like to keep my mind open and to accept people as the beautifully unique snowflakes they are… or something… 🙂

There’s one thing that irritates me though, and that’s C# developers who constantly reach for the mouse to click the tiny crappy toolbar buttons that for some reason seem to have survived in Microsoft IDEs since 1995 VB4. Yeah I’m looking at you! You’re crap!

There is nothing more annoying than pair programming with someone, who cannot even go to another file without having to scroll up and down in Solution Explorer, looking for that file to double-click. And then comes the time to re-run the current unit test… Sigh!!!

Now, if you have any ambition as a C# developer, I recommend you start out every new installation of Visual Studio by

Hiding all toolbars (which, unfortunately, cannot easily be done at once – new ones pop up every time you open a new kind of file for the first time).
Making all tool windows auto-hide (i.e. click the little pin on e.g. Solution Explorer, making it collapse – usually to the right side of the screen).

That will make your work environment resemble the picture on the right (especially if you have a 1337 dark color scheme like mine) – see: no clutter! No stinking buttons to disturb your vision while you’re swinging the code hammer! And, it will serve as an incentive to start using the keyboard some more.

Now, in order to be able to actually work like this, it’s essential that you know how to navigate using the keyboard only. Therefore, here’s a few very basic shortcuts to get you started[1. Assuming of course that you’re using Visual Studio with standard keyboard settings and R# with Visual Studio keyboard scheme]:

Navigate to any open window in the environment: Ctrl + Tab + arrows while holding Ctrl.
Jump to file currently being edited in the Solution Explorer: Shift + Alt + L.
Jump to the R# test runner: Ctrl + Alt + T.
Pop open the context menu: Shift + F10.

Now, with these in place I think it should be possible to start doing all navigation with the keyboard only. And then, when you get tired pressing Shift + F10 and choosing stuff in the menus, you can start learning the real shortcuts to everything.

Using the keyboard for the majority of all tasks has several advantages – in addition to relieving the strain on the right wrist, arm, and shoulder, you also get the advantage that your navigation and execution of common workflows is sped up, allowing your work pace to better match the pace of your train of thought.

Also, I won’t judge you 🙂

Just a personal observation regarding the recent IoC debate on Twitter

2012-02-03 by mookid8000 1 Comment

Systems, where I’ve started out “as simple as possible”, and later wished that I had baked in an IoC container from the beginning: Several.

Systems, where I’ve baked in Castle Windsor from the beginning, and where I later wished that I hadn’t: 0.

#justsaying

(IMO, using an IoC container does not increase overall complexity – it just moves some of the complexity out of my code, and into a thing that implements a bunch of useful patterns in a slightly more opaque way than if I’d implemented those things myself.)