nodestorage - this is a peculiar one; the default option on self-hosted sentry was/is to use postgres which is a terrible solution due to how much it bloats the database. Sentry, even on very small instances, produces a lot of records there and you will be pretty much forced into using pg_repack to reclaim the space (which might have its own downside - a major one - which is that pg_repack cannot recover after crashing due to running out of disk space - it leaves tons of hard-to-clean-up low-level postgres bloat on disk).

For the last few weeks I have been riding the wave of codex and claude code free resets (I wonder when the actual price will have to be paid for those tokens, but oh well). This allowed me to continue rewrite of my side project - something which I would normally not do, because who really can enjoy restyling a Bootstrap 2 based website? Certainly not me.

What’s new with slopping design of an app? Nothing new. Inconsistency, reinventing a slightly different wheel for the fifth time, going into crazy workarounds instead of taking a step back and looking at the bigger picture and fixing the root cause. On the upside, in the end, side users’ feedback was mostly positive, but let’s be honest - the bar was quite low - the site wasn’t even properly scaling on mobile and the whole thing was dated as hell.

I did a useless experiment and decided to rewrite a pretty standard Rails app in Go.

Obviously not me directly, I just had my clankers do it. Did I learn anything? Not really. Was it worth it? Probably not.

But first, some history.

I do own DS918+ with just received its last DSM update - 7.4 (you can skip the AI nonsense).

I am really happy with this purchase, as it’s been serving me well since 2018, and I hope it will run for few more years. I run ot it myriad of containers, and fairly recently I even tried moving some workloads from Hetzner to a local Ubuntu VM running on DSM. It’s packed with four 4TB WD Red HDDs since I owned, and in general whole unit has been hassle-free.

If you want to max out this unit further, you can consider the following.

Three years ago, I wrote about auto-ticketing flaky specs (dear lord, please slow down time maybe a bit? kthx).

In the time since, I was loosely consulting on a small/medium Rails project that was struggling with some technical debt - one aspect of which was a flaky test suite. The project had 231 flaky test reports, around 6,600 unit tests, and 342 feature specs running on RSpec, Capybara, and Selenium-Chrome.

Eventually, it reached 0 (zero) flaky tests - which, I think, makes it the only “production grade” project with such metrics I have ever seen in my life. So, one might ask - how can I get there?

Once again I did a full circle and got back to amd64 architecture, technically replacing everything I setup around 3 years ago. This time I will do it right.

After Hetzner rolled out their new cloud offering, it seems like AMD on Hetzner is kinda dead end at this point (don’t quote me on this). So I ended up in a weird situation where I had some old dangling ARM k3s node, some new PoC Coolify ARM-based server and it was time to put it all back together - obviously by setting up a third new project.

I wasted a few last weekends setting up a self-hosted runner set on a Kubernetes cluster just to… that’s actually a good question - I’ve already forgotten why.

So, I have a fairly easy CircleCI configuration for my Rails app. There are a few jobs running on different containers that prepare the dependencies cache, followed by some linters. Then, there are a few parallelized jobs that run tests, a fan-in job that collects test coverage results, and uploads them to Codecov. There’s also an optional step that builds a Docker image, pushes it to ECR, and optionally triggers ArgoCD deployments.

Almost a year ago, I wrote about how to deploy a simple MySQL leader/follower setup on Kubernetes.

It’s been a while, and I have decided to look into ‘operator’ solutions, which should be fully compatible with native MySQL implementations (MariaDB was out of the question because of reasons).

If you want something fully MySQL-compatible, you have two major options (I’m not going to mention operators, which seem to be abandonware at this point):

• Percona Server MySQL Operator - which went from technical preview to general availability fairly recently; it can run percona-server-mysql, which should be a drop-in MySQL 8.x replacement
• official MySQL-Operator from Oracle - where you just run official MySQL database (8.x/9.x)

I tested MySQL-Operator on a small testing cluster and decided to move my small workload after a month of battle testing. Migration was supposed to be a quick 20-minute adventure.

Another click-baity headline, don’t go, but hear me out, it’s a good idea.

Every now and then I try to look into “simpler” deployment options than my forgotten kubernetes cluster. I eventually abandoned nomad for k3s after running into constant pain from insufficient tooling. Then I forgot about that cluster for like 2 years and I’m waiting for an epic crash which would force me to redo the whole thing again.