In July, while debugging a data export script for my search engine, I ran ps aux on the server as part of the diagnosis. The output contained the application's MySQL password, in plain text, because the script passed it on the command line.
A method's own comment already explained exactly what its SQL needed to do, and why. The actual SQL did the opposite of what the comment described.
Linux From Scratch builds coreutils with an extra patch, the i18n patch, which adds multibyte character support to tools like cut and expand. In my scripted LFS build, applying that one patch took four rounds of fixes spread over eleven days.
CaRMen's backend container builds its Docker image from a Dockerfile that runs composer install during the build, so the image ships with a real, populated /app/vendor baked in.
CaRMen, my CRM, runs on a single VPS as two instances: the real one and a public demo. In October, I gave it a deploy script that can undo itself when a new version doesn't come up, including, when it has to, the database. The database is the interesting part.
CaRMen's customer section used to be split across two controllers for no particular reason: CustomerController owned the list and detail pages, and a generic WebController owned the "add new customer" form, declared as its own route:
#[Route('/customer/add', name: 'customer_add')]
CaRMen didn't have a setup flow for most of its life. Getting a fresh instance running meant running migrations by hand and inserting the first admin user directly through a database client — fine for a one-person project, less fine the moment I wanted to hand someone else a copy of the app without also handing them a shell.
When I moved CaRMen's Playwright tests into GitHub Actions, every login test failed. Partway through each test, the login page redirected to the first-run installer, as if the database were empty. It wasn't. The PHP backend wasn't looking at the database the job had set up at all, because it never saw the environment variables that pointed to it.
The very first Doctrine migration in CaRMen's history — the one that creates the user and messenger_messages tables — was auto-generated against MySQL and never meant to run anywhere else. For a stretch of 2025 it had to run against SQLite too, because the test suite used SQLite while the actual migrations were written for MySQL.
In August, a page from a small Danish website turned up on the "recently indexed" admin page of my search engine. That site's robots.txt is two lines long and couldn't be clearer: