On Learning Vim: False Starts, Pain, and Overcoming the Hump

, , , 2 Comments

I’m not going to try convince you to use Vim.

If you’re reading post and haven’t already closed it, you’re probably already convinced that it’s useful.

The purpose of this post is to help if you want to learn Vim because you see its promise, but just can’t seem to get past the hump of learning it and making it your primary editor. Or, perhaps you don’t know where to start.

In my opinion, and probably many others’, it is worth getting past the Vim hump, so hang in there! I’ll tell you how I went from IDE lover to Vim lover and hopefully provide some useful tips to get you there as well, if you want to.

The Beginning

I got my start developing in Java. So, what was my code editor of choice? An IDE, of course! First Eclipse, then IntelliJ IDEA.

As I moved along in my career, I saw presenters at meetups and conferences who used Vim. I watched in awe as they performed text gymnastics during their presentations. It was like they were playing an instrument, rather than coding.

Occasionally, in a fit of inspiration, I would give Vim a try. But I could never could get into the swing of things. It just seemed too hard to learn and I couldn’t get past how difficult it was to navigate around a project with a large set of files.

Because of this, I never committed. I always ended up going back to my IDE (or some other modeless text editor), even for scripting languages like Javascript. I spent a little time looking for the best of both worlds and found some plugins for my IDE which provided Vim keybindings. But you still had to use IDE features and shortcuts to navigate around. It never felt quite right.

So, I puttered on, half-effectively using Vim on remote Linux servers where I quickly needed to view or edit a file without downloading it.

The moment of inspiration

A few months ago, I had the fortune of working alongside a JavaScript developer who just so happened to be a Vim ninja. I could watch him code in real time, and more importantly: ask questions.

Usually it went something like this:

Vim Ninja: (( tap tap tap )) – ((50 lines show up on screen in the exact spot he wanted))
Me: Wait! How the hell did you do that!? Show me!
Vim Ninja: Oh, that’s a macro, you just type ‘q’ then…

You get the idea.

I didn’t get any detailed training from him, per se, but I was able to find out about some useful plugins and configuration options that got me really excited to use it again.

At that point, I decided that the way I was writing my code was not as effective as it could be, and I needed to fix that. Since I was writing lots of Javascript code for a Node.js application, it was a good fit. My usual IDE features of navigating around types didn’t really matter that much in a dynamic language.

So, I spent a handful of hours learning how to configure Vim and installed those plugins that the Vim Ninja recommended. After I finished, I told myself I was going to force myself to use Vim and only Vim for at least two weeks.

The Commitment

Then, shortly after I started, this happened:

I love this slide from SparkBox, because it is so true with lots of developer tools, but especially with Vim (and Git – perhaps the topic of another post).

If you’re comfortable where you’re at coding, when you decide to try a new tool like Vim, there is an immediate, sharp hurt you will feel. The hurt is usually accompanied by questioning the usefulness of the tool and the strong desire to give up.

You have to be determined to get through that hump, but when you do, you reach places you never thought possible.

How to learn to stop worrying and love the Vim

To appreciate Vim and take full advantage of it, you have to want to learn it, and need discipline. Force yourself to use it as your primary text editor for at least a few days or a week. Longer if you can. If you don’t, you will simply hit the “Ouch!” stage, get frustrated and never go back.

Where to begin?

For people in the same boat I was, or people who are brand spankin’ new to Vim, here are a few suggestions to get started on your Vim journey.

Install the right version

As of this writing, the latest version is 7.4 and that’s the one you should install to get all the latest good stuff.

On OS X

On OS X, Vim is installed by default, but chances are it’s an older version and you’ll want to get a newer one, and update it frequently.

To do this, I would recommend using Homebrew and installing Vim using that: brew install macvim --override-system-vim

You’ll also want to make sure that your fresh new Homebrew install of Vim is the default version you use when you type vim or macvim. The --override-system-vim flag should do most of this.

If you type which vim you should see /usr/local/bin/vim. If you hit issues, the default version of vim may be first in your $PATH and may need to be adjusted. This StackOverflow post is really helpful to get that configured correctly.

On Windows

