Recent posts

Framing the problem

“Some people, when confronted with a problem, think ‘I know, I’ll use multithreading’. Nothhw tpe yawrve o oblems.” (Eiríkr Åsheim, 2012)

If multithreading is so problematic, though, how do we take advantage of systems with 8, 16, 32, and even thousands, of separate CPUs? When presented with large Data Science and HPC data sets, how to you use all of that lovely CPU power without getting in your own way? How do you tightly coordinate the use of resources and processing power needed by servers, monitors, and Internet of Things applications - where there can be a lot of waiting for I/O, many distinct but interrelated operations, and non-sharable resources - and you still have to crank through the preprocessing of data before you send it somewhere?

Building secure web applications is really, really hard. One of the biggest attack vectors in modern webapps is passwords. Even if we set aside the dangers of phishing or other more sophisticated attacks, passwords themselves are a source of danger, between simple passwords, guessable passwords, shared passwords among family members or teammates, and reused passwords across accounts.

We all love Javascript [citation needed], but if you use it a lot you’ve probably run up on small areas where the standard library doesn’t quite cut it. Maybe you’re looking through documentation for an Array#random method (we don’t have it), or trying to find how to compare two dates in two different timezones (hope you’re using moment!) or learning there’s no builtin function to reverse a string (hint: make it an array first).

If you find yourself frustrated by all the little idiosyncrasies, it might be good to know that the kind folks that make our language spec are looking out for us. Here’s three upcoming language proposals to keep an eye on if you’re looking for small quality-of-life improvements.

A UX designer's take on installing and using Google Material Design with Sketch.

If you work on a lot of react projects, you’ve probably seen some interesting unit test suites. After all, there’s lots of schools of thought around how to properly test react applications, right? Some folks will sinon.spy() everything and play with the require lookup. Others might connect all their components to redux or graphql, and in so doing ensure that they can only test their components in the context of that state management.