Simple .NET standalone web server

The other day I got frustrated that I couldn’t find a code example of a simple .NET OWIN standalone (i.e. not using IIS) web server (i.e. not a REST server) for .NET. After some research and trial-and-horror I came up with the following:

using System;
using System.Diagnostics;
using System.Net;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
using System.Web.Http.SelfHost;

namespace WebServer
    class Program
        static void Main(string[] args)
            const string serviceBaseUri = "http://localhost:4578/";
            var config = new HttpSelfHostConfiguration(serviceBaseUri);
            using (var server = new HttpSelfHostServer(config, new MyMessageHandler()))
                Console.WriteLine("Press Ctrl+C to quit.");

    public class MyMessageHandler : HttpMessageHandler
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
            var res = new HttpResponseMessage(HttpStatusCode.OK) { Content = new StringContent("Hello, World!") }; 
            var tsc = new TaskCompletionSource<HttpResponseMessage>();
            tsc.SetResult(res);   // Also sets the task state to "RanToCompletion"
            return tsc.Task;


The Mikado Method is deal of the day today!!

The Mikado Method book at Manning is Deal of the Day today the 14th of May!

Use the code ‘dotd0514au’ (without the quotes) for 50% off at

The Mikado Method Book at Manning

I only write when I feel have something important to tell, and now I do.

Me and Ola has been working on our book about the Mikado Method for quite some time now. First as a free PDF, and now as an upcoming book at Manning: The Mikado Method

At the moment it is in the Manning Early Access Program, which means you can buy it and be a part of the process by sending in your thoughts and feedback. The new book is a thorough rework of what we had before, so hopefully you will find it worth it even if you read the PDF already.

We’ll post the most recent stuff about it at @mikadomethod on Twitter.

What is Software Architecture?

The other day I got a nice LinkedIn email from graduate student asking me if architecture can evolve from continuous refactoring. There were a couple of questions about where it worked and where it didn’t, and I started wondering what was really meant by “software architecture”. Well, at the bottom of the email was RUPs definition of software architecture:

“The set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements, the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.”

WTF? What does that mean? What are they trying to say? That architecture is everything? If architecture is the significant decisions, what are the insignificant decisions?


Technical debt

My preferred definition of technical debt is:

Technical debt is existing (technical) structures that stand in the way of making the next change. The interest is the cost of having to deal with those structures in your day-to-day work, and the down payment is the cost of making the structures apt for use.

Debt can be intentional in that you take shortcuts to meet an important deadline or to hit a market window. In this case you have an expected ROI for the loan you take, one that you hope will pay off more than the cost of later fixing the shortcuts taken.

Debt can also be the unintentional, and here it gets interesting. One type of debt is that which results from sloppiness, usually resulting in a messy code base. This type is not related to any kind of investment, hence there is no expected ROI, it is just like  a loan for consumption of drugs; it will destroy you (your code) and your economy if it doesn’t stop.

By the definition above, debt can also be the result of external events, sometimes out of your control. Your perfect system can suddenly become your largest debt if you go from one to several customers, the company strategy changes, the market changes or laws change.

Some people, among them Uncle Bob in this article, argues that messy code is not debt. I disagree, for the reasons above. I think Uncle Bob and others confuse debt that results from loans taken to make an investment, and debt resulting from neglect, lack of experience or incompetence. The cause is totally different, but you’re still in debt.

There is no reason to make a messy system, since there simply is no return on that investment. Accept debt only to take loans that enable you to make a sound investment.

You are a leader. Yes, you!

A couple of years ago I was attending the course “Secrets of Agile Teamwork – Beyond Technical Skills” by Esther Derby and Diana Larsen. It was a brilliant course, and so far, I have had more use of it than any other course I have attended or book I have read. In the special Esther-and-Diana-style (you must try it if you get the chance), we learned about communication, conflict, feedback, change and leadership. We also learned a lot about ourselves from reflecting over how we behaved in different situations. Highly recommended!

One section in the course was “Team Leadership Activities” and that would prove a real eye-opener to me. It is a great tool to view a team through, to understand what makes a team move forward towards their goal and how you can contribute.


Jambda 0.1

I just released Jambda on Github, a small project in which Johan Kullbom and Joakim Ohlrogge has taught me all I can absorb about functional programming. I have mostly contributed with documentation using my tool Bumblebee in order to learn the concepts. The code is mostly written by Johan.

Jambda is a small Java library with typesafe implementations of options, unions, curryable functions, and a bunch of sequence functionality, like map, fold and filter.

The result is also a rather interesting use of Java generics where we probably have pushed the generics implementation to the limit (I say “we” but mostly I mean Johan).

The documentation is available here. Check it out! Any feedback is welcome.

Previous Older Entries