clux

Not sure if it helps much. It still looks like the same clickbaity garbage that's in my regular trending tab.

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.

Crypto still just means hidden or secret though. Both sides here probably ought to increase their specificity by one level.

Interestingly, r/crypto is the cryptography subreddit and has https://www.reddit.com/r/crypto/comments/7jrba2/crypto_is_no... stickied.

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

This is cool. A few funny ones I found:

ExampleTester

Commanater

java-cruft

Generatter

the-git

Damn that Fermat margin.

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.

There are also 3 gotos in that function.

I would totally install a sublime plugin or something like that for this.

Yeah, got that too. Maybe time to go to bed.

Biggest problem is also its greatest benefit. If everything CAN access anything, everything WILL eventually access anything.

Without any barriers, it's way too easy for things to devolve into spaghetti code.

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.

Alternatively, put this in your code tomorrow to pre-empt all the April 1st bastards:

    Object.freeze(console)

Or safe JS up entirely: https://gist.github.com/clux/3823024

Managed a 4096 piece (more than I've done on normal 2048). Unfortunately, the 4096 background is the same as 1024 (derp).

Here is a picture of my layout before it collapsed into a 4096: http://i.imgur.com/SnmhESY.jpg

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.

I did use cabal-dev, and it only moved the problem from being a global problem to a local one. Is the problem that you cannot have several versions of the same package solved? Because this really needs to work, otherwise you effectively have a limit on how many modules you can use sensibly without expecting things to break.

  What's not to like?

Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

I am sure this is good, but just how much it pulls down to do something basic is ridiculous:

  $ yo webapp
  $ npm ls | wc -l
  240

The default lexicographical sort order on an array of integers is unexpected, yes.

Ad hominems generally are nothing else..

There's plenty of ways to make a difference in the world without having a job that is immediately altruistic.

http://80000hours.org/career-advice has a lot of good information along these lines.

Neither. Small modularized CommonJS files that serve the need of what you are doing is always faster to write and easier to load in your head than large frameworks that you never fully understand. Learn to use npm and use it well.

Speculative non-article..

From the last paragraph:

He said: "A solar proton event and a short gamma-ray burst are both possible explanations, but based on the rates that we know about in the Universe, the gamma-ray burst explanation is about 10,000 times less likely to be true in that time period."

From near the end of the article: "This isn’t to say that 3D TV is dead — but it’s certainly no longer the next big thing."

Linkbait title.

I'm not big on the glaringly inefficient transpilers that Haskell has come up with. You can replicate a lot of Haskell's functionality in JavaScript very elegantly.

See for instance:

* https://github.com/clux/autonomy - prelude like thing

* https://github.com/clux/subset - basically Data.List

* https://github.com/clux/operators - currying helpers

* https://github.com/clux/interlude - a collection of the above 3

It has made my JavaScript development very enjoyable. JavaScript really doesn't suck have to suck. You can write very elegant code in it. It's just not as elegant as Haskell.

Sorry, didn't get it.

You're saying arguments are more convincing if it wasn't for ad hominem x? Says more about you tbh.