Documentation is actually better with LLMs. In 2010s+ majority of the docs is autogenerated doxygen and alike slop or some hello world in marketing speak. Absolutely useless. The ability of LLMs to hoover up everything related to the problem at hand improved my experience manyfold.

It's 9am in the morning. I login to my workstation and muddle my way through the huge enterprise code base which doesn't fit into any model context window for the AI tool to be useful (and even if it did, we can't use any random model due to compliance and proprietary and whatnot).

I have thousands deadlines which are suddenly coming due and a bunch of code which is broken because some poor soul under the same pressure put something that "works" in. And it worked, until it didn't, and now it's my turn in the barrel.

Is this the joy?

I'm not complaining, I'm doing it for the good money.

This, but also look into the rigid lenses. Was a game changer for me.

"The fix going forward is that Microsoft needs [...] not just raw dog risky updates to customers."

Odd critique. Microsoft could do whatever, it was Crowdstrike who "raw dogged" the update to customers without any meaningful staging.

This looks like a great candidate for crowd funding.

yes, in this case I'd say a good crowd funding platform is the IRS.

Sorry, could you elaborate? If I'm creating an API using, say, ASP.NET Core or Go, I can generate OpenAPI spec out of actual implementation. How this "IDL" fits into the workflow? Is this another output in addition to OpenAPI spec?

TypeSpec is designed primarily as an API first tool as opposed to being an output. In the context of ASP.NET and HTTP/REST APIs, our goal is that you can write your spec and generate much of the service implementation and clients. From this same source of truth you could also emit clients or service implementations in other API definition formats like OpenAPI, schemas like JSON Schema, and other things besides.

In my (limited) experience so far with TypeSpec - it really shines in an API first approach, so you define your API before you implement it, but not so much the other way around.

I'm renovating the house I live in and the closest to smart devices I installed were Caseta plug in dimmers with pico remotes. The rest of dimmers are just hardwired Maestros. Knowing the half life of an internet facing service, the last thing I want is someone pulling the rug from under all my electrical stuff.

Once I tried to enable the app for the washer and dryer and have given up on the app suggesting I disable the firewall for something to connect. No thank you.

Lutron is a good demonstration of a company going about it reasonably. The smarts are in the bridge not the switches and not the bulbs.

For context, Lutron is a client. Though I am just a happy user of the Caseta product at home. I don't have any engineering say in how it was built.

Can they be interface directly with home assistant without wi-fi?

I am not sure. I do have mine pair with my iPhone using the picture on the label of the bridge. The bridge itself communicates with the dimmers via the same wireless protocol the pico remotes use. The bridge has all the smarts in it for working with apps, doing schedules, etc. My bridge is about 9 years old and is still getting updates. Internally, I am aware that efforts are made to ensure that systems work for 20 years or more.

Does anyone know what the Soviet mustard is made of? The one that burns you like sulfuric acid.

I've never had Soviet mustard (and my time machine is broken), but it might be just... mustard.

For fun, combine some ground mustard seed and water in a dish. Mix it up into a runny paste, and taste some right away: It'll be vaguely mustardy, and also somewhat boring.

Then set it aside at room temperature and go do something else for 10 or 15 minutes, and taste a tiny bit of it again. It will be like fire -- a seriously-intense, sulfurous heat that tickles the corners of the sinuses that you didn't even know you had.

It's an enzymatic reaction, similar to what happens with fresh pulverized horseradish root, and it gets stronger over time.

And just like with horseradish: To stop it at a given level of intensity, just add an acid.

(Those who mix ground mustard directly with vinegar and thereby skip the part where it is allowed to bloom with water, are completely missing an entire world of what mustard can be.)

Probably horseradish which, incidentally, is also a member of the mustard/cabbage family. If you make mustard from scratch you will note that raw mustard seeds have a very horseradish-like flavor as well.

It exactly is a structured log or log in open telemetry.

To make it easier for myself, I think of spans also as structured logs with a schema that everyone had agreed on, which make it possible to trace requests across multiple services/clients. It's probably more than that, but I don't need academic precision to see how this is more useful during livesite investigations than simply querying logs with unaligned schemas.

Yes, structured log exactly. Why I prefer "wide event" as a term because it has this "wide" component that serves for 2 purposes:

- it highlights the intention of storing as much context as possible - it also hints on the implementation for a system that would serve them. One likely need to use columnar storage to store wide events, there is no way around it

But just a personal preference in the end.