Dmytro on Things

Sometimes we need to run a child process and read its output: it could be ffmpeg to convert a video to another format or apply a watermark, or run pgdump to backup a database. When the process we are running is noisy, it often can lead to unexpected deadlocks, which is the point of this post.

While reading “Service Model”, a book by Adrian Tchaikovsky, I was first fascinated by the librarians, and then later awestruck by the elegance and silliness of their idea. This post will explore a potential implementation of the algorithm, a little bit of exploration of Async in Ruby, and some spoilers for that part of the book. You have been warned.

We often use temporary files when building software: to store a report before sending it to a customer or uploading it to AWS S3; to download a CSV to parse into a database; or to store a picture of your beloved cat before sending it to the generative AI to put a silly hat on the unsuspecting feline. Today, I will talk about common mistakes with temporary files.

Most of the base images in the Docker registry do not offer immutable tags. This means that if you’re building your Docker image based on, for example, an official Ruby image ruby:3.3.0-slim, it might change overnight, and the machines that have already downloaded this tag will never receive an updated image.

Now and then you receive a report about something not working as expected. This time it was scarier than usual: a job, killed by Docker after consuming too much memory with an OOM error, was disappearing from the queue without a trace. In production, we deploy sidekiq-pro for its reliability guarantees, specifically super_fetch strategy for pulling work from the queue, and normally should re-queue the job after a restart.

The idea to restart the blog was lingering in my brain for quite some time. It was never the right time: sometimes I was not sure I have anything to say, often it was dissatisfaction with the available tools and a fear of the amount of effort this endeavor will require. But sometimes you have to accept that things will not be perfect from the start, and some tinkering will be always required.

Nginx is a powerful HTTP server, often used as a reverse proxy for all kinds of service configurations. But even though it is well documented and understood, there are still questions that have contradictory or incomplete answers. One of them is HTTP client header parsing configuration settings, which you normally tweak when nginx returns error 400 and you see “client sent too long header line” in the log.