If you’re getting a failure from ‘rvm install rbx’ during the ‘Configuring rbx’ stage, and your logfile looks like:

[2011-05-20 23:22:41] /Users/austinmills/.rvm/wrappers/ruby-1.8.7-p302/rake install
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems.rb:827:in `report_activate_error': Could not find RubyGem rake (>= 0) (Gem::LoadError)
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems.rb:261:in `activate'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems.rb:68:in `gem'
	from /usr/bin/rake:18

Then you just need to make sure that rake is installed in your global gemset (‘rvm use 1.8.7@global’ and ‘gem install rake’).

1. Denial – “Surely that’s not how their API works!”
2. Anger – “WTF are they thinking? Why would anyone do that?”
3. Bargaining – “Hey, would you be willing to change your API? I can make a pull request…”
4. Depression – “This API sucks. I don’t want to work on it anymore.”
5. Acceptance – “I guess there’s no other choice. Is soap4r still active?”

Barbecue Tech

So, I’d owned a Weber barrel-style smoker for years. It was great, but it just didn’t have enough grill space for me to cook for a crowd.  So, my lovely wife got me an offset smoker with a larger grill:

And thus, it was decreed that our house would host the family Thanksgiving this year. Now, I could have sat around and tended the smoker for 8 hours like our barbecue ancestors would have, but we have the benefit of modern technology… so a few modifications were in order:


The first modifications were some simple ones to improve airflow — namely, extending the chimney down to grill level and sealing some of the air gaps with JB weld.

The next problem I looked had to do with the byproduct of charcoal cooking — the ash. The side fire box comes  with a pull-out ash tray, but the problem is that the grill which holds the coals sits on top of the ash tray — so there’s no way to remove ashes while you’re cooking. (Also, the metal in the OEM charcoal grill had warped due to heat after a single cook.) So, I bought a replacement grill from Lowe’s and had my brother-in-law cut it down to size (about 17″x30″). Now, it sits nicely above the ash tray, and I can dump the ash while cooking, without affecting the coals:


You can also see in that picture part of the electronics setup: the stoking fan, a 10cfm fan which can be turned on and off electronically to control the rate at which the charcoal burns (and thus, the smoker temperature). Normal smokers depend completely on the chimney effect, which works well, but the only way to control airflow is by adjusting the intake and outflow openings, which is inexact and can also be greatly affected by wind conditions.

The fan is controlled by the brains of the operation:

This is a Stoker, from Rock’s Barbque. Based on a TINI board, it has 5 inputs and outputs for temperature sensors and fans, as well as the user interface you can see here for controlling the fans and configuring temperature setpoints. It also has an ethernet port, which I have connected to a wireless bridge (you can see it hiding above the controller in the picture above) so that it can connect both to my local network and the Internet as well.

Through the buttons on the controller itself, or the built-in web interface, you can see what the current temperature readings are, and also control it:

Here, I have Sensors 1 and 3 set up in different locations in the smoker, pulling the ambient (‘cooking’) temperature. Sensor 1 is controlling Blower 1 (the fan), and if the temperature goes past the target, the fan will turn on or off (some hysteresis is introduced to keep the fan from turning on and off rapidly when near the target temp).

Now, you might think, temperature over time… that would be a great thing to see on a graph. With the assistance of AmirM’s StokerLog, we can! Here’s the chart from my Thanksgiving turkey cook:

As you can see, I started the smoker around 9:30, added the bird at around 10, and proceeded to cook it for about 5 hours. Here, the purple line is the temperature according to a temperature probe inserted into the deepest part of the breast, and the blue line moving at right angles is the fan output, either on or off.

One of the best things about the smoker setup is that I no longer have to watch it like a nervous mother hen — I wasn’t even at the house between 10:30 and 12, but I never worried because I’d forwarded a port on my router to the stoker’s web interface and could check on it as much as I wanted.

How did the turkey turn out? Awesomely moist, and with a great smoke flavor:

Wondering, as I was, where the ‘Move Window’ option went to? Or the Restore/Size/Move/Maximize/Minimize options? Just shift-right-click on the app in the taskbar and you’ll get that menu.

Benjamin Black has a great post up about why SLAs are pretty much worthless. I agree — SLAs are a minor nice-to-have item but the cost to your business of any downtime is going to be so much greater — maybe 10x or more — and all they do is refund the cost of the service.  Amazon EC2 servers down for a day? You’ll get a couple of dollars back each.  The cost to your business, on the other hand…

It makes me appreciate companies like SliceHost, who don’t offer an SLA and aren’t afraid to say so.

Auren Hoffman has a good post on TechCrunch about how now might be a great time to cherry-pick the best software engineers available, and how it can pay off not only in the short term, but also over the long, to hire high-quality developers and spend money on developing them individually rather than hiring more, lower-quality developers. I find that a lot of companies do too much of the latter — but often the cost of hiring more and cheaper is so obscured by differing workloads and hard-to-quantify ‘quality of output’ that it may never be evident. In some cases, though, it can be quite evident — as in the study cited here in Joel Spolsky’s post describing the time taken by students to accomplish the same assignment… and their scores. I’ll steal just one graphic from him:

This graphic shows that some students finished in 12 hours what others took 50 hours to do — with roughly equivalent quality!

I’ve seen this personally, as well — we probably all have — where you know one developer can do something twice as fast as another… so why aren’t more companies hiring based on that? If you have to pay 1.25x as much for a developer who works 1.5x faster… wouldn’t you take that deal? I wish more companies would.

Over at the EngineYard blog, they have a couple of posts on working with RoR apps at scale, on general scaling and on sharding your database. We’ve had to do a few of these things already for certain customers and will hopefully have to do more in the future, but I think one of the important takeaways is that you shouldn’t do any of these things before you actually have a need to.

Almost all optimizations for performance are going to introduce some amount of friction in your development process and possibly add failure points, as well — and if you have a solution that works right now, and is going to work for what you estimate the load to be over the next month or two (depending on your release cycle), then you have solved the problem you have right now, and should spend that time adding features or fixing bugs instead.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” — Donald Knuth

In a comment to the page, Gregg Pollack points to his screencasts on Scaling Rails — I haven’t watched them yet, but he had a good session on ActiveRecord at last year’s Lone Star Ruby Conference.