Openhood Experiments

If you tried to compile compile WSO2/WSF-C and WSO2/WSF-Ruby extension on Snow Leopard, you know how painful it is.

Here’s the configure options for WSO2/WSF-C

./configure --prefix=/opt/wso2/wsf_c CC="gcc-4.0" CXX="g++-4.0" CPPFLAGS="-DHAVE_GETIFADDRS"

Then for WSO2/WSF-Ruby, you will have to replace all occurences of:

axis2-1.4.0 with axis2-1.6.0
rampart-1.2.0 with rampart-1.3.0

Use the provided script to find rbconfig.rb file:

ruby find_rbconfig.rb

And add following configs:

#---------------------------------------------------------------------------------
CONFIG["WSFC_HOME"] = "/opt/wso2/wsf_c"
CONFIG["WSF_LOG_DIR"] = "/var/log/"
CONFIG["WSF_LOG_LEVEL"] = "3"
CONFIG["WSF_RUBY_HOME"] = "/opt/wso2/wsf_ruby"
#---------------------------------------------------------------------------------

And run the build script:

# if you're using rvm
sh build.sh
# else
sudo sh build.sh

Inspired by a benchmark of MongoDB versus SQLite by Jeremy Evans, the famous author of Sequel, here is a benchmark of MongoDB via the mongo ruby driver versus Sqlite via Sequel:

The faster “select alls” can be easily explained: SQLite ids are simple integers whereas mongo ids look like this:

BSON::ObjectID('4c4b20a41a221842e3000002')

So there’re simply more data the gather each time. Sqlite is quite fast in fact, but don’t forget that it offers neither concurrency nor scalability.

More interesting is the following chart featuring MongoMapper versus Mongoid versus plain mongo ruby driver:

And here’s more ODM bench:

The source for all these benchmarks is freely available on github.

Sometimes you just want to take the forbidden path. We had the case quite recently, while testing a Paypal integration. We did want to add a route to a fake Paypal service with a link back to our website after succesful payment, but at the same time we didn’t want to polute our routes.rb just for test purpose. Hopefully, it’s still possible to add routes at runtime even on Rails 3. The issue is calling Rails::Application.routes.draw clears all existing routes and after that no further route can be defined. The solution is inspired by how Rails is doing route reloading:

begin
  _routes = Rails::Application.routes
  _routes.disable_clear_and_finalize = true
  _routes.clear!
  Rails::Application.routes_reloader.paths.each{ |path| load(path) }
  _routes.draw do
    # here you can add any route you want
    get "/test#{rand(1000000)}", :to => "sessions#new"
  end
  ActiveSupport.on_load(:action_controller) { _routes.finalize! }
ensure
  _routes.disable_clear_and_finalize = false
end

Please note that using Rails::Application is deprecated and that you should replace it with MyApplicationName::Application everywhere instead. Happy hacking ;)

If you’ve tried to use Rack::Test on Ruby 1.9.x, which is the default when using capybara for exemple, you’ve probably been bugged by nasty warning like this one:

~/.rvm/gems/ruby-1.9.2-head/gems/rack-1.2.1/lib/rack/utils.rb:16: warning: regexp match /.../n against to UTF-8 string

This problem comes when trying to send any UTF-8 character in params. It may even happen without you trying to send any now the rails does automatically add a snowman in all your forms (not a joke). One solution to silence these warnings is to add:

$VERBOSE=nil

somewhere in your initialization. Another solution is to patch rack itself.

I propose an even better solution, the great escape_utils gem. Not only does it removes the warning, escaping will also be faster, I mean like 45x faster!

It’s nearly too easy to be true, just add this to your Gemfile:

gem "escape_utils"

Then somewhere in your initialization (like in config/initializer in your using rails):

module Rack
  module Utils
    def escape(s)
      EscapeUtils.escape_url(s)
    end
  end
end

Problem solved! Now that you’re at it, why not add these lines too:

require "escape_utils/html/rack"
require "escape_utils/html/haml"

If you’re using erb instead of haml, replace last line by:

require "escape_utils/html/erb"

Now all your html escaping will be faster too, this couldn’t be easier!

The Cucumber team released some days ago a beta of the 0.7.0 version. With this release comes one thing we were waiting for a long time : Gherkin integration.

Gherkin is a new parser for the Gherkin language which features are written in. It’s using Ragel and thus generate fast parsers in pure Ruby, C (MRI extension) and Java.

A thread about the performance this brings was started in the Cukes Google Group for the v0.7.0.beta.2 release.

Here’s what we got when switching from Cucumber v0.6.4 to v0.7.0.beta.2:

162 Features
902 Scenario
12993 Steps

Cucumber 0.6.4 :
  Parsing feature files took 1m44s

Cucumber v0.7.0.beta.2
  Parsing feature files took 0m1s

This means our cucumber startup time dropped from nearly 2 minutes to … instant.

Now, what’s your results ?