Anthony Panozzo's Blog

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:

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:

I happened upon an open source tool for refactoring JavaScript that has been useful. The tool is named Grasp, and it enables searching and replacing on the AST (abstract syntax tree) of your JavaScript code. This is powerful because instead of finding or replacing bits of text throughout your codebase, you can replace only identifiers, for instance. Or you could find matching blocks of code that are spread across lines, since we look at the entire syntax tree, not the text representation of it.

There is a fantastic blog post on the Grasp website. It provides several examples of common refactorings (rename variable, changing a function to accept an arguments hash instead of adding another parameter, etc.) It really does a great job of showing why standard tools like sed and grep fall short during refactoring. The examples are clear and provide good starting points for your own refactorings.