"Memory effect" in the 1990s is an old wives' tale. It's a real condition discovered in the 1980s on satellite platforms with computer-controlled charging, but was identified and fixed quickly.
It never existed in consumer applications of NiCd batteries, especially as late as 1996.
It was not an old wives tail. I worked in wireless retail 23 years ago and saw these problems first hand. NiMH phone batteries from that era would scarcely last two years. Of course, it mattered less then because the tech was improving so rapidly that most people wanted a new phone every 2 years anyways. NiMH was an improvement over NiCd, but it still had memory problems nonetheless in its first few generations (modern NiMH batteries are better at this).
It could be mitigated by fully discharging a battery before recharging, and I'm certain that in applications such as satellites , they engineered the charging cycles to mitigate this. However, consumers powering phones and laptops can't be expected to maintain such discipline. Certainly people driving cars over variable distances can't be expected to uphold such requirements either, out of absolute necessity to travel a fixed distance between charges.
Lithium ion ultimately won because it solved these problems altogether. Modern NiMH has caught up a little bit, but Lithium has meanwhile improved as well.
I'd argue the opposite: APIs should publish all datetimes as UTC timestamps and only the client should be involved in presenting datetimes in the way best suited to the user experience.
I'd also argue that presenting dates in ~0KB of javascript is better and less error-prone than several KB of javascript - it also allows users to see dates in non-Gregorian calendars when they prefer.
I'm afraid you have missed the point. My point is that most of the time you don't need datetimes. You only need dates.
Think about sites like blogs. The user only needs to know on what date a blogpost is published. Likewise for newspapers: we have hundreds of years of paper newspapers where people know on what date an article is published but not at what time. Think about banks. My bank tells me the date of a transaction, not its time. Likewise for brokerages.
It looks like `.epochMilliseconds` should work as a Map/Set key/member in some situations, though you'll need to preserve the instant in the value in the Map case if you want to preserve the zonedata / do further operations on the Instant.
For the Set case you could use a Map{v.epochMilliseconds:v} and preserve the Instant.
Not great, but I think we all blame JS for this rather than Temporal. This could be made to work by the runtime but then polyfills would fail.
Passing Dates to a React component caused re-rendering issues in some of my applications due to Date being an object.
I had to resort to numbers (Unix time) to not have to add memoization everywhere. Seems like this will continue with Temporal. Or React-Compiler will solve this.
I've not done it, but have you considered using `pnpm` and volume-mounting a shared persistent `pnpm-store` into the containers? It seems like you'd get near-instant npm installs that way.
The only time npm install was on the critical path was hotfixes. It’s definitely worth considering. But I was already deep into doing people giant favors that they didn’t even notice, so I was juggling many other goals. I think the only thank you I got was from the UI lead, who had some soda straw internet connection and this and another thing I did saved him a bunch of hard to recover timeouts.
You'll also see the benefit when `rm -rf`ing a `node_modules` and re-installing, as pnpm still has a local copy that it can re-link after validating its integrity.
In some scenarios the equation flips, and the enterprise is looking for _more_ scale.
The more bandwidth that Cloudflare needs, the more leverage they have at the peering table. As GitHub's largest repo (the @types / DefinitelyTyped repo owned by Microsoft) gets larger, the more experience the owner of GitHub (also Microsoft) gets in hosting the world's largest git repos.
I would say this qualifies as one of those cases, as npmjs is hosted on Azure. The more resources that NPM needs, the more Microsoft can build towards parity with AWS's footprint.
Water rights in the western US are mercenary. There's a healthy market in prior appropriation rights.
Just because people don't like what the water is used for doesn't mean the water isn't priced appropriately. You'll still get farmers growing thirsty / pricey crops in the desert if it covers the cost of irrigation.
The comparable unit (in terms of estimating irrigation needs vs rainfall vs reservoir draw, which are the terms we reason with in this part of the US) would be the hectare-meter, which is 10,000 cubic meters.
reply