Testing a periodic worker

I came across somebody that was asking about how to test their code. They had a function that would do certain work at short intervals and then some other work after a longer period of time. They provided a simplified version of the code and it looked something like this. They had coverage for the short period work (I guess functions foo and/or bar in the simplified example had some side effect they could test for.

Using soft limits to prevent abuse with good user experience

When you develop a service you will probably run into a situation where you want to put in some arbitrary large limit on something to prevent bad behaving clients from using too much of your resources. This can be a max length of the URI, max length of each request header, max size of a request and so on. What we tend to do is often to return some kind of error when this happens and expect the client to fix their request if it is legitimate. But what if it is a legitimate request - just something you didn't expect to be valid? Or what if there is a bug in the client, but the user have no way of fixing the client but rely heavily on your service? Do you really want to completely break your users in these cases?

Go for C# developers: Polymorphism

One of the things I miss the most in Go is polymorphism. I must confess that the lack of polymorphism is one of those things that still annoys me sometimes.

Go for C# developers: 50 things you should know

Once again I can just lean back and relax as somebody else already did my work.

Go for C# developers: All your async are belong to us

Learning how to write "good" go code (in some definition of good) sometimes mean you need to unlearn old habits. This is especially true when it comes to asynchronous code if you have a C# background.

Go for C# developers: Where to define interfaces

When writing Go code the general guideline is not to create interfaces unless it is really needed. A good example would be an interface with only one concrete implementation. Now for the mind boggling part; in C# we would probably create that interface if the type needs to be faked in some test while in Go you wouldn't. Or actually you would. But in a different place...

Prioritizing, responsibilities and open source

November 2008 had a lot of fun reads and I had a great time going over all those old post. But a few things stood out apart from the $1,000 I apparently spent on fraud prevention fees for US visas.

Amazon AWS DevDay San Francisco: Serverless Track

Earlier this week I spent a day following the serverless track at the AWS dev day in San Francisco. I guess serverless is the "new thing" in "the cloud". By building a serverless service you build a service using an infra structure where you don't care about servers, virtual machines or containers but rather functional units.

DRY vs WET

I've always been and advocate for intentionally ignoring the DRY (Don't Repeat Yourself) rule when writing tests if it makes the tests easier to understand. I've even (repeatably) said that some duplication might actually be a good thing when writing tests.

Inter service communication: pub/sub vs message bus vs req/response

Over the last few weeks I've been going over a few different ways to solve inter service communication. So which one is best then?

Inter service communication: pub/sub

In order to distinguish pub/sub from message bus communication I will assume the pub/sub does not use another component to distribute the data as that would be a message bus pattern. I will assume that the publisher knows about all subscribers either statically or dynamically.

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.

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.

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.

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.

Where does the Repository belong?

Historically I've always viewed repository objects as part of the storage layer fairly deep down. But I recently had an interesting discussion that made me realize I never really meant it to be that way.

CQRS types

While the concept of CQRS is fairly simple to explain my experience is that it takes some time to master. The reason is that there are a lot of things to unlearn if you're used to developing your vanilla application.

The Microservice is not what it seems to be

The microservice hype where every application that uses a service should be implemented as a series of microservices is a little unhealthy. Like most technologies; if you don't know what you are getting yourself into there will be problems...

Asynchronous enumerations - again

Almost 2 years ago I wrote about this problem with accessing data from Azure and returning it in a LINQ friendly way. Well not long ago the discussion came up again only this time it was in regard to access data in a Cassandra cluster.