Q^mSat,3^b:d+s+E,4Fri,3^u:h+k+u,6Thu,3^P:j+
If you are effectively going binary, do it. CBOR or Protobuf or any dozen other binary serializations that would be far more efficient.The author claims this is because of copy and pasting… cool, remind me what BASE64 is again?
Sure, you can encode as JSON, then compress with gzip and then base64 encode. You'll probably end up with something smaller than rx and be extremely safe to copy-paste. But your consumers are going to consume orders of magnitude more CPU reading data from this document.
RX is usable as-is, is compressed, and is copy-pasteable. It's the unique combination of properties that makes it interesting.
>Q^mSat,3^b:d+s+E,4Fri,3^u:h+k+u,6Thu,3^P:j+
My man… no. I have no doubt you could kind of figure out what that sample is hot off the heels of writing this, and likely not in six months. And to consider that anyone else would fill their brain with the rules to decipher that, Nah 2.0.
Even a trivial doc like this is challenging for me to read as a human.
- clipboards
- logs
- terminal output
- alerts
- yaml configs
- JSON configs
- hacker news comments
- markdown documentation
- etc...
I assure you, this is not a solution looking for a problem. I started out with binary encodings first, but then realized it limits so many workflows.
> Nah.com, fam.