512 days or 17 months or 1.5 years. That’s the time between todays post and my last one. Not as long as the Duke Nukem Forever development time, but it still strikes me how much time has gone by since I’ve written something down here.

Today is probably going to be a very personal post and for that matter also non-technical one.

In case you haven’t heard it yet, I’m going to give 2 talks at this years prio conference.

I’m very exited to be part of this years speaker line up (though the quality of the line up is a bit intimidating ;-)). Both talks will be on the 20th of October in Track 4

• 10.05 – 11.05h, Introduction to Rhino.ServiceBus
• 15.20h – 16.20h, (ServiceBus) Patters for always responsive clients

Looking forward to see you there …

I haven’t blogged in a while, mostly because time has become such a limited resource in the last weeks or to be honest actually months. Blogging, my current project, workshops, the F# Bookclub, preparation of the next conference appearances and of course xUnit.BDDExtensions all want a piece of that cake. Finding the right balance between those tasks is often not as easy as I would like it to be. More often as I like skipping blogging seems to be the easiest way to regain some time. I’m really sorry for that, but you know I try to do my best. On the other hand this is a new blog post, so things can’t be that bad, can’t they? Although I haven’t slept much the last 3 days, something inside me urges to write this post.

Yesterday’s F# bookclub meeting in Munich was awesome as usual. It’s very interesting to see our overall understanding of functional programming progressing. Slowly, but steady. Main topics we discussed on the last meeting were Currying and Tail Recursion. Finally “got that” (at least I think so ;-))

Two meetings ago we decided to do some coding on every meeting. The previous meeting we solved Kata FizzBuzz and on yesterday’s meeting we tried to dance with Roy Osheroves StringCalculator. We didn’t make it completely to the end, but I think we solved most of the Kata.

Last F# book club meeting in Munich was awesome (as usual). 2 weeks ago we decided to do a Code Kata on each subsequent meeting. This week was our first, with Kata FizzBuzz.

A lot of my free time currently goes into learning F#. While I had a great time playing around with the F# REPL FSI, I came to the conclusion that using FSI is not my preferred way of a) learning the F# language and b) to develop code. Writing unit tests simply for the purpose of learning and understanding of a language/component/system (aka "Learning tests") seems to be a better fit, at least for me. So, I sat down in order to see how I can use my beloved xUnit.net for this. As it turns out it’s not that difficult, but it’s got some hurdles.

This is just a quick update of an older post of mine. Since StructureMap’s convention API has changed quite a bit, here is the updated version of the code used in the post using the new APIs introduced in StructureMap 2.5.4.

Crap, time can go by so fast. On Monday a tweet by Ralf Westphal caught my attention and I felt the need to comment. It started as a series of Twitter replies, but to be honest Twitter isn’t suited or made for those kind of discussions. So I started to write this post in order to explain why I disagree with Ralf (or at least don’t get the intended message of his tweet). Yeah a short look into the calendar indicates that I’m a little late, but I thought better late than ditch the post and forget about it.

What got me baffled

In his tweet he basically states (my translation from German to English) that

If a domain model consists only of POCOs it should be called data model

My first thought was a) does he mean anemic domain models and b) what has POCO to do with that? As I found out he didn’t mean anemic domain models. So let’s take a look at the POCO aspect.

One of the things that can hit you really hard when writing blog posts about open source software (like StoryTeller is), is the fact that your posts tend to get very fast outdated, especially when you don’t pay that much attention to the detail (like I did, sigh). If you’re not aware of what I’m talking about, it’s StoryTellers command story. I’m not sure when it changed but it definitely has changed and I needed to update my last post 11.2 quite a bit in order to reflect the changes. Today I would like to conclude my trip through StoryTellers UI infrastructure with a look at how Commands are integrated into the Screen Activation Lifecycle.

We’ve recently started to migrate all of our Windows Services from a classic ServiceBase based approach to the hosting framework Topshelf.

Previously we used the standard ServiceInstaller / ServiceProcessInstaller tandem to integrate our services with MSI deployment. This does not work with Topshelf (since Topshelf does the service installation itself via the Registry). However it’s pretty easy to write a custom installer for that. You can do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public class TopshelfInstaller : Installer
{
    private const string AssemblyIdentifier = "TopshelfAssembly";
    private const string InstallUtilAssemblyParameter = "assemblypath";

    public override void Install(IDictionary stateSaver)
    {
        var topshelfAssembly = Context.Parameters[InstallUtilAssemblyParameter];
        stateSaver.Add(AssemblyIdentifier, topshelfAssembly);

        RunHidden(topshelfAssembly, "/install");

        base.Install(stateSaver);
    }

    public override void Uninstall(IDictionary savedState)
    {
        var topshelfAssembly = savedState[AssemblyIdentifier].ToString();

        RunHidden(topshelfAssembly, "/uninstall");

        base.Uninstall(savedState);
    }

    private static void RunHidden(string primaryOutputAssembly, string arguments)
    {
        var startInfo = new ProcessStartInfo(primaryOutputAssembly)
        {
            WindowStyle = ProcessWindowStyle.Hidden,
            Arguments = arguments
        };

        using (var process = Process.Start(startInfo))
        {
            process.WaitForExit();
        }
    }
}

The interesting part is this line:

1

var topshelfAssembly = Context.Parameters[InstallUtilAssemblyParameter];

Took me some time to find this. During installation the Parameter Dictionary attached to the Context contains the full target filename of the assembly being installed (key is assemblypath). With this path you can directly launch the /install or /uninstall command for the Topshelf based exe.

HTH

P.S.: This resource pointed me in the right direction.