In this blog post I will describe how I set up my own web server using just a single Raspberry Pi at home. This is a cheap and fun solution to hosting your own applications, in my case using Docker. Setting up the Raspberry Pi Install the Raspbian OS on your Raspberry Pi’s SD card. In order to connect wirelessly to the Raspberry without having it connect to a monitor, you need to set up headless SSH.

A limitation to all web development frameworks is that environment variables has to be injected during build time in order to made be available in the browser. If we have packaged our web application using Docker, that means that we would need to build a different container image for each different environment where we will want to host our application. This is a waste of resources and also introduces a risk of us ending up with a different codebase in our production environment than what we tried out in our QA or test environment.

In this blog post I will describe how you can deploy services on the same server. The server will be fronted by an NGINX instance acting as a reverse proxy responsible for forwarding incoming traffic to the right service. I will use an EC2 instance on AWS since it has a low monthly cost and I don’t have to worry about hardware maintenance at all, but you can use the same approach for any kind of server.

A common requirement for most serious applications is to be able to produce audit logs: information about which user has accessed what information and when. In the .NET Core 5.0 API we are building right now, we decided to implement this functionality as a middleware that will automatically be executed upon every request to the API. We want to log the response actually sent back to the client, so it’s important that we put our new middleware first (or at least very early) in the HTTP request pipeline.

A while ago, I stumbled across the weirdest error I have encountered so far during my software development career. It happened after a routine bump of the WordPress version running the WooCommerce web shop of my record label. Everything seemed to be running fine, but then one customer reported that the checkout was broken (very bad for a web shop). I verified that I could reproduce the error on my own and started troubleshooting.

The quality of the code reviews within your organization will over time have an huge impact on the overall success of your business. Missing or poor code reviews will lead to deteriorating quality and much headache will follow, while good code reviews will ensure that your code base maintains a high and increasing quality. More importantly, code reviews also acts a way to share knowledge within the team. Therefore properly carried out code reviewing is one of the best, cheapest and fastest ways of acquiring skilled developers.

Currently I’m learning Kubernetes and Flux. Two of my top three favourite methods for learning something is to write about it and to teach it to someone else. This time I combined the two into a short tutorial on what I have learnt so far. If you are interested, you will find my Kubernetes tutorial on Github!

Let’s take a simple example from the world of JavaScript, where we can’t be certain of the type of a variable up front. Let’s say we have a function (myFunction) which we can either pass a string or an array of strings. If we pass it a string, we want to do something with that string. If we pass it an array, we want to do the same thing for each element in the array.

If you have ever run Java inside a lambda function on AWS, you will have noticed the quite significant cold start times that comes with spinning up the JVM environment. In this post, I will discuss some different tricks you can use to minimize these cold start times. The problem with cold starts arises when there are no “warm” lambda available to handle an incoming request, which usually happens whenever an endpoint experiences a large and sudden spike in traffic.

When setting up a new DynamoDB table, an important decision is to decide what primary key to use. However, it’s not uncommon to not have the full picture up front and therefore it could be hard to make the right decision beforehand. While the official AWS documentation states that “you shouldn’t start designing your schema for DynamoDB until you know the questions it will need to answer”, you often need to experiment to be able to discover what those questions are.