@11/10/2020 ¤ Journal
I used to think for a long time my job as a programmer was mostly about translating numbers or strings, into different numbers or strings. My job looked something this:
+-------+ Data +-----------+ Data +-----------+
| Human | ---------> | Metal | ---------> | Human(s) |
+-------+ Code +-----------+ Code +-----------+Roughly speaking:
Sometimes the Metal has many loops, it can have little H→M→H loops in itself too. It's turtles all the way down!
For most applications we are building a communication system between Humans. The Data asked for and retrieved changes rapidly, the Code shifts in waves depending on the velocity of those (also Humans with real biases) working on it. The Metal (hopefully) shifts glacially. Unless, of course:
Humans and Code are going to vary drastically from system to system. The Data though: chances are it's going to be JSON at some point in the process. JSON as the major Data transport format is here to stay, possibly for the rest of our careers. Yes, there have been precursors: SGML, CSV, XML. Upstarts like YAML (gasp!) and MsgPack continue to challenge the status quo, but only JSON remains.
I'm certain that 10, 20, 30+ years from now, JSON will not only still exist, but will continue to be the standard gauge for all data. What can you do on a daily basis to make sure that you know how to best work with our industry's standard gauge? Here's what I'm doing:
- Discover what standard tools exist for JSON (json_pp on every OSX for example)
- Learn and use jq to slice and dice JSON data
- Implement new static configuration in JSON wherever possible
- Prefer databases that have native JSON types
- Know your language(s)' JSON libraries APIs well (and why they can be slow!)
I'm sure that I'm missing more tools here, and I'd love to know what they are (please @ me). Also if you're reading this in 2050 and we aren't writing JSON, please tell me why; and how any of us managed to get through the year 2020.
¤ @qrush