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.

In part 4 of this series, we got forms in place to add and edit books in the library, then made them look better using django-crispy-forms. The many-to-many relationship between books and authors brought some weaknesses of the Crispy Tailwind theme to light, and it took a bit of effort to address that. Now it’s time to get deletion working before we make everything work a little better using HTMX.

In part 1 and part 2, we got the basic project workflow set up. Part 3 saw some initial models and views that were tested using the Django admin UI. Now it’s time to add library CRUD to the reading_log application itself.