I have to agree. At first I loved the idea of bubbletea but I have given up on using it because I feel it is too immature. There are some poor/unfinished design choices that make widgets from different authors take different approaches. Layouting is very difficult as this is not part of the framework and depends on often half-baked third party widgets. Theres this discussion where there seems to be very little movement from the authors to improve the situation (also linked from OP's blogpost).
Afaik it depends on the generate function you use. You can let it keep track of the increment when generating, at a performance cost (atomic operations).
Co-creator of Trek here. Trek generates migration files based on the diff between a pgModeler(1) schema definition and existing migration files. Trek also helps deploying those migrations.
At Printeers(2) we use Trek for development of our main database.
The QOI format is relatively easy to understand, explained in a single page pdf file. I found it very interesting, knowing nothing of image encoding/compression.
It's great but it's an entirely different beast, being both lossless and designed to be fast and minimal above everything else. It works by minimizing the overhead of encoding deltas and run-lengths.
Next.js is very nice. One thing that always strikes a nerve with me though is that it goes against 12 factor. There is no proper way to build once, deploy (with config) multiple times. So either you have to build for each environment, which on kubernetes means building different container images (one for each environment). Or do a full re-build when the container starts, which means slower container startup, but at least you can re-use the container across environments and properly inline environment variables. There's a discussion about this; https://github.com/vercel/next.js/discussions/24010
The fact that Vercel can do deploys to different environments almost instantly, suggests to me that internally they use some variant of the solution suggested in the first reply in that discussion.
Nearly all front end metaframeworks/starters are like this, which is why I've given up on trying to run them in Docker, because it's just over-complicating the deploy process with no real benefit due to what you mentioned, and I'd rather just use simpler tools like Netlify.
Pretty much. I've been able to use some regex-replacements on the build output in the past with varying luck. But it definitely feels like a hack and can break in weird ways. Another option is building all environments into a single container image and then selecting the right build runtime using an environment variable. This makes the build costlier, even if you can build in parallell, and a bigger image takes longer to distribute into your environment.
At that point dedicated frontend hosting infrastructures like Netlify, Vercel, Cloudflare Pages and others seems like a better choice.
That's the idea, a transaction commit log decoupled from underlying durable storage allows you to build your own persistence layers. I'm still thinking to build a simple (memory-mapped?) layer, but as an optional, separate lib.
I'm using the existing PoE hat on several Pi4's in a production environment and it works great. Never had shutdowns or issues with power. Note that I'm not drawing extra power from any of the USB ports, so perhaps the existing PoE hat isn't sufficient when you have USB devices attached to the pi4.
Good to know. I couldn't see any reason that they wouldn't work for a Pi4, but I couldn't find a single manufacturer that said Pi4 was actually supported.
