This is a guest post by Alan Bailward a long time advocate of Vim and friend.

Introduction

When Curtis first asked me to write about my programming workflow, I thought to myself “why would anyone care about a simple setup like I have?”, and told Curtis as such. Then a few days later I was showing him something or other at the FV.rb and I did something in Vi to a surprised “what was that”. A few more tips passed on, and a few more “how do I do that’s” and I realized it might be interesting, at least a little, to others.

The “elevator pitch” for what I do is “you make it pretty, I’ll make it work.” I work with a couple of small design companies who mock up a site and then hand it over to me, and I turn the static files into fully dynamic pages with working elements, create the admin backend to manage it, deal with making contact forms email out properly, and so on.

Most of my work is Perl, old school, none of this fancy “framework” or “php” stuff for me, nosiree! Actually this isn’t by choice, it’s due to it being legacy code, and the effort to re-write it all just isn’t worth it. Don’t cry for me though, now and then I do get a chance to work on some of the fancy-schmancy new stuff, and the setup is pretty much the same.

Working Setup

My set up is actually one of two setups. Some days I do my work on a MacBook Pro sitting on the couch, and some days it’s on an older desktop computer hooked up to a 21″ LCD downstairs in the office.

The hardware itself is pretty old, an AMD XP3000+ with 4G of RAM, an nVidia video card just capable of some of the 3D effects that modern operating systems provide, and basically all the best that 2002 had to offer. Too bad it’s 2010, but my Windows workstation has been on the receiving end of the last round of upgrades, as that’s my gaming box.

However, since my OS of choice for programming is Linux, the older hardware isn’t that big an issue. The version is 10.04, “Lucid Lynx”, which was installed when it came out. Other than a few extra bits of software installed (more on that in a second) and a tweak here and a poke there, it’s a pretty Plain Jane setup.

