Posts

Our teams lean heavily on ansible for templating and the final configuration of virtual machines. That brings up the question of how to make sure deployment scenarios actually work and stay correct.

This post is about faking systemd inside a docker container and validating the end result with the testinfra framework.

Technical Breadth is a term I first heard, in English, from the architect Mark Richards. The Russian rendering would be something like “technical horizon.” The designers’ equivalent is having a “trained eye.”

What do you do with this idea and how do you broaden your own technical breadth?

Semantic Workspace is just a fancy name I came up with about half a year ago for a small set of simple principles for organizing the projects directory on your local machine.

All of our services follow the 12-factor methodology. This post is only about one factor in particular — configuration via environment variables, and specifically about the underrated direnv, which automatically loads environment variables when you cd into a project directory.

This post is about running a deferred-task queue inside a database. In practice, a lot of developers struggle with the idea — they immediately raise concerns about the artificially generated load. On one hand, that’s a fair point. On the other, it’s the kind of barrier you have to learn to step over: watch your application and tune the database properly.

In day-to-day work we constantly use various tools: protoc, golangci-lint, allure, and many others.

To avoid situations where one developer’s tool version or configuration differs from another’s — or from what’s set up in CI — our tools are “baked” into containers.

This post is about “real” virtual machines, not container-based virtualization. So the “you can just stuff it into Docker” reflex doesn’t quite apply here.

Building cloud services means we constantly use virtual machines. In production, type-1 hypervisors — the kind that, simply put, run on bare metal; on our local machines, type-2, the familiar ones — VirtualBox, qemu, and possibly Parallels Desktop.

Sadly, despite all the modern build systems available, we still end up using make and writing Makefiles by hand.

I needed to put together a help screen for the build targets in a project’s current Makefile. Out of the box, the ancient utility doesn’t give you a list of build targets and their descriptions — it was never meant to.

All of our project documentation is written in Markdown. It’s a simple, convenient format you can read in raw form without any post-processing.

I often need to experiment with monitoring settings and error/metric collection across various environments.

Rather than carving out a separate project in our shared Sentry, I prefer to spin up my own local copy.

The deployment takes a while; on an “old” laptop it can take about ten minutes.