This year, I’ve really started to like jupyter notebooks. I first tried them out several years ago, but they’ve only just started to click for me. They haven’t changed; the difference is how I think about them. When I initially tried them, they felt like writing untestable code in a browser, where you could get yourself into an unknowable state very easily as you navigated between cells. While they certainly can be that, it was an incomplete impression, at best.

One thing changed my mind this year: I learned about the --notebook option for django-extensions shell_plus management command. shell_plus is a command that gives you a REPL with all your django models and many of the framework’s utility classes imported and ready to go. The --notebook option has shell_plus import that all into a jupyter notebook that you can access from your browser. Or that you can save and access from your IDE’s notebook support. It’s like absolute magic when it works, but lately you have to hold your jaw just right and explicitly specify a few dependencies' versions in order to make it work. It was 15 minutes of internet searching every time I felt like I was going to spend enough time in my REPL to want it. I recently learned about dj-notebook, which fixes that and adds a few useful features on top of it.

I’m working through Hypermedia Sytstems using django and htmx in public. This post starts applying the patterns from Chapter 6: More Htmx Patterns.

I’m working through Hypermedia Sytstems using django and htmx in public. This post continues to work through Chapter 5: HTMX Patterns.

I’m working through Hypermedia Sytstems using django and htmx in public. This post picks up with Chapter 5: HTMX Patterns.

I’m working through Hypermedia Sytstems using django and htmx in public. This post covers building out the Web 1.0 edition of the book’s contacts app.

I’m reading and enjoying Gross et al’s Hypermedia Sytstems. This post is the start of my plan to work through the exercises in public using Django and HTMX.

Stuff I don’t want to forget about working with Flipper Zero from Mac/Linux

Over the past week or so, I’ve been trying out using Docker to deploy a Django site on a VPS. My preferred setup for that is to have Caddy running on the host, not in any container, as a reverse proxy. (It’s a single, static binary; I don’t see any joy in wrapping that in a container.) In the past when I’ve hosted similar things, I just ran gunicorn in a python virtualenv on the host as well, and bound it to the loopback. The current thing I’m building is a little bit more painful to run that way on my VPS, so I thought I’d finally cave and give Docker a try in “production.” While there was quite a bit to like about it, there was also an unpleasant surprise.

My first open source contributions are old enough to have a beer in the US by now, as is my first python code. But I’ve always found it awkward and disruptive to patch, and contribute a patch back to a library that I’m using in a python project, especially when I’m working with virtualenv or similar setups. With poetry and git, I’ve finally settled on one I like, and I’m capturing it here for easy reference next time.

Poetry is, by quite some distance, my favorite way to manage python dependencies these days. But for modifying open source dependencies and contributing changes back, my workflow has always been awkward. I’ve often resorted to temporarily “vendoring” a project, or to awkward virtual environment manipulations. Here’s an easier way.

As I’ve mentioned a few times, HTMX is really growing on me for building web things lately. When stacked on top of Django, it lets me mostly write server side code, which is my comfort zone, but get pages that load and behave the way people expect them to in 2022. It doesn’t free me from all need to write stuff that runs in the browser, though. Here’s what I’ve found useful lately.