Statsd is a fairly small node.js application that listens for UDP requests on a configured port and collects them for a short period of time before then sending them over TCP to a graphite server. The upshot is if your statsd daemon goes down, your application continues to operate, thanks to UDP’s fire and forget nature.

If you want to save a little time, try checking out Nunes, a gem to automatically cause Rail’s builtin instrumentation to send data to statsd, see https://github.com/jnunemaker/nunes.

Graphite is an interesting beast worthy of some time reading the documentation to become familiar with the whisper database structure and to learn how you might tweak the configuration. A busy graphite server can be as taxing as a database server, making use of SSD drives, etc. Graphite is horizontally scalable, but documentation on scaling graphite in this manner is particularly lacking. This post by Richard Crowley on federated graphite is all I’ve found at the time of this writing.

Now go and instrument all the things.

The code for a basic no-op formatter is below. If you want to output a message when a group is started or finished, or an example starts or ends, or simply record failures to summarize at the end, all the hooks are well defined by RSpec though not well documented.

class MyRSpecFormatter

    attr_reader :output, :results, :example_group

    def initialize(output)
      @output = output || StringIO.new
      @results = {}
    end

    def start(example_count)
    end

    def example_group_started(example_group)
    end

    def example_group_finished(example_group)
    end

    def example_started(example)
    end

    def example_passed(example)
    end

    def example_pending(example)
    end

    def example_failed(example)
    end

    def message(message)
    end

    def stop
    end

    def start_dump()
    end

    def dump_pending()
    end

    def dump_failures()
    end

    def dump_summary(duration, example_count, failure_count, pending_count)
    end

    # no-op
    def seed(seed)
    end

    def close()
    end

end

You can also add your own custom configuration to RSpec. To do that, you need to call add_setting. An example from jaribio_formatter below. One more line of code calls this method when the formatter is required. The relevant source code to the jaribio_formatter is here if needed for reference.

    def self.configure()
      RSpec.configure do |c|
        c.add_setting :jaribio_url
        c.add_setting :jaribio_api_key
        c.add_setting :jaribio_plans, :default => []
        c.add_setting :jaribio_auto_create, :default => false
        c.add_setting :jaribio_timeout, :default => 5
      end
    end

class FooConfig
  include Singleton  
  attr_reader :foo

  def initialize()
    @foo = true
  end
end

Accessing the instance is easy, call FooConfig.instance. This method is also thread-safe so no two threads are going to create/access a different instance. The example is trite, but imagine instead loading data from a remote service. Now combine this with Mike Perham’s Configuration for Rails, the Right Way.

MyApp::Application.config.foo = FooConfig.instance

There is really little reason to access the configuration via Rails.application.config.foo, except that this way you can change it for things like tests more easily.

Speaking of testing, if you find you need to reset a singleton for some reason, the following seems to do the trick, which comes from http://blog.ardes.com/2006/12/11/testing-singletons-with-ruby. Just paste into a file like spec/support/singleton_reset.rb (if using rspec) and require it in spec/spec_helper.rb

require 'singleton'

class <<Singleton
  def included_with_reset(klass)
    included_without_reset(klass)
    class <<klass
      def reset_instance
        Singleton.send :__init__, self
        self
      end
    end
  end
  alias_method :included_without_reset, :included
  alias_method :included, :included_with_reset
end

The most relevant bit is the use of eval like below in the Gemfile you want to include another Gemfile in.

filename="..."
eval(IO.read(filename), binding)

Pushing gem to https://rubygems.org...
/Users/bjones/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:799: [BUG] Segmentation fault

After a bit of googling I found a nice post describing how to resolve the issue.

http://www.christopherirish.com/2011/09/02/ruby-1-9-2-segmentation-fault-and-openssl/

The key part for me was adding –with-openssl-dir=/opt/local to the end of the command when running `rvm install ruby-1.9.3`.

The reason is the assigned variable in the controller is not an array, but is instead expected to respond to additional methods: current_page, num_pages, and limit_value.

Modifying the view spec like below appears to address the issue.

