Extending Janus with runtimepath

TL;DR

You can easily extend Janus by using Vim's runtimepath setting in your .[g]vimrc.local file.

Setting the Scene

About six months ago, I switched from using Textmate to Vim as my primary text editor. At first, I tried configuring things on my own, reading through Learning the vi and Vim Editors, but it was slow going (yes, I read the whole thing).

Needless to say, things went a lot faster after I discovered Janus, the much-discussed Macvim starter kit from Yehuda Katz and Carl Lerche. Many thanks to those fine gentlemen.

Having My Cake

After using Macvim with Janus a while, I needed to customize Vim a bit more, mainly to install a few additional language syntaxes, tweak indentation rules and add color schemes. Janus already has support for some level of local customization, by sourcing the ~/.[g]vimrc.local file, where you can set additional options and overrides. More recently, they added support for installing additional Vim plugins using ~/.janus.rake and vim_plugin_task with a git source location. Both approaches are described in the Janus readme.

This gets you pretty far, but sometimes I just want to dump some Vim scripts in a directory. Dropping files directly in ~/.vim (where Janus is installed) gets messy since it's a git repository and I don't want to mix up what is installed by Janus and what isn't.

I wanted my own sandbox that played nicely with Janus but lived outside its domain.

And Eating It Too

My solution is the runtimepath setting, which defines a "list of directories which will be searched for runtime files." Armed with this, I extended Janus following these steps:

1. Add a ~/.vim.local directory
2. Add any necessary subdirectories to ~/.vim.local and drop Vim scripts inside appropriately (e.g., ~/.vim.local/colors/myniftycolorscheme.vim)
3. Add set runtimepath+=~/.vim.local inside my ~/.vimrc.local file, which Janus already sources

You can see my current settings in vimrc.local and vim.local/ from my dotfiles repo.

VMware ESXi Is Awesome (and Free)

First a disclaimer: This post is mainly geek porn for myself. Since most of the content below has been captured elsewhere, it’s not really adding anything new to the corpus of ESXi knowledge on the Internet. Oh well.

Why Am I Doing This?

Throughout my career, I’ve always worked at organizations large enough that systems administration and IT operations were handled by a different group from the development organization. I have always been on the development side of the fence, which means I run into basic sysadmin work from time to time but my first-hand knowledge is limited. In an attempt to fix this (and satisfy my need to buy new hardware constantly), I decided to buy a beefy home server to run VMware ESXi on.

If you haven’t heard of ESXi, it is a free (as in beer) bare metal hypervisor, which basically means it runs virtual machines without the need for a traditional host OS. Essentially, I can setup multiple virtualized servers on one physical server and learn as much about systems administration as I’d like.

The Machine

Using the excellent unofficial hardware compatibility lists on Dave Mishchenko’s vm-help site, I spent a bunch of time sorting out whether I wanted to build a machine or buy a whitebox server. Eventually, a sale on Dell’s Small Business site led me to decide that the whitebox option was the way to go. I ordered a Dell PowerEdge T110 with the following configuration details and costs:

• Dell PowerEdge T110 - $1300
• Processor: X3440 (Lynnfield) Xeon, 2.53GHz, 8MB L3 Cache, Quad-Core with Hyper-Threading
• RAM: 16GB (4x4GB) 1333MHz, Dual Ranked UDIMM
• Network Adapter: On board
• RAID Controller: None
• Storage (HDD): 4x 1.5TB/7200RPM Seagate Barracuda OEM drives (6TB) - $330
• Storage (Flash): Patriot Xporter XT Boost 8GB Flash Drive - $25

Total cost ended up being just shy of $1655, including shipping. Note that I cheated a bit because I already had one 1.5TB Barracuda that I had picked up for this project at a recent Microcenter sale so its purchase price isn’t included. Through NewEgg, the fourth drive would add about $120 more for a grand total of $1775.

While $1800 is not exactly cheap, 16GB of RAM and 6TB of drive space is a bit excessive, so it’d be possible to build a more reasonable config for quite a bit less. The biggest downfall for this setup is the lack of RAID, so my 4x 1.5TB drives are four discrete drives within ESXi (JBOD). Not a huge deal to me, but not ideal, admittedly.

Putting It All Together

The process of putting all the pieces together was pretty mundane, with the only real delighter being the two internal USB ports on the T110’s motherboard. Since my plan was to install ESXi on the USB flash drive, this allowed me to avoid having it stick out the back of the machine permanently. Overall, the internal design of the T110 is nice. The rest was uneventful, so I won’t bore you with details; only pictures!

