_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.

Accompanying public announcements:

https://neuraldsp.com/quad-cortex-updates/introducing-tina

https://neuraldsp.com/news/neural-dsp-amplifier-modeling-tec...

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.

I have this bookmarked and have been using it for approximately the last five years. There's a similar one for flexbox [1].

[1] https://css-tricks.com/snippets/css/a-guide-to-flexbox/

> 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?

The article claims two competing theories of obesity: the energy-balance and the carbohydrate-insulin model. The energy-balance theory isn't much of a puzzle, as you say. The puzzle is rather how to reconcile these two theories. According to the article, fructose is the unifying factor. Eating more fructose drives increased appetite and lowers metabolism. This feeds into the energy-balance mechanism, causing obesity. To your point, the higher appetites caused by fructose are incentivizing restaurants to offer larger portion sizes.

Web browsers should add a DOM method called `addEventStream()` to supplement `addEventListener()`. It would still accept an event type—e.g. `button.addEventStream('click')`—but would not accept a handler function. It would just return an async iterator of event objects. Backpressure on the iterator would place the element into a `:waiting` state similar to `:disabled` in which the element would become non-interactive. All UI event handling becomes a data processing pipeline.

I've thought about this a lot. My personal theory is that when young leave their home communities to seek opportunity elsewhere, that experience changes them. Afterward, to the extent they return, they rejuvenate their community. To the extent they don't, the community stagnates. The reality in the US is mostly the latter. This also created a self-perpetuating cycle, since who wants to go back to their stagnant little corner of the world after getting a taste of cosmopolitan life?

So all that said, I imagine a hugely beneficial policy would be one where young people who leave for college would get assistance paying off student debt if and to the extent they return to their community afterward.

I think the point is more that multi-generational households would occur naturally, but as you alluded modern society gets in the way. I have a similar situation as you. It's interesting to imagine what policies would have incentivized us to settle down nearer our parents. Like, what would have made that a palatable option?

The problem with two-parent is you're a single misstep away from one-parent. Multi-generational and communal households would be more resilient, and easier to accommodate via tax incentives and housing policy.

Aren't these zero-days sold to highest bidders? Just an honest days work...

I wonder if this was the students' attempt to protect their future careers as much as anything—"keep quiet about this or else"—especially given the issues were quickly fixed. In that sense it differs from the classic 90s era retaliation. From the students' POV it was probably quite terrifying. I wouldn't discount intervention by wealthy parents either, but of course I know nothing of the situation or the people involved.

Or rather, an ideology doesn't operate in service to the individuals who hold it, but in service to itself. So rather than scratching our heads about how an older women could possibly be a rival to the baker, or the town leader, it makes more sense to look at how she might be a rival to the overall belief system of the community, especially in situations where a new belief system (e.g. Christianity) has displaced an older belief system (e.g. paganism, animism, etc).

I don't think every aspect of culture necessarily can be traced back to a pragmatic reason. Sometimes people just act out their belief systems, regardless of whether the results are helpful or detrimental to them or their communities.

    Until recently, an internal API framework, Falcor,
    powered our mobile apps. They are now backed by
    Federated GraphQL, a distributed approach to APIs
    where domain teams can independently manage and
    own specific sections of the API.

I was an early-adopter of Falcor back when Netflix first started promoting it, and have also spent some time migrating those Falcor calls to GraphQL.

Redux is very straightforward until you start adding middleware, then the complexities start piling up.

Nothing other than they're one of the more esoteric and misunderstood features of the language.

Why not have it return an async iterable, which has both push and pull semantics? Combined with the iterable helpers proposal you'd get a lot of things for free, including end-to-end backpressure.

Inclined to disagree. I once worked on a product that went all-in on modals for detail-views, and we ran into all of the problems mentioned in the article. It produced a constant stream of tickets, and at the end of the day the UX was indeed terrible.

> Don’t use sugar substitutes if you are trying to lose weight, according to a new guideline from the World Health Organization.

Is weight loss the main reason for using artificial sweeteners? I thought avoiding blood sugar spikes and crashes was at least as important, and also that the by-products of fructose metabolism weren't great.

> Why not send top stockholders to prison while you're at it?

Or just curtail every holder's shares by a fixed percentage, if/when a publicly-owned company is found to have engaged in anti-competitive behavior. If the incentive of maximizing shareholder value is no longer aligned with the interests of society, maybe that's how to fix it.