Being a capable programmer, he “took an evening” and wrote up a Ruby library to replicate this functionality.  Then he extended vim with a plugin called fuzzyfinder_textmate that called out to this Ruby library.

The results were terrific, and fuzzyfinder_textmate is my go-to solution for opening files in vim.  I almost never type “:e …” anymore.  I’ve yet to see anything faster at grabbing a file buried somewhere in a directory tree. This plugin is particularly useful for me when working on Rails projects, where vim’s ‘current directory’ is Rails.root, and everything I want to open is down at least one level.  If you’re not familiar with the plugin, here’s a silent-movie-style screencast Jamis put together when he released it.

Sadly, this terrific plugin has a bit of a problem: it’s a pain in the ass to install.

Jamis’ fuzzyfinder_textmate relies on a second plugin, called fuzzyfinder.vim.  The author of this plugin makes frequent changes, which usually end up breaking fuzzyfinder_textmate.  This got to be too much for Jamis, and he officially dropped the project a year ago.  Today, the latest versions of these plugins won’t work together.

However, thanks to several contributors and github’s forking, you can get this big mish-mash of libraries and plugins to work…provided you install exactly the right versions of each.  It’s a trifle annoying, but fortunately I’ve done the homework for you.  Follow the steps below and enjoy my favorite bit of vim functionality.

Installing fuzzyfinder_textmate:

1. Make sure you’re using vim 7.2 (the latest, as of this writing).  It’s possible earlier versions work as well, but I can’t confirm these steps will apply.
2. Make sure the vim you installed was compiled with ruby support.  Check this by running vim –version | grep ruby at the command line.  A result of +ruby means you’re good, -ruby means you DON’T have ruby support.  Debian/Ubuntu users can get a ruby-capable vim by running sudo apt-get install vim-ruby.  Another test to make sure you’ve got ruby support: type :ruby in vim.  Argument required is good.  Not an editor command: ruby is bad.
3. Install Jamis’ fuzzy_file_finder Ruby library from here.  This is installable as a gem, but I strongly recommend simply git cloneing this repo, creating a ruby directory in your .vim folder, and placing the lib/fuzzy_file_finder.rb inside there.   This keeps this dependency in your .vim directory (rather than on a system gem you’ll forget about when you change servers), and enables keeping your vim configuration in a git repository (HIGHLY recommended).
4. Install vim-fuzzyfinder version 2.22.3.  IMPORTANT: you MUST use this exact version.  Other versions (particularly anything NEWER than this one) will NOT work.  After installing, confirm it works by running :FuzzyFinderFile in vim.  You should get a pop up box with a list of files.  If you do you’re almost there.
5. Install fuzzyfinder_textmate, but use sethbc’s fork from github.  Don’t use the version from Jamis’ repo as it will NOT work with the version of fuzzyfinder.vim we installed.  git clone again, and simply put fuzzyfinder_textmate.vim in your .vim/plugin folder. To test that everything worked, run :FuzzyFinderTextMate in vim.  If you get a popup box, you’re done!

If you’re having trouble, the most common culprit is that you’ve mucked up the versions.  This collection of files is quite finicky, and if you’re using the wrong version of any one things fall apart quickly.  After that, double-check you’ve got Ruby support.

If you’re still having trouble, do a git clone of my dotfiles.  My setup is confirmed working, so you can diff your copies of the library/plugins against mine.  Any differences mean you’ve got the wrong version.

If you still have issues, leave a note in the comments and I’ll try to get you sorted out.

Finally, if you found this post useful, I’d urge you to check out my screencast: Vim for Rails Developers.  In it, I’ll teach you the best plugins, external tools, and editing tricks for writing Rails code at top-speed.  If you write Rails code in vim, it’s sure to save you time.

They look like this:

Factory(:user) do |u|
 
  u.after_create { |user_instance| do_something_to(user_instance) }
 
end

Now, when you use Factory(:user) in your tests, the do_something_to method will be called after the user is saved in the database.  Also notice that you’ll be passed the instance of the user as block parameter.

There are two other callbacks now available: after_build and after_stub.  Their callbacks fire pretty much where you’d expect them to.

You can mix and match these callbacks on the same factory.  Multiple definitions of the same callback will be executed in the order you provide them:

Factory(:user) do |u|
 
  u.after_build { |user_instance| do_something_to(user_instance) }
 
  u.after_create { do_this_after_create }
 
  u.after_create { then_do_this }
 
end

I’m excited about this addition because of how much more flexibility this gives factory_girl.  There are some kludgy parts of my factories.rb files that will be more elegantly accomplished with these tools.

Accepting these little lambdas to be run later feels very lispy, something I take as a great sign.

For more usage details, check out the ‘callbacks’ section of the README.

