Official Rebus documentation

Rebus logoHello world!

Due to the fact that there’s actually a few people using Rebus in real systems now, and also to give myself some insight into whether I have thought things through ;), I have started working on the official Rebus documentation.

For now, it resides on Rebus’ GitHub wiki – if you’re interested, you should check it out.

Also, if you think that something is missing, please don’t hesitate to let me know!

Just a thought on the MVP program

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 🙂

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

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 🙂

2011 retrospective and 2012 resolutions

In the same vein as last year, I’ll spend a post summing up on what happened this year, and then try to come up with some goals for the next year.

2011 retrospective

What did I do in 2011? Well, I

  • Wrote 27 blog posts (+ this one = 28).
  • Gave my “Frictionless Persistence in .NET with MongoDB” talk at Goto Copenhagen. Great experience, and Microsoft even recorded it.
  • Gave the talk again as a free geek night.
  • Hosted an Aarhus .NET User Group code camp on MongoDB.
  • Gave the Frictionless talk again, this time at an Odense .NET User Group meeting.
  • Made tiny contributions to Castle Windsor and MassTransit.
  • Started building an NServiceBus-like service bus: Rebus. It already has pub-sub messaging and sagas 🙂
  • Attended Udi Dahan’s “Advanced Distributed Systems Design With SOA” course. Udi was no stranger to me as I have been following his work, but the course presented some extremely interesting ideas on how to build a service-oriented architecture.
  • Spent most of my time monkeying around with code and architecture on the PowerHub project, which is getting more and more serious. Oh, did I mention that the system’s regulation parts have zero downtime? With a nifty master-slave setup with automatic failover, PowerHub can continue to optimize and control local units, even in the face of system and platform upgrades… 🙂
  • Got a new job!!! Yes, that’s right: The 30th of December 2011 will be my last day as a Trifork Software Pilot! On January the 2nd in the new year, I’ll join d60 as a consultant. This fact deserved a dedicated blog post. 🙂
  • Had my photo of a hard-wired hairdryer included in Mark Seemann’s book about DI in .NET (see page 8 in chapter 1). Needless to say, this photo went right into my slidedeck 🙂

If I compare that to my 2011 resolutions, I think I’m only missing a “real” pet project. The closest thing is PriorityQ, which I made as an example app for my MongoDB presentations – it’s a “question collector” that can be used during presentations.

2012 resolutions

This is what I’d like to do in 2012:

  • Gain a footing in my new position, and help out with some of the company’s challenges.
  • Attend a couple of conferences – in passive as well as in active mode.
  • Contribute some more to some of the OSS projects I like – including my own.
  • Put Rebus to (some serious ab)use.

and, most importantly – just like my 2011 resolutions – I’d like to continue to be inspired by communicating with smart people.

Lastly, I will express my feelings in the form of an animated GIF that reeks of 1996: Animated GIF fireworks Now, let’s see what 2012 brings…

New job!!

As I’m writing this, I have spent 4 years and 9 months working at Trifork. That means a majority of my professional experience comes from working there, and I must say that it has been a fantastic time!

Throughout the years, I have been allowed to work on interesting projects, attend conferences, speak, teach, and play, and thus continually be challenged – and almost be forced to grow.

When I read Chad Fowler’s “My Job Went To India” (which later became “The Passionate Programmer”), the “Be The Worst” chapter immediately made sense to me, because I think that pretty much describes me when I started working with Trifork. If you haven’t read it, please do yourself a favor and do it – it’s available online.

As Chad puts it: “The people around you affect your own performance. Choose your crowd wisely”.

So, if you’re looking for an inspiring environment and some extremely talented colleagues, Trifork is definitely a great place to be. Especially as a .NET developer, I think Trifork can offer a healthy exposure to Java, ObjectiveC, Riak, Erlang, Ruby, and more non-.NETty things, which I think has helped me become more wholistic in my views on technology.

d60 logoAfter almost 5 years however, I feel it is time to seek new challenges.

So, on Januar 2nd 2012 I’ll join d60, which is a fast-growing Microsoft-based consultancy agency on the outskirts of central Aarhus. d60 is just about equally split between systems development and business intelligence, so hopefully I’ll gain some insight in BI, which I think will help me build better systems. At d60 I’ll continue working as a software development consulatant, and hopefully I’ll continue to communicate with smart people about software development and help building cool solutions to real world problems.

Tell, Don’t Ask

or “How big is an interface?”… Uuuh, what?

Well, consider these two interfaces:

– which is bigger?

If you think that ISomeService1 is the bigger interface, then there’s a good chance you’re wrong! Why is that?

It’s because an interface is not just the signatures of the methods and properties it exposes, it also consists of the types that go in and out of its methods and properties, and the assumptions that go along with them!

This is a fact that I see people often forget, and this is one of the reasons why everything gets easier if you adhere to the Tell, Don’t Ask principle. And by “everything”, I almost literally mean “everything”, but one thing stands out in particular: Unit testing!

Consider this imaginary API:

Now, in our system, on various occasions we need to change the values for a particular name. We start out by doing it like this:

Obviously, if GetValues returns a reference to a mutable object, and this object is the one kept inside the value store, this will work, and the system will chug along nicely.

The problem is that this has exposed much more than needed from our interface, including the assumption that the obtained Values reference is to the cached object, and an assumption that the Value1 and Value2 properties can set set, etc.

Now, imagine how tedious it will be to test that the Run method works, because we need to stub an instance of Values as a return value from GetValues. And when multiple test cases need to exercise the Run method to test different aspects of it, we need to make sure that GetValues returns a dummy object every time – otherwise we will get a NullReferenceException.

Now, let’s improve the API and change it into this:

adhering to the “Tell, Don’t Ask” principle, allowing a potential usage scenario like this:

As you can see, I have changed the API from a combined query/command thing to a pure command thing which appears to be much cleaner to the eye – it actually reveals exactly what is going on.

And testing has suddenly become a breeze, because our mocked ISomeKindOfValueStore will just record that the call happened, allowing us to assert it in the test cases where that is relevant, ignoring it in all the other test cases.

Another benefit is that this coding style lends itself better to stand the test of time, as it is more tolerant to changes – the implementation of ISomeKindOfValueStore may change an in-memory object, update something in a db, send a message to an external system, etc. A command API is just easier to change.

Therefore: Tell, Don’t Ask.

2010 retrospective and 2011 resolutions

Now that ++year == 2011, and the last remaining effects of New Year’s Mojitos has finally left my brain, I think it is in order to take a look back at 2010 and evaluate a bit, and then maybe come up with some goals for 2011.

2010 retrospective

2010 has been pretty busy for me – check out this list of professional as well as personal activities:

  • My 2nd child was born in February :).
  • Wrote 34 blog posts spread pretty evenly over the year (except February).
  • Gave two talks on MongoDB in June, two talks on Castle Windsor in November and December, and two talks on NServiceBus in December.
  • Gave two 2-day introductory courses on getting up to speed with C#, .NET, dependecy injection, unit testing, and continous integration.
  • Gave one 1-day course as an introduction to C#, . NET, and WCF.
  • Gave 2 courses on NServiceBus.
  • Spent September and October on paternity leave.
  • Spent most of my other professional time as a development and architecture consultant on the core team of Dong Energy’s smart grid project, PowerHub. We’re controlling a hydro power plant right now at this very moment :).
  • Participated in two episodes of ANUGCast about MongoDB: Part 1 and part 2.
  • Learned a lot about new and emerging .NET technologies, NoSQL databases, and about architecture in general.

Looking back at all this, I think 2010 has been a little bit too busy – especially since most of the presentations and teaching happened in November and December :).

2011 resolutions

This is what I’d like to do in 2011:

  • I would like to continue doing all these great things in 2011, because that’s what makes my job alternating and fun, but ideally I would like to spread the activities some more.
  • I would like to start a pet project – i.e. build “something real”.
  • I would like to continue widening my horizon by cheching out non-.NET-stuff, like e.g. MongoDB and Node.js, which I am actually starting to like quite a bit.
  • I would like to continue contributing to OSS – either in a direct manner with code, or indirectly by blogging, tweeting, helping, creating courses, etc.
  • I would like to continue communicating with great people and be inspired.

Actually I should have hightlighted that last bullet – I guess it pretty much sums up my main goal for 2011 :).

I will be speaking about NoSQL and MongoDB

as seen from the eyes of a .NET developer at two events in June (in Danish).

The first event is a JAOO Geek Night at Dong Energy in Skærbæk on Tuesday June 29th at 4:30 pm. You can read more about the free JAOO Geek Nights here.

The other event is a meeting in Århus .NET User Group, which is the day after, on Wednesday June 30th at 6 pm – you can sign up via Facebook here.

I’m really looking forward to it, because I think we will have some interesting discussions. And perhaps we can widen a few people’s horizons 🙂

Hope to see a lot of engaged people at both events.


Recently, I had the opportunity to teach an introductory course in programming in C#, including topics on dependency injection, IoC containers, and test-driven development.

When I introduced the concept of dependency injection, and I suggested that this seemingly pretty simple and trivial task be accomplished by putting an IoC container to use, some of the attendees reacted with scepticism and doubt – would this thing, configured with either endless fluent spells or – shudder! – tonnes of XML, not make everything even more complex?

At the time, I tried to convince them that an IoC container was cool, and that learning its ins and outs could be considered some kind of investment that – over time – would actually reduce complexity. This is not something new, and everybody who has ever used an IoC container will probably agree with me that this investment pays off. But still, I think I needed some words that would support my argument better.

So, here goes a few random thought about complexity…


Right now, I want to focus on the kind of complexity that is inherent in non-trivial programs. That is, the complexity can not be removed from the program. The complexity can be anything, really, and it is there in some form or another, and we need to deal with it.

Immediate vs. deferred complexity

Assuming we need to deal with it, how do we do it then? Which strategy do we follow? Well, acknowledging its existence is not the same as dealing with it, but it’s definitely a first step. Thereafter, we should probably consider either A) solving the complexity on a case-to-case ad hoc kind of basis, or B) building some kind of mechanism, that abstracts the identified complexity away, thus dealing with the complexity right now.

Localized vs. dispersed complexity

Definitely coupled to the above somehow, but not inseparable, is the localized vs. dispersed complexity question: When you identify some kind of complexity, do you A) solve the problem in all the little places where the complexity surfaces, or B) build some kind of framework that makes all the other code oblivious of the complexity?

My opinion, and how it relates to IoC containers

I don’t know about you, but I prefer B & B: the abstraction and the framework. It might leak, and it might take some time for other developers to grok if they have never seen that particular problem solved like that before, but if the abstraction holds, it will probably assume some kind of pattern status that will be used, re-used, and recognized from then on.

The force of IoC containers is that they take control over object creation, thus providing hooks around whenever objects are created, and object creation is an incredibly important event in a running program. Having a hook in that proves to be infinitely useful (almost).

The IoC container solves the complexity of deciding when and how to create (which) objects. This would otherwise be a severely dispersed (spatially as well as temporally) complexity, or cross-cutting concern if you will, in that it is a really common thing to instantiate stuff and/or use existing instances of stuff, and the alternative would be to new up objects, maybe pulling from a cache somewhere, all around the place – thus infiltrating our program with our solution to that particular problem.


Use an IoC container. Learn to use its features. Allow the container to take responsibility. This will make you happy.

(seriously, do it! :))