Stupid Ruby Tricks

Ruby 1.8.6 Considered Harmful

2011-04-20T00:00:00Z

At $WORK today, we discovered the following anomalie in Ruby 1.8.6:

  {:a => 1}.hash != {:a => 1}.hash
  >> true

wat.

This basically means that hashes are not reliable hash keys. It also means that arrays of hashes cannot be modified through set operations, such as #–.

Please, upgrade your rubies.

You can argue that you should never be in a position to find this out. You would be right.

Still upgrade your rubies.

Init Scripts with Thin, Bundler and Monit

2010-10-15T00:00:00Z

#!/bin/bash
LANG=en_US.UTF-8 \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
BUNDLE_GEMFILE=/u/apps/my_app/current/Gemfile \
/usr/local/bin/bundle exec thin ${1:-start} -C /u/apps/my_app/shared/thin_conf.yml -O

You will thank me later, for sparing you much pain.

Some discussion:

LANG is used to set the language in the shell. This is necessary because Ruby looks at this variable to decide which language it should normally use. This is important because the Locale code for ActiveRecord has a bunch of UTF-8 Characters in it.

PATH is important because when monit starts up a shell, it’s basically like doing

env -i

BUNDLE_GEMFILE points to our gemfile.

Then we start our process with thin.

Rails Security Made Easy

2010-04-25T00:00:00Z

