Today, I did a talk on Rebus. It’s in Danish, and the slides can be seen below

Yesterday, I did two talks at Miracle Open World: “So you want to liberate your data?” and “Ride the bus!”

Slides are available here:

Today, I read Davy Brions latest post, “Most Valuable Professionals? Give me a break.” I have to admit that I was a little bit saddened by Davy’s experiences with the MVP program and its representatives in Belgium, because my view of the MVP program has almost always been positive.

I know that the program is notorious for its obscure election process, and I followed Rob Eisenberg’s hazzle back in January, yet I am confident that the MVP program is a good thing – because all the MVPs here in Denmark that I know of are genuinely cool people, who are working hard on interesting projects, and who still manage to find time and energy to spread good vibes about technology that widens everybody’s horizon. I simply do not know any MVPs that are not awesome technologists!

Another thing is that I was recently given the MVP award – and I can honestly say that I do NOT scratch Microsoft’s back unmerited in any way!

I am pretty invested in the open source .NET world, and when I give talks, I talk about stuff like Castle Windsor, MongoDB, and NServiceBus. And personally, I am much more an indie-underground-micro-framework-kind-of-guy, than I am an enterprisey blessed-by-Microsoft-kind-of-guy, even though I tend to work in enterprisey environments. I just happen to enjoy working with C# and the .NET stack, both professionally and in my spare time, and I guess that’s what shows when I communicate with people about software development.

What I am saying is this: The fact that I get an MVP award can only be a sign that Microsoft (at least in some regions) actually want to encourage developers to be active and contribute to the .NET communities in various ways, even though they’re not necessarily praising Microsoft at every occasion. I guess Microsoft (still: at least in some regions) realize that active software developers are good for the .NET ecosystem as a whole, and in my eyes that’s what the MVP program is about.

I guess I just wanted to chime in with a positive MVP story

It’s very very alpha, even more alpha than Rebus itself – but here it is: Rebus Snoop – a tool to aid developers and operations in managing their Rebus queues.

The goal of The Snoop is to provide that little extra bit of tooling that will give you a feeling of transparency and confidence when developing and operating systems based on Rebus.

At the moment, it’s extremely basic – it allows you to see which queues exist on a given machine, and it will display the contents of the selected queue.

When a message is selected, various pieces of information from the message will be shown in the panel to the right.

If the extension element from the MSMQ message can be properly deserialized into a dictionary of headers, and those headers are proper Rebus headers, they will be displayed at the top.

If the rebus-encoding header is present, The Snoop will attempt to decode the message body and show the contents in the windows to the right.

If the rebus-source-queue header is present, The Snoop will unlock the “Return to source queue” button, allowing you to retry the selected messages.

You can go to Rebus’ download page on GitHub if you want to try out The Snoop. I’d be grateful if you would report any problems you may encounter and/or crazy feature requests to Rebus’ issue tracker.

Now that Rebus is present on NuGet, it has become extremely easy to get started. This small guide will show how to build a simple TopShelf service, that will send a message to itself. It should be pretty easy to extend this to a more complete example with multiple services, but let’s just keep it really simple for now.

Create the host process

First, we create a TopShelf host process that has all the necessary stuff to be able to run and be debugged, as well as installed, uninstalled, and be managed as a Windows Service. Precious stuff when you’re building backend processes.

Create a Console Application

Do what the header says – and change the target framework from that bastard “.NET 4 Framework Client Profile” to “.NET 4 Framework”.

Go get TopShelf

Open a package manager console (we’ll need it for the Rebus alpha packages), and

Install-Package TopShelf -Project <NameOfYourProject>
Install-Package Log4Net -Project <NameOfYourProject>

For some reason, you need to download Log4Net manually, even though TopShelf depends on it.

Configure Log4Net and declare the TopShelf service

Now, do something like this in your Program.cs:

using Topshelf;
using log4net.Config;
 
