> as simple as installing Claude in the VM and connecting via an SSH terminal
I've done exactly this, and it works pretty well!
1. I setup a VM in UTM (but this could be any kind of containerization thing). I don't even bother with a non-root account in there (the agent has free rein to install packages, write files, etc).
2. I SSH into the container.
3. I install Claude or whatever there.
4. I setup git things in a way where I can push/pull to move code between the container and my host machine.
Upsides: the agent is isolated from the rest of my host system, only being able to read/write what I've explicitly handed to it.
Downsides: the agent is isolated from the rest of my host system, so it's more limited in capability.
For context, my engineering team is fairly small – no guarantees this scales well for larger organizations. I capture the reasons for decisions on why code was written a particular way or why a particular architecture was decided upon in commit messages. We follow a squash-and-rebase flow for commits, so each PR is ultimately a single commit before merging. During that squash process, I'll update the commit message to sometimes be a few paragraphs long. Later when I'm curious why we made decision in the past, I can use git blame to navigate back until the point where I can find the answer.
I’d love to see a variation on the concept that minimizes information on each card. It would of course result in a larger deck, but would reduce visual noise while playing games.
I think one colored suit symbol and one rank is the most needed. Some cards could have symbols like Uno’s “skip” card as their rank.
I also do my best to stick to a "one strike and they're out" personal policy.
But I also have apps that push marketing through notifications _and_ are urgent on a reoccurring basis (usually delivery or rideshare apps). For those, I'd love if there was a system notification setting (per app) for "allow notifications from this all for the next X hours" _and_ a simple UX to make that happen.
I personally prefer leaving the measurement in the instructions for two reasons.
1. I'll often use the ingredients list (and quantities there) before cooking to ensure that I have everything I need ahead of time. Depending on what ingredient it is, I might not mise en place it. In those cases, a step that says "add ingredient" would require me to go reference the list in the beginning, losing a bit of context.
2. It's not often, but I've followed a few recipes that require a particular ingredient in 2 different steps in different amounts.
Why not simply have your webserver remember what state the door _should_ be in? Maybe don't rely on that from a security standpoint (eg. GET /garage/status => "closed, everything is secure"), but I suspect it would work for most situations.
I don't know much about Windows development, but I'm sure the system is modularized in some way. Why wouldn't you want to break up the project into multiple repos for different parts of the system? That would let you work on and test each part independent of the rest. Each part should be able to function on its own, right? Of course some engineers would need to build and test the entire OS as a whole, but I'd wager that (for example) the team working on visual design of the settings app doesn't need to have the source code of how the login screen verifies passwords.
Clearly Microsoft's process works well enough for them, so I wonder what benefits there are to using the monolithic repo choice over many smaller repos.
I've done exactly this, and it works pretty well!
1. I setup a VM in UTM (but this could be any kind of containerization thing). I don't even bother with a non-root account in there (the agent has free rein to install packages, write files, etc). 2. I SSH into the container. 3. I install Claude or whatever there. 4. I setup git things in a way where I can push/pull to move code between the container and my host machine.
Upsides: the agent is isolated from the rest of my host system, only being able to read/write what I've explicitly handed to it. Downsides: the agent is isolated from the rest of my host system, so it's more limited in capability.