Universal Scalability for Orgs

Last week, Coda Hale published a very thought-provoking essay, “Work is Work” where he explores what is necessary to increase (not to mention just maintain) productivity as an organization increases in size. A man after my own heart, he applies queuing theory to the process of getting work done in increasingly larger organizations. I was inspired to look at the same problem through a slightly different theoretic lens: the Universal Scalability Law (USL), as put forth by Neil Gunther.

An Introduction to JSON-LD

I’ve been spending some time recently thinking about ways to maintain loose coupling between lots of different teams. I suspect this involves thinking about shared protocols between the teams (i.e. having well-defined interactions) more than worrying about internal “implementations” like what flavor of Agile you use or what programming language you write in. The World Wide Web is a pretty obvious example of a system that did this well, and its architectural style was described in Roy Fielding’s thesis.

Complex Systems Talk at Philly DevOpsDays

I gave a talk at Philly DevOpsDays last month: “We Have a Complex Systems Problem…and We Need to Talk About It.” Check out the video below!

On People Leaving a Department

I recently fielded a question in a department ask-me-anything (AMA) session noting that a few folks have left our department recently, and asking what I thought about it. I thought I would share a lightly-edited version of what I wrote: In general, I assume that when someone joins my department, it will be for a finite period of time; it would be really unusual to hire someone right out of college and have them work in our department until they retire!

Running Concourse Locally on Windows

Update 3: Ok, got this all documented, cleaned up, and pushed to Github: vagrant-concourse-local. Update 2: Bosh deployment also didn’t work on Windows. I did finally manage to get builds working. Rough recipe was: use Vagrant (from the Windows shell) to spin up an Ubuntu box. Run vault, postgres, and concourse via docker-compose (I wanted to use Vault because that’s how I am used to managing secrets, although unsealing is a pain).

VerySillyMUD: Continuous Integration

This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we got an autotools-driven build set up, which gets us going along the path towards being able to use a continuous integration tool like Travis CI. In this episode, we’ll see if we can get it the rest of the way there. I’ll be referencing the getting started guide, the custom build instructions, and the C project instructions.

VerySillyMUD: Adding Autotools

This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we got all the remaining compiler warnings fixed. While I was merging the pull request for it, I noticed GitHub was prompting me to get continuous integration set up. I had run across Travis CI, and knew that it was free to use for open source projects.

VerySillyMUD: Fixing the Rest of the Compiler Warnings

This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we used unit tests to document a function’s behavior so we could refactor it to fix a security warning. Now we are able to pick up where we left off three episodes ago: fixing compiler warnings to find any gotchas. To get started, let’s re-enable the -Werror compiler flag.

VerySillyMUD: Understanding a Function with Tests

This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we got a basic framework for unit tests in place. Just to refresh our context (and which layer of yak we are shaving at the moment): we need unit tests so we can (a) capture the current behavior of a particular function, dsearch(), so that we can (b) refactor it safely, so that we can (c) fix a compiler warning about it, so that we can (d) finish fixing all the compiler warnings in case there are other latent bugs being hidden.

VerySillyMUD: Unit Tests

This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we encountered a function we needed to refactor: Only trouble is: we don’t have unit tests in place, and I don’t really have any idea what this function is supposed to be doing. Looks like we have to get some tests! Now, I am used to the wonderful JUnit family of unit testing frameworks, but it’s unclear which C unit testing framework to use.