The Setup Process

I went into the ESXi setup process thinking it was going to be this big battle that would take me all weekend. It actually took about an hour, and was so straight-forward I was kind of disappointed. This is all I did:

• Downloaded and burned the ESXi 4.0 Update 1 Dell Customized ISO from VMware
• Enabled “Virtualization Technology” under “Processor Settings” in the T110’s BIOS to turn on Intel’s VT-x
• Changed boot order to flash drive first (the USB drive was recognized by BIOS without issue)
• Installed ESXi 4 U1 from the disc to the flash drive, which the installer saw as a drive without any changes

That’s really all there was to it. Based on VMware forum posts, this process was harder before Update 1 of ESXi 4, but it’s pleasantly uneventful now.

Creating Servers

Once ESXi booted up, I was able to configure TCP/IP and host name settings using the text-based menu system on the machine. I christened the new box kermit (all my PCs are named after Muppets) and then installed the VMware vSphere client on my main Windows 7 machine to finish configuration settings and start making virtual machines. I ran into some issues cloning my base Windows Server 2008 R2 VM, but due to the length of this post, I’ll leave the details for another day.

So far, I’ve got primary and secondary Active Directory controllers (affectionately named statler and waldorf), along with the accompanied DNS servers, running my home network name resolution. Unified logins and not having to mess with IP addresses or hosts files is pretty cool.

Was It Worth It?

With two servers performing networking duties and a third ready for configuration, I can easily say I’ve learned more about running servers in the past two weeks than I have in the last two years at work. I’ve had the need to dig into sysinternals a few times, learned quite a bit about Active Directory and was up until 3AM one night reading about DNS record types. I’m still not an expert, and probably never will be with such a small network to manage, but I’ve been having a ton of fun along the way. It’s been an effective learning tool for me so far, and I’m just getting started with what I want to do.

In fact, ESXi is one of the coolest things I’ve played with in quite a while, so my only regret is that I didn’t look into it sooner.

Adrenaline Junkies and Template Zombies

I’m a big fan of patterns, as I find that codebases employing well-known patterns (such as MVC) are much more approachable for developers new to a project, making them easier to maintain over their lifetime. Of course, patterns aren’t limited to just code, but are also found and applied in other fields, from architecture to medicine, because they help quickly communicate a shared understanding of a situation or approach. This allows discourse to more quickly move to the relevant bits, rather than just getting up to speed.

My predisposition to patterns is one reason I enjoyed Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson and Susan Robertson.

If you don’t recognize those names, it’s the Atlantic Systems Guild, the same group of people that wrote Peopleware. In Adrenaline Junkies and Template Zombies, the guild outlines common project and organizational patterns that they’ve observed throughout their careers. Many of the patterns tend to be anti-patterns, rather than traditional patterns you would want to emulate. This is also why so much of the book struck me as humorous, if only because they may be familiar from your own experience.

My favorite pattern in the book happens to be the first one, which is Adrenaline Junkies. From the book:

You probably recognize the characteristics of the adrenaline junkie organization: Priorities are constantly shifting; everything is needed “yesterday;” there’s never enough project time before delivery; every project is urgent; and the urgent projects just keep coming. Everybody is frantically busy . . . all the time.

People in these organizations do not think strategically. Work gets done on the basis of its urgency alone. Unless a project’s “frantic factor” is high, it will be ignored – even though it promises a significant long-term advantage. It will remain ignored until it suddenly (surprise, surprise) becomes urgent. Adrenaline junkies believe that the best way to work is not by planning but by running as fast as possible.

Most of us have probably seen individuals, teams or entire organizations exhibiting this behavior. It’s all too often to find an adrenaline junkie developer, as they tend to be the types who see their entire job as the act of writing code. If they aren’t writing code, they’re wasting time, since planning, design and research are more strategic actions and not directly related to that urgent bit of deliverable they’ve just been asked for. The pattern even highlights the fact that adrenaline junkie organizations tend to “enthusiastically embrace the customer service ethic: They confuse responding to urgency with admirable responsiveness.” The truth, of course, is that treating all requests equally based only on urgency, without thinking about the larger value (or even usefulness), is actually a disservice to your customer.

The book’s goal is to capture and identify common patterns, and there are dozens of other patterns which are equally interesting. It only glosses over what can be done to fix projects or teams that exhibit anti-patterns, but understanding the behavior is the first step to addressing it in any event. It’s a good read that is likely to give you a better understanding for behavior you may encounter during your career, while also entertaining you. If you’re at all interested in the soft skill side of IT project work, I recommend checking it out.