Many of us use more than one computer for work. And we use, if not identical, then overlapping sets of applications and tools that need the same configuration on every machine:
gitvim/nvimtmuxeditorconfigkarabinerzshThese configuration files are usually called dotfiles — their names start with a dot (.), which in the world of Unix-like systems makes a file hidden.
One of my subscribers pointed out that the source code for the solutions we put together on stream wasn’t publicly available. To be honest, I didn’t think it would be useful to anyone outside the stream context — we show the process of solving a problem, shaping it into a workable result. Turns out I was wrong, and the source code is interesting on its own.
I recently got over the awkwardness and finally followed through on a long-standing idea — I launched a YouTube channel. I’ve always wanted to show and talk about approaches to development without clickbait thumbnails and headlines, to stay on point and pass my experience along to other people.
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.
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.