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.

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.

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.