And, if you’d like to read more about using Ruby’s blocks this way, Greg Brown has an excellent article on the topic (excerpted from his also-excellent book).

I also can’t stand reading code on the site.

Why?  Frankly, the text is plain old ugly:

Those italicized comments look like faintly-etched glass.  And the bolded bits look clumsy as well (check out the ‘m’ on ‘module’)!

What’s with the ugly?  Let’s ask Firebug:

‘Bitstream Vera Sans Mono’?  Never heard of it.  Haven’t got it installed.  If you’re on Windows or OS X, you probably don’t either.

Okay, so I haven’t got Bitstream, so it looks like we’re falling back t–oh my GOD it’s COURIER.

Yes, Courier.  Invented in the 1950s.  For typewriters.  I think I last used this font while editing GORILLA.BAS to mess with the speed and gravity.  No one should be using Courier anymore (unless you’re writing a screenplay).

Fortunately, there are two easy ways to fix this.  The first, you and I can do.  The second will have to be done by the Github guys.

What we can do: install Bitstream Vera Sans Mono.

Download it here.

Installation is OS-specific, but I bet you can figure it out.

Here’s how things look after the install:

Sweet mystery of life at last I’ve found you!  This is about…a billion times more readable.

Now, the experience of not having their first-choice font shouldn’t have been so painful.  If you’re going to lead with a talented but fragile rookie, make sure you have a dependable second-string something something sports analogy.

Anyway, the Github guys should change ‘Courier’ to ‘Courier New’ in their stylesheet. Courier New is an updated and refreshed grand-child of Courier, and it’s far more readable, especially when bolded or italicized.  Plus it’s just as widely installed as Courier.

Little change on our side.  Little change on their side.  Code looks beautiful; everyone’s happy.

Github — no longer a butterface.

The grumbling surprised me at first: I like OpenID.  But I think I’ve figured
out why these judges didn’t: it’s easy to do a crappy login page.

Here’s an example of a really unfriendly OpenID login page:

Yikes.

That blank white text box is like an iron door between me and this site.  I am a
nerd AND an OpenID proponent, but I do not have my provider’s URL memorized.
Even if I did, it’s a drag to type: “https://www.google.com/accounts/o8/id”

(Incidentally, Googlers: can we get https://openid.google.com for this?  C’mon,
that’s kinda cool, no?)

So, please don’t ever make me go look up my OpenID provider URL.  Particularly
if I’m using someone as large as Google for a provider.

Okay, cleanse your palatte and let’s check out an example of an EXCELLENT OpenID login page:

Kudos to you, SO team.  This page kicks ass.

Stack Overflow gives me exactly what I want on an OpenID login page: a huge button with Google’s logo on it.
Not only that, but they’ve shrunk the buttons for the less popular providers. I love that sort of touch in software.

If you’re going to support OpenID, please read the organization’s Best UX
Practices.  Or maybe Yahoo’s OpenID Usability Research.

Then just go copy StackOverflow’s page.

I think we should shoot to have all OpenID login pages look like siblings: possessing a thread of sameness despite their differences.

I have been programming professionally for over three years, with the last five months doing full time Ruby on Rails development.  I would label myself an intermediate Ruby user: comfortable with the basics, but with limited exposure to its more advanced topics.  Lately, I have been reading more and more open source Ruby projects, and have been looking for ways to contribute back to our teriffic community.

Given my experience and goals, Ruby Best Practices was a perfect read.  The book is a collection of general strategies for solving problems in Ruby, with a focus on real-world code examples. Its author is an experienced Ruby developer who also happens to be an excellent writer.

Ruby Best Practices has a number of notable strengths. First, Brown is highly pragmatic. When discussing closures, he writes “I could show some abstract examples or academically exciting functionality such as Proc#curry, but instead, I decided that I wanted to show you something I use fairly frequently.”  This attitude has lead to a book that is full of ideas you can actually use.  It feels like the experienced guy down the hall showing you all his best stuff.

Secondly, RBP’s examples are almost uniformly excellent.  As contributor or creator of several popular Ruby projects (Prawn and Ruport) Brown has no lack of real-word code examples to choose from, and he does so with skill.  In addition, he’s not shy about trimming down the examples to leave behind just the most relevant code elements.  These two factors combine to produce code listings which are indicative of real open-source programs while remaining quite comprehensible.  Not only are Brown’s examples excellent, but they are plentiful.  Nearly every new idea he introduces is demonstrated through a case study of real (or plausibly real) code.  Working through this book will definitely sharpen your code-reading skills.

