Sven Slootweg @joepie91@pixie.town

Just learned that there's a trashbag brand in NL that has a whole dedicated 'complaints' website, with an extensive list of possible manufacturing errors: https://www.klachtenadreskomoafvalzakken.nl/

Can't tell whether they really care about quality, or they just have so many manufacturing issues that they needed to automate the complaint handling process this extensively

It's particularly odd because it's the comments where I explain some government procedure that get removed, and not the more irritated superficial comments.

Hmm. Lately I've noticed some of my comments on YouTube disappearing from view, especially those that mention government in some way; both in Dutch and in English.

In all cases, it's unlikely that they were removed by the channel owner, given the content of the comment, who operates the channel, and the rest of the comments around it.

Wonder what's up with that.

(This has been true for at least 7 years by this point, probably longer)

Since I realized that probably not a lot of people know this: Google does network-level (ie. TCP/IP-level) fingerprinting to detect automated requests, in addition to HTTP fingerprinting and more 'traditional' methods such as cookies and IP tracking.

I only know with *certainty* that this is used for scraping prevention on the search engine, but I would not be surprised if this were used for user tracking as well, given Google's history.

There's a lot of common advice about things like API stability and upgrade paths and whatnot, but that sort of advice tends to be very "draw the rest of the fucking owl" - the recommendations above are how you actually *get to* those kinds of design properties without burning yourself out.

(You can go further and have a fully-decoupled 'constellation' of unopinionated libraries, or take a standards-first approach to every component, but those sorts of approaches require a lot more upfront work and practice than the things described above - I definitely recommend working toward them, but start with the above or you'll never get anything out the door!)

How to make a framework or library that doesn't end up producing applications that are miserable to maintain or extend:

1. Make every component optional to use and easy to bypass.

2. But make sure that the lower-level mechanisms that those components use are also directly addressable/usable.

3. Leave deliberate gaps in your API design for bespoke application-specific things to go.

4. Do not make assumptions or structural demands of user code unless you're also willing to design abstractions that ensure them on behalf of the user.

5. Decouple the parts of the framework as much as possible, and treat them as mostly-separate libraries that just happen to work well together, preferring standardized data representations between parts where possible.

That's really all you need to allow users of your framework/library to do their own thing and swap out the bits that don't work for them, but so so few projects actually do these things...