This works out well for someone like me who started with Ruby in 2005, when Rails was in its infancy. I have nearly seven years of experience with Rails, ten years of writing web applications, and 15 years of HTML, CSS, and Javascript. You can find workers aplenty who list Rails on their résumé but have really only dipped a toe in the water, which doesn’t cut it. There’s definitely a “Ruby way” and you can tell just by looking at someone’s code to what degree they get it. Even without looking at code samples, when I look through candidates on oDesk or eLance, I can safely assume the ones who title themselves things like “Senior Ruby/PHP/Java/Drupal/Coldfusion developer” are not competent Rubyists—probably not competent anythingists. I pass over candidates if they so much as mention PHP in their description.

Why is Ruby expertise so important?

Isn’t one of Ruby’s selling points that it’s easy to learn? Yes, but if you’re building anything that’s critical to your business, costs a significant amount, and that you want to have lasting value, you’d better build it right—not unlike constructing a new building. A good engineer is aware of a wide variety of resources (be it concrete and steel or full-text search and currency conversion libraries) and has worked with them enough to know their strengths and limitations. A good engineer builds things efficiently and follows convention. A good engineer has solved thousands of problems in this domain before, so when new ones appear, they know where to start looking. There’s no substitute for experience. A developer who has been in the Ruby trenches longer will have better solutions and come up with them more efficiently.

These are the experts; They’re not interested.

You can fairly easily find Ruby experts by:

• looking for the authors of popular and mature open-source Ruby projects,
• tracking down the leaders of local Ruby meetups,
• checking out who speaks at Ruby conferences, and
• investigating who writes books for the Ruby community.

Chances are, they’re unavailable, prohibitively expensive, and not interested in your job.

But they can be persuaded

What experts can’t resist, especially in the fanatical Ruby community, is proselytizing—disseminating information and winning others over to their side. They’re much more likely to take a gig that involves training other smart developers who just haven’t “seen the light” than they are to just take the job themselves.

If you already have developers that you like, hire an expert to train them on Ruby. That doesn’t mean three months of classes in the conference room. Experts like hands-on work and seeing that things are done right. That’s how they got to be the experts, after all! Put them on pair programming and code reviews to transfer their Ruby expertise to your best people. Develop Rubyists from within. You can always hire more Javaheads.

Ending up with talented, loyal Ruby developers and a successful project

Hire one or two Ruby experts to start your new project, apprentice your best developers, and after two or three months, taper off their involvement. They’ll have started the project with the right tools, set the standard for what good Ruby code looks like, solved the initial design problems, and equipped your developers to carry on. The project won’t be done—you might not even have a beta version deployed—but hopefully the project will be on-track for a solid finish and there will be good feelings all around.

Speaking for myself, I love the initial design phase, love watching others catch the Ruby bug, and love leveraging collaboration to produce more than I could alone. Oh—and I like being in charge, getting paid well, and moving on when the novelty has worn off!

So, recruiters, no more whining about how you can’t acquire top Ruby talent. It’s there and it’s available if you’re using the right bait. We’re not interested in full-time $120k + benefits because a.) we can probably do better freelancing, b.) who wants to work full-time?, and c.) it’s not about the money!

The company hired you to hire developers, but what they really need is successful projects. (The old selling drills vs. selling holes analogy.) Sell them on needing to invest in expertise, but say you’ll save them money by apprenticing existing developers and they’ll think you’re brilliant. (You don’t need to tell them where the idea came from!) You really are brilliant, because guess who gets to find the replacement for their Javahead-turned-Ruybist…

With Ruby 1.9:

1
2
3
4
5
6
7
8
9
10
11
12
13

ruby which_string_coercion_is_faster.rb ↵
Rehearsal -----------------------------------------------
''.to_s       0.970000   0.000000   0.970000 (  0.968759)
"".to_s       0.960000   0.000000   0.960000 (  0.960182)
String(str)   0.920000   0.000000   0.920000 (  0.920623)
str.to_s      2.250000   0.010000   2.260000 (  2.249877)
-------------------------------------- total: 5.110000sec

                  user     system      total        real
''.to_s       0.930000   0.000000   0.930000 (  0.931371)
"".to_s       0.940000   0.000000   0.940000 (  0.934964)
String(str)   0.910000   0.000000   0.910000 (  0.913435)
str.to_s      2.250000   0.010000   2.260000 (  2.252326)

Similar results on 1.8:

1
2
3
4
5
6
7
8
9
10
11
12