class Program
{
    static void Main()
    {
        XmlConfigurator.Configure();
 
        HostFactory
            .Run(c =>
                        {
                            c.SetServiceName("RebusTest");
                            c.SetDisplayName("RebusTest");
                            c.Service<Program>(p =>
                                                {
                                                    p.ConstructUsing(() => new Program());
                                                    p.WhenStarted(s => s.Start());
                                                    p.WhenStopped(s => s.Stop());
                                                });
                        });
    }
 
    void Start()
    {
    }
 
    void Stop()
    {
    }
}

and then add some XML to your app.config:

  <configSections>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
  </configSections>
 
  <log4net>
    <appender name="ColoredConsoleAppender" type="log4net.Appender.ColoredConsoleAppender">
      <mapping>
        <level value="ERROR" />
        <foreColor value="White" />
        <backColor value="Red" />
      </mapping>
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />
      </layout>
    </appender>
    <root>
      <priority value="DEBUG" />
      <appender-ref ref="ColoredConsoleAppender" />
    </root>
  </log4net>

Now you should be able to run the service and see a buttload of log statements, courtesy of TopShelf.

Insert Rebus

Now that we have the host process up and running, let’s make the program do stuff.

Let’s get Rebus

Go to the package manager console again, and do this:

Install-Package Rebus.Log4Net -Pre -Project <NameOfYourProject>
Install-Package Rebus.Castle.Windsor -Pre -Project <NameOfYourProject>

Let’s configure and use it!

Now, you should be able to implement your Start and Stop methods like this:

IBus bus;
 
void Start()
{
    var container = new WindsorContainer();
 
    container.Register(Component.For<IHandleMessages<string>>().Instance(this));
 
    bus = Configure.With(new WindsorContainerAdapter(container))
        .Logging(l => l.Log4Net())
        .Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
        .Serialization(s => s.UseJsonSerializer())
        .DetermineEndpoints(d => d.FromRebusConfigurationSection())
        .CreateBus()
        .Start();
 
    bus.Send("HELLLLLO WORLD!!!1");
}
 
void Stop()
{
    bus.Dispose();
}

Now, in order to make the container.Register(...) line from above compile, you need to let Program implement IHandleMessages<string>. Try adding something like this:

class Program : IHandleMessages<string>
{
    // (... cut for brevity ....)
 
    public void Handle(string message)
    {
        Console.WriteLine("w00t!!!: {0}", message);
    }
}

If you run the program now, you’ll get some kind of error, saying that the input queue name is invalid. That’s because we haven’t configured Rebus yet. Let’s do that by modifying app.config by adding this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <!-- (...) -->
 
    <section name="Rebus" type="Rebus.Configuration.RebusConfigurationSection, Rebus" />
  </configSections>
 
  <!-- (...) -->
 
  <Rebus InputQueue="RebusTest.input" Workers="2">
    <Endpoints>
      <add Messages="System.String, mscorlib" Endpoint="RebusTest.input" />
    </Endpoints>
  </Rebus>
 
</configuration>

The InputQueue attribute above tells Rebus to receive messages from the RebusTest.input queue, and the <add ...> elements says to send messages of the System.String type to the same RebusTest.input queue.

Let’s run it

Now you should be able to run it and see something like this on your screen:

If you get the same w00t!!!: HELLLLLO WORLD!!!1 in your console, it means you’re ready to start building stuff with Rebus

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.

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

1. Instantiate RebusBus manually, filling in the ginormous constructor with implementations for how you want the bus to run.
2. 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>

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 :)

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¹ 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.

Oh btw., if you’re thinking of going to Software Passion Summit 2012 in Göteborg, you should use the promotion code MOGENS when you register – you’ll get a 10% discount with this bad boy.

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¹:

• 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

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 as 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.)

This is just to say that on the 19th of March (and the 20th as well), I’ll be in Göteborg at Software Passion Summit 2012.

On the 19th (my birthday), I’ll do my “Frictionless Persistence in .NET with MongoDB” talk, which is just awesome!

I love talking about these things, so it’s a real treat to get to do that in an exciting new conference.