Taking stock of my current development environment. This could be useful in the future as a comparison point if parts of my development environment change.

nginx + norikae

I have nginx installed with homebrew (brew install nginx) with port :80 forwared to port :7999

server {
    server_name _;
    listen 80 default_server deferred;
    listen [::]:80 default_server ipv6only=on;

    location / {
        proxy_pass http://localhost:7999;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

On port :7999 I have running my norikae server.

This gives me a xinetd way of managing all of my dev servers.

# A hugo configuration for my blog
[service.paul]
host = "paul.localhost"
port = 8005
cwd = "~/Projects/paultraylor.net"
command = "hugo server --buildDrafts --buildFuture --port {port}  --liveReloadPort 80"

By default, most browsers direct *.localhost back to 127.0.0.1 which is the magic of how this works. For the cases that it doesn’t automatically work, it is fairly trivial to add extra entries to /etc/hosts.

The Upgrade and Connection headers ensure that websockets work for things like Hugo’s auto reload.

This makes it quite nice to work on multiple projects since I can just type foo.localhost or bar.localhost into the browser, and it will automatically launch it in the background, running in tmux as-needed. Norikae is probably one of my most useful projects, though I am not sure how to better market it for others to use. For starters, I likely need more documentation beyond just the readme.

graph LR nginx[[nginx on port :80]] norikae[[norikae on port :7999]] nginx --> norikae norikae --> A[Hugo localhost:8001] norikae --> B[Django localhost:8002] norikae --> C[Other localhost:8003] hugo.localhost --> nginx django.localhost --> nginx other.localhost --> nginx

Docker Desktop

I still use docker for any assorted services that I might need.

Currently it is only postgres and redis though I also use kafka for some of my projects. If I was not on an Intel Macbook, I would be curious about moving my limited docker usage to apple/container

colima is another project I have also considered that could be an alternative if I had trouble with upstream docker.

Alfred + Dash

Alfred with my fork of alfred-repos is another invaluable tool. I have a slightly different implementation of folder specific icons than the upstream project, that maps how I use folder names in development.

This makes it easy to check code ~/References vs ~/Documents projects or any of my coding ~/Projects with an icon to help more quickly distingush.

Combining Alfred with Dash for viewing documenation, means I can quickly search within Alfred for Python or Django or Bootstrap documenation while developing.

VSCode

I would prefer to graduate from VSCode to something like VSCodium but have not yet been able to make that migration.

Several plugins like Remote - SSH and Pylance can not install to VSCodium, though Astral’s ty extension is a possible replacement for pylance. I have not done enough research yet on a good replacement for Remote - SSH yet. It has been super useful to be able to edit on one of my remote machines, and largely replaced my usage of Lapce .

I still like some of the ideas behind Zed but some of their gushing about ‘ai’ has me slightly warry.

Forgejo + Codeberg + GitHub

While this also has overlap with my deployment environment, right now I have my code split between several forges.

Forgejo - Most of my private code or code that is pre-alpha
Codeberg - Most projects I want published as public
GitHub - Waiting to be migrated

I was running my Forgejo as more public, but I recently changed each of the orgs to ‘internal’ to reduce bot scraping. I don’t love having bots scrape to add to their LLMs, but I changed things to ‘internal’ more for reducing load on the servers.

While Forgejo has support for automatic mirroring, I would prefer a setting that lets me select the branches to mirror instead of everything. That way I could have main automatically mirror, but any weird testing branches could stay local to my instance.

git-pending

I also combine my dev environment with a script I call git-pending

It’s a small wrapper around some of the git status plumbing, and lets me check both uncommited files, and unpushed commits.

This combined with the --report and --address flag means I can easily see what repos I need to check on.