Anthony Panozzo's Blog

While at Haven, I thought we had a pretty good system for tracking the current status of a given pull request. In this post I'll document some of the labels that we used, what they meant, and how they helped us collaborate.

Labels For A Leaner Workflow

One of the challenges of working with pull requests is that they can sometimes take a long time to get merged in. Some of this can be mitigated by keeping pull requests small, some by reviewing pull requests as soon as possible. However, a lot of time passes while waiting for someone to review or respond to comments, or even know that there is an issue or question that needs to be addressed.

Why do we care about reducing cycle time of pull requests? It is work that is almost finished. If we can finish it, we reduce the overall work inventory in the system. It helps us get business value more quickly and learn what doesn't work.

Labels can clarify where a pull request stands. I see the clear next step and whether I am responsible. If something needs review, I review it. If one of my pull requests can be merged or needs changes, I do these.

The Labels

I'll cover the basic labels that I thought were most helpful, and how we thought of them. We didn't start with all of these; we just built them up over time and revised as necessary.

"work in progress"

"This isn't ready for review, but I want to make it public." It might be just to get code off of my machine in case something bad happens to my laptop, or it might be work that I want help or have questions on. By pushing code up early, we can communicate with actions rather than words. Instead of "I'm working on X", you can let commits do the talking.

My wife and I lived in San Francisco for a year starting in the summer of 2013 and the summer of 2014. One of the very best things about living there was the fantastic Ultimate scene. Some of our friends had a weekly track workout on Mondays that we participated in, and I felt that it helped me be a better competitor on the field by being in better shape. Some of them were participating in a fitness challenge, and it sounded like fun.

The next year, starting around October, they announced that they were expanding the fitness challenge to include anyone that wanted to join. To join, you put in $10 and most of the proceeds went to the Bay Area Disc Association. About a hundred people signed up, and I was one of them.

The Challenge

The challenge was fairly easy to grasp: every day and every week there are certain fitness requirements to be done, with one off day for the daily requirements. If you miss two daily exercises (not done by midnight) or miss the weekly requirement by midnight on Sunday, you are out. All participants get a weekly email on Monday discussing the week's requirements and explaining any new exercises if there are any. Deciding whether you were in or out was just based on the honor code (Spirit of the Game, in Ultimate terms.) The exercises were all body weight, so no special equipment was really needed.

As they say on the website, one week's challenge might be:

Below is an example of a hypothetical workout routine for a given week with daily exercise requirements of ten push ups and ten squats and a weekly exercise requirement of one hour of non-Ultimate cardio.

• Monday: ten push ups, ten squats
• Tuesday: ten push ups, ten squats
• Wednesday: ten push ups, ten squats
• Thursday: ten push ups, ten squats, one hour non-Ultimate cardio
• Friday: ten push ups, ten squats
• Saturday: OFF DAY
• Sunday: ten push ups, ten squats

Ramping Up

The challenge started out very simple, and could be done in about two minutes per day. There was no weekly requirement to start. Really the challenge at this point was just remembering to do the exercises. A few people were knocked out because they forgot to do the exercises.

How do you deal with work that is challenging, time-consuming, or risky?

If something is hard, the typical approach to reducing the pain is to do the activity at hand less often. The logic is, this thing should be done as little as possible so it consumes fewer resources or exposes us to less risk. I see this option being used often in software development.

However, I think that a generally more effective – but counter-intuitive – option is to do difficult things more often.

DevOps

One of my favorite practical examples of this is modern development and deployment of software products. In some organizations, deploys happen monthly, quarterly, or annually. The pain of manually testing for regressions and getting all of the pieces aligned and documentation updated just makes it too difficult to do often. We wouldn't want to put out a product that is less than perfect, so let's make sure that it works correctly before releasing. And who can get it to build and deploy correctly? We need three engineers to take three hours to deploy the changes and make sure that everything works as expected.

The costs, however, are high. Features are shipped in batches instead of when they are finished. Integration is done at the end, and manually tested. Customers wait months for bug fixes. When there is a major bug in the final release, instead of being constrained to a small set of changes to fix it, the technical team might need to stay up late looking through weeks worth of changes.

The problem might be solved another way. Instead of considering how long we can defer the pain, what if we try to take the pain early and as often as possible? What if we deploy all code that has been peer reviewed and accepted at the end of every week? What if we did the same every day? What if we did it after every merged pull request? What would need to change to make deploying multiple times per day possible?

In this post I'll cover the plugins and configuration I have found to be the best for editing and navigating Javascript projects with Vim.

Background

I have had around a year's worth of experience at this point. I tried out various plugins, uninstalled some, tweaked others, and found a decent setup. There are probably some plugins out there that I am missing, so please let me know if I should investigate one. Primary stack has been Mongo, Angular, Express, Mongo. I'll update if I find more good Vim JavaScript setup.

The Best Vim JavaScript Plugins

I use the following plugins on my current project. I listed them roughly based on importance, how much I use them, and how surprising they were.

vim-javascript

The biggest advantage of this plugin is how much better the default indentation is. I'm sure there are others, but indentation was unbearable before using it, and pretty good afterward.

vim-node

Although it has other utilities, I primarily use vim-node for gf on a relative require to go to that file. Following Vim conventions, gF opens that file in a split. This really aids in navigation, especially when paired with Ctags (discussed below.) It might not sound all that helpful, but when you have:

var UrlFinder = require('../../../server/util/other/urlFinder');

I can just type gF to view the file in a new split window to figure out what functions I might want to call on it. Much faster than other methods of getting there. Generally Vim would choke on the relative file path since I typically have my current working directory as the project root.

jsctags setup

I had not used Ctags much before, but have found them very useful on the project that I am working on. Ctags works by creating an index of tags, which are things that you want to be able to jump to. Vim supports Ctags-style tags.

The value is being able to jump to the definition of a function when your cursor is over it. So being able to say Ctrl+] and then jumping right to where the function is. I can easily get back with Ctrl+T (or perhaps Ctrl+O since that will take me out to the edit stack.)

This gets us closer to many IDEs, and avoids running the function name through grep/ack/ag and/or opening the file manually.

The core issue is that the current Exuberant Ctags JavaScript support is not very good. Often it would not be able to find a function declaration. There is an old Mozilla project, but it had one basic, but large issue with installation that cannot be solved by forking/patching (to my knowledge.) So I made a custom ZSH install function:

function install_jsctags {
  npm install jsctags
  # https://github.com/mozilla/doctorjs/issues/52
  gsed -i '51i tags: [],' ./node_modules/jsctags/jsctags/ctags/index.js
}

This is helpful because I sometimes switch node environments with nvm, or do an npm prune which removes it since it is not in the package.json file.

Node.js seems interesting as a backend technology because of its highly scalable nature. Also, it seems to be gaining steam in terms of developer mindshare. It is somewhat interesting to write in the same language on the front end as the backend, but then you are writing in JavaScript everywhere.

I wanted to play around with Node a bit, so I got the latest version of Node and installed by doing the standard download, unpack, ./configure, make, sudo make install. (Running on Ubuntu for kicks today.)

I thought about what things I might want to make and generally Googled around a bit. I got some ideas and a general lay of the land.

Then I said, "well there must be a Hello World app that I can play around with." The node.js site had an example, so I copied it into a new Vim buffer. I ran it from the command line with node hello.js. There was a useful console message that was printed (as expected), and then I fired up localhost:1337 and got the expected "Hello World" message. I thought, "pretty easy!"