Anthony Panozzo's Blog

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!"

I like writing, and I often write at night. However, writing at night on a computer monitor increases exposure to bright light and blue light, which delay sleep onset and suppresses melatonin production, respectively. Even tablets have this drawback, which is why I try to avoid reading on them at night.

Alternatives

I looked for an alternative to writing on a standard computer monitor. I considered finding a Kindle-like screen that has e-ink technology. This seemed technically feasible, but difficult to set up and maintain as well as being expensive.

I briefly considered writing by hand, but this has the disadvantages of being slow and difficult to get into electronic form.

I also took a look at some electronic typewriters (yes, really!) I could type on a familiar keyboard layout and then scan the resulting copies and use OCR on them to get the text extracted to a digital format. This seemed cumbersome and error-prone, and lacked many of the simple editing tools that a modern word-processor would use.

What I really wanted was a few line LCD display. I remembered my parents had a small address book that ran off of a few batteries, and figured maybe I would have to make something like that. In a last ditch effort, I posted to Twitter: