I like to use NixOS on my servers, it makes dealing with upgrades easy and provides a good deal of stability. The declarative configuration is a game changer - I can rebuild my server setup anywhere with minimal hassle.

I’ve recently purchased a Hetzner EX44 dedicated server, and despite a good number of blog or wiki articles about how to deploy NixOS on baremetal at Hetzner, I did not find one that worked out of the box for this specific model. So here is a quick recap of how I’ve managed to configure the server.

In his article Practice of Reliable Software Design, kqr offers compelling perspectives on software design principles.

His thoughts on building reliable software carry significant implications for both developers and stakeholders alike:

It is much easier to add features to reliable software, than it is to add reliability to featureful software.

This quote illustrates a common misconception in software development cycles. Many organizations misinterpret the principle of shipping early, viewing it as permission to rush out buggy features quickly. However, the value lies in delivering small, reliable components first, then iteratively building upon that stable foundation. This approach gives us practical insight into our design decisions and their real-world effectiveness. Another important but frequently neglected aspect kqr highlights is the importance of establishing clear boundaries and limits in our systems.

I’ve learned through experience that seemingly functional code often breaks down precisely because it lacks defined constraints, eventually depleting critical resources. When these issues emerge, implementing fixes becomes increasingly difficult and expensive. That’s why designing a system, should includes deliberate consideration of it’s intended capacity, imposing appropriate limitations rather than allowing unchecked growth.

The article also explores other significant aspects of reliable software design, such as the importance of testing, simplicity, and working with existing solutions. A thoroughly enjoyable and insightful read!

I’ve been heavily using claude-code since its release and have found it to be one of the most powerful LLM-assisted coding tools on the market today.

There was just one problem: it’s not available on NixOS which my home computer is running on. I decided to package it myself.

Fortunately, the packaging process turned out to be relatively straightforward, though with a few interesting challenges. Since claude-code isn’t open-source, we need to work with the npm-hosted version.

I’m documenting my packaging approach below to help fellow NixOS users who want to use this tool.

Prosopite, recently featured in Ruby Weekly #740, emerges as a promising alternative to the well-known Bullet gem. This newer tool offers a more streamlined approach to detecting n+1 queries in Rails applications while boasting improved accuracy with fewer false-positives.

N+1 queries often significantly impact application performance. Having reliable detection tools in our arsenal is essential for maintaining efficient database interactions.

I’ve recently dealt with removing N+1 queries on an application, leading to 2x latency improvements. That system also suffered from another kind of N+1 problem - it looked up a ton of cache keys in Redis, which I’ve changed to a single lookup, avoiding unnecessary roundtrips to the cache.

Honyaku recently featured in Ruby Weekly #740 is a tool built with LLM-powered tools (Cursor and Claude Sonnet 3.5) to automatically translate Rails locale files.

While automated translation isn’t revolutionary on its own, Honyaku’s business impact is striking:

Created because it replaced a $34K/year SaaS contract and streamlined our deploy process.

This case perfectly illustrates the power of focused software development: building a targeted solution to a specific problem can drastically cut costs.

It’s fascinating how this practical approach often delivers better, more efficient results than using off-the-shelf, expensive services.

From my experience, this problem-first mindset typically leads to solutions that are both simpler and more economical.

rails-diff via Ruby Weekly #740 is a tool which allows comparing the files generated by Rails during the installation or upgrade process with their current version in the local repository.

When dealing with Rails upgrades, or with generator *:install commands, I often find that figuring out the diffs and what needs to get updated or removed is the least enjoyable part of the process.

I have yet to try this tool, but lately I’ve been thinking of a few ways to improve this process:

1. Make the diff easier to deal with by adding your own edits at the end of the generated files, unless changing a generated option value.
2. Move your own changes to dedicated files which, by limiting the changes to the generated files to a minimum, would make dealing with diffs easier.

Either way, I’ll try these approaches on our applications at work and hopefully make upgrading Rails an enjoyable experience.

In olmOCR, Simon Willison shares an interesting piece of software. OCR is, as far as I know, a resource-heavy and costly process. Unfortunately, the article doesn’t mention the latency of the process. I find the concept of “document anchoring” really interesting, and I appreciate that they released a training dataset, which is still relatively rare these days.