codahale.com٭blog

Rails Plugin: rails_rcov

Been paying attention to Mauricio Fernandez’s rcov, but have no idea how to easily integrate it into your Rails application? Well, you had no idea how to do that. In about 15 seconds, you’ll be all over the code-coverage bandwagon. Ready? GO!

First, Install Rcov

I shouldn’t need to say this. Go here, download, untar, and ruby setup.rb && sudo ruby setup.rb install. Go! Go! Go!

Second, Install rails_rcov

Using SVN?

./script/plugin install -x http://svn.codahale.com/rails_rcov

Still partying like it’s 1995?

./script/plugin install http://svn.codahale.com/rails_rcov

Third, Bask In The Joy Of Rake Magic

For each test:blah task you have for your Rails project, rails_rcov adds two more: test:blah:rcov and test:blah:clobber_rcov.

Running rake test:units:rcov, for example, will run your unit tests through rcov and write the code coverage reports to your_rails_app/coverage/units. Running test:units:clobber_rcov will erase the generated report for the unit tests.

Each rcov task can take two optional arguments: RCOV_PARAMS, whose argument is passed along to rcov, and SHOW_ONLY, which limits the files displayed in the report. Here are some examples:

# sort by coverage
rake test:units:rcov RCOV_PARAMS="--sort=coverage"

# show callsites and hide fully covered files
rake test:units:rcov RCOV_PARAMS="--callsites --only-uncovered"

# only show files which begin with "app/models"
rake test:units:rcov SHOW_ONLY="app/models"

Check the rcov documentation for more details.

Please note that rails_rcov has only been tested with a Bash shell, and any other environment could well explode in your face.

Fourth, Marvel At How You Ever Survived Without Mauricio’s Crazy Metaprogramming Robot Watching Your Back

Is that cool or what? All that red in the report is work you haven’t done yet, so get crackin’! Don’t stop shooting until everything’s green! Hup hup hup!

Rails Plugin: http_caching

Allows your Rails application to take advantage of the caching mechanisms built into HTTP 1.1 (i.e., 304 Not Modified return code). Inspired by a Rails cookbook entry (manuals.rubyonrails.com/read/chapter/62). If it fits into your app’s architecture, HTTP caching can make a real difference in user-perceived speed. “And it must pop pop pop!”

Installation

If your project is source-controlled by Subversion (which it should be, really), the easiest way to install this is via Rails’ plugin script:

./script/plugin install -x http://svn.codahale.com/http_caching

If you’re not using Subversion, or if you don’t want it adding svn:externals in your project, remove the -x switch:

./script/plugin install http://svn.codahale.com/http_caching

Usage

An example using send_data:

  def get_orders
    @photo = Photo.find(params[:id])
    unless_cached_after @photo.updated_at do
      send_data @photo.data, :type => @photo.mime_type, :disposition => ‘inline’
    end
  end

If the photo hasn’t been updated since the last time the client requested it, the photo isn’t sent, saving you time and bandwidth.

Another example, this time using a simple RHTML view:

  def get_user_profile
    @user = User.find(params[:id])
    render_unless_cached_after @user.updated_at
  end

A slightly more complicated RHTML example:

  def get_orders
    render_unless_cached_after Order.maximum(:updated_at), :layout => 'orders_feed', :action => 'all_orders'
  end

Or you can keep frequent refreshers from swamping your server:

  def shiny_object
    unless_cached_after 10.minutes.ago do
      @shiny_object = ShinyObject.complicated_database_call(:woo => :hah)
    end
  end

You get the idea.

(And yes, all I do is make Rails plugins.)

Rails Plugin: xhtml_content_type

xhtml_content_type allows you to set the default MIME type for rendered .rhtml views to application/xhtml+xml if the client supports it, and only falling back to text/html for older clients.

For more information as to why this is good behavior, read this: http://hixie.ch/advocacy/xhtml

Installation

If your project is source-controlled by Subversion (which it should be, really), the easiest way to install this is via Rails’ plugin script:

./script/plugin install -x http://svn.codahale.com/xhtml_content_type

If you’re not using Subversion, or if you don’t want it adding
svn:externals in your project, remove the -x switch:

./script/plugin install http://svn.codahale.com/xhtml_content_type

Alternatively, you can just check the trunk out from the repository, if you’re super-DIY.

cd path_to_rails_app
cd vendor/plugins
svn co http://svn.codahale.com/xhtml_content_type

Usage

xhtml_content_type is super easy to use. Add the method sends_xhtml_with_correct_content_type to a specific controller, or to ApplicationController to make all controllers send XHTML properly:

  class ApplicationController < ActionController::Base
    sends_xhtml_with_correct_content_type
  end

sends_xhtml_with_correct_content_type also accepts standard filter-style conditions, if you need them:

  class MySpecialController < ApplicationController
    sends_xhtml_with_correct_content_type :except => [:seriously_weird_action]
  end

  class MyOtherSpecialController < ApplicationController
    sends_xhtml_with_correct_content_type :only => [:the_only_regular_action]
  end

You can also explicitly specify an XHTML content type using this plugin:

  def xhtml_only_action
  	render :content_type => :xhtml
  end

Have fun!

I fought the law and…

So you remember that ticket I got back way back when? The one I totally didn’t deserve, considering I didn’t break the law?

Wanna find out how it ended?

(continue reading…)

dollars_and_cents: a Rails plugin

Update: Use of this plugin is deprecated. If you’re using Rails 1.2 or higher, use the :decimal field type for your monetary values. This will provide you with fixed-point math on both the database and Rails sides of your application.

(Yes, another plugin. I’m full of them.)

One of the big problems with a database-agnostic framework like ActiveRecord is that it doesn’t have a decent data type for money. Yes, you can use a FLOAT, but then you end up charging someone $12.3000000000000001, which is just awkward. You can hard-code a database-specific type, but then your code takes a dive when you hit the bigtime and get bounced up to a DB2 backend or some nonsense. Or you could store prices as an integer value of the smallest unit possible–the cent–and do the math in the model, but then you have to write an attribute wrapper, which is boring and not very DRY. Or…

Aw snap, Coda’s hauled off and done it for you! Oh happy people! Oh frabjous day!

Installamacation

Love SVN?

./script/plugin install -x http://svn.codahale.com/dollars_and_cents/

Ambivalent about it?

./script/plugin install http://svn.codahale.com/dollars_and_cents/

Usamization

dollars_and_cents is an easy plugin to use.

Name your fields the right thing

All prices should end with _in_cents. That’s the convention I made up, and you all get to deal with it. I think it’s rational, but I think many things are rational with which other people violently disagree (e.g., my dad and I on the direction in which twisty ties should be fastened–he says clockwise, I say whatever).

In a migration or somesuch:

create_table :buyable_things do |t|
  t.column :name, :string
  t.column :price_in_cents, :integer
end

Profit

Once installed, dollars_and_cents adds a Float attribute price to the model BuyableThing. Use as you would any other attribute:

  @buyable_thing = BuyableThing.find(params[:id])
  old_price = @buyable_thing.price   # => 19.99
  @buyable_thing.price = 23.99
  new_price = @buyable_thing.price   # => 23.99

And now 2399 is stored in the database, in a nice, cross-platform format: the humble int.

(If you had a database field called tulpa_death_chant_cost_in_cents, it would add an attribute called tulpa_death_chant_cost. It’s not limited to the phrase “price”. FYI.)

All yours, under the MIT license © 2006. Woo hah.