Say you wanted to select all the accounts from your applications with no associated users. You’d think this would be obvious, however I racked my brain for a few minutes thinking of a Rails-way of sorting this out.

The good news is with Rails 2.2 or later, it can be accomplished like this thanks to join hashes.

Company.find(:all, :include => :users,
             :conditions => { :users => { :id => nil } })

Before Rails 2.2, you would have had to resort to the following.

Company.find(:all, :include => :users,
             :conditions => "users.id IS NULL")

The memcached support in Rails is great, but it’s a bit difficult to see what the heck is going on in a production environment. The first problem is, by default Rails doesn’t keep a list of all memcached keys that are available on the system. So, you have to use a plugin like memcache_store_with_delete_matched to have memcache itself store a list of all available keys.

You can install this plugin with the typical script/plugin command.

script/plugin install git://github.com/lacomartincik/memcache-store-with-delete_matched.git

Then, you configure memcached in your environment.rb like this.

mem_cache_options = {
    :c_threshold => 10000,
    :compression => true,
    :debug => false,
    :timeout => false,
    :namespace => 'app',
    :readonly => false,
    :urlencode => false
  }
  config.action_controller.cache_store = :mem_cache_store_with_delete_matched, ['127.0.0.1:11211'], mem_cache_options

The other benefit to using memcache_store_with_delete_matched is that regular expressions within expire_fragment works.

expire_fragment(%r!/index_user_.*!)

So, down to debugging. If you want to see all keys in a script/console, you can do the following.

YAML.load(ActionController::Base.cache_store.fetch("memcached_store_key_list"))

You can select certain keys from the memcached_store_keylist.

YAML.load(ActionController::Base.cache_store.fetch("memcached_store_key_list")) .detect{ |k| k.match(/index/) }

Once you have the list of keys, you can plug them into a fetch command.

ActionController::Base.cache_store.fetch("app/blog/index")

You can also manually expire keys from a console.

c = ApplicationController.new
c.expire_fragment(/index/)

YUICompressor is a standalone Javascript and CSS minifier from the YUI folks. It’s fairly awesome in that it does deep analysis of Javascript using Rhino (a standalone Javascript interpreter). Most minifiers take the low road and merely remove spaces and newlines, and, if you’re lucky maybe shorten the variable names. YUICompressor one-ups them all because it actually parses all your JS and aggressively optimizes it for download speed.

CSS and Javascript Conflation

The problem is most of the guides out there for integrating YUICompressor with Capistrano and Rails are woefully out-of-date. The main issue is that Rails now has built-in support for combining all JS files into a single file. So, there’s no need to manually do this in Capistrano these days.

You can make Rails combine automatically combine your Javascript by adding a :cache => "cache/all" to your javascript_include_tag and stylesheet_link_tag in your layout.

<%= stylesheet_link_tag 'one', 'two', :cache => "cache/all" %>
<%= javascript_include_tag 'jquery', 'ninja',  :cache => "cache/all" %>

Priming the JS and CSS Caches

The Capistrano stuff is a bit tricky because Rails doesn’t generate the Javascript and CSS until after the app has been visited for the first time. So, you have to visit each of your web servers after restart during your deploy.

task :after_restart, :roles => :web do
  desc "Visiting each web server"
  sleep(5)  # Wait for passenger to fully spin-up
  run "/usr/bin/wget -O- http://127.0.0.1 >/dev/null 2>&1"
end

Invoking YUICompressor

Now, we can invoke YUICompressor after after_restart. The previous after_restart task automatically gets invoked after the web servers are restarted, however, the compression needs to happen after that. So, you have to manually chain a minify just after after_restart.

after "deploy:after_restart", "deploy:minify"

The actual task is quite simple for running the compressor itself. It’s just a normal Capistrano task.

task :minify, :roles => :web do
  desc "Minify JS and CSS Using YUICompressor"
  javascript = "#{current_path}/public/javascripts/cache/all.js"
  stylesheet = "#{current_path}/public/stylesheets/cache/all.css"
  compressor = "java -jar /usr/lib/java/yuicompressor-2.4.2.jar"
  run "#{compressor} --type js #{javascript} -o #{javascript}"
  run "#{compressor} --type css #{stylesheet} -o #{stylesheet}"