The day to day programming situation, or in my case, evening to evening, is sitting with with basically 3 windows open, one is a browser to run tests on the site, one is my actual programming window (sometimes several tabs of terminals, and one is tailing the log-files in the background so that I can see if anything strange is cropping up.

Tools

As you can see from the screenshot above, work is basically done in a couple of terminal windows and a browser. Code in the terminal window, reload the browser until things work. Rinse and repeat.

Of course, if that was it, that’d be the end of the article, and like I said earlier, I figured it would be.

However it seems that the tools involved in those two windows might be at least mildly interesting. Because I’ve been a Linux geek since 1994, most of the things I do are in the terminal, and therefor the tools I use are all terminal based.

While coding, I need tools that let me do three things really well:

• See what is going on all the time
• Quickly switch between different tools and documents
• Make the code sing by being lightning fast inside my editor

My tool list consists of the following:

• Vim – for all my editing needs
• Screen – for keeping programs running and quickly switching terminals without switching windows
• Tail – For watching log-files
• Firefox or Chrome for a browser
• The firebug web developer extension, along with the a few plugins (YSlow being the most prominent one)

So as you can see, not a lot there. I’ll go into a bit more detail on some of the apps and how they’re used.

Vim

Ah Vim, my old friend. I learned Vim from a huge gold book called Unix Unleashed back in my early days with Linux and Unix, sometime in the dark ages, before Kernel 1.0 (that’s 1995 for you kids out there). The reason that I prefer Vi over EMACS? Simple, the Vi chapter was first. Also I like my fingers where they were, and decided that the surgery needed to make that much use of the ctrl key wasn’t worth it compared to hitting ESC a bunch.

Note that I used Vim as well as Vi. Vi is the classic editor, available on pretty much any UNIX system since the 80’s, whereas Vim is the new and shiny version of Vi, with the same heritage, but with all the modern amenities such as syntax highlighting, tabs (in the GUI versions), multiple windows, ability to use the mouse, and so on. While I’m perfectly comfortable using “classic” Vi for most anything, for hardcore coding, Vim is the way I roll.

Vim Essentials

My Vim setup is fairly Plain Jane as well, but I do have a few settings and commands that I use all the time. Settings are stored in your “vimrc” file, which is a file named “.vimrc” and stored in your home directory. If you are working on a Unix based system (Linux, MacOS, etc) you can find this by editing “~/.vimrc”. Here’s a (very) abbreviated version of my .vimrc, with some comments:

" set syntax highlighting to work better with dark backgrounds, it defaults to 'light'
set bg=dark
" highlight found search terms
set hlsearch
" ignore case sensitivity in searches
set ignorecase
" searches for lowercase words match any case, mixed case searches turn on case sensitivity
set smartcase
" indent code properly
set smartindent
" similar setting to ensure tabs work properly
set smarttab
" if available, turn syntax highlighting on
syntax on
" switch quickly from window to window and maximize the window
map <C-J> <C-W>j<C-W>_
map <C-K> <C-W>k<C-W>_

A word of note here; despite having used Vi for 10+ years of coding, my knowledge of it is restricted mostly to the functionality that I use on a daily basis. I’d be remiss to not mention the excellent VimCasts podcast for a deep, yet beginner friendly look at some advanced functionality in Vim, and learning to love your .vimrc file.

Some of these settings should be wrapped with if/then/else’s, but just using these settings will give you the start of a much nicer experience, and you can copy and paste them into your ~/.vimrc file safely. Of course, to have an efficient workflow you need to know some commands.

As I said, I use the text version of Vim, not the GUI version. The GUI version allows you to have proper tabs, use a mouse, and fancy stuff like that, but that means you take your fingers off the keyboard, and if you take the fingers off the keyboard, you slow down, so I try to keep my fingers on the home row as much as possible. Vim’s history is in the console only dark ages of computing, so it’s well suited to this.

Here are a few “special” keystrokes that you might not know, assuming that you are familiar with Vi’s modal editing, and inserting and removing text:

ctrl-w ctrl-s

or

ESC :split

or

ESC :split <some other filename>

The first two commands will simply split the current editing window in two, allowing you to view two parts of the same file simultaneously. The last command will split the window in two and load the filename you specify into the second pane.

ctrl-w ctrl-v

or

ESC :vsplit

or

ESC :vsplit <some other filename>

Same as the above, except the window is split horizontally. Note that you can split a window as many times as you want and in combinations of “split” and “vsplit”.

ctrl-w ctrl-w

This will let you jump from window to window. If you have the mappings I use in my .vimrc you can also use ctrl-j and ctrl-k to jump between windows, while maximizing the current one. If you want finer adjustment of your window sizes, you use ctrl-w + and ctrl-w – to resize the windows.

If you’re not happy with the order of your split windows, you just need to run:

ctrl-w R

(Note the “R” needs to be capitalized). This will reverse the order of the windows.

Vim is a huge program, so this stuff is only scratching the surface, but it is a step up in terms of helping you to code from the defaults.

Screen

Screen is one of the two or three UNIX tools I’d choose to spend the rest of my life on a desert island with. That doesn’t sound too weird does it? Screen is described as a “screen manager with VT100/ANSI terminal emulation”. Not all that descriptive. The description from the man page goes something like this:

Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC terminal and, in addition, several control functions from the ISO 6429 (ECMA 48, ANSI X3.64) ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is scroll-back history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows.

What is means is that you can, with a single login, in a single window, control and switch between multiple windows. If you’re really old school you might have used DESQView back in the day, and this might be familiar. No one here is that old though.

Regardless, the details are unimportant compared to how it actually helps you do your job. The workflow goes something like this for me.

1. Start a terminal window and ssh to the web server
2. On the server, change to the correct working directory, more on this in a moment
3. Run screen
4. In the screen program start editing the source code that I’ll be working on today
5. Create another screen window with the shortcut key “ctrl-a c” (IE: Hit the key combo “ctrl-a” to get screen’s attention, and then ‘c’ to create a new window) and edit another source code file in that window (note that here a “window” is actually another terminal session, displayed in the same “shell” as you are already)
6. Open another screen window with ctrl-a c and start up the mysql command line
7. Switch back to the first window by hitting ctrl-a <space>

Screen has only a few keyboard shortcuts you need to know to get a lot of use out of it

• ctrl-a c – Create a new window
• ctrl-a <space> – switch to the next window
• ctrl-a ctrl-a – toggle between this window and the next
• ctrl-a <ESC> <arrow keys> – scroll back in the terminal scroll-back (your terminal scroll-back won’t work)
• ctrl-a d – Disconnect this screen session from the window, but leave it running

There are lots more, but these are the core. The last one is the most interesting though, what this does is allow you to do is to stop coding, disconnect your session, go to work, to Starbucks, whatever, boot up an ssh session to the same machine, and then start session with “screen -r” and have your session back exactly where it was, with the editor just where you left it, your programs running, etc. Extra bonus: If you forget to disconnect your session when you left home, you can run “screen -rd” to start up and disconnect the running session and reconnect to it. You can even have multiple screen sessions running at once.

How does this help? Well, it means I can have all my editing environment set up the way I like it and never shut it down, while being able to get at your currently used workspace from whatever computer you’re at, as long as you can get to the server as the same user.

Browser and Add-ons

I don’t have anything overly special in the browser, a few plugins that help with any HTML, CSS or JavaScript debugging I may be tasked to do. These will be pretty familiar to anyone who has done much web development work using Firefox:

• Firebug for performance tuning and checking things like post variables and some minimal CSS/Javascript/HTML tweaking
• YSlow for doing performance testing
• (Sometimes) the Web Developer Toolbar for some of it’s nifty CSS/HTML revealing
• Live HTTP Headers is also used periodically

Conclusion

So that’s about it…a very, very long way of saying that I use a web browser and a 20 year old text editor in a terminal window to do all my work 🙂