garthk

“Society is a construct”, for starters?

"endlessly powerful"?

See also: Twitter's Finagle [1] for the JVM, and Bouyant [2] providing Finagle-as-a-microservice on localhost for language independence.

1: https://twitter.github.io/finagle/ 2: https://buoyant.io

http://decentsecurity.com/?

For those still not quite getting it:

The first copy to RAM was a sequential image copy, thus not bottlenecked on seeks despite spinning platters.

The second copy from RAM was a file copy with a lot of random I/O, but not bottlenecked on seeks because it was reading from RAM.

Bulk writes tend to be more efficient. They might have made temporary configuration changes to make that end faster, or not if they lacked the appetite for the extra risk.

This is going to look bad. I'd better tase the corpse so I can claim I tried non-lethal means first, but the guy was unstoppable and I had to kill him.

Thanks for the handshake tone! The more, the merrier: did anyone archive examples from 1200bps up?

I've also been fruitlessly searching for line noise examples ~~~~~}}~00 etc. Remote Access had a line noise simulator; someone has to have details…

I think the most dangerous advice I got was to avoid DTOs and similarly domain-behaviour-free object graphs. That corner of the .NET world at the time called such a model an 'anaemic domain'. Instead, we were encouraged to model problems with objects for every noun, methods for every verb, arguments for every adjective, and all the code dealing with them attached to the class.

It worked fine while our domain remainded small, but got ghastly quickly.

The Sun 3/50's pixel buffer was world readable and writable by default, and in console mode had an area at the bottom not affected by scrolling. One could invert random horizontal bars across the screen, transpose the bitmap, or apply a sine wave to persuade the user the massive TV set on top of their workstation was broken. Or, fade text in and out as if the machine was commenting on the user's ineptitude. Much fun was had by all.

> It's like static linking an entire operating system for each application.

You say it like it's a problem, but that's the most concise description of Docker I've yet read. It rhymes with the way all the fed up oldies using Go like its static linking.

Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. – Blaise Pascal, Lettres Provinciales, 1657

Now it's serving or proxying gogs.io.

Strikes me you could also go through the process using letsencrypt in a container (eg Docker on Linux) and extract the results.

'npm ls' might give you a clue.

Most mysteries come down to loose dependency declarations and semver stuffups, sometimes in combination. One of your deps' deps takes a ~ on one of its deps, that dep makes a breaking change and changes its version from 0.3.2 to 0.4.0… boom. Your fresh npm install on workstation #2 inhales the breaking change and doesn't work, but workstation #1 still works fine.

Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.

It's a machine. It's a lot more predictable than you think.

The payments on technical debt never seem to come due when you expect, nor at the size you expect, hence arguments we should think instead in terms of unhedged call options, e.g. http://www.higherorderlogic.com/2010/07/bad-code-isnt-techni...

Everyone thinks they can pay after the release. If you cut those corners hard, though, you'll often regret it before your release. Cut harder still, and you won't even make it to the end-of-sprint demo before there's a knock at the door.

On the other hand, there's every reason to believe the "Go [a]Way" prohibition on certain language features will leave Go 2 insufficiently attractive vs Go 1 to overcome the switching costs, dragging out any migration period. See also: Python 3.

Ha! I'm like that with my QA people, begging them to come after me with a blunt weapon.

Many correlate "sane" with "statically typed". [1]

JacaScript can cope perfectly well with modules A and B relying on different versions of C. It'll often cope even if A calls B with an object it got with C, or some other module broadly compatible with C. Static typing proponents aren't comfortable with the idea, so it's not "sane" to them. Sane or not, many argue it's not just not slowing down the Node community, but actively contributing to its explosive growth.

In C#, you get MethodMissingException if A.DLL and B.DLL refer to different copies of C.DLL and A calls B with an object it got from C, even if the copies of C.DLL are identical.

1: Perhaps I should contrast with strong typing, not static typing. Meh.

We rolled our own Flux library before they published any code, dodging singletons and gaining mock-free testability. I just re-wrote it, but will check Flummox out.

Thanks for using your own account.

See also: E_NOTADATABASE.

http://howfuckedismydatabase.com/nosql/

I'm not as sold on passion as a requirement as I was. Too often, it's just monomania or obsession in a fancy outfit. See also: Programmer Passion Considered Harmful: https://news.ycombinator.com/item?id=9211214

The only numbers I've seen come from the Separating Programming Sheep From Non-Programming Goats papers by Saeed Dehnadi and Richard Bornat:

> We have discovered a test which divides programming sheep from non-programming goats. This test predicts ability to program with very high accuracy before the subjects have ever seen a program or a programming language.

http://www.eis.mdx.ac.uk/research/PhDArea/saeed/

It's entertaining, but I think the double hump in first year comes more from Dunning Kruger and compulsory courses than anything else. I've heard of the same kind of distribution in first year biology classes. Even if "true", I don't think it gives us an excuse to anyone we think is insufficienty spectacular out of the industry.

I often find bold text helpful for key points, or for the first mention of key terms to help orient me in a document. There was something about the mix in this document that felt inconsistent. I found myself pausing to try to figure out why the author wanted my attention on this particular word or phrase.

A thousand times: this.

… which is one of the pressures driving Docker adoption. Each process tree gets its own root filesystem to trash with its multitude of dependencies. DLL hell, shared library hell, JDK hell, Ruby and Python environment hell… a lot of it can be summed up as "userland hell". Docker makes it easy to give the process its own bloody userland and be done with it.

Same as everything: look at how it was built. Many of the images are built by CI systems according to Dockerfiles and scripts maintained in public GitHub repos. Audit those, then use them yourself if you're worried about the integrity of the services and systems between the code and the repository.

Only in marketing buzz, and only if he cares.

lodash is as fast as fast: see the JSPerf results posted elsewhere. John manages lodash well. He has managed it well for quite a while. Why switch to another library with no track record for little or no gain?

Thanks for that. I can tell the young pups to calm down.