probabletrain

this helps manage the combinatorial explosion of exceptions you need to add to your agent's skills when you prescribe workflows everywhere. writing facts rather than workflows lets the agent reason about situations you didn't predict, so it can handle the long tail.

provider fallbacks are also expensive since you lost the prompt cache. openrouter have a 'session' concept to help with this, but we ended up going direct to providers for higher rate limits and writing our own fallback logic.

I'd be very surprised if the very-similar-looking design of corgi's product breaches any copyright law, copyright of design or layout is much more finicky than copyright of code. This seems like more of a moral issue than a legal one.

They're officially yellow. Many people (~50% in my experience) perceive this colour as green though.

> Tennis balls are fluorescent yellow in professional competitions

https://en.wikipedia.org/wiki/Tennis_ball

> Looking at the OpenClaw model, where the conversation history is in the chat channel and the agent process and LLM provider are both separated from that, you can’t build the same design on Cloudflare or Anthropic

Yes you can - durable objects do exactly what the "Ably pub/sub channel transport" diagram describes. And it's even easier with the cloudflare agents SDK. This article strawmans the capabilities of competing infra.

I use https://rectangleapp.com/ and enjoy it. I have shortcuts to move windows to the left/right half of the screen, and cycle between monitors. This, combined with native cmd+tab and cmd+` is enough for me.

I know that anecdotal experience is definitionally just that, anecdotal. But I've had a handful of attentive London cabby experiences (and enough in-Waymo experiences) that give me conviction that Waymos are far safer than them. They're out there driving all day every day, it's obvious to me that a Waymo driver is going to be safer than even a professional.

One cabby pulled out of a t junction to end up alongside me on a motorbike – a Waymo would never do that.

recently (past couple of months) they've been much more aggressive in the ways that make a good driver a good driver - confident and assertive when they should be. for me this has anecdotally been a massive improvement

If you were choosing between getting into a Waymo or a car driven by a human driver (where Waymo operates, for a route that Waymo would do), the data shows that the Waymo is safer.

it's an application built with webgl that plays audio, rather than just an audio player

media sound is generally unaffected by the silent mode toggle, which apple suggests is only for notifications. but the toggle inconsistently affects media, muting some things but not others. it's incredibly frustrating. android has much better audio controls for notifications, media, alarms, and vibrate.

> We need Claude and Claude Code, with their skills and plugins, with their context, to be first-class participants in our company's Slack. But this problem can't be solved by a Slack integration because of another problem: data access.

Yes it can? We have agents in Slack as first class participants. They can even use Slack search.

I think there’s a difference between what’s expected/acceptable for library code vs application code. Types like this might be hard to understand, but they create very pleasant APIs for library consumers. I’ve generally found it very rare that I’ve felt the need to reach for more complex types like this in application code, however.

RXJS’s pipe function has a pretty complex type for its signature, but as a user of the library it ‘just works’ in exactly the type-safe way I’d expect, without me having to understand the complexity of the type.

> This whole site smells off vibe coded jank.

A vibe-coded double pendulum sim should produce a much better result than the physics on this page. Claude Code made this just now off one prompt, the physics are much better: https://keir.is/swinging

Not sure how other stacks solve this, but with GraphQL the backend defines a `User` type with a full set of fields, and the client specifies only the fields it wants to query. And with codegen you get type safety.

So on the /posts page the client asks for `{ user: { id, posts: { id, content }[] } }`, and gets a generated properly-typed function for making the query.

In an ideal world you'd have one source of truth for what the shape of a User could be (which may well be a discriminated union of User and AnonymousUser or similar).

Without fullstack TS this could look something like: (for a Python backend) Pydantic models+union for the various shapes of `User`, and then OpenAPI/GraphQL schema generation+codegen for the TS client.

GraphQL is another one, with schema introspection and codegen for queries and types.

> all the photos where shoot with the Leica M11 + 35mm Summilux FLE

These photos look great, but I'm having a hard time figuring out exactly why.

The Barbican certainly looks better here than from what I remember of seeing it through the naked eye.

Navigation isn't usually "undo", conceptually.

> Previous sync engines really want you to sync all data

Linear had to do all sorts of shenanigans to be able to sync all data, for orgs with lots of it – there's a talk on that here:

https://www.youtube.com/watch?v=Wo2m3jaJixU&t=1473s

I think with good presence (being able to see what other users are doing) and an app that isn't used offline, conflicts are essentially not a problem. As long as whatever is resolving the conflicts resolves them in a way that doesn't break the app, e.g. making sure there aren't cycles in some multiplayer app with a tree datastructure. Sounds like Zero has the right idea here, I'll build something on it imminently to try it out.

I've used PixiJS and react-pixi-fiber to write a declarative 2D WebGL renderer in React with excellent results. PixiJS also has a Canvas2D fallback when WebGL isn't available. I wonder how this compares.

I think "tons of code and maintenance" is an exaggeration for this effect, once it's done you'll rarely have to come back to it.

Many people value creating and using products with these kinds of details, I disagree with "don't use this in projects you intend to maintain" as across-the-board advice.

I'm a huge fan of this. Apollo doesn't have it baked in as a pattern like Relay does afaik, but I do something similar manually in Apollo, inspired by Relay.

Deleting code automatically removes its data dependencies from the root query, it's ideal.

What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits:

- If data already exists in cache, a query will return that data instead of making a network request.

- Everything that has a data dependency on something in the cache will automatically update when the data is updated, e.g. after a mutation.

- Cache data can be optimistically updated before the request completes, UI that queries this data will automatically update.

- Components will automatically refetch data if they need to, e.g. if an object is partially updated.

The pain points are pretty painful though:

- Really hard to debug unexpected refetches.

- Normalizing the data for the cache comes at a cost, it can be pretty slow for big responses.

- You quickly realise you need to really understand how the client works under the hood to be productive with debugging/complex behaviour.

I see it as a case of "this is the worst API/client, except for all the others". I'm curious to hear how people using non-graphql APIs are managing data in the client in web-apps with complex data needs?

[1] https://www.apollographql.com/docs/react/why-apollo [2] https://relay.dev/

> clients create re-usable fragments for every object in the system and use it everywhere

I quite like Relay's pattern where components define their data requirements, and this is passed up the component tree to some query at the root. Avoids a situation where the query defined at the root asks for unnecessary fields because it's so far away from where the data is actually required.

https://relay.dev/docs/principles-and-architecture/thinking-...

The desktop-switching animation is too slow on new Macbook pros with "promotion" (high refresh rate) enabled. The animation speed is tied to the display refresh rate, so disabling promotion (setting refresh rate to 60hz) fixes the issue.

It's particular annoying because windows aren't interactable during the animation, so you have to wait for the ease-out to fully complete before you can click on things in the new desktop. This has been known to Apple for over a year.

Its real use is the few hours of fun I had making it, this is really a toy

I made this a couple of days ago, mainly as a fun excuse to try out some cool frontend stuff

Oh hey, I made this a couple of days ago!

I initially made this to experiment with 'faking' depth of field in CSS (check out my penultimate tweet for the demo vid and inspiration from shuding_, link at the bottom of the site).

But last night I remembered that ThreeJS exists, so rewrote it using react-three-fiber. This was my first time playing around with it and I'm super impressed, it's incredibly ergonomic.

Edit: not documented, but right-click drag to pan