This looks great! Question on the API/CLI - is there any provision for capturing frames (or even streams?) from Homekit cameras, or even triggering events or webhooks based on the cameras detecting motion?
The camera streams are HLS via AVFoundation – Apple doesn't expose raw frames, so no programmatic capture there. But motion detection events do flow through the SSE endpoint (/events), so you can use those to trigger webhooks or automations. For HA cameras there's also a snapshot endpoint you can hit on demand, e.g. when motion fires.
SSE is in the upcoming 2.0.0 which is currently on TestFlight – happy to add you if you want to try it out.
When we bought our house (1950s semidetached) it needed a full electrical rewire. I’m so glad I asked the electricians to run Ethernet all over the house at the same time, including to the ceiling in some rooms for WiFi access points.
Hi, author here. I have been building Django and DRF applications commercially for about fifteen years at DabApps, and this guidebook is an attempt to write down the architecture patterns we have arrived at, for projects that have to survive years of ongoing maintenance.
High level summary:
* We don’t hide Django under layers of abstraction, we just slice it up a bit differently than you would by default.
* Organise code by responsibility (readers, actions, interfaces, data) rather than by app.
* Put most business logic in plain functions, not in fat models or deep class hierarchies.
* Keep views thin: treat GET as "read some data" and POST as "do an action".
* Design endpoints around real frontend use cases (backend for frontend) instead of idealised resources.
* Control queries carefully to avoid performance traps.
Thank you for sharing this — I found it really fascinating and insightful. It's a shame it didn’t get more attention here. I work in an environment similar to yours and have come to similar conclusions, though not quite as "radical," for the most part.
The part about the query/values/projection of the readers layer was the most foreign to me, but I have to say, it really clicked and finally put my finger on something that’s been nagging me for a long time.
Since you mention that this came out of your work projects, I’m curious — how has your experience been onboarding developers with this way of managing Django projects?
Idiorm was started in early 2010 while I was still writing PHP professionally. I’d heard about Django from a talk @simonw gave at the FlashBrighton meet-up group in 2009 and immediately fell in love. Idiorm and Paris, although not direct attempts to duplicate Django’s ORM, came from frustration that such an elegant ORM and query builder didn’t exist in the PHP world.
So in a roundabout way, Laravel’s ORM was absolutely inspired by Django.
As a side note, I’m still doing Django 16 years later and love it more than ever.
It's worth noting that uv also supports a workflow that directly replaces pyenv, virtualenv and pip without mandating a change to a lockfile/pyproject.toml approach.
uv python pin <version> will create a .python-version file in the current directory.
uv virtualenv will download the version of Python specified in your .python-version file (like pyenv install) and create a virtualenv in the current directory called .venv using that version of Python (like pyenv exec python -m venv .venv)
uv pip install -r requirements.txt will behave the same as .venv/bin/pip install -r requirements.txt.
uv run <command> will run the command in the virtualenv and will also expose any env vars specified in a .env file (although be careful of precedence issues: https://github.com/astral-sh/uv/issues/9465)
It’s an absolute godsend. I thought poetry was a nice improvement but it had its flaws as well (constant merge conflicts in the lock file in particular).
Uv works more or less the same as I’m used to with other tooling in Ruby, JS, Rust, etc.
I never got a chance to see the difference there because I moved on shortly after.
It was just that almost constant conflicts with poetry (and the errors about the project being out of sync) with a team developing in parallel were painful enough for me to suggest we try uv instead.
It seemed uniformly better with a simpler docker setup too (although I liked how pants would created executable bundles and you could just ship those).
Fair enough! I'm a bit surprised that anyone could get regular out of sync errors unless a team member were constantly updating dependencies every commit. But then if they did that with uv I'd imagine they'd have the same issue. Unless uv does something extra smart and creates you a new environment for every git branch.
> uv will respect Python requirements defined in requires-python in the pyproject.toml file during project command invocations. The first Python version that is compatible with the requirement will be used, unless a version is otherwise requested, e.g., via a .python-version file or the --python flag.
"Lobsters is hosted on three VPSs at DigitalOcean: a s-4vcpu-8gb for the web server, a s-4vcpu-8gb for the mariadb server, and a s-1vcpu-1gb for the IRC bot. DNS is hosted at DNSimple and we use restic for backups to b2. (Setup details are available in our ansible repo.) Lobsters is cheap to run, so we don't take donations."
Do you have a source for your statement about copper? The closest I can find is [1] "The expansion of electricity networks means that copper demand for grid lines more than doubles over the same period". That's a doubling of demand, not of total current circulation.
Sorry not in circulation, my bad. The discrepance between required(for net zero) and planned mining is still worrying. Other metals like cobalt can be substituted by something else but not copper.
From the article: "It adds LLM as a dependency, and takes advantage of LLM’s Python API to abstract over the details of talking to the models. This means sqlite-utils-ask can use any of the models supported by LLM or its plugins"
reply