thedirt0115

Consider owning an ETL system where users can create periodic jobs, like calculating a "daily active user" rollup table from a bunch of event source tables. Now consider being asked to switch the query execution engine from A to B, perhaps because engine B is much more cost-effective for your system's query patterns. Ex: You are tasked with switching from MapReduce to Tez, from Presto to Spark, etc. Before full migration, you can reduce risk by double-writing jobs, with engine A writing to the standard output location, and engine B writing to some other migration location. This should lead to two identical SQL tables, which you should then verify, because sometimes these execution engines have bugs hiding in the corners :)

There is a rule variation that disables confirmation of whether the person you're voting off was a crewmate or imposter --- this variation makes the "kill, self-report, blame other person" strategy viable. It's a simple change, but it really spices things up!

This is really cool, thanks for sharing! It would be great if the hover text for the tools also displayed the keyboard shortcuts that I found in the nice and easy-to-read JavaScript :)

Don't be afraid to put unfinished code or code without tests up on GitHub -- just mention in your README that it's not production-ready yet or something. It still has educational value for the community. Maybe someone will even help you write tests! Btw, thanks for sharing -- I had never heard of the R-Tree data structure before.

That looks like it's from 2016 -- is this still the case? (I'm not a Dropbox user, but would like to know)

These are called "pangrams". Here's a fun one that's short and makes sense: Waltz, bad nymph, for quick jigs vex!