What's Sous Vide?

Take your steaks (or your fish or your veggies) and vacuum-seal 'em. Put them in a low-temperature bath for longer than you expect. That's sous vide. It's not poaching, because water never touches the food. Meat cooks completely in its own juices, and it physically cannot overcook, because the water temperature is exactly the temperature you want the meat to be.

High-end restaurants use expensive heaters and cirulators to make this work. The most affordable home sous vide setup is $450 from Sur La Table. Here's the deal though: it's just hot water. You can do this at home.

Season the steaks

A perfect, succulent, medium-rare steak is 130°. You guarantee perfect medium-rareness by keeping the water at exactly that temperature.

I went with some new york strips from Whole Foods, and seasoned them simply with fresh ground pepper and sea salt on both sides.

Bag 'em up

Professional sous vide gear uses sealed, vacuum-packed plastic cooking baggies. It turns out that ziplock bags work just as well. The temperature we are cooking at is (apparently) well beneath that at which the ziplocks will leach into your food.

Here's the trick to getting as much air out as possible: immerse the bags into a bowl of cold water. The water pushes all the air out. Just zip the bag and you're set -- cheapo vacuum-pack.

I also threw some thyme into the bags for a little seasoning flair.

Into the hot water

My initial plan was to heat the water separately to a few degrees above target, and let the cooking happen in a cooler. The idea is that the insulated cooler contains the heat sufficiently for an hour or two — long enough for your steaks to cook.

As ingenious as this hack sounds, it didn't work for me. My cooler was losing water temperature too quickly. No problem; I transferred it to the stovetop in the dutch oven over the lowest possible flame, and monitored it for temperature:

Total cooking time: about two hours. The time depends most on the thickness of your steak. Refer to this excellent article for cooking times.

Out of the hot water, into the frying pan

You can't have a great steak without a nice crust. That crust doesn't happen underwater. Heat up a thick-bottomed pan very hot with some olive oil. As the oil begins to smoke, transfer the steaks to the pan for 30-60 seconds on each side. The caramelization adds essential flavor and makes the steak look like a steak. Warning: this step will smoke up your kitchen.

The verdict

The steaks were delicious. The texture and flavor were amazing. The tenderness of these steaks easily surpassed that of much pricier fillets I've cooked using traditional methods.

So the steaks were a win. The process, not so much. One of the big advantages of sous-vide is unattended cooking: drop the food into its cozy hot bath and walk away for a few hours. It doesn't matter if stays in there an extra hour because (remember) it can't overcook.

The home-brew setup doesn't provide that key benefit of unattended cooking. I had to watch the temperature and adjust the burner over the two-hour cooking time. That's fine for an experimental session, but it's not viable for day-to-day use.

The next step

Here are two low-budget alternatives that still provide totally unattended cooking:

1. This completely awesome do-it-yourself setup. Can be constructed for ~$80.
2. A $140 thermometer probe / controller for use with a rice cooker. I'll probably go this route — It will take up minimal space and allow the rice cooker to do double-duty.

Sous Vide links

• How to cook a steak Sous Vide at Serious Eats.
• Lengthly technical Info, including temperature matrices for various kinds of food.
• The cooking in a cooler thread that started this whole endeavor.
• A good Hacker News thread on cooking Sous Vide.

Two of my side projects, shapewiki and hotspotr are now running in production on Ruby 1.9.1. There are some good resources out there for getting familiar with Ruby 1.9. I wanted to share a few tips/observations on the upgrade process.

Gem/plugin compatibility: not really an issue on the two projects I deployed. Obviously, your experience will be a case-by-case depending on the gems/plugins you use. My takeaway was that the apprehension of dealing with this was far worse than actually dealing with it. The worst case was having to seek out a newer version (acts_as_versioned) or swapping in an alternative (nokogiri). Some of the gems/plugins I dealt with were:

• authlogic: ok
• geokit: ok
• acts_as_versioned: ok, I had a pretty old version and updated it to: http://github.com/technoweenie/acts_as_versioned/tree/master
• hpricot: seemed ok until I ran into run-time issues, had to switch to nokogiri. Which turned out to be very easy, essentially no code changes. Note: I did this part six months ago, and haven't checked hpricot since, so it may be fine now.
• haml: ok
• mislav-will_paginate: ok

Local development environment: there's just one thing you need to know: RVM. RVM makes it incredibly easy to install 1.9 and switch back and forth frictionlessly. And if you're concerned about messing up your working-just-right current system, don't be: you can revert back to your original setup in one command, or remove all traces of RVM whenever you want to. But trust me, you won't want to. RVM is awesome. Install it now so you can start doing the right thing.

Character encoding issues: this is what kept me off of 1.9 for quite a while. I initially got a few applications running on 1.9 six months ago, but ran into problems in production with extended characters from existing production data. Here are the fixes that finally got me up and running: http://gist.github.com/273741. Just drop this into your Rails app as confit/initializers/ruby_191_hacks.rb and you should be good as long as your database content is stored as UTF-8.

Ruby 1.9.1 in production: I took the shortcut of just using RVM to install Ruby 1.9 in production as well. A dedicated installation probably makes sense in the future, but the RVM installation works fine for now.

I feel strongly that building & maintaining momentum on Ruby 1.9 is important for the Ruby and Rails communities. The important thing to know is that it's not hard. RVM makes it very easy to dip your toes. Gem and plugin compatibility is very good at this point, and getting better all the time. So go ahead, install RVM and start the process. Once you've upgraded your app or got a new gem working on 1.9, put up a quick post or tweet on it. Every bit helps us move forward as a community!

