I’m still using devcontainers and encouraging their adoption across the team. One thing I’ve added: checking in development decryption keys so the container can come up with zero interaction. Rails encrypted credentials need a key to decrypt, and if that key isn’t available, you’re prompted before anything works. Really I want anyone to be able to just click that “Launch Workspace” button and have a ready-to-use IDE and development environment.
Checking in keys sounds like a bad idea, and in general it is. The reason it’s fine here is that the development credentials file doesn’t contain anything real — no production secrets, no API keys that matter. If someone gets the dev key, they get lorem ipsum. The habit of never checking in keys is a good one, but it exists to protect real secrets. Blindly applying it to dev environment setup just creates friction for automation with no actual security benefit.
In the last post I said I wasn’t using git worktrees because of port conflicts — the Shakapacker dev server port gets baked into the build and hardcoded into the repo, so two containers can’t share it. That was accurate at the time.
What’s changed is that I now have a custom skill that handles port provisioning automatically. When it creates a new worktree, it picks an available port, updates the relevant config, and brings up the container on that port. The problem is mostly solved. I’m using worktrees. Except that worktrees still don’t work out-of-the box with devcontainers since the repo is a symlink, and Docker won’t import symlinks by default. The march towards perfect environment setup continues.
It’s worth calling out that I’m not using Claude Code’s built-in worktree support, though. It leaves orphaned worktrees around, and it gets the mechanics wrong often enough that I stopped trusting it for this. The custom skill is more reliable because it’s specific to this project’s port setup. I do see the built-in Claude Code worktree feature being much more useful when I have fully migrated my development environment to the cloud cause I just wont care how many worktrees it spins up when the environment is ephemeral. Not quite there yet with the team though.
I’ve set up the @claude GitHub action on a few repos. When I open an issue, Claude Code picks it up automatically, runs headless, and opens a PR. I’m not watching.
The clearest example is claude-code-radar, a Technology Radar I maintain for the Claude Code ecosystem — tools, plugins, patterns, and practices organized by adoption maturity (Adopt, Trial, Assess, Hold), modeled on the ThoughtWorks radar. Every week, I open an issue asking Claude to research recent releases and update the radar. It reads the changelog, checks community sources, and opens a PR with a sourced, well-reasoned update. I review, merge, done.
What I appreciate about this pattern is that it matches the task to the agent’s actual strengths. Tracking a fast-moving ecosystem means reading a lot of release notes and making incremental updates — tedious for a human, easy for Claude. The output is consistently good enough to merge with light review.
We’ve adopted Git Town for stacking PRs. The motivation is keeping individual PRs reviewable — a 1500-line PR gets shallow reviews because nobody wants to read it. Splitting work into a stack of focused PRs means reviewers actually engage with the code.
The side effect I didn’t expect: I’ve learned things about git. Claude uses tools like rerere naturally — it just sets it up, uses it when rebasing across multiple branches, moves on. I’d never touched rerere. Watching it work made me understand what I’d been missing. I’m a decent git user, but Claude is better, and working alongside it has closed some gaps.
In February I wrote about bin/mcp-setup, a Go script that configures MCP servers across different agents for everyone on the team. We’ve moved to a Claude Code team plan, and that’s changed the picture.
On the team plan, managers can approve and centrally install plugins. Atlassian and Figma — which I was previously wiring up manually as MCP servers — are now just there. The person who owns the tool access grants it, and it shows up in everyone’s environment. That’s the right model: tool access is an organizational concern, not a developer concern.
bin/mcp-setup is still around for the MCP servers that don’t have a team-managed equivalent, but it covers less ground now.
Using Claude Code and Git Town together has a side effect: a lot more PRs. More PRs means more CI runs, and CI queues that were fine before started backing up.
To address it, I used a two-phase approach. First, a main agent researched the CI suite and identified where improvements were possible. Then I told Claude to use the worktree skill to create five worktrees and launch five subagents to implement the changes in parallel, one per worktree, each opening its own PR.
The constraint is that this only works when the changes are genuinely independent. If two agents are touching the same files, you’ve just created merge conflicts at scale. The main agent’s research phase is what makes the parallel phase viable — it tells you which improvements don’t step on each other.
One more thing worth mentioning: /insights. Run it in a Claude Code session and it analyzes your history and generates a report — interaction patterns, friction points, what’s working, and ready-to-paste suggestions for your CLAUDE.md. It’s a useful way to surface things you’re doing repeatedly that could be codified as instructions or skills. I’ve run it a few times and each time caught something worth adding to project config.
The trajectory since February has been toward less babysitting. Background agents handling recurring research, worktrees running in parallel, plugins provisioned by admins rather than configured by hand. The interactive workflow is still there for design and complex problems, but a growing share of the work is just happening in the background.
Claude Code recently shipped /loop, a native scheduled task command. /loop 1d /my-skill and it runs on a cron, no external infrastructure needed. That’s essentially what OpenClaw was doing — always-on background work on a timer — but built into the tool I’m already using.
I haven’t tried the Ralph Loop yet — running an agent repeatedly against a PRD until it’s done, with git as the memory between fresh sessions. Still on the list.
]]>This is the piece that moved the needle the most. New project, legacy project, doesn’t matter — clone, open in VS Code, and the devcontainer comes up with Ruby, Node, Postgres, Redis, whatever the project needs. Zero setup on the host. I used to sometimes spend hours getting a legacy Rails app running on a new machine. Now it’s seconds or, at most, minutes. If you’ve never used them, they’re worth the hour it takes to learn.
I tried. The problem is specific to Rails with Webpacker/Shakapacker (a thoroughly antiquated setup these days). The Shakapacker dev server runs on its own port, and that port gets baked into the client-side HTML at build time so the browser knows where to fetch assets from. Rails has to know about it at startup.
With worktrees, you’d want each branch in its own devcontainer, each on its own set of ports — you can’t have two containers fighting over 3000. But the port configuration lives in the repo, so it’s the same across every worktree unless you manually change it per-container before you start. And if you have to configure a container before you can use it, you’ve lost most of the reason to have worktrees in the first place.
Chicken and egg. I stick with one working tree per project and switch branches the normal way.
Claude Code runs on my host machine, not inside the devcontainer. It needs access to my MCP servers and the broader file system, not just what’s inside one container.
The trick is a CLAUDE.md in the project root that tells it how to reach in and use the shell:
Commands need to run inside the devcontainer. Prefix commands with `docker exec`:
docker exec -it my-app bundle exec rails test
docker exec -it my-app bundle exec rails console
Claude reads the workspace files directly through the volume mount — no copying back and forth. Any command that needs the container environment goes through docker exec. It works well enough that I rarely have to think about the boundary.
The thing I’d like to change eventually is running Claude inside the devcontainer instead. If it’s already in the container, I can pass --dangerously-skip-permissions and stop worrying about the docker exec indirection entirely. I haven’t gotten that working yet — MCP setup is the sticking point — but it’s on the list.
At work I’ve got a handful running that feed Claude context it would otherwise have to go dig for:
gh CLI directly, so I go back and forth.The MCP servers are the part that changes the day-to-day the most. Before, I’d bounce between six tabs gathering context before I could even ask a useful question. Now I just ask.
Not everyone on the team uses Claude Code. Some use Cursor, some use Codex, and each one stores its MCP configuration in a different place and in a different format. One of them uses TOML. Manually maintaining separate config files for each agent wasn’t going to work.
So there’s a bin/mcp-setup script in the main repo. You clone, you run it, it presents a menu of supported agents, and it writes the right config to the right place for whichever one you picked. The list of MCP servers is defined inside the script and mirrors what I wrote above.
The script is a compiled Go binary. I don’t know Go — Claude wrote it. The reason for Go specifically is portability: a single static binary with zero runtime dependencies. No Ruby, no Python, no Node. Anyone on the team can pull the repo and run it immediately regardless of what’s installed on their machine. Autodetecting which agents are installed would be nicer than a menu, but that would mean the script needs to probe a bunch of directories and config files on the user’s machine, and that felt like too much to ask for. I can see go being a big winner as devs write less and less code directly.
Skills are another piece worth mentioning. They’re slash commands you can add to Claude Code — reusable prompts that expand when you invoke them. I’ve got one for /gmail that can access my inbox using the Gmail Python API, both for reading and writing mail.
The use case is inbox management. I get 60–100 emails a day, and having Claude summarize what’s unread or find a specific thread is genuinely useful.
Claude wrote the skill. I described what I wanted, it found the Gmail API docs on its own, and generated a Python script that handles OAuth, calls the API, and returns email content in a format it can work with. I don’t write Python often, so having Claude handle the credentials.json setup, the token refresh logic, and the API query syntax saved me a lot of fumbling through documentation. The whole thing lives in ~/.claude/skills/gmail/.
Skills are simpler than MCP servers — just a prompt template and optionally a script. If you find yourself repeatedly giving Claude the same setup instructions, a skill is probably the right abstraction.
Open a project, devcontainer comes up (or it’s already running), open Claude Code in a terminal on the host. Give it a Jira task number. It reads the CLAUDE.md, knows how to run things in the container, pulls what it needs from Jira or Sentry or GitHub, and gets to work.
There’s an extra layer of indirection for every command thanks to the host/container split. But compared to where I was a couple of months ago — manually provisioning environments, context-switching between tools, spending half my time on plumbing — it’s a significant step forward.
]]>I’d been mulling over a complicated setup using Docker and containers until I gave up and just wrote a shell script (ash in this case since the server is running Alpine):
#!/bin/ash
set -e
service nginx stop
certbot renew --standalone
service nginx start
which I trigger once a month from cron:
# min hour day month weekday command
0 2 1 * * /root/renew.sh
Note that certbot renew --standalone requires running certbot manually at least once for every domain that the server hosts.
Is this portable and will it work for multiple servers? No. Do I care? Not at this time. Is this perfect? Nothing ever is.
Just one of those things that I can’t believe it took me this long to automate.
]]>Oddly, I still enjoy running my own Linux server. A few years ago, I became interested in deploying a container-based application using an automated Github-Actions-based CI/CD workflow to a $5/mo Linode VPS server. These workflows run the test suite against PRs and build and deploy docker images via SSH.
I recently split up this workflow into separate files and stopped using the Docker-based docker-compose.test.yml/sut workflow. I’ve replaced it with the native Github Ruby pipeline, which is substantially faster than building a Docker image just to run tests.
Here’s my test workflow pipeline that runs the Ruby-based test suite on every new PR.
# in .github/workflows/test.yml
name: Tests
on: [pull_request]
jobs:
# Run tests.
# See also https://docs.docker.com/docker-hub/builds/automated-testing/
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Ruby
uses: ruby/setup-ruby@v1
with:
bundler-cache: true
- name: Install ruby dependencies
run: bundle install
- name: Install javascript dependencies
run: yarn install
- name: Run tests
run: bundle exec rake
Once PRs are merged to main, a follow-up Deploy workflow builds a Docker image and deploys it to my Linode server via SSH:
# in .github/workflows/deploy.yml
name: Deploy
on:
push:
branches:
- main
jobs:
# Push image to GitHub Packages.
# See also https://docs.docker.com/docker-hub/builds/
build:
runs-on: ubuntu-latest
if: github.event_name == 'push'
steps:
- uses: actions/checkout@v4
- name: Log into registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: $
password: $
- name: Build image
run: docker build . --file Dockerfile --tag ghcr.io/my-profile/my-repo/my-image:latest
- name: Push image
run: docker push ghcr.io/my-profile/my-repo/my-image:latest
deploy:
needs: build
runs-on: ubuntu-latest
if: github.event_name == 'push'
steps:
- uses: actions/checkout@v4
- uses: webfactory/ssh-agent@v1
with:
ssh-private-key: $
- name: Deploy
run: ssh $@$ "sh -s" < deploy.sh
The above Deploy workflow references a custom deploy.sh script. Here’s a generic example of what that script does:
#!/bin/sh
# This script runs on the docker server to deploy the application. It can be kicked off locally via:
#
# ```
# ssh my-server < deploy.sh
# ```
set -e
echo 'Removing dangling images'
yes | docker image prune
echo 'Pulling latest'
docker pull ghcr.io/my-profile/my-repo/my-image:latest
echo 'Stopping the container'
docker container stop my-app || true
until [ "`docker ps --filter 'name=my-app' --format ''`" == "" ]; do
sleep 0.1;
done;
echo 'Starting the container'
docker run --rm --name my-app -d -p 3000:3000 ghcr.io/my-profile/my-repo/my-image:latest startup.sh
Note: This post was written in 2020 and is significantly out of date. The advice may no longer reflect current practices or resources.
Here are a few things that I recommend doing to become a Software Developer:
Attend meetups to network. Nine years later, I still correspond with people from my first programming meetup (the Dallas Ruby Brigade).
Pick one high-level language and UI or web framework and go really deep on both. For a first language, I really liked learning Ruby because the Ruby community tends to pick one style and stick to it, which made it easier to learn. It also has an amazing book: “Practical Object Oriented Design in Ruby.” The Ruby on Rails framework is really easy to learn the basics and find jobs. If you already know a dynamic programming language, learn a statically-typed programming language like Java or C#.
Learn some C programming. C is the ancestor of many modern languages. I read “C Programming Absolute Beginner’s Guide” a few years ago and liked it.
Practice coding fundamentals. Entry-level programming interviews will probably expect some demonstration of using an algorithm to solve some well-trod problem. The book “Cracking the Coding Interview” is invaluable and it has a timeline for beginning a coding career. Codewars is great for self-paced practice in a variety of languages. Advent of Code is fun and very challenging. There’s also Project Euler.
Read about trends in programming languages, architectures and frameworks. Hacker News is a good source for daily trends, but I also like to read blogs and tech radars. My favorite blogs include Martin Fowler and Coding Horror.
Launch a personal project. Don’t think you need to know everything to start your career. Start interviewing as soon as you have a personal project that you can show off. A common first project is a todo list app.