Den där bloggposten om när Hugo sa upp sig från Aptitud

Tidigt igår imorse meddelade jag alla härliga kollegor på Aptitud att jag säger upp mig.

Tanken om uppsägning har jag burit med mig sen början på året men det har varit otroligt svårt att fullfölja eftersom kollegorna och kulturen på Aptitud är så fantastisk(a)!

Hur skulle jag kunna lämna något som jag själv har varit en del i att bygga upp och som blivit så bra?

Så varför sluta?

Jag har jobbat med mjukvaruutveckling sedan 1998 och som konsult sedan 2007; att jag vill göra något nytt är ett svar på frågan. 

Att ständigt utmana mig själv och att inte stanna upp och nöja mig är ett annat svar. 

Att magen säger att det är dags är ett tredje svar.

Så vad ska du göra?

Jag vet inte, kanske något helt annat såsom ambulanshelikopter pilot eller något mer bekant, såsom att starta ett produktbolag som bidrar till en bättre mer jämställd och hållbar värld.

Min sista dag på Aptitud blir någon gång i slutet på Mars och efter det vet jag som sagt inte vad som väntar – det känns spännande!

God Jul och Gott Nytt År!


Nancy and the issue with Enums as strings



The other day I was trying to show an enum property as a string in an Nancy based API.

And I just couldn’t do it at first but later on I found a way. Just so I remember until next time I thought I’d write a step by step instruction.

The initial Code

I’ve created an Empty ASP.Net project and added Nancy.Hosting.Aspnet Nuget package with the following command:

Install-Package Nancy.Hosting.Aspnet

In this project I’ve created a very simple NancyModule that returns a list of a class called TeamMember. Each TeamMember has a Name and an Avatar property that is an enum.

public class Index : NancyModule
    public Index()
        Get["/"] = _ =>
            var teamMembers = new List()
                new TeamMember { Name = "Marcus", Avatar = StarWarsCharacter.Luke  },
                new TeamMember { Name = "Hugo", Avatar = StarWarsCharacter.Chewbacca }
            return Response.AsJson(teamMembers);

Above shows my very basic NancyModule. And the code below shows the TeamMember class and the enum called StarWarsCharacter.

public class TeamMember
    public string Name { get; set; }
    public StarWarsCharacter Avatar { get; set; }
public enum StarWarsCharacter

Above the enum used in my example. This generates the output as shown below.

   name: "Marcus", 
   avatar: 2 
   name: "Hugo", 
   avatar: 6 

As you can see the enum is represented by an integer in the json-output.

First solution

If you do a google search for Enum as string then you probably will find people mentioning that you need to decorate your enum properties with the [JsonConverter(typeof(StringEnumConverter))] attribute:

    public StarWarsCharacter Avatar { get; set; }

So now I can’t build because I’m missing some references. I Install the Newtonsoft.Json Nuget package with this command:
Install-Package Newtonsoft.Json

and I hit the rebuild.

Still the json-output is representing the enum as an integer.

Why? I still haven’t figured out that part yet but if you install the Nuget package called Nancy.Serialization.JsonNet with this command:

Install-Package Nancy.Serialization.JsonNet

Shabaam, presto!

  Name: "Marcus",
  Avatar: "Luke"
  Name: "Hugo",
  Avatar: "Chewbacca"

Next challange

This is awesome! But wait a minute, now my json properties aren’t formatted as I like. The properties start with a capital letter, not like I want.

Solution continued

Don’t panic Hugo, you’ll only need to add a CustomSerializer and a Bootstraper and then it will be alright.

Below is the CustomSerializer class.

public class CustomSerializer : JsonSerializer
    public CustomSerializer()
        ContractResolver = new CamelCasePropertyNamesContractResolver();

And below you can see the BootStraper.

public class BootStraper : DefaultNancyBootstrapper
    protected override void ConfigureApplicationContainer(TinyIoCContainer container)
        container.Register(typeof(JsonSerializer), typeof(CustomSerializer));

The final solution

For a final touch you can remove the attribute JsonConverter all together and configure everything in the CustomSerializer by adding a StringEnumConverter to the Converters.

public class CustomSerializer : JsonSerializer
    public CustomSerializer()
        ContractResolver = new CamelCasePropertyNamesContractResolver();
        Converters.Add(new StringEnumConverter
            CamelCaseText = false

And lastly remove the attribute from the TeamMember class as all enums will be converted to strings as defined in the BootStraper above.

public class TeamMember
    public string Name { get; set; }
    public StarWarsCharacter Avatar { get; set; }


It’s always easy when you know how to solve issues, so here goes the perfect recipe for solving the enum as string issue on Nancy.

The code is as always here. You can find the different solutions as different branches.



See ya later Mob programming, hello parenting

From the Book Vader’s little Princess

Yes you heard me right! I’m leaving my work life for a fulltime life as a father for our daughter Paula, beginning the 23rd of December.

I’ll be on my parental leave until August/September 2016 and I’m excited and really looking forward to it.

I’ve come up with some small tasks/goals that I would love to accomplish during my parental leave.

These are tasks/goals aside from parenting that will be my absolute focus, that goes without saying.

Surely I’ll never finish or even start these tasks/goals but here goes anyways:

  • Complete Fallout 4, hehehe good luck with this one Mr. Häggmark
  • Paint the south side of the house, let’s procrastinate this one until it gets warmer
  • Move blog from WordPress to GitHub pages, this is just a technical journey and I think I can learn lot’s from it
  • Create an Android watch face where the background is a slideshow from Google Photos, well can’t find any good watch face that does this except OneDrive and it has stopped working for some reason.

There you go, I’m all setup for my parental leave but as a last thing a thought I’d blog about all the stuff I’ve learned during my last almost 2 years at TUI Nordic aka Fritidsresor.

If you’re not interested in reading about keeping yourself lean, Agile and fast stop reading now. For the rest of you I hope you enjoy. 

Mob programming

Our team has been Mob programming for more than one year now. It’s still fun and It’s really obvious that we all are so Intune with each other that there is very little discussion on how to solve the basic stuff.

When new challenges arise though we have great discussions about how to best solve these challenges.

By the way I think this might be one of the Achilles heels for Mob programming, after a long while you really need to bring in new people in the mob or your mob will be too tight and unified.

See my previous post here for more info.


While we have made the transition from an agile team to a really agile team thanks to Mob programming, some parts of the organization here has gone the exact opposite direction.

Let’s call the “others” the Empire not because they were evil in any way but because they were large, very hierarchicaly organized and headed straight for their doom.

Our team on the other hand worked like true Rebels (and I’m Chewbacca of course). Challenging the norm that was forming and working fast, small and fighting alongside the huge monster that the Empire had become.

By building an organization that was mostly outsourced, with many different hierarchy layers with release managers and configuration managers the Empire had really set them self-up for trouble with a non-agile work environment with long release cycles and long deployments (yes we’re talking many hours to deploy a release).

At several points, we the Rebels, had to sweep in and rescue the slow Empire because the really didn’t manage to release stuff in time and business was hurting.

There is even a story told that one of the teams in the Empire thought that our Rebel team had 40 (we were 5 at the time) team members because we were going so fast.

What I think is really fascinating is that people working for the Empire thought they’re doing all the right things. In contrast we thought we were doing all the right things before we started to Mob program.

Now we know better.


Another approach that we use in the Rebel team is the concept of MVP. That means that every time a PO (product owner) comes to us with a new task/user story/requirement/whatever you call it/ they will have to argue their case real good to get 100% of their task released out to production.

We often persuade the PO’s that the essence of the task can be released first and then if that works out we can look at the rest. Sometimes “the rest” will never see the daylight of production.

This way of working together with the PO keeps our tasks small and fast.

Less Estimates

We work almost 99% without any planning or time estimates. We work with a continuous stream of work that never ends.

Sometimes a PO will approach us with a task that isn’t an MVP and that she/he want to know how long it will take. Seriously this isn’t a very strange question in fact it’s surely a common question within the Empire for instance.

First of all we try to break things into MVPs (read above) and secondly we try to turn the question to the PO.


-When do you need this “thing” in production?


-I want it at this date x.


-Well that’s not possible but we’ll have this MVP of your task on this X date, good enough?



By turning the question to the PO they will have to engage in the decision and we find that it’s easier to continue the discussion.

Only on 2 occasions during these last 2 years we had to estimate the old fashion way.

Both times that has led to an estimate that was more than 6-8 months which is somewhat insane if you think about it.

Micro Services

Another technique/practice that we use is to build Micro Services. Mind you we don’t have a “written in stone” kind of law that determines the size of our Micro Services.

Instead we use our collective Mob mindset to create smallish components that do one thing great (except for 1-2 Micro Services that do more than one thing). With this comes the included benefit of not writing unit tests. No tests you read, I can see the horror in your eyes. Wait for it…

We write end-to-end tests for the Micro Services and unit tests for very complex rules (there are few in our domain). With the end-to-end type of approach we can verify that the complete (but small) Micro Service is working as expected. Furthermore for some of the absolute smallest Micro Services we skip the tests completely.


The majority of our Micro Services are backend services and they do stuff like this:

  1. Read stuff from an external source like a database table or flatfile
  2. Transform stuff to a json structure
  3. Store json and publish json on event queue

To make this deployable and runnable on Windows we’ve taken the approach to create a Windows Service for every backend Micro Service. This can be a hassle if you use the templates provided in Visual Studio (I sure have had a lot of irritation with them) to create a Windows Service.

Instead we use the TopShelf which makes creating and debugging Windows Services like a walk in the park.


Some of our Micro Services are used by other teams and they like to be notified when changes occur. For this we use RabbitMQ as a mechanism for event based message system.

RabbitMQ is easy to get started with, does the job and it’s free.


Our “frontend” Micro Services mostly do this:

  1. Answer some GET route via http
  2. Read json stored from backend Micro Service
  3. Return json to requester

For this we use the lightweight web framework called Nancy. It’s the best in the .Net world because it so easy and lightweight and nonintrusive.

We could use used Node.js but then we would have to change our deployment mechanism as well.

Octopus Deploy

Speaking of the deployment mechanism, we use Octopus Deploy for all our deployments. And it’s very nice for .Net deployments and has a good API that we call from our builds.

The only drawback is the use of PowerShell within Octopus but that’s whole other rant that I don’t want to get into now.


We use git as our source control and we host all code on GitHub which has been great. Easy to use and good documentation.


We use Jenkins as our build server mainly because it’s free. I believe there’s better build servers but Jenkins does the job nicely and has many many plugins.


Lately we have automated some of our daily jobs like:

  • Create a repo on GitHub
  • Create a job in Jenkins
  • Create a project in Octopus
  • Create a deployment pipeline for a backend Micro Service called Foo (creates repo + Jenkins job + Octopus project base on a backend project and connects it all)
  • Create a deployment pipeline for a frontend Micro Service called Bar (creates repo + Jenkins job + Octopus project base on a frontend project and connects it all)

We do this by typing a specific message in our chat channel (we use Slack). That message is then picked up by our Hubot bot that executes the commands.


Slack is our preferred communication channel because it’s simple and has many connectors like GitHub and the one for Hubot.


There you have it, some of the techniques/technologies that I’ve learned and adapted during the 2 years I’ve been at Fritidsresor. These techniques/technologies are what keeps us fast, lean and small like the Rebels we are.

Looking back to before this assignment at Fritidsresor I’ve worked as consultant in large enterprise projects and I’ve always felt that there was so much potential being lost during those projects. That’s when it hit me like an iron fist in my face.

I too have been part of the Empire.

But somehow this conflict inside me during my time in the Empire has made me choose another side; a lighter side.

Many thanks go out to the ones still fighting fight, you know who you are. Don’t give into hierarchies, estimates or release managers because that leads to the dark side.

May the fork be with you,