RubyMine is a pretty sweet IDE. I've been using it for a few versions now, including the current 2.0 beta.

However, I hit snag when I upgraded my Mac to Snow Leopard this weekend -- RubyMine was showing gibberish for any file I opened. Apparently, RubyMine is trying to use a font which doesn't exist on my upgraded Snow Leopard system. A quick fix is to go into RubyMine's preferences->fonts:

And change it to another monospaced font of your choosing. Hope this helps someone who encounters the same issue.

We've documented two big lessons learned on the Scout blog. The main points:

• You will underestimate the ongoing cost of complexity in your product
• Cool new capabilities don't sell themselves

Give it a read! We will have more hard-earned business lessons coming, so stay tuned.

If you like the post, feel free to upvote on hacker news!

$ grb create branch_name [origin_server]

Create a new local branch as well as a corresponding remote branch based on the branch you currently have checked out. Track the new remote branch. Checkout the new branch.

$ grb publish branch_name [origin_server]

Publish an existing local branch to the remote server. Set up the local branch to track the new remote branch.

And an additional nice touch: grb "prints all commands it runs on your behalf in red, so you eventually learn them." Nice! The link again: git_remote_branch.

An easy solution that worked for me: adding a Rails.logger.flush to my script/runner call in cron.

Before:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it'

After:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it; Rails.logger.flush'

Bonus tip: to capture any other output from the cron task, use this:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it; Rails.logger.flush' >> PATH_TO_APP/log/my.log 2>&1

Happy logging!

Also some specifics on running tests for the gem and the plugin there.

Ruby 1.8.6:

Completed in 3368ms (View: 2256, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3668ms (View: 2420, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3312ms (View: 1964, DB: 12) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3296ms (View: 1896, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]

Ruby 1.9.1

Completed in 989ms (View: 593, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 1035ms (View: 591, DB: 6) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 1055ms (View: 588, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 985ms (View: 592, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]

1. MySQL encoding.

How to check it: I use Sequel Pro ... just click on a table name for the metadata:

How to change it if it's wrong:

I had a bunch of UTF content living in a latin1 table (MySQL calls it ISO-5589-1 latin1). To fix this, export your database and re- import as UTF Details are here, but the gist of it is:

mysqldump -uUSER -pPASSWORD --default-character-set=latin1 DB_NAME | sed 's/latin1/utf8/' > temp.sql 
mysql -uUSER -pPASSWORD DBNAME  < temp.sql

Why not just run the conversions in-place (ALTER TABLE table_XXX CONVERT TO CHARACTER SET utf8 COLLATE utf8_ci;)? That's a different operation -- CONVERT TO CHARACTER SET is appropriate when your content and your DB's encoding already match, and you want to convert it to another encoding. If you have a mismatch in content and encoding, the export/import trick is just what you need. Discussion on additional techniques are here.

2. The charset defined in your HTML headers

How to check it: use curl

~ $ curl -I http://hotspotr.com
HTTP/1.1 302 Found
...
Content-Type: text/html; charset=utf-8

Rails uses utf-8 by default, so unless you've consciously changed it you should be good.

3. The charset specified in your HTML metatags.

How to check it: just view your source and look for something along the lines of <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />. Yes, this is different from the charset in the headers. Mine didn't match on one site. Fortunately, browsers pretty much ignore the metatags in favor of the value given in the header. Still, if you've got a mismatch, it's trivial to fix.

How to fix: open up your application.html.erb and make the change.

4. Your database.yml

Just make sure you have the line encoding: utf8 in your database configuration blocks in database.yml.

5. One more thing to look at...

if you're doing static html caching, then Apache (or whatever web server you're using) probably controls the charset when it serves up the cached page. Make sure it's setting the right charset. More details here

And here is my graph for Ruby 1.9:

• Adding GeoPluginGeocoder for IP geocoding (thanks github/xjunior)
• Ruby 1.9.1 compatibility and Unicode fixes (thanks github/Nielsomat)
• thanks other githubbers who fixed bugs/submitted patches

Since I don't like typing, I automated the process in a very simple Ruby script: http://gist.github.com/64519

What it does for you

1. adds the remote repo
2. checks out the remote repo as a local branch
3. pulls from the remote master or specific commit you provided
4. switches back to master
5. (with your confirmation) merges the just-checked out branch
6. (with your confirmation) deletes your just-checked out branch

To use

• put the contents of the gist into ~/mergefrom.rb (or anywhere in your path)
• make sure it's executable
• (inside a git repo): mergefrom git://github.com/foo/bar.git

Thanks to everyone on github who made updates and sent me pull requests. The reverse geocoding is from FloWi.

• Gem released: Geokit is now separated into a Gem (geokit-gem) and a Rails plugin (geokit-rails). You can use the gem separately. The plugin requires the gem.
• Rails 2.2.2 compatible: the plugin is all updated for Rails 2.2.2
• Many bug fixes/updates:
  • Improved Geocoder.us support -- respects authentication, and can geocode city names or zipcodes alone
  • cross-meridian finds work correctly with bounds conditions
  • fixed a problem with columns with "distance" in their name
  • added Geonames geocoder
  • the gem and plugin are now hosted at Github. The overall site is still athttp://geokit.rubyforge.org

Geokit makes it easy to build location-based apps. It provides geocoding, location finders, and distance calculation in an easy-to-use API.