Don't hold me accountable for old opinions

Once in a while I get a comment about something I wrote a long time ago and sometimes that is embarrassing as the opinion I expressed a while back might not be how I feel today on that subject. Hence I decided to look into some old blog posts and see how bad it is...

Linux performance investigation in 60 seconds

Since it is new year's eve I'm going to make it easy for myself.

Your new BFF

I think it was a few years ago when Netflix blogged about how each client had their own server component and how this made the client development easier. A few weeks ago I read about this again in the context of micro services. The term Backend For Frontend (BFF) was coined.

Yet Another Code Coverage Rant

Instead of me ranting over why code coverage measurements can be good but in general are used in the wrong way; why don't I let somebody else do it for me...

Do I need to remove the Server header from my HTTP responses?

You might have heard the recommendation that your web server should not return the Server header to reveal exactly what software is being used. It even says so in the RFC. Given how hard it was to remove the Server header when using .Net HttpListener you might wonder what is really the right thing to do here.

Web service scale testing

When I say web service scale testing I mean testing to figure out how many instances of your service you need. This type of testing is really easy to explain but typically hard to get right.

Yet another retrospective idea: Successes, Frustrations and Opportunities

During a training I was teaching recently we were talking about retrospectives and different ways to make them interesting. Afterwards one of the students came forward and suggested something interesting.

Is logging raw HTTP requests ok?

When you are working on services that need to scale to millions of users you typically come to the conclusion that you will never be able to start a debugger on one of your live services. Instead you need instrumentation (also known as logging, tracing or diagnostics) to make sure you can figure out what went wrong. What I see happening a lot is that developers start logging the raw HTTP request to capture all data. And there are several problems with this approach...

Writing your own LINQ extension methods?

I stumbled upon this article with "best practices" for writing your own LINQ extension methods.

Preventing DoS attacks with puzzles

So when a web service is getting too much traffic it starts returning the 503 status code. Well written services also return the Retry-After header hinting the client when it should come back again. Good behaving clients then respect that or will back-off by themselves to make sure the server is not getting too much traffic. However this is not enough if there are bad behaving clients in the mix. And how do you identify the bad behaving clients?