How to Relate to AI

Intro

Another midnight I’m working on my side project; my child and wife are sleeping a few meters away.

I’m asking Claude to help out: write a plan, implement a simple feature. I do a review and the result is quite clean. Modified 9 classes in a few minutes.

But did the model follow practices? Project design, patterns, separation of concerns? Do we have documentation, do we know what and how in the project?

Continue reading How to Relate to AI

My Always-On Dev Environment pt. 2 – More Than One Stack

In part 1 I set up a Raspberry Pi 5 as an always-on dev box: code-server running as a systemd service, and a single PHP/MySQL/Vite project running inside Docker Compose. The whole point of keeping the host clean — no PHP, no Node, no MySQL installed directly on the Pi — was that the Pi was never going to stay a single-project machine. Sooner or later I’d want to run something else next to it without the two stacks fighting each other. This post is what happens when “sooner or later” arrives.

Running More Than One Stack on the Same Pi

The PHP/MySQL/Vite project is the one I’ve been using as an example, but the whole point of keeping the host clean is that it’s never just one project. The Pi doesn’t care what language a project is written in — it just needs a Compose file and a free range of ports.

The pattern I follow is simple and boring, which is exactly what you want:

  • One folder per project, each with its own docker-compose.yml.
  • One Docker network per project (Compose creates this automatically from the folder name), so services in different projects can’t accidentally see each other.
  • A port allocation note in my own head — or in a text file — so projects don’t collide on the host ports.
Continue reading My Always-On Dev Environment pt. 2 – More Than One Stack