I’ve been playing around with refactoring a Koa application to use modern JavaScript constructs like async, await => and do away with generators etc.

In doing so I had an epic battle with mocha, monk and supertest to use async / await etc. I finally found a good structure for this purpose that I wanted to share.

The case

This will be small but not too contrived. The test will store an object in a MongoDb database, then will call an HTTP-endpoint (/user/:id) that simply returns that object for us again.

To do this we will have to await the call to mongo using monk, then do the request using supertest and finally use supertests own asseration features to ensure that we get back what we expected.

I started with a simple setTimeout...

This is the fifth and last post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application - this post

The last post ended with us finishing refactoring the individual part applications. The time has come to the orchestration app on top. If you remember from the very first post I had done this to show a feature of...

This is the fourth post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application - this post
• Part V - wrapping up by refactoring the root application

In the last post we made significant progress and now have some very modern and neat looking tests. That run and pass. Time to turn our attention to the system under test and give that an overhaul too.

Keep the test...

This is the third post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing - this post
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application

We have done some progress cleaning up and linting our code.

Moving to async over generators - tests

This is pretty good, but not there yet. There’s a major thing bugging me and here is where we need to start...

This is the second post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit - this post
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application

In the last post we just go the test to run. So now we can start to do some:

Simple refactoring and lint

Perfect! With passing tests I feel much more confident to make changes. And I want to. This...

I have learned so much by following the Koa Js community and framework over the years. My first post on the topic was written in March 2014, when Koa was just a little tiny bird trying out its wings (look up that reference…).

From that point I’ve written many posts, done a few screencasts for fun and other for profit.

4 years (MY GOD!) is a long period but in the JavaScript world it’s eons of time. I noticed that the other day when I refactored one of my later Koa applications into something more modern. I learned so much about the topics that I ran into, while upgrading my code and the resulting code was much more elegant, functional and understandable.

So… I thought I’d do it again. This time you can tag along. This post will be long, but hopefully worth it.

Read More

I have a very particular set of memories from my childhood, that revolves around me falling, hitting or otherwise hurting myself. If it was just a bruise my father often said to me:

How bad is it? Is it worth crying for, like you do now?

(I was probably exaggerating quite a lot). Of course, it was!

Tell me, what are you going to do if it really hurts, then?

That was maybe not pedagogically correct for a child in pain but it at least got me thinking. Indeed… what comes after screaming and crying? Could I turn this up? Would it make a difference? Would I get … yes, what was it I wanted, really? Maybe just a hug or comfort. Could I get that by other means of communication that the display I was putting on now?

Of course, 7-year old Marcus didn’t reflect...

I talk a lot about flow these days and I’m continuously fascinated how many good things follow by shifting our focus to supporting a better, faster and smoother flow.

In this post, I just wanted to share a few thoughts that have been on my mind lately.

Flow of what?

This picture above is my favourite picture on the net. I have done a 2-hour lecture on lean with this as the only slide.

I will not go into all details, that can be observed and learned from this picture, but note how much value that gets delivered. You can tell but I’m sure that poor animals legs are plenty busy, running for his life with fear. That business doesn’t help much. None of the bags on the trolley gets delivered.

At this point I often ask:

What is the simplest and...

I once worked at a large company where they had so many priorities 1 features that they decided to introduce … bam-bam-ba-baaaa … Priority 0. But after a few minutes, we ended up with about 5 items in that category and we realized the ridiculousness of continue to do Priority -1 etc.

Today I saw this pattern in action again, and a new realization about a missed teaching opportunity washed over me. I wanted to share this with you in this post.

The team I’m working with right now have a long (50+) backlog of items that are due to work on. Their team lead created a nice visualized board with the priorities for the top 15 items. It is great and super clear what they are prioritizing. Priority #1 is to be worked first and if you cannot do that you can pick up #2 and so...

The last couple of weeks I have been re-discovering an old diagram (eerm … sketch really). You can find it scribbled on close to every whiteboard in our office now. Because it opened a lot of interesting discussions on flow, flow efficiency and optimizations for value delivery.

I wanted to share this with you here, in a few iterations and also share some of the discussion that it triggered.

First of all, this came up as we had a process that was taking a long time. Too long. It involved a few people from different departments that needed to do their work before handing it over to the next department. And then there was a user acceptance testing phase in the end that of course took a long time.

The backlog of work is growing much faster than these people are completing work. High stakes, stakeholders, and customers...