In this blog post I will briefly explain some of the most common DNS record types. A (address) record: always points to a static IP address. AAAA record: the same as the A type record, but for IPv6 IP addresses. CNAME (canonical name) record: alias to another name (=domain), which can be an A record or another CNAME record. The only exception is that you cannot create a CNAME record in the zone apex (the root of your domain).

I read at least 25 books per year, both fiction and non-fiction. I have also worked out a system in order to get as much out of each of these books as possible, and most importantly to actually remember what I read. Today I would like to share my system in case it might help someone else. This is how I read a book. What to read This might sound like an obviously important topic, but don’t worry too much about what to read.

Finding out how much traffic your site has and how your users interact with it is always crucial. Such information will enable you to scale your backend properly, fine-tune the user experience and weed out unused features. Some even go so far as claiming that data is the “gold of our time”. Regardless of the truth of that claim, few can dispute the usefulness of user analytics data. The go-to solution for most developers is to use Google Analytics (in fact used by 55% of all websites) or some other third party framework.

A common challenge in software development is how to decide and then fulfill non-functional requirements, such as the maximum response times of your API. Two metrics to consider is the average response time of a certain endpoint, as well as the percentage of outlier requests that will fall outside of the accepted time bounds. Such outliers will always be there, especially when designing a microservice architecture using lambdas with their dreaded cold starts which is common these days.

I believe software developers have just as high ethical responsibilities as engineers within other disciplines. Many engineers (and other professionals) do for example not want to work with weapons, animal experiments and so on. My opinion is that you should consider the ethical implications of your work even if you are within a more “mundane” field such as e-commerce or game development. This is especially important considering the fact that we are just a limited number of people with the knowledge how to develop the applications that are used by the majority of the world’s population.

In this post I will describe a number of best practices I find useful to keep in mind when writing tests. It is intended to act as a complement to my previous post, A successful testing strategy. Code coverage “100% code coverage tells you nothing, but less than 100% code coverage tells you something.” – Unknown Aiming for covering 100% of your code with tests is probably not realistic and perhaps not very useful neither.

Today we will a closer look at the classic testing pyramid and see how we can transform that into a concrete strategy for how to write your tests. While the terminology I use is not exactly the same as the one used by Mike Cohn when he first described the testing pyramid in his book Succeeding with Agile, the core concepts remain the same – a strong foundation of unit tests, complemented with a sufficient number of component tests (which are similar to Cohn’s service tests) and sprinkled with a few end-to-end tests (which are called UI tests by Cohn) as a last line of defense.

In this post I am going to give you an overview of different approaches to use when unit testing your backend code and database calls. Background In my current project, we have a backend written in Go and a PostgreSQL database. We have for a long time been writing unit tests for the backend to be able to guarantee that the code is working as intended. In order to not have to rely on a database connection and be dependent on the state of the data in that database, we chose to mock away all database calls using a tool called go-sqlmock in the unit tests.

What is commonly referred to as the Unix tools are a set of commands that are available on all Unix systems. Together, these form part of the basic toolkit for any serious software engineer. You should learn how to use these tools properly, as they can grant you an enormous boost in your daily workflow, and not the least when it comes to automating task and routines, such as in your team’s automated CI pipeline.

Everything in nature goes in circles. Days turn into night in a circadian rhythm. Seasons replace each other. Even life itself is iterative. In every generation, a small number of genes gets changed due to random mutations. I’m not a biologist, but through some quick googling I found out that the human genome changes with a mutation rate of about 10-8 per generation. This is obviously a number that natural selection has arrived at and found optimal.