William Blankenship
Filter: 20192018201620152014
Stop Saying Technical Debt!

Problems with Technical Debt

Debt is a Four Letter Word

Technical debt is a negative word. It immediately frames the work as shitty but necessary.

Nobody likes technical debt. Very few people appreciate the work necessary to address technical debt. Most people don’t want to work on addressing technical debt, because the people around them don’t appreciate that work!

Debt is the Wrong Word

The word “debt” carries with it a ton of cruft that has no business being in the conversation when talking about tooling, architecture, etc.

Let’s look at the definition of debt:

2 : something owed : OBLIGATION
3 : a state of being under obligation to pay or repay someone or something in return for something received : a state of owing
4 law, business : the common-law action for the recovery of money held to be due

The first definition implies that you’ve done something wrong, and you must account for your transgressions. But who have you transgressed? The co


What Open Source Means to Me

I've noticed a significant shift in my views on open source. I was blind to the shift while it was happening, but in retrospect it is fairly clear. The perfect storm of having read bunny's The Hardware Hacker and seeing a twitter thread got me thinking that it was time to write my thoughts down. I'm sure my views on open source aren't done changing, but maybe future me will find this snapshot entertaining.

How it Started

I came from modest means. As a kid, when I was first introduced to open source, I was interested solely in the price of the software: free. Open source (and freemium software) gave me access to the means of production, which meant I could afford to do software development. Having these tools gave me extreme economic mobility. I attribute a vast majority of my where I am today to having free access to the tools necessary to enter the field of software development;


Libfuse Template

When I was getting started with libfuse, it was extremely intimidating. I still don't have a full grasp on the API, but I've put together a template to help future adventurers get through the early learning process.

The Libfuse Template

The repository has been structure so that each fuse operation lives in it's own
file. For getting started, we have stubbed out each operation and have included
a simple logger that let's you know when these stubs are being called. This
should give you a good understanding of what order you need to implement
operations in, simply start playing around with the filesystem and implement
whatever stubs you see being activated!

Libfuse Documentation

This was the hardest part for me when I was getting started. There is a lot of misinformation about fuse floating around, and its hard to find definitive information for the API version you are developing against.

