So you have a project idea and you want to get approval to work on it? Since this is presumably something that’s not within your current authority/ability to do, you’re going to need to pitch it to someone. Having been on both the pitching and receiving end of these, not to mention just being in the room as an observer, I’ve developed a particular approach for these. Since I’ve found myself providing this advice to folks several times recently, I figured I’d write it down.
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.
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.
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!
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!
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).
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.
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.
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.
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.