Inter service communication: message bus

Last week we covered request/response communication and now it is time to talk about the complete opposite; message bus communication.

Inter service communication: request/response

Over the next few weeks I will cover a number of different ways to services can communicate with each other. First out is the classical request/response.

Code Coverage and nothing is too simple to test

So time to look back again and update some old opinions from June 2008. And while there are some other useful stuff in there I'll focus on code coverage and testing simple things. Because I feel the urge to explain myself...

All you ever wanted to know about Feature Toggles

Feature toggles can be used for several reasons. They can be used to avoid branching (for some people that is important), test things in production, A/B testing, a safety net or to enhance the experience for certain customers. Regardless of what the reason is the basics are the same.

Go, maps and randomization

A couple of years ago it was very easy to DoS attack .Net web services as the headers were added to a dictionary. Back then the hash of the key was predictable so using a bunch of machines in azure and a few days it was possible to generate enough strings that resulted in the same hash value that you then could make a fake request with a lot of headers (a few hundred is typically enough) that caused the web server to spend 100% of CPU searching and updating the header dictionary. Since I recently started doing some work using go (aka golang) I immediately started to wonder how this worked in this language.

ET/U/LP over MVP

Well sometimes my life is easy. Or you could say I'm cheating because today I'll just hand it over to somebody else...

Books, Mocks and Open Source

So time to look back again and update some old opinions from May 2008. This time I'd like to talk about three old articles.

What does a good exception message look like?

Today I have to bring up a great article that is over a year old. They topic is what exception messages really should look like. As bonus I would like to increase the scope of the discussion to also include log messages and test failures.

Alternatives to hydrating IEnumerables

You should know that whenever you get an IEnumerable you should only enumerate it twice as some implementations don't allow you to enumerate it twice. Normally you don't get an error the second time - just no more items. But what is really the best way to handle this?

Assigning vs picking tasks

If you have followed this blog for a while you know how important I think the choice of words are. But the difference between assigning and picking tasks within a team might be bigger than than you think.