Honestly I'd much rather have some configurable yaml than some obscure app in the middle of your cluster that reads CRDs when what you're doing is just adding a side car.
At least this way you can tell if your local yaml is applied or not without a complicated diffing algorithm that compensates for an in-cluster modifier.
You can get it much of the way there by tweaking `~/.inputrc`
"\e[A": history-search-backward # Up key
"\e[B": history-search-forward # Down key.
Allows you to get press up while you have `ssh 10.2` in the terminal to cycle through ips matching, etc. It won't display like in fish before pressing it, but I find that's a reasonable tradeoff.
Managing node with package managers feels like a a bit of a fools errand at the moment. They are going to be wrapping npm somehow, but when npm can't even do things right..
Is there really any benefit to this over explicit child process calls? I realize the syntax is shorter, but now you're hiding the fact that you are shelling out.
Overloading require for this purpose is a guaranteed way to break static analysers and module bundlers.
Nitpick, on the nothing can save me there part. This is arguably a failure of `your-class`'s API.
A file exposing a class SHOULD either wrap it: `module.exports = function () { return new YourClass(); }` or use `if (!(this instanceof YourClass)) return new YourClass()` guards in the constructor to stop users of a class having to worry about whether or not to use new.
At least this seems to be the convention many module publishers seem to adhere to.
Asynchronicity isn't an optimization, it's a simplification. Blocking code and threads are hard to reason about, but callbacks are simple. You still have to deal with errors in a synchronous world, and an evented system allows you to deal with branching event possibilities sanely.