end

Today I decided to turn on HAProxy to load-balance between Apache instances running Phusion Passenger on two separate machines. The results are clear. Doing this nearly doubled our ApacheBench throughput scores.

This config was adaped from the 37Signals blog post here.

# /etc/haproxy/haproxy.cfg
global
        maxconn 4096

defaults
        mode    http
        retries 3
        option redispatch
        maxconn 2000
        contimeout	5000
        clitimeout	50000
        srvtimeout	50000

listen web1 XXX.XXX.XXX.210:80
       mode http
       balance roundrobin
       server web1 XXX.XXX.XXX.210:8080
       server web2 XXX.XXX.XXX.211:8080

Passenger is configured the normal way.

<VirtualHost *:8080>
        ServerName www.example.com
        DocumentRoot /var/www/rails_project/current/public
</VirtualHost>

There aren’t many examples of how to combine named_scopes programmatically on the ol’ Blogosphere these days. All I could find were a few scant references to using anonymous scopes like this. It took me quite a while to figure this out which is surprising since this use case seems like such a common thing to do.

If you want to stack conditions on a search form with will_paginate on top of that, this seems to be the spice.

class Shape < ActiveRecord::Base
    named_scope :created_after, lambda { |m| {:conditions => ["created_at > ?", m]} }
    named_scope :with_color, lambda { |color| {:conditions => {:color => color}} }
end

class ShapesController < ApplicationController
  def index
    scope =  Shape.scoped({})
    scope = scope.created_after(params[:months_ago].to_i.months.ago) if params[:months_ago]
    scope = scope.with_color(params[:color]) if params[:color]
    @shapes = scope.paginate(paginate_options({:order => 'id DESC', :page => 1}))
  end
end

I started to use eval to do this, but Ken Turner set me straight today. I view eval as more of a last resort when all else fails. In this case, it’s possible to tap these filters in using a rubber mallet. No sense in busting out the sledgehammer for this one.

Apparently, it is possible reset an entire form using Javascript from a button using the Rails form helpers. Up until now, I’ve been sniffing the submit tag’s name in the controller and avoiding the save when posting an update. The beauty of the Javascript form reset method is that it requires absolutely no code in the controller.

Oddly enough, there did not exist any easily findable examples from Google. So, here is how to reset a form to the original using only Javascript.

<% form_for :person, person, :url => { :action => "update" } do |f| %>
# Other stuff
<%= f.submit "Cancel", :type => "button", :onclick => "this.form.reset()" %>
# Resets the form back to the original values set in the edit template
<% end %>

Rails’ country_select form helper doesn’t accept a :selected option. If a validation error occurs, you really don’t want to force the user to reselect a country. However, there’s no documented way of persisting that data when re-rendering an unvalidated form.

Fortunately, the country_select helper accepts a parameter called priority_countries. This exists so you don’t have to scroll all the way down past Uganda and Ukraine just to arrive at the good ol’ US of A. A clever workaround to this problem is to use the priority_countries parameter to effectively “select” the previous value through a bit of magic.

<%= form.country_select :country,
  [@location['country'] || 'United States'] %>

This ERb line merely appends your selected country to the top of the priority country list. And, indeed this allows your old country to remain selected even if a validation errors causes the form to be rendered again.

Even though Jeff Atwood believes that monkeypatching will lead to the apocalypse, I’ve discovered three cases where it has proven to be most useful.

Case 1: Dynamically Patching a Plug-in

Let’s face it. The Ruby on Rails wiki is littered with a cadre of unmaintained plugins. One example is file_column. Attachment_fu pretty much replaces this, but for whatever reason, the project that I’m working on is using the old warhorse of file upload packages. Recently, I’ve noticed several problems with file_column. The biggest issue is that it was written pre-Leopard So, file_column doesn’t support the new way of calling OS X’s file command. Combining monkeypatching with the Rails alias_method_chain allows us to patch the underlying code with minimal effort. And, keeping the dynamic patch separate, means that updating the plugin will not overwrite the patch.

