Steven Merrill has a nice writeup on using HipChat with IRC through BitlBee. I started installing BitlBee to run on my Mac, but then realized there are public servers running BitlBee thanks to kind people around the world. I picked IRC.net since Pittsburgh is close to Philly.

Here’s how to set it up: (replace the words in CAPS with your info)

1. Connect to the IRC server: irc.net:6667
2. Join the &bitlbee room if you’re not already in it
3. Generate a secure password and register it with bitlbee: register PASSWORD
4. In a browser tab, open the XMPP Account Settings page in your HipChat account. You’ll need some of this information.
5. In your IRC client, send account add jabber USERNAME@chat.hipchat.com 'PASSWORD' using your HipChat Jabber ID and HipChat password
6. account hipchat set nick_source full_name
7. account hipchat set resource bot
8. account hipchat on
9. /join &hipchat
10. chat add hipchat ROOM_JABBERNAME@CONFERENCE_SERVER #CHANNELNAME. Conference Server will probably be conf.hipchat.com. Give it whatever channel name you want.
11. Before you can join, you must set your nick to match the Room Nickname setting in your HipChat XMPP settings.channel #CHANNELNAME set nick 'ROOM_NICKNAME'
12. /join #CHANNELNAME
13. Start chatting!
14. When you’re ready to sign out of HipChat, use account off. account hipchat off

Thanks to Steven for the instructions. I wouldn’t have figured out BitlBee for a long time without his blog post.

1. Poor Backup Bouncer test results. When I restore files to my Mac, I want all the metadata too. I’m a programmer so ownership, permissions, timestamps, and symlinks are important to me on my development machine.
2. They say they won’t store my private key anywhere, but I have to enter it on their site in order to restore files. They may keep the files decrypted for up to 7 days. I don’t want decrypted files anywhere but my computer.
3. I’ve switched to SSDs and needed to move some infrequently-used photo libraries to an external hard drive. I can’t be sure I’ll plug it in every 30 days. The idea that my backup of those precious photos would be deleted if I forgot to plug it in scares me.

I tried out Arq and generally liked it. It has the benefits of Backblaze plus performs well in the above three areas. Amazon’s S3 reduced-redundancy pricing is a little more expensive for the amount of data that I have (85GB), but the improved peace-of-mind is worth it to me.

If Backblaze ever fixed those things, I’d probably come back because it was otherwise a good service.

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.