Beyond simply being clear, Brown’s writing is also fun to read.  His enthusiasm for the subject matter is obvious: “I could stop here and move on to the next topic, but similar to when we looked into the belly of lazy.rb earlier in this chapter, I can’t resist walking through and explaining some cool code.”  This sort enthusiasm continues throughout, and leads to a technical book that I’m tempted to call a page-turner. Making my way through the book really excited me to read and work on open-source projects.

If you’re still on the fence, take a read through the sample chapter, Mastering the Dynamic Toolkit.  Or, if you’d prefer a quicker read, check out this post on the book’s blog to get a feel for Brown’s writing style.  If you like what you see, don’t hesitate to pick up a copy of this excellent book.

Chapter Titles:
1.  Driving Code Through Tests
2.  Designing Beautiful APIs
3.  Mastering the Dynamic Toolkit
4.  Text Processing and File Management
5.  Functional Programming Techniques
6.  When Things Go Wrong
7.  Reducing Cultural Barriers
8.  Skillful Project Maintenance
A.  Writing Backwards Compatible Code
B.  Leveraging Ruby’s Standard Library
C.  Ruby Worst Practices

This post is targeted at newer Rails programmers. If you’ve moved beyond the beginner stages you might not find much here for you.

Onward!

Let’s start with some code that’s not so good.

# app/controllers/book_controller.rb
def new
  @book = Book.find(params[:id])
  ...
end
 
def create
  @book = Book.find(params[:id])
  ...
end
 
def edit
  @book = Book.find(params[:id])
  ...
end

Why it’s not so good:

This controller contains repeated code. ALWAYS BE WARY OF THIS! Pay particular attention when you’re doing the exact same thing in multiple places. This type of code should almost always be refactored. In Rails, this duplication can be removed using a before_filter.

Better code:

# app/controllers/books_controller.rb
before_filter :find_book
 
def new
  ...
end
 
def create
  ...
end
 
def edit
  ...
end
 
protected
 
def find_book
  @book = Book.find(params[:id])
end

Why it’s better:

The repeated code has been pulled out into a method (find_book). Now, changes to the way we find books will be easy to make in this controller. Notice also that we made it protected. We only need to use this method in this controller, and a gentleman’s objects share as little as possible.

# Return an array of titles
 
def all_titles(books)
  book_titles = []
 
  books.each do |book|
    book_titles << book.name
  end
 
  book_titles
end

Why it’s not so good:

Local variables can make complicated code more clear, but the variable in this method isn’t pulling its weight. It’s just a box around the stuff we’re really interested in.

Good code:

# Return an array of titles
 
def all_titles(books)
  books.inject([]) { |book_titles, book| book_titles << book.name }
end

Why it’s better:

It is a single, clear line, where each token pulls its weight. Experienced Ruby users will find this version clearer, despite its greater density.

It is possible you find this version less clear. A few months ago, I would have felt the same. Back then, inject felt a little scary: I’d only bumped into it other peoples’ code, and never written a fresh one myself. However, after a bit of experience, I find it the perfect tool in the certain situations. Think of using it particularly when you want to build up a collection (like an Array or Hash) from some other collection.

If you’d like to improve your skills with inject:
1. Check out Jay Field’s inject post (good)
2. Read its documentation and experiment in irb (better)

Update after posting:
Several commenters have (rightly) pointed out that this code is better written thusly:

# Return an array of titles
 
def all_titles(books)
  books.map(&:name)
end

Quite right guys. Inject is still great in the right spots though, and it’s well worth your time to learn it.

# app/views/books/index.html.erb
 
<% for book in @books %>
  <%= render :partial => 'shared/book', :locals => { :book => book }
<% end %>

Why it’s not so good:

You’re calling a partial on a collection of objects, passing each one in through a variable. This idiom appears in Rails so frequently that a better syntax was created for it.

Good code:

# app/views/books/index.html.erb
 
<%= render :partial => 'book', :collection => @books %>

Rails will render the partial once per item in @books. Each item will be available in the variable ‘book’ (this is the name of the partial, NOT the singularization of your collection’s name).

Why it’s good:

We’re being efficient by leveraging functionality that Rails already provides for us. This version makes its intention clearer: “I’m rendering a collection.” The goal of the first version is less obvious, and takes longer to parse.

Similar to your ‘repeated code’ alarm, you should have a ‘roughly a million programmers must have written these exact lines in the past’ alarm. When that one goes off, check the Rails API and browse some plugins. Rails is great about providing you efficient ways to perform common tasks.

Within a few moments of President Obama being sworn in, a new whitehouse.gov was revealed.  The new site looks great, and promises greater transparency about the actions of our President and government.

Along those lines, check out its robots.txt file, in entirety:

User-agent: *
Disallow: /includes/

Compare this to the robot.txt from Bush’s era, and I think you’ve got a lovely little microcosm; one that points to a hopeful, and open future.