@books = [
  Factory.build(:book),
  Factory.build(:book)
]
@books.stub!(:current_page).and_return(1)
@books.stub!(:num_pages).and_return(1)
@books.stub!(:limit_value).and_return(1)

PlansController POST create with invalid params re-renders the 'new' template
Failure/Error: response.should render_template("new")
expecting <"new"> but rendering with <"">
# ./plans_controller_spec.rb:73:in `block (4 levels) in <top (required)>'

PlansController PUT update with invalid params re-renders the 'edit' template
Failure/Error: response.should render_template("edit")
expecting <"edit"> but rendering with <"">
# ./plans_controller_spec.rb:117:in `block (4 levels) in <top (required)>'


The problem is that my application is requiring a valid user here, so the controller is redirecting rather than rendering what is expected.

If you look you’ll find helpful advise on the Devise wiki about how to resolve this issue for your controller specs.

• https://github.com/plataformatec/devise (see “Test helpers”)
• https://github.com/plataformatec/devise/wiki/How-To:-Controllers-and-Views-tests-with-Rails-3-%28and-rspec%29

I’m using FactoryGirl, so this is the solution I went with:

$ cat spec/support/controller_macros.rb

module ControllerMacros
  def login_user
    before(:each) do
      @request.env["devise.mapping"] = Devise.mappings[:user]
      user = Factory.create(:user)
      # or set a confirmed_at inside the factory. Only necessary if you
      # are using the confirmable module
      user.confirm!
      sign_in user
    end
  end
end

In spec/spec_helper.rb:

RSpec.configure do |config|
...
  config.include Devise::TestHelpers, :type => :controller
  config.extend ControllerMacros, :type => :controller
end

Now what about those integration tests, so-called request specs in rspec parlance. It turns out you need a means of logging in for those specs too.

1) Plans GET /plans works! (now write some real specs)
Failure/Error: response.status.should be(200)

expected #<Fixnum:401> => 200
got #<Fixnum:605> => 302

After quite a bit of googling I came across the following which seems to work great.


$ cat spec/support/request_macros.rb

module RequestMacros
  def login(user)
    page.driver.post user_session_path, 
      :user => {:email => user.email, :password => user.password}
  end
end

In spec/spec_helper.rb:

RSpec.configure do |config|
...
  config.include RequestMacros, :type => :request
end

The answer is to essentially do what would normally be done if you were testing inside of a Rails application, by looking at what files get required by your testing framework. I use rspec, and here is my spec_helper.rb.

$LOAD_PATH.unshift(File.dirname(__FILE__))
$LOAD_PATH.unshift(File.join(File.dirname(__FILE__), '..', 'lib'))

ENV["RAILS_ENV"] ||= 'test'

require 'rubygems'
gem 'actionpack', '>= 3.0.0'
gem 'activesupport', '>= 3.0.0'
gem 'activemodel', '>= 3.0.0'
gem 'railties', '>= 3.0.0'

# Only the parts of rails we want to use
# if you want everything, use "rails/all"
require "action_controller/railtie"
require "rails/test_unit/railtie"

root = File.expand_path(File.dirname(__FILE__))

# Define the application and configuration
module Config
  class Application < ::Rails::Application
    # configuration here if needed
    config.active_support.deprecation = :stderr 
  end
end

# Initialize the application
Config::Application.initialize!

require 'rspec/rails'

RSpec.configure do |config|
end

require 'my_gem'

Due to Rails 3 modularity, we can now include only the parts of it we need for our tests. So instead of requiring “rails/all” you can see me bringing in only action_controller and some test unit helpers.

I banged my head against another problem, which is not visible from the code here. Rails looks for its root directory by looking for a specific file starting with the directory of the file in which you’ve done this configuration. I’ve seen evidence that some code looks for script/rails and other code looks for config.ru. It isn’t necessary for either of these files to have anything in them, but simply to exist as you’d expect in a rails application. I put them in my ‘spec’ directory.

• spec/config.ru
• spec/script/rails

I’m testing a gem that does something with controllers, so I also setup spec/config/routes.rb. All of my tests use the same two controllers, so I set those up in spec/app/controllers/.

After all this setup, spec tests work as usual in a Rails application for spec/controllers, spec/routing, etc.