And you are here why?

 ruc /via http://www.commitstrip.com/en/2016/05/30/very-very-old-projects/ ‘It’s not like the “fun” we had when we swapped out Angular for React, but this pretty much holds for any/all breaking changes. Turnover in the core-services team leads to swapping out SaltStack for Ansible  but only for the new environments, because we’ll deprecate the old environments, right? We should keep up with django updates,  except for that one high revenue client’s environment, because “high revenue” right? I could go on, but there is  always a reason to not update. What’s worse, the reason might actually be a good one 😟

I'm not quite sure what's more frightening - that I just do it without thinking, or that doing it actually makes sense. /via http://www.commitstrip.com/en/2016/05/10/a-moment-of-nostalgia/

/via http://www.commitstrip.com/en/2014/02/03/trop-de-code-tue-le-code/ Mind you, nowadays you’re lucky if you get to use the same damn framework twice in a row…

You’ve heard of “Micro-architectural attacks” yes? You know, stuff like   Rowhammer ,   ASLR bypass ,   DRAM addressing attacks , and so forth? An excellent   paper by Schwarz et al.  — reviewed by Adrian Colyer   here — describes how one can protect against these attacks coming in via JavaScript. Which basically translates to “preventing any random website from hacking you”   . The one I found particularly fascinating was how JavaScript can be used to identify memory addresses, and how   JavaScript Zero   (the solution described in the paper) defeats it. The thing about JavaScript is, it’s sandboxed nature ensures that virtual addresses are never actually disclosed to the user. That said, 1. JavaScript has   ArrayBuffers  — what is effectively a block of virtual memory that is directly accessible to the user in a fast and efficient way 2. Browsers allocate   ArrayBuffers   in a page-aligned manner (at the start of a new ph...

So yes, the field is new, the tooling is *not* mature, and the skillset is still being figured out. That, however does not excuse us from having to follow good software practices. I mean, we’ve been through this before with Javascript — in the early days, the sheer horror that was *any* JS code-base would blow your mind (•). So yeah, when building out whatever you’re working on, don’t for get the basics, like Unit Testing, Evolutionary Architecture, Clarifying Requirements, Validating Results, and so forth. I could go on, but luckily, Radek has already done a lot of the heavy lifting here —  https://hackernoon.com/doing-machine-learning-efficiently-8ba9d9bc679d  — go read it. (•) Or maybe not. I mean, it’s better now, but still pretty horrible (••) (••) Note that I’m differentiating between the *average* badness of development, and the *uniquely* bad thing that was JS back in the day, when anybody who could insert a <script> tag was not a “JS Developer”

/via CommitStrip

/via CommitStrip

/via Reddit