Posts

Hi! Petr Korobeinikov here again, tech lead for the Redis and RabbitMQ services at #CloudMTS. Today we’ll talk about the single most important component of Developer Experience (DX) – the developer’s local environment. Or rather, about how to make it spin up fast and automatically, and also keep it uniform across every member of the team.

I’ll share our approaches and point out a few things that may be specific to developing cloud services. In this article I won’t get into implementation details – everyone’s implementation can be different. But I think the approach itself will be useful to many.

Soon I’ll need to add another language to my stack — Kotlin. The process of getting comfortable with the syntax doesn’t worry me; that’s the easy part. As always, what I care about most is making the setup simple, fast, and reproducible — especially the local developer environment. I won’t be the only person on the team, and it matters that my coworkers’ compiler versions line up with mine down to the patch.

Hi everyone! Petr Korobeinikov here again, tech lead for the DBaaS for Redis and RabbitMQ (release coming soon) services at #CloudMTS. In this article I want to share some of my experience preparing for algorithmic interviews. Of course, this isn’t an article about hardcore algorithms – it’s more of a rough sketch of a prep roadmap. Still, I hope it’ll be useful to newcomers (and even to a few “old hands”).

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.

Hi! I’m Petr Korobeinikov, tech lead for the DBaaS for Redis team at #CloudMTS. Some time ago I set out to build a common toolkit for our development teams. The goal was simple: a developer doesn’t waste time digging into how a specific tool works, takes the ready-made instructions, and simply does the job – writes code. A standard environment helps people move from team to team and adapt quickly, and makes it easier for newcomers to get started.

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.