Run guard-jasmine-headless-webkit without X server

You write specs for your javascript, right? If not, you really should.

jasmine-headless-webkit really helps with that. guard-jasmine-headless-webkit makes it all even more enjoyable, although there’s one caveat – it’s not so easy to set it all up.

There is a great guide for that, but it lacks some important details on running guard-jasmine-headless-webkit without graphical interface (X server).

Assuming you already have Xvfb installed, execute this command to run Xvfb in the background:

Xvfb :0 -screen 0 1024x768x24 > /dev/null 2>&1 &

And then you need to setup the DISPLAY shell variable in order for guard-jasmine-headless-webkit to automatically connect to our virtual frame buffer. Here’s the excerpt from my .bash_profile (it first checks if there is Xvfb running on display :0 and only then sets the DISPLAY variable):

xdpyinfo -display :0 &>/dev/null && export DISPLAY=:0

Hash to HTML (hash2html) in Ruby

I needed to output a Hash as a nested HTML structure. Googling didn’t find any satisfactory results, so I decided to roll my own. UL/LI tags seemed like the best choice. It was a nice exercise in recursion.

The result is a function, which outputs a nicely indented HTML. Note, however, that it’s a very basic solution. It doesn’t cope well with anything other than Strings and Numbers (unless your objects support a nice to_s method).

# Prints nested Hash as a nested <ul> and <li> tags
# - keys are wrapped in <strong> tags
# - values are wrapped in <span> tags
def HashToHTML(hash, opts = {})
  return if !hash.is_a?(Hash)

  indent_level = opts.fetch(:indent_level) { 0 }

  out = " " * indent_level + "<ul>\n"

  hash.each do |key, value|
    out += " " * (indent_level + 2) + "<li><strong>#{key}:</strong>"

    if value.is_a?(Hash)
      out += "\n" + HashToHTML(value, :indent_level => indent_level + 2) + " " * (indent_level + 2) + "</li>\n"
      out += " <span>#{value}</span></li>\n"

  out += " " * indent_level + "</ul>\n"

Who knows, maybe someone somewhere finds it useful.

Update: much more concise solution by Piotr Szotkowski.

hookup is the shit!

This is simply amazing:

$ g pull
Already up-to-date.

$ g co edge
Switched to branch 'edge'
==  AddFileTypeToSong: migrating ==============================================
-- add_column(:songs, :file_type, :string)
   -> 0.0048s
==  AddFileTypeToSong: migrated (0.1380s) =====================================

$ g rebase master
Current branch edge is up to date.

$ g co master
Switched to branch 'master'
==  AddFileTypeToSong: reverting ==============================================
-- remove_column(:songs, :file_type)
   -> 0.1674s
==  AddFileTypeToSong: reverted (0.1679s) =========================

Oh, and it will bundle automatically for you as well, so don’t hesitate and hookup your Rails project!

On Heroku

While Heroku is nice and all, it suffers from the same disease as every other hosted-for-you solution:

$ git push heroku
-----> Gemfile detected, running Bundler version 1.0.7

$ bundle --version
Bundler version 1.0.10

It’s a whole three patch versions behind! Now I don’t really know (and maybe don’t even really want to know) what has changed between .7 and .10, but I can easily imagine things braking precisely because those minor inconsistencies in Bundler versions.

And sure, I could downgrade to .7, but to do that just because of Heroku? Thank you, but no. I want to ride the latest.

Mocha. The stubbing library

This example (shortened here):

class Order
  def shipping_cost
    total_weight * 5 + 10

require 'test/unit'
require 'rubygems'
require 'mocha'

class OrderTest < Test::Unit::TestCase
  # illustrates stubbing instance method
  def test_should_calculate_shipping_cost_based_on_total_weight
    order =
    assert_equal 60, order.shipping_cost

and this snippet (emphasis mine):

The more interesting discussion deals with whether to mock or stub your database-backed model. One upside is speed: This test case will not hit the database at all. Another is independence. I completely isolate the code under test to the controller layer.

convinced me that there just might be some treasure to be found beyond the Test::Unit. And I know that it's just the tip of the iceberg.

Rails and Merb together

Or putting it in another words: Merb will be merged into Rails to become Rails 3.0. Is it 1st April just way too soon or what? – was my first thought the moment I’ve read it on the Ezra’s blog. But then I’ve read the official announcement and… it kind of turned out to be true. Surprised I was, definitely. I haven’t really jumped on the whole Merb bandwagon. Sure, I was planning to try out Merb in the (rather distant) future. Now it seems I won’t have to. Merb supposedly did lots of things better than Rails (modularity, less dependencies, more lightweight, faster) and those things are to be incorporated into Rails. Will see how this pans out.

Exciting times. Definitely exciting. Nice Xmas gift.