These are enormous numbers:

Donald Berwick, the president of the US Institute for Healthcare Improvement, said of the innovation: “I cannot recall a clinical care innovation in the past 30 years that has shown results of [this] magnitude.”

The change?  The surgeons were required to run through a simple checklist before and after every procedure.

Now, this checklist [pdf] is not lengthy.  In fact, it’s less than twenty questions.  Even more strikingly, the questions are not complicated: before administering anesthesia, has the patient confirmed his identity?  Does the patient have any known allergies?  Have we confirmed that this is the right foot?  I’d wager that the most common reaction of people seeing this checklist is “you mean these things weren’t being asked already?”

The thing is, these questions were already being asked.  The difference is that they weren’t being asked in systematic way.  Members of a surgical team assume that these obvious things have been checked because they’re so obvious.  “Of course this is the right patient.”  “Of course we asked if he’s allergic to the anesthetic.”  “Of course we marked the right limb for amputation.”

The problem is, these things are sometimes done incorrectly, or missed entirely.  Not often, not usually; just sometimes.  Forcing doctors and nurses to use the checklist caught these “sometimes” problems, and dramatically improved patient safety in the process.

From this study, we can draw the following conclusions:

1. Even obvious errors are easy to commit, and once committed, can have terrible consequences.
2. Those who overlook these problems can be highly-trained and intelligent people.  It appears that you cannot out-train or out-brain our human tendency to err from time to time.
3. Instituting a rigorous system to check for errors lowers their occurrence dramatically, compared to existing processes that check for them informally.

Laid out this way, these statements are probably starting to look familiar, because they are exactly like the arguments for using unit tests in programming.  As a software developer, I look at this list and think we knew this stuff already!  We knew it, and we came up with a way of mitigating the problems caused by our own flawed humanity.

The errors that this checklist catches are the kind that kill people.  Thousands of people, every year.  If we, as an industry, had somehow conveyed the efficacy of systemic testing with the medical field, this checklist might have been implemented sooner, and lives could have been saved.

The fact that ideas like this don’t flow across fields is not surprising.  Industry-specific myopia reflects our human tendency to form into groups and distrust outsiders.  Despite this, I do believe it’s worth struggling against.  Perhaps the field of architecture could provide useful insights into the construction of software (perhaps it already has).  Maybe the next big idea in architecture will be inpsired by chemistry, or biology.  Maybe the next time I open my editor I should think “first, do no harm.”

It certainly couldn’t hurt.

(This post is part of a series.  To read more tips and to learn about the philosophy behind these posts, check out the parent post.)

You know you’ve done this way too many times:

ben@lispclub ~ $ apt-get install blahblahblah
E: Could not open lock file /var/lib/dpkg/lock – open (13 Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Bah.

You forgot to type sudo first.

So what do you do?  Hit up arrow, swing back to the beginning of the line, type sudo–ARGGH…THE WASTED SECONDS!

Do this instead: sudo !!

In bash, !! means “repeat the last command I entered.”  Bash substitutes your apt-get command after the sudo, and you finally get to install blahblahblah 0.0.13.  Note that this isn’t specific to sudo.  If you do an ls, and then wish you’d grepped the results for foo, type !! | grep foo.

How to remember it:

Imagine an angry father yelling for his son.  “Sudo!!”  Sudo runs down from his room, sees the command  he was supposed to be in front of, and executes it immediately.

Here are some guidelines on what to expect:

1. One tip per post.

I’m a sucker for productivity tips.  I’ve read dozens of articles with titles like “25 _____ Tips for Fun and Profit!”  I usually take away at most one useful tidbit from these articles.  A lot of good stuff gets lost in the tidal wave of new information.  This posts in this series will be short: one tip each.  I’ll focus on just one idea and move on.

2. I’ll provide mnemonics or imagery to aid recall.

Can you name the nine planets in our solar system?  How about the order of arithmetic operations?

If you can, I bet you access a mnemonic you’ve learned for this purpose.  I use My Video Eye May Just Show Us Nine Planets, and Please Excuse My Dear Aunt Sally for these two.

I’m never, EVER going to forget the names of the planets.  That mnemonic is in my brain for good.  I want the things you learn through this series to be the same way.  As such, I’ll try hard to come up with memorable mnemonics for them.  Sometimes mnemonics don’t make sense, and I’ll instead provide an image to think about that will hopefully stick in your mind.

3. The tips will involve tools programmers tend to use daily.

The value of a tip is proportional the number of times a day you can use it.  These tips will probably only be worth a few seconds each on their own, so I want to be sure there’s a big fat multiplier next to each one.  I’ll be focusing on the heavy hitters in the programming world.

The Posts:

When You Forget to type Sudo