Side projects are fickly things and when you are working on something that you can’t always schedule consistent time for, I've found that having an environment that allows you to resume work as quickly as possible is really important. While migrating to AWS and EC2 last year, I came to the realization that the cost of having to synchronize between server and local development environments would quickly become a nuisance, dissuading me from putting in the little bits of time between work and class to finish my side projects.

Instead, by creating a single setup on the server, I could strike two birds with one stone by reducing the overhead of spinning up as well as tightening up the development iteration cycle (also very important). The immediate question of connectivity was a potential deal-breaker, but the combination of ever-pervasive wifi and the ability to fall back to tethering to my Galaxy Nexus meant that it has been a non-issue in my experience this past year. I’ll explain a bit of how my setup works below.

My EC2 servers run Ubuntu and a large part of working effectively in Linux is getting comfortable with the command line. As tmux and vim are two of the largest parts of my setup, I’ll elaborate a bit more of how I use them in this particular post. Both tools have great documentation (and user support) and both share the same positive characteristic of not trying to get in the way of your workflow.

Firstly, tmux is a terminal multiplexer that allows you to create, organize and manipulate virtual terminals. Instead of having multiple terminal windows open in your primary OS, you can instead keep a single tmux session open on the server that can be shared across all your different devices. I personally run tmux in my bash profile, which means that I’m never in the default Ubuntu shell, and the convenience of being able to come back to the exact same set of terminals with the exact line I was on after a week away is immeasurable. Most commonly, I find that I have between three and six virtual terminals open; one for mysql, one for vim, and the rest scattered throughout various project directories. Naming them early will help you prevent future headaches, and because I work from smaller 13” laptops, I’ve found that keeping each of them at full screen works out well. Having a full screen also facilitates my heavily usage of split panes in vim. There are a few downsides to using tmux though, it is a little harder to switch terminals (Ctrl+b,n/p), and scrolling a virtual terminal in OSX does not seem to be fully supported out of the box... but after a short period of use, the benefits of using tmux were clear.

The primary tool that I use is of course vim, which is where “all the magic happens”. I’m sure I could dedicate an entire post to what vim is, the various modes and how to use it, etc., so for the sake of brevity, I’m just going to explain a few of the tips that I use to reduce the pain of developing without an IDE (or a mouse).

In no particular order:

• Enable sane search options including incremental search (incsearch), highlighting the search results (hlsearch), and case insensitive searching (ignorecase)
• Remap A (Shift+a) to jump to insert mode at the front of the line, and I (Shift+i) to the end, you’d be surprised how many cases those two keystrokes cover
• Remap Tab and Shift+tab to effectively shift-and-reselect in visual mode to mimic modern IDEs (ie. and >gv)
• Learn to use, and love, Ctrl+u/d to page up and down in visual mode (it gets you around quicker and does not wear on your sanity)
• Set timeoutlen to 250ms to enable you to remap double keystrokes (ie. ,, to escape input mode, or ,s to save overwriting changes, etc.)

And perhaps the most useful tip I’ve learned over the years working in vim:

• Map Ctrl+v to vertically split panes on the fly, and Ctrl+h/l to jump left and right between panes. It is incredible how seamless it is to be able to quickly pop up two or three different files side by side, makes some related changes, and close them back down without losing your previous context.

That said, there are still a few small frustrations with working in vim that I need to fix on (partly spurred by this article), namely, “find”ing files in the project is still a pain (since there are often similarly named files, like controller/search.php, views/search.php, cs/css/search.css and I don’t particularly like the idea of adopting a full project-style-plugin). In addition, splitting aside, general text editing is still easier with an IDE where you are also less likely to wipe out a part of your buffer when you accidentally rest a book on your keyboard while in visual mode :).

Lastly, it is important to keep in mind that working on the server doesn’t mean you stop using best practices. My projects are still organized into development and production environments on the server, versioned using git with periodic backups to local machines. But working on the server does allow you to minimize the iteration loop (writing, testing and deploying code), and investing a bit of time up-front to set up such an environment can result in a simpler, untethered development process.