For Windows, the Vim installer will give you options to install a gui and console version of Vim to use.

Learn the basics

This post isn’t about how to do this, but there are tons of resources out there:

Go whole hog

Don’t learn a bit of Vim, dip your toe in, then shift back to Sublime Text (without vintage mode on).

Make Vim your default editor, and open up all your text files in it. Resist any urge to open up anything else to type into, unless there is no other option! Do this for at least two or three weeks.

This is a bit like trying to get into an exercise regimen. It’s painful at first, but then gets easier and easier. Finally, you get to a point where you feel great about it and it starts to become more effortless.

Find a time when you’re not under tight deadlines

Under the gun to get features or fixes in at the end of a project? Not the time to be learning a new editor. Learning Vim will cause you to frequently pause, remember a key combination, and interrupt your flow temporarily.

Find a stretch of time at the beginning of a project, or second to that, in the middle of a project, where you have a bit of leeway to let your brain and your finger muscles get used to the shift in how your new editor works.

If you’re not under a lot of pressure, you’ll power through the “Ouch!” stage in a much easier fashion.

Focus on how to properly use Visual Mode

Learning how to really use visual mode effectively was my “a-ha” moment. This is why using a modal editor is great.

Learn the basics of shift+V, shift+v and about yanks and puts. Once you get the hang of these basics, you will be flying and the (text) world is your oyster.

Learn about the basics of a .vimrc file

A .vimrc file in your home directory is how you will configure Vim. And you’ll probably want to set some custom configurations right off the bat.

A great start is showing line numbers. (Why doesn’t Vim show them by default!?)

Just create a file called .vimrc in your home directory which contains this:

And start vim up. Viola, you’ll have line numbers all the time.

Then, go from there. There are tons of great resources out there on how to configure Vim. I would recommend finding some examples of .vimrc files and learning about the configurations you see in them. Everyone and their brother are starting to post their .vimrc and other dotfiles on Github.

You can find my .vimrc, too, it’s right here.

My favorite resource is to look at ThoughtBot’s .vimrc file. They have a good default set of options and the comments do a pretty good job of explaining what certain things are.

Install Some Good Plugins

There are some Vim purists who think you should learn Vim without using plugins. I disagree. It is useful to know “pure” Vim in case you’re out on servers and don’t have any plugins. But doing any significant development in Vim without a few decent plugins is like using a rotary phone – it’ll get the job done, and it’s kinda hipster-retro-cool, but it ain’t fun.

First off, go get Vundle. Vundle is a Vim plugin manager that will make installing new Plugins and updating them a breeze.

Once you get it setup, you can just add lines like this to your .vimrc to add new plugins:

In this config, the text you put inside the quotes is a git repo for a Vim plugin. Then you can run :PluginInstall to install. You’re done.

A list of plugins that will come in handy regardless of your language

CtrlP

This allows you to type ctrl+p and a filename. It’ll do some fuzzy searching on your filesystem to find files that match. You can then navigate up and down the search results list and open a file in your buffer.

This is really similar to Eclipse’s ctrl+shift+r or IntelliJ’s ctrl+shift+n functionality.

NerdTree

This gives you a sidebar with a tree version of your filesystem (think the tree view in Sublime Text).

It’s awesome to be able to navigate up and down your file structure and open folders freely with just the keyboard. This is really great when you can’t even start to remember the name of a file.

I also find it really useful to use Vim’s / search functionality find a folder name in the tree to quickly navigate to it.

I would recommend mapping the toggle on/off for nerd tree to a key binding like map <C-n> :NERDTreeToggle<CR>. This maps ctrl+n to turn on the tree.

DelimitMate

Auto completion of parens, brackets, etc. Ya need it.

NerdTree Git Plugin

If you use git, this one is great to see visual indicators of what git status your files are in right in a file tree.

GitGutter

Again, for you git users, this one is great to visually see added/deleted/changed lines in the left hand side of your buffer.

Javascript coders, you’ll be in plugin heaven

Javascript has an amazing community of developers making great plugins for Vim. You’ll have a blast trying them all out.

I’ll leave the configuration and plugin recommendations to this excellent post to help you get setup for Javascript in Vim: Equipping Vim for Javascript

