Due to popular inexorability, I’m learning to use the “Vim” text editor(specifically MacVim).

Having recently finished Pragmatic Thinking & Learning, I decided to follow one of the suggestions and mind map this new information.

The mind map turned out pretty good. This one includes the basic commands, which I’ll update with the more advanced stuff as I learn it. I made a large version to hang next to my screen. Here’s a preview:

You can download the full version as a PDF here. Also, if you want, you can work on this mind map some more by importing the OPML for it into whatever software you use.

PS: Yes, I wrote this post in Vim :)

Site search is one of the most important missing features when moving your blog off of a blog engine to a static site. I’m using Jekyll to churn out the pages for this site, but wanted back my missing search.

This post brought to you courtesy of the Google Search AJAX API

As it turns out, I need only to drop in the AJAX powered Google search and it just works. Here’s how.

  1. First, head on over to Google Code and get an API key.
  2. Then, make yourself an include file named google_ajax_search.html (create the _includes directory in the root of your Jekyll project if you don’t have one).
  3. Next, add this code to the file you just created and substitute your api key and url:

    <script src="http://www.google.com/jsapi?key=your_api_key" type="text/javascript"></script>
    <script language="Javascript" type="text/javascript">

    google.load("search", "1");

    function OnLoad() {
    // Create a search control
    var searchControl = new google.search.SearchControl();

    // Add in a WebSearch
    var webSearch = new google.search.WebSearch();

    // Restrict our search to pages from this site
    webSearch.setSiteRestriction('your site url');

    // Add the searcher to the SearchControl

    // tell the searcher to draw itself and tell it where to attach

  4. Now, create a div in your layout, with id=“search” where you’d like the search box to appear.
  5. Lastly, include your google_ajax_search in the <head> of your layout.

How I Use Screen

20 Feb 2009

GNU Screen is described a “a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.”

GNU Screen

What this means in plain english is, screen is a whole lot of awesome. Special thanks to @voxdolo for getting me hooked.

Screen essentially lets you run multiple command line based apps, scripts, or prompts from a single terminal and then detach and resume that session whenever you like. This is super useful when you ssh into remote machines and you need to run a script, monitor a log, and just poke around all at the same time. However, it has other applications that motivate me to have it running all the time, instead of just a plain ol’ shell. (I use bash by the way)

First off, screen uses an command character to access it’s commands, by default ctrl-a. However, I type in dvorak layout, mostly on my mbp which has no control key on the right side, making ctrl-a super difficult to press in a hurry. So I changed it to ctrl-h. You can remap any of the bindings in screen however you like.

Using screen in a single context

I know most folks who use screen like to create separate screenrc’s depending on what they need open. That works like this:

I’ve got my default, ‘all the time’ settings in ~/.screenrc and per context settings in ~/.screen/foo. So let’s assume I’m going to be doing some rails work – I’d startup screens with the following command:

  screen -c ~/.screen/rails

That’d fire off a server, autotest, console, and prompt – all ready to go from whatever project dir I was in. The config file for that looks like:

  source ../.screenrc

screen -t svr ./script/server
screen -t con ./script/console
screen -t at autotest —rails

Using screen while context switching

Contrary to this, quite a bit of the time I’m flying through one off tasks and switching contexts too much for this approach to be productive. In that case I start screen in my home directory and rely on its ability to bind any command to a key. Using these bindings coupled with a utility that lets you jump around really quickly(I use j) allows you to terminal your way around all your chores. Some of my bindings look like this:

  bind S screen -t svr ./script/server
bind C screen -t con ./script/console
bind T screen -t test rake
bind P screen -t cucumber ./features

Why not just use tabs in Terminal.app or something?

Well, because of many of the other great features like splitting, monitoring, capturing output and others. I’m not going to cover them now, as they’re outside the scope of this article, but I encourage you to give screen a try.

So I’ve made the move to Jekyll

I don’t mean physically(unfortunately). I’ve moved this blog to static pages on GitHub powered by the Jekyll static site generator.

When I saw a project on GitHub titled Jekyll, it caught my eye. My grandparents had a beach house on Jekyll Island in GA where I spent many summers. So, I checked it out and am quite impressed. Its author, mojombo makes a great point about how blogs are currently setup backwards.

Jekyll lets you author your posts in Textile, Markdown or plain HTML and cranks out the HTML for the entire site for you. It will even generate the xml feeds for you.

The only thing that’s generally dynamic content on a blog are the comments, but with services like Disqus you can transparently host them off-site.

I’ll probably hack on Jekyll a bit in the next few days to add HAML support which is noticeably missing, but other than that – it’s great!

PS: Since most of the old content is dated and irrelevant anyway – I’m not going to bother moving it over.