• Varnish is easy to use, if your app isn’t setting session cookies until you actually need them. The presence of a session cookie usually means that content shouldn’t be cacheable.
• Hitting any page with a form results in Rails generating a CSRF token and sticking it in the session, generating a session cookie and effectively locking the rest of the session out of being cacheable (even if it should be).
• Just *breathing* the method session in your app initializes your session.
• The Rails cookie session middleware assumes you always want to write a session cookie.

Fortunately, since so much of this is in Rack middleware, we can fix its mistakes with a middleware of our own. In a nutshell, I’m going to:

• Avoid writing CSRF tokens until we actually need them
• Check and see if we have an “empty” session (ie, no interesting data, just the session ID)
• Prevent session cookies from being sent to the browser unless there’s actually useful data in them.

Let’s get started. There’s a lot to this, and it’s a delicate collection of hacks, but it works nicely.

The care and feeding of CSRF tokens

To get started, I disabled CSRF functionality based on user state. In your application_controller.rb:

  protect_from_forgery :if => :user?
  skip_before_filter :verify_authenticity_token, :unless => :user?

protected

  def form_authenticity_token
    if user?
      session[:_csrf_token] ||= ActiveSupport::SecureRandom.base64(32)
    end
  end

In this case, user? is a method from my authentication framework that lets me check if I have an active session. The astute reader will note that this check performs the aforementioned breathing-on (and thereby initializing) the session, so it’s unfortunately not quite as simple as this. However, this will prevent authenticity checks for unauthenticated sessions. There’s no real point to them if you aren’t performing privileged operations anyhow, so we’ll just save the overhead.

Stuffing your cookies back into the jar

Next, we need to deal with the session cookie itself. We have two options when invalidating cookies – either strip them from the already-written headers, or just add another Set-Cookie line to instantly invalidate them. Since we’re dealing with Varnish, we want option 1 – ideally, we won’t be passing the Set-Cookie header, since Varnish (by default) won’t cache any response that attempts to set a cookie.

Session cookie management happens in ActionController::Session::CookieStore, and it’s really high up in the middleware stack. rake middleware will dump your stack – you’ll find it’s usually in position 2 or 3. So, in order to tweak it, we’ll need to inject a new middleware into your stack to mess with your cookie headers after the cookie handler itself blindly writes them out.

Scroll down if you want the code, but the gist of it is this:

• Check for a special “cookie.logout” environment parameter. If this is present, we’re going to just flat-out nuke the session cookie. More on this later.
• Otherwise, check to see if the session has any interesting keys. If it doesn’t, remove it from the Set-Cookie header

The code itself. Drop this in lib/strip_empty_sessions.rb.