I’ve just released an early-alpha version of secure_rails (http://github.com/alexbartlow/secure_rails), a way of collecting the cross-cutting concern of security into a single cohesive set of policy files.

It looks a lot like this:


#rails g security:model User
# lib/security/models/user.rb
 Secure(User) do |u|
   u.policy(:default) do
     attr_accessible # complete lockdown
   end
   
   u.policy(:self) do
     attr_accessible :name, :email # The user himself can edit name and email
   end
   
   u.policy(:admin, :include => :self) do
     attr_accessible :status # moderators can edit status
   
     validates_exclusion_of :status, :in => [:banned_forever], 
       :unless => :skip_status_validation
       
     def skip_status_validation ; false ; end
     # but the moderator cannot set the status to banned forever
   end
   
   u.policy(:manager) do
    # this doesn't do anything, but is here to show that you can use include to
    # pull in multiple roles
   end
   
   u.policy(:super_admin, :include => [:admin, :manager]) do
     def skip_status_validation ; true ; end 
       # superadmins skip the status validation check
   end
   
   # policies always take precidence over the policies they include.
   # That's why the super-admin policy works.
 end

That’s for models. It also lets you specify controller-grained access control:

# lib/security/controllers/users_controller.rb
SecureController(UsersController) do |u|
  u.policy(:default) do
    # Don't allow unprivileged users to change anything
    if [:create, :update].include?(params[:action])
      raise SecurityTransgression.new
    end
  end
end

Pretty awesome, dry, an unlikely to have you forget a before_filter :require_admin in an internal page. Default everything to closed, and you can open up all of your controllers and models in one place.

Check it out over on github (http://github.com/alexbartlow/secure_rails) – play around with it in your rails 3 apps, and let me know if you have any problems!

Serve up JSON Metadata in Rails

2010-03-28T00:00:00Z

So Imagine that you’re using will_paginate in your Rails app.

In order for the display to update properly, you’ve gotta give the view back the current page number, the number of records on a page, and the total number of records you allow. You might do that like this through json:

    def index
      @articles = Article.paginate(:page => params[:page])
      render :json => {
        :data  => @articles,
        :total => Article.count,
        :page  => params[:page] || 0,
        :per_page => Article.per_page
      }
    end

But then that muddles up your pretty JSON interface with a bunch of metadata. Say goodbye to using JesterJS, or any other ActiveResource out there. It also means you miss out on the respond_with magic of Rails 3.

But hey – HTTP already serves up this metadata in the form of headers. Why don’t we just set all of these values in the appropriate header?

  def metadata opts = {}
if params[:format] == :json
response.headers['X-JSON'] = opts.to_json
elsif params[:format] == :xml
response.headers['X-XML'] = opts.to_xml(:root => 'metadata')
end
end

def index
@articles = Article.paginate(:page => params[:page])
metadata :total => Article.count,
:page  => params[:page] || 0,
:per_page => Article.per_page
respond_with @articles
end

Pretty and DRY, all at the same time! Looks like a win!

Since prototype automatically evals the X-JSON header, we can write a tiny bit of javascript to update our view accordingly:

new Ajax.Responder({
  onComplete: function(instance, request, metadata) {
    if ((typeof metadata !== "undefined" && metadata !== null)) {
      $$(.current_page).each(function(elt) {
        elt.update(metadata.page);
      });
      $$(.total_records).each(function(elt) {
        elt.update(metadata.count)
      });
    }
  }
});

Running on Toto

2010-03-21T00:00:00Z

So I’m running on this git/ruby powered weblog called toto. Feels good to be off of wordpress and able to compose my posts in TextMate.

I’ve also tweaked the “transform to html” commands in textmate to replace inline, so I can throw my language over to ruby (^ ⇧ ⌥ R 3), bust a move on some code, hit the bundle command (^ ⇧ ⌥ ⌘ H), and then slap back to markdown (^ ⇧ ⌥ M 3).


class StupidRubyTricks
  def /
    self.send :/
  end
end

The color scheme is significantly less ghastly than my old one too. Too bad I have no sense of aesthetics.

Back to code-monkeying

Vertical Tables in Rails

2010-03-20T00:00:00Z

I just released a rails plugin that provides a mix-in so a class can get it’s attributes from an associated vertical table.

So if you have a table called ‘preferences’ or something that your other developers are constantly stuffing key-value pairs into, then go ahead and use this muh to stop writing a bunch of accessors. It wraps around an existing association to provide DRY access to that table, in a way you’ll never have to think about again.

Something cool about this – It basically de-schemafies one of (or all of) your models. You COULD, though I don’t know why you’d want to, do something obscene like this:

#  no attributes, just an ID and Type column
class DbObject < ActiveRecord::Base
  has_many :db_attributes, :autosave => true
  include VerticalTable::Attributes

  def self.has_attributes(*attrs)
    vertical_attributes_from(:db_attributes) do |v|
      attrs.each do |a|
        v.send(a, :key => a)
      end
    end
  end
end

# id, db_object_id, key, value
class DbAttribute < ActiveRecord::Base
  belongs_to :db_object
end

Person = Class.new(DbObject) do
  has_attributes :fname, :lname, :phone
end

should "allow me to use a person as if it had real attrs" do
  p = Person.create(:fname => "Alex", 
    :lname => "Bartlow", :phone => '8675309')
  assert_equal "Alex", p.fname
end

So there you go. Schemaless MySQL. The scary thing is, you might be able to cluster/partition this by the db_object_id and it might actually be performant.

Head asplode and all.

Cucumber Tables + Factory Girl = Crazy Delicious

2009-08-01T00:00:00Z

Consider the following cucumber step:

Given /^the following "([^\"]*)" exist:$/ do |type, table|
  singular_name = type.singularize
  table.hashes.each do |hash|
    Factory(singular_name.to_sym, hash)
  end
  if Object.const_defined?(singular_name.classify)
    (class << singular_name.classify.constantize ; self ; end).instance_eval do
      define_method(:find_by_cucumber_handle) do |x|
        find(:first, :conditions => {table.headers[0].to_sym => x})
      end
    end
  end
end

Sure, no surprises. We use factorygirl to pump out a ton of models in the table. But what’s with all that metaprogramming crap in the middle? #find_by_cucumber_handle?


    # features/support/paths.rb
    # ...
    when /the "([^\"]*)" page for "([^\"]*)"/
      path = $1
      parameter = $2
      constant = path.capitalize.classify
      send (path.gsub(/ /, '_') + "_path", constant.find_by_cucumber_handle(parameter) )
    # ....

Which lets you do things like:

Background:
  Given the following "users" exist:
    |username|
    | alex   |

Scenario: User logs into site
  Given I am not logged in
  When I go to login
  And I fill in "login" with "alex"
  And I fill in "password" with "password"
  And I press "Login"
  Then I should be on the "user" page for "alex"
  And I should see "Logged in as alex"

Only for every model ever.

Tasty!

For extra credit, use the splat operator + regex-fu so you can do /user/products/commentaries/etc as the cucumber step:

Then I should be on the “user” “products” “commentaries” “etc” page