Rehearsal -----------------------------------------------
''.to_s       1.470000   0.000000   1.470000 (  1.475513)
"".to_s       1.540000   0.000000   1.540000 (  1.540667)
String(str)   1.510000   0.000000   1.510000 (  1.509818)
str.to_s      2.710000   0.000000   2.710000 (  2.713870)
-------------------------------------- total: 7.230000sec

                  user     system      total        real
''.to_s       1.500000   0.000000   1.500000 (  1.497413)
"".to_s       1.520000   0.000000   1.520000 (  1.512449)
String(str)   1.540000   0.000000   1.540000 (  1.536261)
str.to_s      2.690000   0.000000   2.690000 (  2.700433)

When I switched my blog from Radiant CMS to Octopress, I wanted to keep the site on Heroku. It’s free under normal scenarios and if I ever get on HackerNews or Reddit, I just have to scale up my web processes and pay a bit to keep the site responsive. If I were to be so fortunate, I wouldn’t have to scramble to set up load balancing on Linode or even wait while my slice resized. Yay cloud!

The standard method for deploying Octopress to Heroku involves generating your site, checking in the generated contents (within the public/ folder), and deploying to Heroku. As Matthew Manning noted, neither having to check in generated content nor having it generated on-the-fly is ideal. We really need to hook into Heroku’s build phase.

The Cedar stack lets you provide a buildpack for generating the app. It’s how the stack can support Node.js, Python, PHP, etc. I forked Manning’s buildpack and customized it for Octopress. Here’s what you need to do to deploy your Octopress site to Heroku:

Get your repository ready for Heroku

Heroku needs to see the plugins, sass, and source directories, but they’re left out of the Heroku application slug unless you remove them from .slugignore.

echo '' > .slugignore

Fix Pygments

Pygments won’t work on Heroku—or at least I haven’t found a way—so let’s switch to a Pygments API hosted on Heroku.

First, remove pygments.rb from the Gemfile. You’ll then need to patch plugins/pygments_code.rb, removing the require at the top and adding an API call instead of the Pygments library call in two places.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@@ -1,7 +1,9 @@
-require 'pygments'
+require 'net/http'
+require 'uri'
 require 'fileutils'
 require 'digest/md5'

+PYGMENTIZE_URL = URI.parse('http://pygmentize.herokuapp.com/')
 PYGMENTS_CACHE_DIR = File.expand_path('../../.pygments-cache', __FILE__)
 FileUtils.mkdir_p(PYGMENTS_CACHE_DIR)

@@ -21,11 +23,11 @@ module HighlightCode
       if File.exist?(path)
         highlighted_code = File.read(path)
       else
-        highlighted_code = Pygments.highlight(code, :lexer => lang, :formatter => 'html', :options => {:encoding => 'ut
+        highlighted_code = Net::HTTP.post_form(PYGMENTIZE_URL, {'lang'=>lang, 'code'=>code}).body
         File.open(path, 'w') {|f| f.print(highlighted_code) }
       end
     else
-      highlighted_code = Pygments.highlight(code, :lexer => lang, :formatter => 'html', :options => {:encoding => 'utf-
+      highlighted_code = Net::HTTP.post_form(PYGMENTIZE_URL, {'lang'=>lang, 'code'=>code}).body
     end
     highlighted_code
   end

Rearrange your Gemfile

When Jekyll builds your site, it needs the gems in the development group, but it’s assumed you’re generating your site before deploying, so you won’t need them in production. Since we’re pushing the generation step to Heroku and it uses bundle install --without development:test, it won’t have the gems it needs in the build phase. We’ll need to pull everything but rb-fsevent out into the default group.

Also add gem 'heroku' inside the development group. If you like, you can add gem 'thin' to use thin for your server instead of WEBrick.

Your Gemfile should now look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

source "http://rubygems.org"

gem 'rake'
gem 'rack'
gem 'jekyll'
gem 'rdiscount'
gem 'RedCloth'
gem 'haml', '>= 3.1'
gem 'compass', '>= 0.11'
gem 'rubypants'
gem 'stringex'
gem 'liquid', '2.2.2'
gem 'sinatra', '1.2.6'
gem 'thin'

group :development do
  gem 'rb-fsevent'
  gem 'heroku'
end

Create the app on Heroku

heroku create --stack cedar --buildpack git://github.com/jgarber/heroku-buildpack-ruby-octopress.git
git push heroku master

The site should build cleanly and should work at the app URL given. If not, look at the build output when you pushed to Heroku and also check heroku logs.

Let me know in the comments if it worked for you and feel free to fork the buildpack.

Update: Plain Jekyll supported by the buildpack as well.

Mat Schaffer added support for vanilla Jekyll sites as well. Very elegantly done.