It does get at what I'm talking about. But I've seen retrying in this situation lead to worsening the situation, because your basic problem is two hot paths conflicting with each other and now you're conflicting even more.
Do folks have any thoughts on ways of avoiding deadlocking access patterns? In a codebase where folks are sort of adding ad-hoc endpoints left and right, it's hard to avoid the case of two endpoints that more or less want to do:
tx1: update a
tx2: update b
tx1: update b
tx2: update a
Is there a "discipline" or practice that works well? Like, can you realistically, in a real-world messy business codebase, impose an "ordering" on your tables to avoid dining philosophers?
> I do not agree that slice() should operate on extended grapheme clusters. Don’t lump the grapheme cluster/scalar value split in with the sins of UTF-16 and its unreliable code point/code unit split.
Maybe a simpler argument against this idea is that the definition of an extended grapheme cluster changes between versions of Unicode. The relevant standard is on its 47th revision (not all of which change extended grapheme clusters, but many do): https://www.unicode.org/reports/tr29/
In old-school chess AIs, zugzwang is also of interest because it can break null-move pruning[0], which is a way to prune the search tree. "Null move" just means "skip your turn", and the assumption that skipping your turn is always worse than the optimal move. But in zugzwang positions, that assumption is wrong, so you have to avoid doing null-move pruning.
Stockfish's heuristic for "risk of zugzwang" is basically "only kings and pawns left over", alongside logic for "is null-move pruning even useful right now" [1]:
It is news to me that manipulating ASCII art is something AI can do well! I remember this being something LLMs were all particularly horrible at. But I just checked and it seems to work at least with Opus 4.5.
claude(1) with Opus 4.5 seems to be able to take the examples in that article, and handle things like "collapse the sidebar" or "show me what it looks like with an open modal" or "swap the order of the second and third rows". I remember not long ago you'd get back UI mojibake if you asked for this.
Goes to show you really can't rest on your laurels for longer than 3 months with these tools.
For those unfamiliar: https://news.ycombinator.com/item?id=26998308 ... It's basically a bunch of posts that 'dang and 'tomhow (others too? idk) think are underrated, so it tends to be potent hacker-catnip stuff.
For others, I'm sure parent knows: OKLCH is largely a bugfix for CILEAB. Both try to make a color space where even steps feel evenly spaced to a human. But CIELAB had procedural flaws in its creation.
See slide 19: https://www.w3.org/Graphics/Color/Workshop/slides/talk/lille... -- if you ask CIELAB to make "pure blue" (RGB 0 0 100%) become grayscale, the intermediate colors become purple to the human eye. The entire point of a perceptual color space is that that doesn't happen. OKLCH fixes that.
BTW, credit to Björn Ottosson, who basically side-projected a color space into the web standards and more: https://bottosson.github.io/posts/oklab/ ... folks like him are why we sometimes have nice things!
Kind of moot anyway; 100x zoom is equivalent to a 2400mm lens (with no stabilization assist). If you can hand-aim that on target, you're an elite marksman.
The area in this photo -- the Caineville Mesa, Factory Butte, "Long Dong Silver" (I'm not aware of a more polite name) -- is some of the strangest land in America. It really is that lunar blue gray. The Temples of the Sun and Moon (enormous natural sandcastles) are also nearby, and are similarly eerie in the evening.
The closest I've ever felt to being in space. Recommend!
Since we both worked there: I can think of a few places at Segment where we'd have added more reporting/analytics/search if it weren't such a pain to set up a OLAP copy of our control plane databases. Remember how much engineering effort we spent on teams that did nothing but control plane database stuff?
Data plane is a different story, but not everything is 1m+ RPS.
Which isn't exactly what you're talking about, but between that and other things in the "Builder's Library" series, you can see that people are doing this, and writing about it.
In practice, identity providers (Okta, Entra, etc.) will retry for a bit before reporting to the IDP admin that their SCIM connection to the SaaS vendor is unhealthy. From there, things get fixed ad-hoc.
Okta and Entra have different request patterns, and so have differing artifacts if the SaaS vendor's state diverges from the desired state. Okta tends to be more stable, because they usually GET-then-PUT (c.f. compare-and-set). Entra likes to PATCH, which leads to dead-reckoning artifacts.
What you're describing is an interesting and hard problem in computer science, but SCIM is not trying that hard to get it right.
One way this comes up is that the way those C# objects serialize, there are properties that Microsoft will send you in form `"key": { "value": "xxx" }`, but which they expect that you read back to them of the form `"key": "xxx"`.
It's best to not take the SCIM RFCs too literally.
Right now we offer prebuilt pages you can redirect to, as well as SDKs your clientside JavaScript can talk to if you want to reskin. Said SDKs are glorified cURL wrappers, and our prebuilt pages are built using them too.
Since Tesseral's data model is that users belong-to organizations, anytime you have a user, an organization is also available to you (e.g. in the context of a JWT's claims, or an API call to `api.tesseral.com/v1/users/user_...`, etc):
For authz checks, you have a similar denormalization when you use Tesseral's RBAC. When a user gets an access token, those access tokens have a list of `actions` that the user is allowed to carry out. All of our SDKs have a `hasPermission` function that basically just `accessToken.actions.contains(...)`:
So we do a little bit of denormalization whenever we mint an access token, but in exchange your code doesn't need to do any network hops to get an organization or do a permission check. (Access tokens are ES256-signed, and our SDKs handle caching the public keys, so that network hop is very infrequent.)