For basic SETNX single instance redis instances, sure.

But for the Redlock algorithm, I've never encountered anyone that was already running 5 redis masters to use out of convenience.

You're much more likely to have an etcd, consul, Zookeeper, etc cluster that you could use for coarse-grained distributed locking.

The best research I've seen on this is the paper "On the Prehistory of QWERTY" [1] which has a great figure on the fourth page with the presumable original prototype showing all the consonants wrapping around alphabetically and the vowels on the top row.

[1] https://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433...

Specifically, these functions to not provide "uniform distribution".

That isn’t a requirement of an algorithm called a hash function

From the article:

> For a function to be useful as a hash function, it must exhibit the property of uniform distribution

It's also listed as the first property on the Wikipedia page:

https://en.wikipedia.org/wiki/Hash_function#Uniformity

I can’t find the text you quoted. The article starts off:

> A hash function is any function that can be used to map data of arbitrary size to fixed-size values

And the first sentence in the section you link says

> A good hash function should map the expected inputs as evenly as possible over its output range.

It doesn’t have to be “good” to be a hash function.

That's not a meaningful definition of a hash function, then.

    def hash(val):
        return 0

Yes, this is a hash function. Whether it’s “useful” or “good” is the purview of the architect.

Tangential edit: https://xkcd.com/221/

The best thing about that one is that it seeds the panel with a random number every time you refresh

That has a pretty uniform distribution..

The biggest issue I've personally experienced is semantics when wrapping your head a design or debugging a service you aren't familiar with.

"POST" has come to imply a "write" operation, and mixing up the the reads and writes of a system leads to cognitive dissonance.

This is a Javascript issue, not a JSON issue. The JSON spec doesn't apply any limits on the number type. ECMA-404 states:

> JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange.

It also explicitly excludes NaN encoding, which further distances itself from any coupling to IEEE floating point expectations.

Yep, if you use e.g. Java's jackson, you can configure it easily to deserialize numbers as BigInteger or BigDecimal instances. Useful trick if you need it and it really works. You can have arbitrary precision numbers in Json. Of course this does challenge most other parsers out there.

That level of scale always boils down to partitioning work. The fact that these partition are distributed across regions is done for risk mitigation (e.g. what happens when AWS's eu-central-1 catches in fire). Architecturally, nothing really changes if you stuffed them all in the same region.

Check https://use-the-index-luke.com/no-offset as a better reference.

But in most SQL databases, cursors are something you implement and parse at the application layer, and translate to a WHERE clause on the (hopefully indexed) column you're ordering on. That turns the O(N) "OFFSET" into a O(log(n)) index seek.

Many databases have actual cursor implementations which are transactional. That means you’ll get a consistent view at the point in time you created the cursor.

That said, they tend to live only as long as the db connection (with some exceptions), so yeah you need some application work to make it sane.

How is a cursor different from key set in that case?

It's not in that case, cursors can be implemented however you want though. Its an abstraction, that prevents you from having to change the schema of the API when you change the implementation.

While Dvorak is a good layout, in 2021 I would always advocate using Colemak instead (at least for English typists). Colemak is:

- easier to transition from QWERTY since it changes fewer keys (particularly the QAZXCVB shortcut keys)

- scores marginally better than Dvorak in different models, e.g. http://mkweb.bcgsc.ca/carpalx/?colemak

That said, if you're already this deep into Dvorak, I don't think the gains are worth the effort involved in another switch.

This is a tangent on your metaphor, but PB&M has actually been a popular combination in the past. https://www.atlasobscura.com/foods/peanut-butter-mayonnaise-...

Oh wow. I never knew that was a thing. When I was 6 or 7, I decided to make the most disgusting sandwich I could think to make. I ended up "inventing" a PB&M on white bread.

I was pretty disappointed as it wasn't too bad.

Programming languages mostly boil down to symbols, and I haven't seen standardization efforts around that concern specifically. Some layouts swaps the "shift" state on the number row (i.e. you type ! by default, and have to hold shift to type 1). There are more commonly efforts around dedicated layouts for compact boards, like [Miryoku](https://github.com/manna-harbour/miryoku). You will find a ton of bespoke layouts though. https://configure.zsa.io/ergodox-ez/layouts/Qa34z/latest/1 is what my own layout that places `{}() -_+=` on the homerow. This is heavily dependent on language though. A Haskell person is going to have different symbol histograms from a Javascript person.