Posts

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.

Many teams discuss and maintain ADRs using tools like Confluence and Wiki. We all know perfectly well that this is a “write once, read never” approach.

ADR — Architecture Decision Record.

I keep running into engineering teams that underestimate ADRs.

asdf is a runtime version manager.

It can replace nvm, rbenv, pyenv, gvm, and a pile of other version managers with a single tool.

jo is a command-line json builder.

I often see coworkers in chats passing around request snippets or API call examples with the json baked in as escaped strings.

This coming Saturday, the Avito Moscow office will host a PostgreSQL championship. It’s a database administration competition built around hands-on tasks. We built it on a platform assembled entirely from open source components. We’ve already tested it in two internal competitions (turned out to be interesting), and now we’re getting ready to run #PGHACK for anyone eager to test their Postgres chops (we’re still accepting entries – link at the end of this post). In this post I’ll talk about how we prepared the platform for the championship.