gabetax

Who would want to? APISIX apparently: https://apisix.apache.org/docs/apisix/getting-started/rate-l...

From the toki pona conlang, this also visually reminds me of the "sitelen musi" writing system.

https://www.reddit.com/r/tokipona/comments/hlpvx0/sitelen_mu...

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

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

Specifically, these functions to not provide "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.

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.

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

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.

You can implement emptiness with the wrapper message types, e.g. StringValue: https://github.com/protocolbuffers/protobuf/blob/master/src/...

and sometimes defining your own, e.g. nullable lists.

It's not elegant, but it is simple.

Have you read that NASA study? It involves air being run through an activated carbon filter, and the plants using that carbon filter as its growing medium. From the paper:

This air filter design combines plants with an activated carbon filter as shown in Figure 1. The rationale for this design, which evolved from wastewater treatment studies, is based on moving large volumes of contaminated air through an activated carbon bed where smoke, organic chemicals, pathogenic microorganisms (if present), and possibly radon are absorbed by the carbon filter. Plant roots and their associated microorganisms then destroy the pathogenic viruses, bacteria, and the organic chemicals, eventually converting all of these air pollutants into new plant tissue.

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/199300...

This isn't how most people setup their house plants.

I prefer to think of it as the mullet of the database world: Bigtable in the front, Dynamo in the back.

For such a long README, this utterly fails to explain or even link to what Lilypond is. I googled for a few pages, assuming that it wouldn't be related to http://lilypond.org (partially due to the differences in capitalization), only to find if I searched the README for "music" that it seems to be related. I'm still not sure why a music notation program needs a package manager.

http://static.googleusercontent.com/media/research.google.co... is a collection of more advanced container patterns you might be interested in.

If this sort of stuff is relevant to you, http://patshaughnessy.net/ruby-under-a-microscope is an essential book to read.

You can use a datastore like HashiCorp's vault: https://vaultproject.io