class StripEmptySessions
  ENV_SESSION_KEY = "rack.session".freeze
  HTTP_SET_COOKIE = "Set-Cookie".freeze
  BOGUS_KEYS = [:session_id, :_csrf_token]

  def initialize(app, options = {})
    @app = app
    @options = options
  end

  def call(env)
    status, headers, body = @app.call(env)

    session_data = env[ENV_SESSION_KEY]
    sc = headers[HTTP_SET_COOKIE]
    if env["cookie.logout"]
      value = Hash.new
      value[:value] = "x"
      value[:expires] = Time.now - 1.year
      cookie = build_cookie(@options[:key], value.merge(@options))

      if sc.nil?
        headers[HTTP_SET_COOKIE] = cookie if env["cookie.logout"]
      elsif sc.is_a? Array
        sc << cookie if env["cookie.logout"]
      elsif sc.is_a? String
        headers[HTTP_SET_COOKIE] << "\n#{cookie}" if env["cookie.logout"]
      end
    elsif (session_data.keys - BOGUS_KEYS).empty?
      if sc.is_a? Array
        sc.reject! {|c| c.match(/^\n?#{@options[:key]}=/)}
      elsif sc.is_a? String
        headers[HTTP_SET_COOKIE].gsub!( /(^|\n)#{@options[:key]}=.*?(\n|$)/, "" )
      end
    end

    [status, headers, body]
  end

  private

  # Copied from the cookie session middleware.
  def build_cookie(key, value)
    case value
    when Hash
      domain  = "; domain="  + value[:domain] if value[:domain]
      path    = "; path="    + value[:path]   if value[:path]
      # According to RFC 2109, we need dashes here.
      # N.B.: cgi.rb uses spaces...
      expires = "; expires=" + value[:expires].clone.gmtime.
        strftime("%a, %d-%b-%Y %H:%M:%S GMT") if value[:expires]
      secure = "; secure" if value[:secure]
      httponly = "; HttpOnly" if value[:httponly]
      value = value[:value]
    end
    value = [value] unless Array === value
    Rack::Utils.escape(key) + "=" +
      value.map { |v| Rack::Utils.escape(v) }.join("&") +
      "#{domain}#{path}#{expires}#{secure}#{httponly}"
  end
end

Next, you’ll need to add this to your middleware stack. In your environment.rb:

config.middleware.insert_before "ActionController::Session::CookieStore", "StripEmptySessions", :key => "your_session_key", :path => "/", :httponly => true

The :key and :path parameters should match your session cookie settings.

What this will do is let this middleware run on the way back up the stack, right after the session handler gets a crack at things. If there is nothing interesting in the session, it’ll remove that line from the Set-Cookie header, so if you aren’t setting any other cookies, the header should end up being empty and should get thrown away. If you triggered a logout, will invalidate the client cookies (rather than just writing a cookie with no data in it back to them).

To do that, you’ll need to modify your logout method:

def logout
  request.env["cookie.logout"] = true
end

That should be it. You should now:

1. Not be setting session cookies for empty sessions
2. Not be setting CSRF tokens for anonymous sessions
3. Not be leaving “empty” session cookies laying around on client machines after a logout.

The net result is that you should be cookieless for anonymous sessions, resulting in trivial caching with Varnish. This can vastly improve the performance of your site – especially if you’re catching high-traffic pages from web crawlers and the like with Varnish, so they never touch your Rails stack.

Cookie image (C) scubadive67, used under Creative Commons license

For example, something like this might be used in a model validation:

require 'uri'

def validate_url(url)
	parsed_uri = URI::parse(url)
rescue URI::InvalidURIError
	errors.add :url, "Sorry, that doesn't look like a valid URL"
end

I noticed a bit ago that I started getting invalid URL errors where there shouldn’t be any. After far too long spent in the library’s code, I realized my error: the URLs were being pasted with a trailing space. Stripping the string before attempting to parse it fixed it right up.

I’d argue that URI::parse should likely strip any incoming strings, but in the meantime, remember to strip your user input before trying to determine whether it’s valid or not, or you may end up with frustrated users.

That’ll work, but if speed is a factor, it might not be your best option.

ActiveRecord makes interface to the DB very easy, but it doesn’t necessarily make it fast. Instantiating an ActiveRecord object is costly, and if you do a lot of ‘em, that’s going to cause you to bump up against the garbage collector, which will significantly hinder performance. There are several options, though, depending on how much speed you need.

There are benchmarks at the bottom of the post, so if you’re just interested in those, scroll down.

Option 1: Use transactions

This is definitely the easiest method, and while you’ll realize gains from it, you aren’t going to be breaking any speed records using only this method. However, it’s well worth it if you are doing mass inserts via ActiveRecord.

Instead of

1000.times { Model.create(options) }

You want:

ActiveRecord::Base.transaction do
  1000.times { Model.create(options) }
end

The net effect is that the database performs all of your inserts in a single transaction, rather than starting and committing a new transaction for every request.

Options 2: Get down and dirty with the raw SQL

If you know that your data is valid and can afford to skip validations, you can save a lot of time by just jumping directly to raw SQL.

Imagine, for example, that you’re running the following:

1000.times {|i| Foo.create(:counter => i) }

That’s going to create 1000 ActiveRecord objects, run validations, generate the insert SQL, and dump it into the database. You can realize large performance gains by just jumping directly to the generated SQL.

1000.times do |i|
  Foo.connection.execute "INSERT INTO foos (counter) values (#{i})"
end

You should use sanitize_sql and such as necessary to sanitize input values if they are not already sanitized, but with this technique you can realize extremely large performance gains. Of course, wrapping all those inserts in a single transaction, as in Option 1 gets you even more performance.

Foo.transaction do
  1000.times do |i|
    Foo.connection.execute "INSERT INTO foos (counter) values (#{i})"
  end
end

Option 3: A single mass insert

Many databases support mass inserts of data in a single insert statement. They are able to significantly optimize this operation under the hood, and if you’re comfortable using it, will be your fastest option by far.

inserts = []
TIMES.times do
  inserts.push "(3.0, '2009-01-23 20:21:13', 2, 1)"
end
sql = "INSERT INTO user_node_scores (`score`, `updated_at`, `node_id`, `user_id`) VALUES #{inserts.join(", ")}"

No transaction block is necessary here, since it’s just a single statement, and the DB will wrap it in a transaction. We build an array of value sets to include, then just join them into the INSERT statement. We don’t use string concatenation, since it will result in significantly more string garbage generated, which could potentially get us into the GC, which we’re trying to avoid (and hey, memory savings are always good).

Option 4: ActiveRecord::Extensions

njero in #rubyonrails pointed me at this nifty little gem and I decided to include it. It seems to try to intelligently do mass inserts of data. I wasn’t able to get it to emulate the single mass insert for a MySQL database, but it does provide a significant speed increase without much additional work, and can preserve your validations and such.

There’s the obvious added benefit that you stay in pure Ruby, and don’t have to get into the raw SQL.

columns = [:score, :node_id, :user_id]
values = []
TIMES.times do
	values.push [3, 2, 1]
end

UserNodeScore.import columns, values

Benchmarks

I used a simple script to test each of the methods described here.

require "ar-extensions"

CONN = ActiveRecord::Base.connection
TIMES = 10000

def do_inserts
	TIMES.times { UserNodeScore.create(:user_id => 1, :node_id => 2, :score => 3) }
end

def raw_sql
	TIMES.times { CONN.execute "INSERT INTO `user_node_scores` (`score`, `updated_at`, `node_id`, `user_id`) VALUES(3.0, '2009-01-23 20:21:13', 2, 1)" }
end

def mass_insert
	inserts = []
	TIMES.times do
		inserts.push "(3.0, '2009-01-23 20:21:13', 2, 1)"
	end
	sql = "INSERT INTO user_node_scores (`score`, `updated_at`, `node_id`, `user_id`) VALUES #{inserts.join(", ")}"
	CONN.execute sql
end

def activerecord_extensions_mass_insert(validate = true)
	columns = [:score, :node_id, :user_id]
	values = []
	TIMES.times do
		values.push [3, 2, 1]
	end

	UserNodeScore.import columns, values, {:validate => validate}
end

puts "Testing various insert methods for #{TIMES} inserts\n"
puts "ActiveRecord without transaction:"
puts base = Benchmark.measure { do_inserts }

puts "ActiveRecord with transaction:"
puts bench = Benchmark.measure { ActiveRecord::Base.transaction { do_inserts } }
puts sprintf("  %2.2fx faster than base", base.real / bench.real)

puts "Raw SQL without transaction:"
puts bench = Benchmark.measure { raw_sql }
puts sprintf("  %2.2fx faster than base", base.real / bench.real)

puts "Raw SQL with transaction:"
puts bench = Benchmark.measure { ActiveRecord::Base.transaction { raw_sql } }
puts sprintf("  %2.2fx faster than base", base.real / bench.real)

puts "Single mass insert:"
puts bench = Benchmark.measure { mass_insert }
puts sprintf("  %2.2fx faster than base", base.real / bench.real)

puts "ActiveRecord::Extensions mass insert:"
puts bench = Benchmark.measure { activerecord_extensions_mass_insert }
puts sprintf("  %2.2fx faster than base", base.real / bench.real)

puts "ActiveRecord::Extensions mass insert without validations:"
puts bench = Benchmark.measure { activerecord_extensions_mass_insert(true)  }
puts sprintf("  %2.2fx faster than base", base.real / bench.real)

And the results:

Testing various insert methods for 10000 inserts
ActiveRecord without transaction:
 14.930000   0.640000  15.570000 ( 18.898352)
ActiveRecord with transaction:
 13.420000   0.310000  13.730000 ( 14.619136)
  1.29x faster than base
Raw SQL without transaction:
  0.920000   0.170000   1.090000 (  3.731032)
  5.07x faster than base
Raw SQL with transaction:
  0.870000   0.150000   1.020000 (  1.648834)
  11.46x faster than base
Single mass insert:
  0.000000   0.000000   0.000000 (  0.268634)
  70.35x faster than base
ActiveRecord::Extensions mass insert:
  6.580000   0.280000   6.860000 (  9.409169)
  2.01x faster than base
ActiveRecord::Extensions mass insert without validations:
  6.550000   0.240000   6.790000 (  9.446273)
  2.00x faster than base

The results are fairly self-explainatory, but of particular note is the specific single INSERT statement. At 70x faster than the non-transactional ActiveRecord insert, if you need speed, it’s hard to beat.

Conclusions

ActiveRecord is great, but sometimes it’ll hold you back. Finding the balance between ease of use (full ActiveRecord) and performance (bare metal mass inserts) can have a profound effect on the performance of your app.

It’s definitely worth a look, especially if you’re running in a complex environment, where new closures will be large and unwieldy. It’s very easy, too. Any time you use:

def note(text, options = {}, &block)
  options[:class] = ((options[:class] || "") + " form-note").strip
  content_tag(:div, text, options, &block)
end

Instead, don’t explicitly name the block parameter; just yield to it, and you prevent all the messiness of creating a new Proc object.

def note(text, options = {})
  options[:class] = ((options[:class] || "") + " form-note").strip
  content_tag(:div, text, options) {|*block_args| yield(*block_args) if block_given? }
end

I don’t have benchmarks just yet, but anecdotally it has definitely slowed instance memory consumption in my apps. It’s worth taking a look at!

find_by_sql versus find_by_x

First, Konstantin claims that Model#find_by_field is slower than Model#find_by_sql. This one is hard to dispute; the first will invoke method_missing and spend time generating SQL, while the latter simply executes a statement. Is cutting the knees out from under your ORM worth the time saved? Let’s see!

require 'benchmark'

def measure_find_by_sql_vs_orm(num = 1000)
  puts "find_by_sql (#{num}x)"
  puts Benchmark.measure {
    num.times { User.find_by_sql "select * from users where id = 123" }
  }

  puts "find_by_id (#{num}x)"
  puts Benchmark.measure {
    num.times { User.find_by_id 123 }
  }
end

measure_find_by_sql_vs_orm(10000)

Let’s run this a few times.

[chris@polaris benchmarks]$ script/runner benchmark.rb
find_by_sql (10000x)
  2.290000   0.540000   2.830000 (  4.452150)
find_by_id (10000x)
  4.660000   0.400000   5.060000 (  6.766629)

[chris@polaris benchmarks]$ script/runner benchmark.rb
find_by_sql (10000x)
  2.300000   0.480000   2.780000 (  4.473950)
find_by_id (10000x)
  4.520000   0.560000   5.080000 (  6.837272)

[chris@polaris benchmarks]$ script/runner benchmark.rb
find_by_sql (10000x)
  2.170000   0.540000   2.710000 (  4.419207)
find_by_id (10000x)
  4.580000   0.540000   5.120000 (  6.881676)

find_by_sql: Averages 4.44 sec for 10,000 queries
find_by_id: Averages 6.83 sec for 10,000 queries

Conclusion the first: Using the ORM to build SQL adds some overhead; in my tests, 2.47 sec/10,000 queries, or 0.000247 seconds per query. Is this worth optimizing out? Yeah, probably not. In fact, the productivity lost by using find_by_sql is likely going to end up costing the project more.

IDs and numbers in quotes

Second, they claim that quoting values in your SQL statements slows down your queries. This one struck me as just a little out there. Let’s see what the benchmarks say.

require 'benchmark'

def measure_select_with_quotes(num = 1000)
  puts "Without quotes (#{num}x):"
  db = ActiveRecord::Base.connection.instance_variable_get :@connection
  puts Benchmark.measure {
    num.times { db.query("select * from users where id = 123") {} }
  }

  puts "With quotes (#{num}x):"
  puts Benchmark.measure {
    num.times { db.query("select * from users where id = \"123\"") {} }
  }
end

measure_select_with_quotes(10000)

And the results:

[chris@polaris benchmarks]$ script/runner benchmark.rb
Without quotes (10000x):
  0.690000   0.340000   1.030000 (  2.639554)
With quotes (10000x):
  0.670000   0.290000   0.960000 (  2.655049)

[chris@polaris benchmarks]$ script/runner benchmark.rb
Without quotes (10000x):
  0.570000   0.320000   0.890000 (  2.654003)
With quotes (10000x):
  0.550000   0.400000   0.950000 (  2.617369)

Well, that’s certainly interesting. In 10,000 queries, an average difference of about 3/100ths of a second. Certainly not worth combing through your codebase as an optimization point.

Conclusion the second: The performance gain from quoted versus non-quoted field values is so small to be inconsequential.

On a side note, there is a very interesting subtlety here. Observe the difference between

num.times { db.query("select * from users where id = 123") {} }

and

num.times { db.query("select * from users where id = 123") }

The former passes the Mysql::Result object to a block, and frees it after the block terminates. The latter does not, and the returned Mysql::Result object remains in scope for the entire pass of the benchmark. This subtlety makes a massive difference.

def measure_select_with_free(num = 1000)
  db = ActiveRecord::Base.connection.instance_variable_get :@connection

  puts "Query with block, result immediately freed"
  puts Benchmark.measure {
    num.times { db.query("select * from users where id = 123") {} }
  }

  puts "Query without block, result remains in scope"
  puts Benchmark.measure {
    num.times { db.query("select * from users where id = 123") }
  }
end

[chris@polaris benchmarks]$ script/runner benchmark.rb
Query with block, result immediately freed
  0.060000   0.040000   0.100000 (  0.267983)
Query without block, result remains in scope
  5.040000   0.050000   5.090000 (  5.266476)

Whoa damn. Ruby’s GC is slaughtering performance there. Just adding a pair of curly braces makes the benchmark run 20 times faster.

It’s better to request only specific column

Finally, Konstantin mentions that selecting only specific fields from a table is faster. This is a truth in both MySQL and in the ActiveRecord ORM, for a number of reasons. However, he says that

Person.find_by_name(“Name”).phone_number. It would be much faster if you use: Person.find_by_sql(“SELECT persons.phone_number WHERE persons.name = ‘Name’”)

Why not just use the :select option that ActiveRecord provides?

Person.find_by_name("Name", :select => "phone_number")

Let’s test those assumptions.

def measure_single_field_select(num = 1000)
  puts "Find with all fields"
  puts Benchmark.measure {
    num.times { User.find_by_id(123)}
  }

  puts "Find with one field, with :select"
  puts Benchmark.measure {
    num.times { User.find_by_id(123, :select => "email")}
  }
end

[chris@polaris benchmarks]$ script/runner benchmark.rb
Find with all fields
  0.720000   0.060000   0.780000 (  0.963273)
Find with one field, with :select
  0.310000   0.010000   0.320000 (  0.364554)

[chris@polaris benchmarks]$ script/runner benchmark.rb
Find with all fields
  0.710000   0.110000   0.820000 (  1.014548)
Find with one field, with :select
  0.260000   0.020000   0.280000 (  0.351761)

Very significant difference there…and we didn’t have to bypass the ORM to get it, either.

That said, many times providing views in non-HTML formats tends to be bulky and unwieldy. You end up with either very brittle representations of your data, or extremely bulky respond_to blocks in your controllers.

Fortunately, there’s a better way! We’re going to provide two new render targets, :to_yaml and :to_json which will let us write a single XML builder view, and then provide that view in XML, YAML, and JSON formats according to the consuming developer’s preferences.

In application.rb you’ll want to override the render method.

def render(opts = {}, &block)
  if opts[:to_yaml] then
    headers["Content-Type"] = "text/plain;"
    render :text => Hash.from_xml(render_to_string(:template => opts[:to_yaml], :layout => false)).to_yaml, :layout => false
  elsif opts[:to_json] then
    content = Hash.from_xml(render_to_string(:template => opts[:to_json], :layout => false)).to_json
    cbparam = params[:callback] || params[:jsonp]
    content = "#{cbparam}(#{content})" unless cbparam.blank?
    render :json => content, :layout => false
  else
    super opts, &block
  end
end

As you can see, we render a single XML view, and then load it to a hash from XML, and use Rails’ built-in Hash#to_json and Hash#to_yaml methods to provide the data in the desired format. There is a single glaring problem with this approach, though – Hash#from_xml is dog slow because it uses REXML. There’s a fantastic solution, though!

Courtesy of a blog post over at cobravsmongoose, we have a libxml drop-in for Hash#from_xml

First, install libxml and then faster_xml_simple.

Second, include a monkeypatch to Hash#from_xml with the following:

require 'faster_xml_simple'
class Hash
  def self.from_xml(xml)
    undasherize_keys(typecast_xml_value(FasterXmlSimple.xml_in(xml,
      'forcearray'   => false,
      'forcecontent' => true,
      'keeproot'     => true,
      'contentkey'   => '__content__')
    ))
  end
end

You can run the benchmarks if you’d like, but it’s orders of magnitude faster than REXML. Seriously. Don’t use REXML. It’s like trying to run a Ferrari off of a 9-volt battery.

Now, let’s say you have an action you want to provide HTML, XML, JSON, and YAML views for.

def index
  ...
  respond_to do |wants|
    wants.html
    wants.xml  { render :layout => false }
    wants.json { render :to_json => "posts/index.xml.builder" }
    wants.yaml { render :to_yaml => "posts/index.xml.builder" }
  end
end

Finally, throw together your index.xml.builder file as you best see fit.

xml.instruct! :xml, :version=>"1.0", :encoding=>"UTF-8"
xml.posts do
  @posts.each do |post|
    xml.post(:id => post.id) do
      xml.user(:id => post.user.id) +
      xml.content do
        post.post_body
      end
    end
  end
end

And all of a sudden, bam! You’ve got your posts available in HTML…

/posts/index

…and in XML, YAML, and JSON, along with the associated User. By using an XML builder, you can make the serialized data as complex and customized as you’d like. No more funky respond_to blocks, no more exposing data you don’t want to. Expose what you want, and just what you want, in several formats.

/posts/index.xml
/posts/index.yml
/posts/index.json

One final trick is that the JSON views accept an optional callback or jsonp parameter, which will cause the content to be passed to a Javascript function matching the passed parameter, as per the JSONP spec.

For example, if you have a /foo/bar.json view that would render the following JSON:

"{\"foo\":\"bar\"}"

Calling /foo/bar.json?jsonp=returnFunc would return the following:

returnFunc("{\"foo\":\"bar\"}")

Check out the JSONP spec for more.

Presume that we have a model named Image, which is our target for attachment_fu. Adding URL upload capability is surprisingly simple:

class Image < ActiveRecord::Base

	# Standard attachment_fu inclusion here
	has_attachment :storage => :file_system,
		:content_type => :image,
		:resize_to => "1024x1024>",
		:path_prefix => "public/images/cache/attached",
		:format => "jpg"

	# Allows the direct assignment of a URL to this image, which is the source image to save from
	def url=(v)
		self.uploaded_data = UrlUpload.new(v)
	end

	# Or, we can just pass a URL to Image#uploaded_data
	def uploaded_data=(filedata_or_url)
		if filedata_or_url.is_a? String and filedata_or_url.match /^http(s)?:\/\// then
			file = open(filedata_or_url)
			file.extend(UrlUpload)
			super(file)
		else
			super(filedata_or_url)
		end
	end
end

module UrlUpload
	def filename
		base_uri.to_s.split("/").last
	end

	def original_filename
		base_uri.to_s.split("/").last
	end
end

There you go. All you need now is Image.create(:url => "http://some.url/to/an/image.png") and when the model is saved, the image will be sucked down and saved. Easy!

Jabberish is a DRb-backed Jabber client designed for use in multi-server Rails apps. Just drop in the plugin, configure, start the daemon, and off you go.

Installation is painless, as you’d expect.

 script/plugin install git://github.com/cheald/jabberish.git

Jabberish calls in your code will fail silently if the Jabberish DRb process isn’t running, so if the daemon goes missing, it won’t bring your app crashing down around your shoulders – you just won’t get IMs.

Once it’s installed, it’s very easy to get it up and running.

1. Pop open config/jabberish.yml and set your preferences as you best see fit.
2. run rake jabberish:start – this will start up your DRb daemon, and connect to your configured account to your Jabber network
3. Call Jabberish from your code!

JabberishAgent.deliver("your-email@gmail.com", "Hi there!")

There are many potential applications. For example, to send yourself IMs when your app has an error, in application.rb:

def rescue_action(e)
  # The third parameter is "throttle", which will cause Jabberish to refuse
  # to send the same message to a given recipient twice in a row
  msg = sprintf("[#%s] %s (%s)", Time.now.to_i, e, e.backtrace.first)
  JabberishAgent.deliver("your-email@gmail.com", msg, true)
end

And lickety split, you’re IMing error reports to yourself in realtime. I’m sure others will find much more interesting things to do with it!

It’s very simple, but makes configuration dead-easy. To install it:

script/plugin install git://github.com/cheald/site_config.git

Once you have it installed, check out config/site_config.yml – there’s your config file.

You’ll notice that it has some dummy data in there to begin with. It’s much like your database.yml file; just specify the environment, and under that, specify the key:value pairs you want to have available in your app. site_config has one little trick up its sleeve, though – the key “inherit” is special, and tells it to pull values from another environment. This helps you DRY up your configs, and makes it quite easy to maintain.

For example, if you had the following site_config.yml:

development:
  page_title: "my development site"
  admin_user: chris

production:
  inherit: development
  page_title: "my production site"

You can then use those configured values in your site like so:

<title><%=config_option :page_title %></title>
Your friendly admin is <%=config_option :admin_user %>

site_config will pull values defined for your current environment. If you don’t have a value defined for a given environment, but do have an inherit defined, site_config will then look to the inherited config to pull values from.

Additionally, if you want a value from a specific environment, config_option accepts a second parameter, which specifies the environment to pull from.

config_option :page_title, :development

There’s more at the github page. Check it out.