> It's not like there is a mirror datacenter just two blocks away
Isn't that exactly what Availability Zones are for? They're physically separate[0] datacenters and each one contains a copy of each S3 object (unless using the explicit single-zone options)
It's also straightforward (although not necessarily that cheap) to replicate S3 objects to another region
Not sure about heat pumps, but in the UK at least there are a couple of companies that specialise in residential water cooled AC, e.g [0]. They use the cold water intake to cool down the compressor which sits inside the property
From a marketing perspective it’s not (as far as I’ve seen) driven by eco credentials, but by not needing planning permission - external AC compressors are not automatically permitted in the UK.
Kysely is excellent! Another library that complements it is pgTyped[0]. It compiles .sql files into functions with strongly typed parameters and return values
Not sure if this is what you're getting at, but RabbitMQ is indeed pretty great at having thousands of queues, even on modest hardware, and can be used for per-tenant queues in this way.
It does have some drawbacks though: if you have thousands of mirrored or quorum queues, managing the cluster becomes more cumbersome - it can take a while to replace nodes (rebalancing thousands of queues around). Also, the management tools (the web UI especially) don't perform that well if you have 10,000s of queues and 100,000s of consumers
I think the typescript-eslint plugin in particular has some high value eslint rules that complement TypeScript.
For example, the no-floating-promise[0] rule catches some easily-made mistakes involving promises in a way that TypeScript doesn't on its own.
Other rules can be used to increase type safety further. There are various rules relating to `any`, like no-unsafe-argument[1], which can be helpful to prevent such types sneaking into your code without realising it; TS has `noImplicitAny`, but it'll still let you run something like `JSON.parse()` and pass the resulting any-typed value around without checking it.
> For example, the no-floating-promise[0] rule catches some easily-made mistakes involving promises in a way that TypeScript doesn't on its own.
Is there a fast linter that checks for this? I find this error easy to make as well, and it usually causes weird runtime behaviour that's hard to track down.
The object key order thing is not a JSON spec compliance issue, but this one is. Either PG should store this escaped or use counted byte strings, but you can see why neither is desirable for a high-performance binary JSON format.
Indeed, the interchanges can be quite arduous, as it tends to be very deep, and usually quite a trek from the other lines in that station. This also means it can take a good chunk of time to even get to or from the platform.
For example, if you wanted to go from Farringdon to Liverpool St, Google Maps would suggest using the Elizabeth line, but, in practice, it's usually better to use the sub-surface lines (Metropolitan etc). The time taken for the extra stops will be cancelled out because the Elizabeth line takes significantly longer to get into/out of of as it's so much deeper. Add another couple of minutes if you happen to get on the wrong end of the train, because those platforms are long!
That being said, it's a joy to ride and is the only air-conditioned train that runs through the central section of London.
They just changed the versioning scheme; it used to be that e.g. 9.3 -> 9.4 was a major version (i.e. can't be upgraded in-place). Starting with PG 10 major versions are now 10 -> 11, etc. I don't believe the major release cadence itself changed that much
It seems like they fell more inline with Semantic Versioning when that format came in vogue. Semantic Versioning is what most devs expect now; it makes sense to communicate the version in a format that has a broadly understood meaning for devs.
I think there is no semantic versioning anymore, they just release one major number version every year, regardless how large and backward compatible changes are there.
Power is needed for the full “smart toilet” experience, which can include a heated seat and warm water, and other less useful features like a self-opening toilet seat. It’s hard to go back to a regular toilet or a cold-water bidet!
