New version of Reeder now out. I've been using Reeder (now Reeder Classic) since ~2012 (v2.5.4 from what I can tell in old email receipts).
This new version is a redesign that doesn't seem relevant for me at least. The single timeline view isn't how I want to view feeds but I can see how that is what many people might be used to coming from social media.
It looks like Github branch rulesets allow setting a bypass for specific app integrations! This should allow my Github app to avoid making a branch, PR, and auto-merging... which would be nice eventually!
First time giving rulesets a try
I'm exploring using Github Apps for w2z instead of fine-grained personal access tokens (PATs). Replacing PATs every 90 days is a bit tedious. Eventually the app flow should give a better experience.
you should know that if the algorithm chooses you it has nothing to do with the quality or value of your work. And I mean literally nothing. The algorithm is nothing more than a capitalist predator, seeking to consume what it can, monetize it quickly, then toss aside. If you make the algorithm your audience, you get very good at creating for an audience of machines rather than humans. Creating for humans is harder, it may get you ignored by the algorithm, but your work will be better for it, and it will find an audience in time.
Saw Daybreak via Simon Clark and would love to give it a go at some point! The collaborative nature of the game and the reality of climate action seems really appealing.
Don't really need any new espresso cups, but maybe if I break any I should give these a try.
Based on a Github issue I was able to get a collection with Zola taxonomies writing the proper TOML-frontmatter format.
collections:
- ...
fields:
- label: "Taxonomies"
name: "taxonomies"
widget: "object"
fields:
- { label: "Tags", name: "tags", widget: "list", allow_add: true}
This is written out into the frontmatter as
+++
[taxonomies]
tags = ["tag"]
+++
Anyone using DecapCMS? I gave it a try a while ago and looks like there is now Nested Collections which should now match how I have my site setup.
I guess I'll look forward to PostgreSQL 17, between better upserts and some label improvements.
The MERGE
seems to take more code than I'd like, I wish ON CONFLICT
didn't bloat and could have an option for ALWAYS RETURNING
that would return the row even if not modified. I'd deal with the bloat if it were simple code and always returned the row.
Cool looking Rust crate registry, Cratery. OAuth login, S3 storage. Guess could setup Litestream for DB storage as well.
Last spring we found it slightly too cold to go camping when we otherwise had the chance. Maybe time to pick up a warmer sleeping bag.
I was confused when I didn't see a Vegan label on a Silk carton. I'm not really less confused after reading the FAQ.
I was able to get tracecontext passthrough to OTel working! I was missing the opentelemetry_sdk::trace::TracerProvider
which pulls in the infomation to help build the OTel data that gets sent to collectors.
A new sqlparser release pushed out my changes for supporting declare-schema! I released 0.0.1 but haven't gone through and updated my services yet.
In a month or so of using the dev version of declare-schema
in my services I've had a good time! Since I wrote it with my mental model for services in mind, it works as I want it to! The library itself would probably wind up with significant data loss for others.
Interesting to see Rust Otel discussing the friction for (tokio)-tracing
. Tracing with DataDog was really convenient. I always wanted to get our shop moved to Otel to eventually be able to move away from DataDog though, partially due to pricing, partially due to more adoption of Google Cloud and not wanting to ship data out just for tracing.
I lean towards wanting tokio-tracing to be a/the supported case. I haven't found a solution with Otel that I really like. The initial setup has always seemed tricky, and with a cross-cutting concern like tracing, adopting Otel seems heavyweight. A single ecosystem (Otel) across language stacks is super appealing. At this point I'm mostly writing Rust things though so that isn't a huge selling point for me.
I do finally have a tracing setup in a lib that is working well, but haven't gotten distributed tracing going yet. I'm fine adopting Otel for wire formats but I'd like to keep tracing
in my app. I've yet to find a good way to thread W3C tracecontext into Otel output.
Works for me to try cleaning out a Docker registry: Docker Registry Cleaner. Keeps the last N images of each repo as determined by a label on the image.
On each deploy to my homelab I set a label on the image to be used so this cleans up images I'm no longer using.
Super alpha-y state... will likely result in data loss!