Making MacVim Pretty

The holy editor wars. Almost everyone has their favorite, and your colleague, conference mate, or cellmate will rabidly talk your ear off about one editor versus another. I have to admit, I bounce back and forth between TextMate and MacVim, and am closely watching my new up and coming favorite, Vico.

Lately I've been favoring MacVim. Especially with these modifications I'm about to show you that make it... pretty!

First, there is Alloy's MacVim fork. It gives you a nice Mac-like sidebar, project drawer - just like TextMate. The easiest way I found to install Alloy's fork is to use the normal homebrew recipe for macvim, but edit it, and point it to a new tarball that you've created.

  • install homebrew if you haven't already
  • git clone https://github.com/alloy/macvim.git
  • tar -cvzf macvim-7.3-63.tgz macvim/
  • brew edit macvim
  • change the line with the URL to something like file:///Users/ivan/dev/macvim-7.3-63.tgz. Make sure to use your own file path
  • you can either delete the md5 line or calculate the md5 of your tgz file with: md5 macvim-7.3-63.tgz
  • you may need to update the version if it has changed
  • brew uninstall macvim if you already had it installed
  • brew install macvim
  • launch MacVim and press command-, to get the preferences window. You should now have the option to show the sidebar

Secondly, there is Geoffrey Grosenbach's PeepOpen. It gives you an improvement over TextMate's Command-T file picker. There are Vim plugins that duplicate and improve on Command-T's functionality already, like Ctrl-P but none of them are a pretty Cocoa GUI like PeepOpen. It is a paid product, but it's worth the cost if you like to make your environment worth to look at it.

Other reasons I am preferring Vim over TextMate lately are Tim Pope's excellent plugins: Rails.vim, and Fugitive.com (for Git).

Integrating Git with a Visual Merge Tool

One of the first real points of frustration a developer encounters with Git is the initial unresolved merge conflict. And it’s only a matter of when, and not if, it will happen. The root cause of the conflicts is unavoidable in any kind of parallel development: Updates that are made independently may modify the same or overlapping regions of the codebase. The longer the development remains independent, the greater the probability this will take place. For a tool that is basically based on branching and parallelism, Git is essentially inviting this “trouble.” (Rest assured that the benefits are still well worth it.)

Testing Ruby on Rails Obfuscated Email Addresses with RSpec

You may have known that Ruby on Rails can protect email addresses that you have on your web pages with the mail_to view helper. But how do you test email obfuscation in your RSpec view tests?

To obfuscate an email address in a rails view, you can simply add encode: "javascript" to your mail_to helper.

obfuscate and protect an email address
1
mail_to "[email protected]","email me", encode: "javascript"

To test this, I created a method in my spec/spec_helper.rb file. This method goes through each character (byte) of the string containing the email address, and calls the sprintf method to format the character in the way that the javascript decoder in rails can read.

email encoder to include in spec_helper.rb
1
2
3
4
5
6
7
def encode_email(email)
# copied escape method from:
#http://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html#method-i-mail_to
escaped = ""
email.each_byte { |c| escaped << sprintf("%%%x",c) }
return escaped
end

Having that method available makes my example very easy to read:

email encoding example
1
2
3
it "should obfuscate and display the contact email" do
render.should have_content(encode_email("[email protected]"))
end

Do you know a better way? For example, hooking directly into the view helper code from ActionView::Helpers::UrlHelper#mail_to? Let me know in the comments.

DRY Up Your Factory Girl Factories With RSpec and Cucumber

factory girlWhen I first set up the fixture replacement gem Factory_Girl in my current Ruby on Rails project, I had two files with the same code in each one, creating the same factory twice. One in RSpec's spec/factories directory, and another in Cucumber's features/support directory. According to the Don't Repeat Yourself (DRY) principle, this was not ideal. How to fix?

I asked the question in the #rspec channel on IRC, and lucky me, David Chelimisky, the lead developer/maintainer of RSpec, answered. Simply require the factory file from RSpec in Cucumber's features/support/env.rb file. Like this:

require one model factory
1
require_relative("../../spec/factories/model_name.rb")

But this could get quite tedious, if you have more than one model. Which of course, you probably do. So, here's a snippet that will load all of your factories:

require all factories
1
Dir["../../spec/factories/*.rb"].each {|file| require_relative file }

I put this in my features/support/env.rb file. If you use Spork, I put it in my Spork.each_run section.

Are you using factory_girl, machinist, or another fixture replacement library? Let me know in the comments if you know a better way to do it.

Vico Editor Combines Best of TextMate and Vim

I'm in love with a new text editor. It's called Vico. For Vim fans, you have all your comon keybindings for blazingly fast editing. For TextMate fans, you've got all your bundles and snippets. It really is the best of both worlds.

Here's a screen shot showing a vertical split between the view and the view spec, with RSpec results in a Rails app:

screenshot

There is a link on Vico's site for a free trial app - go try it!