There is a handy [doxygen


Musings on Ready Player One

Spoiler alert!

This post dives into the movie assuming you have seen it. If you are planning
on seeing it and don't want the plot ruined STOP READING NOW!

The movie itself is just a mainline injection of nostalgia. The storyline is rather weak. It is a take on society with late stage VR. The year is 2040ish and it appears everyone has standardized on playing a single VR based MMORPG. The creator (and apparently sole designer) of the game has died and left the "keys to the empire" hidden away in the game as a series of easter eggs. Whoever finds all the easter eggs inherits the game, and apparently the rights to make decisions about how the game is structured.

The antagonist of the story is a large corporation that sells mods in-game. They want to acquire the rights to the video game in order to maximize its profitability by making significant changes. Essentially they want to turn it into this pay-to-play, advertising ridden, nightmare of an experience.


I'm already


Debugging GAS ASM with GDB

This tutorial will walk you through debugging amd64 AT&T ASM using the GNU as assembler and gdb. Why would you ever want to do this? More than likely you were sitting around bored drinking cocktails and decided to give assembly a try.

Following along

If you are running an amd64 distribution of Linux, you just need gdb, ld, and as installed. Otherwise, you need to download VirtualBox and install amd64 Linux to follow along. The distribution shouldn't matter.

Example Application

We are going to use an example application that is fairly common. It comes from the book Programming from the Ground Up by Jonathan


left-pad and Proper Engineering Principles

A recent event in the Node.js ecosystem received widespread attention. There has been a surprising amount of logical fallacies, conflation of problems, and general misinformation about what transpired. This post is me throwing my hat in the ring as a voice in the conversation.

In this article, we will separate out each individual conversation that has been taking place around the events of #npmgate, we will put forward the reason it caused as much trouble as it did, and how you could have protected yourself from what transpired. This will be entirely from an engineering perspective. The "people", "legal", and "philisophical" questions will be saved for another time.

Separation of Concerns

Much of the misunderstanding and borderline panic has been caused by the conflation of several problems. Before we dive into the opinionated section of this piece, I'm going to take a moment to separate out the individual issues tha


Debugging the Docker Daemon

This week I needed to dive deeper into some performance issues I have been experiencing with dante. The first section will detail the struggle that lead me to this point. If you want the quick-n-dirty DIY instructions for profiling Docker, feel free to skip ahead.


At NodeSource, I'm building hundreds (literally hundreds) of Docker Images. This has lead to the pressing need of parallelizing these. Currently, I'm provisioning a 32-core box and triggering 100 simultaneous builds to burn through my 600+ images. I've noticed though that, at any one time, there is never more than ~25 layers actively running. Somewhere, there is a bottleneck. Running ps shows me that Dante is indeed spawning 100 docker build commands, so it would seem the docker daemon isn't keeping pace.

Diving into the Daemon

So golang has a built-in profiler called [pprof


Dockerizing your Node.js Infrastructure

Cross post from https://nodesource.com/blog/dockerizing-your-nodejs-infrastructure

This post is a deep dive into the concepts I introduced in my webinar: Need to Node Ep. 2: Dockerizing your Node.js Infrastructure from NodeSource on Vimeo.


In our last walk through, we tackled taking a Node.js application and getting it inside of a Docker container. This time around, we are going to look at Dockerizing our entire infrastructure.

We are going to start from the project we completed in the last blog post. This project should contain the following files:

$ ls
app.js Dockerfile package.json

These examples will assume you are using terminal on a Unix style machine. If this assumption does not hold, you will nee


Automatically Populating a known_hosts File

You are probably here because you are trying to automate a service over ssh and you need to get past this prompt:

The authenticity of host '[REDACTED]' can't be established.
ECDSA key fingerprint is [REDACTED].
Are you sure you want to continue connecting (yes/no)?


Use the following bash script.

for address in $ADDRESSES; do
  ssh-keygen -F $address 2>/dev/null 1>/dev/null
  if [ $? -eq 0 ]; then
    echo “$address is already known”
  ssh-keyscan -t rsa -T 10 $address >> ~/.ssh/known_hosts

Where $ADDRESSES is a list of hostnames or IP addresses.

The long version

So you are automating some service that needs to communicate over ssh. Why not just ignore this warning and press on with your day?

Well, for starters, you have probably found that it can be rather difficult to bypass this warning depending on the tool you are using. More importantly, this prompt is giving you the opportunity to recognize a remote server as “trusted” f


Dockerizing your Node.js Applications

Cross post from https://nodesource.com/blog/dockerizing-your-nodejs-infrastructure

This post is a deep dive into the concepts I introduced in my webinar: Need to Node Ep. 2: Dockerizing your Node.js Infrastructure from NodeSource on Vimeo.


So you have Node apps, and you want to use them with Docker. In this tutorial, we will show you how to take your Node.js application and bake it into a Docker image. This is part one of a two part tutorial on Dockerizing your Node.js Infrastructure. If you are interested in a big picture talk on what Docker is, and why Node.js and Docker are a powerhouse couple, checkout my latest webinar recording from #NeedToNode.

Without further ado, let’s get started!

Starting from a Node.js Project

I’ve put together a sample project for this tutorial. If


Docker and Node.js

Cross post from https://nodesource.com/blog/dockerizing-nodejs

The barriers between developers and operations are slowly eroding, creating a healthy environment of rapid iteration, continuous integration, and horizontal scaling. Increasingly, the tools of choice when breaking down that barrier are powered by open source software that promise openness, power and freedom to see their technology and business dreams realized. This is what brought many of us to Node.js and Docker in the first place.

But as the pace of innovation has increased, the mission of creating a “full-stack” development shop has broadened to a need for a full-stack dev/DevOps/deployment organization. Docker will increasingly become a common part of that stack.

So, what do we get out of Dockerizing Node.js?

Documenting dependencies beyond Node/npm

Part of the great appeal of Node.js is that it has a large, rich and [massive](https://medium.com/@nodesource/npm-i


Docker: Owning the Stack


This is the third post of a 3-part series on docker. This series was transformed from a talk I gave at an STL DevOps meetup.

Here we are going to dive into the implications of developers taking ownership of their stacks through docker, and the work I have been doing at NodeSource to help developers take ownership of their Node.js stacks. If you haven’t already, take a few minutes to skim through the previous article in this series which lays the groundwork for this topic.


In my previous article, we introduced the concept of developers owning the stack. Now let’s follow that rabbit hole down into the work I’ve been doing at NodeSource. When developers take ownership of their stack, they are no longer simply running Node 0.10.34, they are dep


How Docker Changes Things


This is the second post of a 3-part series on docker. This series was transformed from a talk I gave at an STL DevOps meetup.

We are going to talk about “owning the stack” via docker, and what that means to us as developers. If this post is successful, you will understand the full meaning and depth of that statement by the time you are done reading this. For a quick primer on what docker is, and why it is fantastic, check out the precursor to this blog post here.


Often, when we hear people talk about docker [being](http://www.zdnet.com/article/what-is-docker-and-why-is-it-so-darn-p


What Docker Is


This is the first post of a 3-part series on docker. This series was transformed from a talk I gave at an STL DevOps meetup.

Let’s take a moment, really quick, to bring everyone up to speed on what docker is. If you already understand what docker is — and why it is so great — feel free to skip ahead to the next article.


Docker started as an api on top of Linux Containers. It has grown to be a tool set and ecosystem for packaging and distributing applications. It’s api is built to be pluggable allowing the underlying technologies to be exchanged without any apparent changes to the end user.

Docker uses the primitives collectively known as “Linux Containers” including Linux Control Groups, Namespaces, and [IPtables](h


You are More Than a Resume

I have been getting asked for resume advice quite a bit recently, so I figured I would sum up my thoughts here. First and foremost, I’m not going to claim that I know anything at all about hiring processes. I've only ever looked through a stack of resumes once, for a student organization, and everybody passed screening. I have no magical insight into what companies want, or why they prefer one thing over the other. In fact, I have no idea why you want my advice in the first place. With that being said, I have been told that my advice is a pretty good at motivating people to put their best into their resumes. So, with that in mind, you should not expect me to tell you how to write your resume in this blog post. What I’m going to do is give you a little pep-talk and perspective that will push you in the right direction so you can decide how you want to write your resume.

The question I get most frequently is:

"I don’t have any experience, so what should I put on my resume?"

I can g


NS Docker Images

Cross post from https://nodesource.com/blog/nodesource-docker-images

Note, the images described in this blog post have been depreciated. Checkout https://github.com/nodesource/docker-node for the awesome new images which offer version pinning.

Containerize All The Things!

NodeSource is rolling out a line of Docker images based on the binary Ubuntu and Debian distributions we maintain in collaboration with Chris Lea.

Although a relatively new product, Docker has quickly become an essential part of many companies' deployment environments. The new NodeSource images aim to simplify and standardize containierized Node.js application deployments.

The new images are hosted on Docker Hub at: https://registry.hub.docker.com/u/nodesource/node

So What Is Docker?

For those new to the D