Hello 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!
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 🙂
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
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]:
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 🙂
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.
What did I do in 2011? Well, I
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.
This is what I’d like to do in 2012:
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: 
Now, let’s see what 2012 brings…
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.
After 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.
or “How big is an interface?”… Uuuh, what?
Well, consider these two interfaces:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
public interface ISomeService1 { void SetStuff(double value); void SetSomeOtherStuff(string anotherValue); void SetMoreStuff(bool moreStuff); void SetEvenMoreStuff(bool eventMoreStuff); } public interface ISomeService2 { SomeValue GetValue(); } |
– 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:
|
1 2 3 4 |
public interface ISomeKindOfValueStore { Values GetValues(string name); } |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
public class BusinessLogic { ISomeKindOfValueStore someKindOfValueStore; public BusinessLogic(ISomeKindOfValueStore someKindOfValueStore) { this.someKindOfValueStore = someKindOfValueStore; } public void Run() { var values = someKindOfValueStore.GetValues("MegaCorp"); values.Value1 = 2.3; //< secret biz constants values.Value2 = 4.5; // more logic in here } } |
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:
|
1 2 3 4 |
public interface ISomeKindOfValueStore { void SetValues(string name, double newValue1, double newValue2); } |
adhering to the “Tell, Don’t Ask” principle, allowing a potential usage scenario like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public class BusinessLogic { ISomeKindOfValueStore someKindOfValueStore; public BusinessLogic(ISomeKindOfValueStore someKindOfValueStore) { this.someKindOfValueStore = someKindOfValueStore; } public void Run() { someKindOfValueStore.SetValues("MegaCorp", 2.3, 4.5); // more logic in here } } |
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.
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 has been pretty busy for me – check out this list of professional as well as personal activities:
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 :).
This is what I’d like to do in 2011:
Actually I should have hightlighted that last bullet – I guess it pretty much sums up my main goal for 2011 :).
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.
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.
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?
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! :))