# Rails lib/project_system.rb
module FileColumn
  def get_content_type_with_leopard_rules(fallback=nil)
    if not RUBY_PLATFORM.eql?('universal-darwin9.0')
      return get_content_type_for_leopard_without_apple_rules
    end
    if options[:file_exec]
      begin
        content_type = `#{@options[:file_exec]} -bI "#{@local_file_path}"`.chomp
        content_type = fallback unless $?.success?
        content_type.gsub!(/;.+$/,"") if content_type
        content_type
      rescue
        fallback
      end
    else
      fallback
    end
  end
  alias_method_chain :get_content_type, :leopard_rules
end

Case 2: Adding a Feature to a Plug-in

I’m a total Unix snob. Upper-case filenames injure what’s left of my dwindling sanity. File_column recklessly allows the user’s filenames to be saved directly to the filesystem. This has the side-effect of dumping a flagon full of mime-type detection FAIL when you view the files that have been uploaded to the server. Think of users uploading images named me.jpeg, me.JPG and me.Jpeg. Inconsistent capitalization is clearly evil and has to be sanitized before it gets to our precious disks. Using a monkeypatch with alias_method_chain, you can override file_column’s sanitize_filename method to convert the filename to lowercase.

# Rails lib/project_system.rb
module FileColumn
  class << self
    def sanitize_filename_with_downcase_rules(filename)
      self.sanitize_filename_without_downcase_rules(filename).downcase.gsub(/\.jpeg$/,'jpg')
    end
    alias_method_chain :sanitize_filename, :downcase_rules
  end
end

Case 3: Overriding a Native Ruby Class to Facilitate Symbol#to_proc Abuses

Ever since reading Reg Braithwaite's (1..100).inject(&:+) post, I've been mystified and rather infatuated with Rails' Symbol#to_proc method (which, incidentally, was only possible through Rails' monkeypatch to the Ruby Symbol class).

Recently, I wrote a method to detect whether any one checkbox or radio button had been selected on a HTML form. This would serve as a form validation, but was complicated due to the fact that radio button values are arbitrary strings and checkbox values are posted as "0" and "1". The radio button values had to be converted to boolean by the controller, but ActiveRecord's value_to_boolean method does not support this. Monkeypatching came to the rescue yet again and allowed me to override Object in an inject-friendly way.

# Rails lib/project_system.rb
class Object
  def selected?
    return true if self and self.is_a?(String) and self.include?('location')
    ActiveRecord::ConnectionAdapters::Column.value_to_boolean(self)
  end
end

Rather than writing a massive case statement or nested if/elsifs, we can just write the following in a model.

# Rails app/models/model_name.rb
def selected_place?
  places.collect(&:selected?).inject(&:|)
  # Logically, the same as places.collect(&:selected?).any?
end

The preceding loop calls our new Object selected? method on each of the location_types column, and the inject ORs all the data together.

I don't really understand why Jeff is writing these slime pieces on monkeypatching. Jeff's logic is equivalent to reasoning that driving should be outlawed because cars are dangerous. However, just because a few people drive drunk doesn't mean that no one should drive! Oddly, I would get behind a law to make drunken monkeypatching a felony.

For the three people in the world building the Rails mysql gem on a PowerPC G5-based OS X Server with the 64-bit MySQL installed getting this crazy error:

lazy symbol binding failed: Symbol not found: _mysql_init

The magic ninja gem install command that will cure all your ills goes a little something like this:

sudo env ARCHFLAGS="-arch ppc64" gem install -V mysql -- --with-mysql-include=/usr/local/mysql/include/ --with-mysql-lib=/usr/local/mysql/lib --with-mysql-config=/usr/local/mysql/bin/mysql_config --with-mysql-dir=/usr/local/mysql

Pretty obvious when you think about it. Not sure why it took me a little over an hour to discover the crucial lynchpin for correcting this system-wide thought-tastrophy.

I don’t hear many people talking about Sass, but it is indeed fantastic. Basically, Sass is kind of like the Smarty of CSS Templating. Sass files compile to CSS after every change just like Smarty’s TPL files compile directly to PHP. Sass fits well into the Rails don’t-repeat-yourself methodology because you can define color and style constants within CSS rather than explicitly specifying them twenty times. The beauty of Sass is that you get a level of abstraction without any runtime overhead. As a result, Sass performs well and allows quick updates to color schemes and typography without resorting to perl/find or ninja text editor foo. So, why aren’t more people using it?