Software-Related Intel


The Only OS X Shortcut You Need to Remember

I’m a big fan of the keyboard. Minimizing time between thought and action helps me flow. Vim helps me do this, as do keyboard driven utility apps like LaunchBar. For everything else I rely on keyboard shortcuts. Unfortunately, it’s easy to forget a shortcut, and mousing through the menu is slow and clunky. So, here’s my all time favorite OSX keyboard shortcut: Shift + CMD + /. This is the universal shortcut to toggle an application’s help menu. Not only can you search for application help topics, but menu items are also returned.

Now, you can quickly launch the action and be on your way. But if you take a moment to hover over the menu item, you will be shown where in the menu it can be found along with its keyboard shortcut.

It’s like an internal command launcher for each application. Plus, you can see the keyboard shortcut for next time and skip the help menu altogether. Enjoy!



Pomo-pairo : Pomodoro Technique + Pairing

Recently, another Obtivian, Scott Parker, joined my team at a client. Since this meant we’d be pairing a lot, I thought we should experiment and see how the Pomodoro Technique worked for us pairing. Overall, I’ve really enjoyed using it and wanted to share some of my thoughts.

Disclaimer - When it comes to productivity boosting techniques, I’m not dogmatic. Instead, I’ll figure out the core ideas and fit them into my work flow comfortably. Try, assess, and adjust.

The Good

  • Reducing broken pairs - Pair-programming works best with both people there…blew your mind, didn’t I? As silly as this seems to point out, pairing loses value when team members are taking breaks at different times (e.g- grabbing snacks, bathroom breaks). Having a visible indication of the next approaching break encourages the pair to power through.
  • Break checks - It’s easy to lose track of time during a break (“I have time to check twitter quick…”). With both team members aware of the break duration, they can keep each-other in check. A quick “ready when you are” at the end of a break reminds the other it’s time to rock.
  • Progressive burn - Pairing is exhausting. Even when you’re not driving, you’re constantly communicating, thinking about design, and proofing your pair’s work. The paced nature of the work/break cycle leads to a steady daily-burn. It’s easy to lose track of time pairing. Cranking through a problem and ignoring breaks seems productive, but I’ve noticed it leaves me mentally fatigued earlier in the day.

Some Challenges

  • Inconsistent availability - If the person you pair with has a drastically different schedule than you, the Pomodoro Technique can fall short. Recently, I worked on a project where the other developer frequently had administrative meetings that would cut through large coding blocks. If he only had a one hour block to code, I’d prefer to just pair the entire block.
  • Interruptions - This isn’t pairing specific, rather a frequent issue I have using the Pomodoro Technique at work. The bread and butter of a pomodoro is that it’s dedicated, uninterrupted work. However, not every member of the team understands how detrimental context switching is to productivity. I have no problem putting off an email or IM till a break. However, I have a hard time waving off an approaching teammate without feeling like a jerk.

So far, it’s been working well for us. I recommend giving it a try. Experiment. Tweak. And if it’s not working, drop it.



Homebrew or: How I Learned to Stop Worrying and Love Package Management

Homebrew is package management system for OS X designed to automatically tune build configurations for your system. No more fumbling with compile flags. No more mucking up your $PATH with various installation locations. Just use ‘brew install package_name’ and let Homebrew handle the rest.


I recommend installing Homebrew as a git repo in /usr/local. I’ll cover some benefits of this later.

$ cd /usr/local
$ git init
$ git remote add origin git://
$ git pull origin master
$ sudo chown -R `whoami` /usr/local

The last command is to eliminate the need of sudo when installing a new formula.

Here are some of the key folders in the Homebrew directory:


(not tracked by git)

Initially, this contains only the brew executable (for installing and maintaining packages). When a package is installed, a symbolic link is created here which points to the executable in the package installation


(not tracked by git)

Packages are installed in their own folder here. (e.g.- /usr/local/Cellar/mysql/5.1.41/). Different versions are separated into sub folders. This way, you can have multiple versions of the same package built and ready for use. Just change the destination of the link in bin/ to point to a different version.


This folder contains all of the Homebrew formulae. Each formula is a Ruby class which uses a DSL to craft the package build recipe. As of this writing, there are 469 formulae that come in the default Homebrew package. If your desired formula is unavailable, check Github or add your own.

Cherry-picking Formulae

So far, so good. I have built every package that has previously given me problems (i.e.- mysql, postgres, imagemagick). I thought I would try something a little more obscure: MacVim.

Error: No available formula for macvim

Denied…Github to the rescue!

I could take the lame route by pasting this to a file in my local Formula folder, but lets show off how easy Github+git makes sharing code.

First, I setup d0k’s fork as a remote git repository in my homebrew repo

$ git remote add mac_vim git://

Now, I can fetch all of d0k’s changes not in my homebrew repo (remember, fetch pulls down the changes but does not merge them in).

$ git fetch mac_vim

Using cherry-pick, I can apply the single MacVim commit to my local repo. All I need is the SHA (accessible via Github or logs). In the master branch, execute:

$ git cherry-pick 1dd0594acbe80b52d26175c2ae97314967a02f06

That’s it! Git automatically knows which branch based off the SHA and commits that change to my current branch.


$ brew install macvim


Creating Shell Commands with Boson + Zsh

Recently, I decided to play around with Boson, a framework for organizing and executing Ruby.  Commands can be executed from both irb and the command line.  Check out the link above as there is a lot of customization available to craft exactly the command library you want.

For example, let’s say I want to post a tweet from the command line.  I create the following module and place it in ~/.boson/commands/

require 'twitter' # twitter gem

module Twitterr

# module named Twitterr to avoid naming clash with twitter gem

def tweet(message)

httpauth ='dev_ajw', 'not_my_password')

client =




Now, I can post a tweet from the command line:

or from irb:

So this is pretty cool.  Not only can Boson be used to organize helper functions for use in irb, but new command line functions can be written using pure Ruby.  Now, if only I didn’t have to type ‘boson’ before each command.

Zsh’s command_not_found_handler

Turns out zsh contains a function similar to Ruby’s method_missing.  If you define command_not_found_handler(), this function will be called when a command is not recognized.  So I drop this in ~/.zlogin:

command_not_found_handler() {
boson $*

and any command not recognized by the shell will be forwarded to Boson.  Now, the tweet command can be called directly from the command line:

One possible side effect is the additional time taken to scan the Boson modules for every unknown command.  So far, this hasn’t bothered me.  I’ll see if things change as my Boson library grows.

page 1 of 1
Tumblr » powered Sid05 » templated