Java coders, things are lacking…

Even thought I’ve been coding a lot recently in Javascript, I still code in Java a decent amount. I wish I didn’t have to say this, but I still find myself going back to IntelliJ IDEA when I need to work in it.

Simply put: I could not find anything that could really compare with the tight integration and IDE provides for a static language like Java.

There is real power of being able to navigate to static types and methods with a simple keyboard command or ctrl+mouse click. It’s also crucial for me to be able to do type-safe refactorings. Both of these things are built right into these IDE’s and are bound to keyboard shortcuts right out of the gate.

That’s not to say there aren’t options for Vim: I tried out Eclim which requires a headless version of Eclipse, but it was wonky to setup, and didn’t run very smoothly. It just didn’t feel worth it.

So, if you have to code in Java and only Java, you might have a tougher time really committing to Vim using the suggestions in this post.

However: You can install Vrapper for Eclipse or IdeaVim for IDEA which provide nice Vim-like keybindings for those IDE’s.

If you learn a combination IDE shortcuts for navigating around files and combine those with Vim’s keybindings along with Visual Mode, you’re more than halfway there. That’s what I do, and I find it really effective.

If you’re new to Vim and this is your only option, just really force yourself to not turn the plugin off if you get frustrated! :)

Some other thoughts

If I had unlimited time, I would really love to create an open source project which packages up these essential Vim plugins and installs them with some default configurations. I spent a pretty good amount of time getting configurations together so Vim felt usable enough for me. It would help others get over the hump a lot quicker if there were pre-configured “packages” that could be installed. Maybe something like this already exists and I don’t know about it?

Finally, while writing this post, I found this really great post from Antonin Januska which shares some very similar opinions of mine and is a really good read.

Update 2/26/2015: I Just came across a fantastic, step by step tutorial to setting up vim with plugins by jez on github. He uses a great approach of using git commits to walk through the process.

Getting started with Golang on OS X

, , , 0 Comments

I’ve heard a lot of buzz recently about the (relatively) new language Go (aka Golang) created by Google. Notably, that the fantastic Docker was written in it.

I decided to try learning it recently, so thought I’d share my experience getting setup with a development environment on OS X. I’ve been doing a lot of Node.js development recently, and I come from a Java background, so it was a bit of a shift in what I’m used to setting up a development environment.

My intention with this post is not to teach Go fundamentals (see later on in the post for some resources), but rather to help you get your environment setup so you can start writing and running Go code quickly on your Mac.

Finally, at the end, if you’re still reading, I’ll share some of my thoughts about how my experience went and about the language itself.

Getting started using Homebrew

First off, I use Homebrew to install all my developer tools, so I pursued that route to get myself started as opposed to installing from source. I’ll document those steps below and note where they’re Homebrew specific, however, you can also install from the source

First, install Mercurial (using Homebrew)

Go needs this to install lots of common packages.

brew install hg

Second, install Go itself (using homebrew)

brew install go --cross-compile-common

You’ll get some information about exporting some directories to your $PATH variable. More on that below.

The cross-compile-common option will come in handy later if and when you want to try creating executables for OS’es other than OS X. This option will increase your install size, though. So, if you don’t plan on trying cross compilation, don’t worry about adding that flag.

Third, set the right environment variables

Go has a much different directory setup than I’m used to with something like Node.js, where you can simply put a project wherever you want on your filesystem and run a command.

Go expects you define where your main workspace is, and it will then install packages and compile binaries relative to that path. It does this by using an environment variable called $GOPATH.

Additionally, if you don’t install in the “standard” Go install location, you’ll need to tell Go where to find binaries. You can do this by setting the $GOROOT variable. If you installed with Homebrew, see the output it gives you during the install, but the install location is most likely something like this:

export GOROOT=/usr/local/opt/go/libexec

Finally, you’ll want to make sure anything you compile you can execute easily on your path. When you compile, Go will by default put your binary in the root of your Go workspace in the bin/ directory. You can use the $GOPATH variable to reference it.

Also, because the Homebrew output suggested it, I added the $GOROOT/bin location to my $PATH variable for good measure:

export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

(Note that that last part may not be necessary given that Homebrew does a lot of this for you. I was a bit confused by the message Homebrew output during the install. If anybody can clarify, please leave a comment and I will update this post.)

Fourth, try installing the Go Tour as a test

It should be easy:

go get code.google.com/p/go-tour/gotour

This retrieves the source code into your $GOPATH/src directory under the right namespace directory.

Then, once that’s done:
go install code.google.com/p/go-tour/gotour

This will actually compile the code for you in the $GOPATH/bin directory.

Hopefully, at that point, you’ve got no errors. If you don’t, you should be able to simply run the gotour command on the command prompt and it will spin up a webserver which runs the official Go tour on your local developer machine.

Fifth, go forth and learn!

Finally, grab a coffee, and try out some Go code!

I wouldn’t actually recommend learning Go from the “official tour” (see my thoughts at the end of this post). However, it is a good test to make sure your install is running well, which is why I note it above.

In retrospect, I wish I had tried some of the tutorials found on Dave Cheney’s “Resources for new Go Programmers”, at a glance they appear to be much better. When I have more time I will try one of them out.

Also: Here’s a quick and easy command line trick to help speed up your learn / code / test process: Use logical operators to make sure you compile then run your program in a one liner:

go install code.google.com/p/go-tour/gotour && gotour

This will compile and execute your program assuming that the compilation is successful. This is just using the Go tour as an example. Rinse and repeat as needed for your own package and executable while you learn.

Sixth (optional): Try cross-compiling

One of the things I wanted to try out while I was learning was cross-compiling. I wanted to see how easy it was to code on my Mac and then build an executable for some of the Linux (RHEL) servers we have at my organization.

If you used the --cross-compile-common flag in the Homebrew install above, you should have many of the common OS and Architecture combinations that you can compile to.

You can cross compile by running a command like this:

GOOS=linux GOARCH=386 go install code.google.com/p/go-tour/gotour

This will compile the Go tour executable for Linux on a 386 architecture. It will put the binary in $GOPATH/bin/$GOOS_$GOOARCH. Whereas your normal compile without flags simply goes into $GOPATH/bin

You can replace $GOOS and $GOARCH with a valid combination* from the list here (search for “$GOOS and $GOARCH”). And, of course, substitute your own package name for the Go tour :)

(The “valid combinations” may not work unless it is one of the “common” ones that the Homebrew recipe installs for you. You can see which ones are installed in the recipe itself. You can also run the Homebrew install with --cross-compile-all and it will install all options for you, but it will take up a lot of space. This Coderwall article was very helpful in figuring this all out)

Parting thoughts

Finally, if you’re interested, here’s my thoughts on Go itself and my experience learning it.

The good:

  • Go has built in package management system from the get Go (ha, get it!?)
  • You can import packages directly from a Git repository (awesome!)
  • It’s pretty easy to cross compile, which is nice to create simple executables for different environments
  • Concurrency is easy (see “the bad”)

The bad

The official language tour is not very good.

Given that this is the first place people will likely start to learn the language, I thought that this tour did not explain concepts very well, leaving them to short code examples that took too long for me to grasp, given how short they were. Additionally, leaving math exercises to the user is not engaging or effective for me, and I’m assuming the same goes for many developers interested in using Go.

As I mentioned above, try seeing if Dave Cheney’s “Resources for new Go Programmers” has something better for you.

Making concurrent function calls is almost too easy

I was trying to make some HTTP GET requests with goroutines and very quickly learned that I would overwhelm the machine running it and it would fail with a “too many open files” error. Trying to throttle those concurrent requests to a manageable amount was not nearly as easy as creating all of them. The pattern I came across using semaphores seemed a bit convoluted for a language that’s supposed to make concurrency “easy.”

Still need native drivers to connect to Oracle

This is a biggie in the large organization where I work. We use Oracle heavily, and it would be great to have executables that were able to connect to Oracle without native Oracle drivers installed separately. Alas, this is nothing new, however, since in the Node.js and Ruby world, this is the standard as well. It’s not the end of the world, but using Oracle in Java is still a heck of a lot easier.