_greim_

Since the goal is to create an illusion of real physics, I wonder when they'll just cut to the chase and start using actual physics engines.

Reason I mention it is neither this nor bezier curves deal with the target changing mid-animation very well. CSS just starts over from the current position, which breaks the illusion. A physics engine would maintain the illusion, and could be simpler to specify:

    transition: physics(system=gravity, force=10, bounce=on, dampening=3)
    transition: physics(system=spring, force=5, bounce=off, dampening=5)

> Developers can also easily create, view, and upgrade skill versions through the Claude Console.

For coding in particular, it would be super-nice if they could just live in a standard location in the repo.

What's messing with people's heads when it comes to predicting solar is the perfectly rational tendency to base projections on past and current data. I think it qualifies as a black swan event for this reason.

As I understand, this company's existing consumer-level product can already be used to capture the sound of an amplifier, but it's a snapshot of the device's (amplifier, effects pedal) settings in terms gain, eq, etc.

Meanwhile, they have an extremely labor-intensive set of techniques for modeling a device's analog circuitry, resulting in a model that allows the user to adjust gain, eq, etc. This isn't a consumer-level process; it happens in a laboratory somewhere, and the output is shipped as a software plugin or model on a digital effects unit.

This technology bridges the gap. Ultimately it's an unguided ML approach akin to the former, but introduces ML-guided robotic knob-turning (AKA "TINA") which (unlike the former) maps continuous changes within the device's parameter space, allowing to ship something more like the latter.

I'd divide CSS development into eras.

First there was the DIY Era, when layout options were limited and CSS implementations were riddled with bugs and browser differences. Most folks coded their own layouts using a small bag of tricks (e.g. float + clear-fix). It was messy, but it all fit in your head.

Then came the Framework Era, when lots more things became possible, but the size of the spec exploded, and with it the number bugs and incompatibilities. A common choice at this point was to use a framework.

This article fits with the idea that we've entered the Reference Era. Implementations have matured enough that browsers do what you want without arcane hacks and workarounds. You just need a good cheat-sheet, because the spec has long since stopped fitting into most peoples' heads.

Phone-free schools seem like an obvious way to fight this, but supposedly modern parents need constant access to their kids and tend to oppose the idea.

"Reduce bugs" is kind of a loaded term anyway. Static typing doesn't reduce bugs in an absolute sense, but I think it does reduce bugs per unit of value delivered. That's a lot harder to measure in a formal study.

    Hype: "Static Typing reduces bugs."

    Shower: A review of all the available literature (up to 2014),
    showing that the solid research is inconclusive, while the
    conclusive research had methodological issues.

Static typing lets you do more complicated things by offloading a subset of complexity-management to robots. The remaining human-managed complexity expands until new development slows to a crawl, and no further human-managed complexity can be admitted to the system, similar to adding more lanes on a freeway.

Glad to hear I'm not the only one who forgets what those things are called! There was a time when CSS fit in my head, but those days are gone.

> So put your EV charger on the same circuit as the dryer. Then as long as you don't need to charge the EV at the same time you are running the dryer as far as your house wiring is concerned it is like you are running an extra two loads of clothes through the dryer every day.

I asked an electrician about this once and got lectured. Apparently per regulations a dryer needs to be on a dedicated circuit, and tapping into that line is a big no-no. Nor do you want to have to depend on a breaker as a fail-safe at this amount of current. Instead he ran a separate 50 amp line to my garage terminating in a single outlet, that I can do whatever I want with, EV or welder or whatever.

The visual design problem mirrors a problem with the organization producing the website. Before mobile, a website was the entire online presence of a company; every subdivision within the company had a presence above the fold. The culture and conceptual structure of web development developed around this concept. As mobile mandates pushed things below the fold or off the site entirely, web teams found themselves unprepared and have adapted awkwardly, as this article shows. Mobile app teams never had this cultural baggage, which is one of the many reasons native apps are perceived as superior.

I know nothing about airplanes, but surely it would be a multi-step process involving override modes, power-down phases, klaxons, red blinking lights, warning messages, physically separate switches, and so forth?