Rails applications must often retrieve random content to display variety, such as a smattering of recent stories for a blog’s home page. To choose content at random with (a modicum of) memory efficiency, use pluck and sample to choose a set of IDs.

Here’s an example class method:

def self.random_selections(count = 1)
  ids = pluck(:id).sample(count)
  find ids
end

pluck(:id) returns an array containing only the ID column. sample(count) picks count elements. find ids returns the list of records that match the IDs.

If the model was Post, for example, the resulting query looks like this:

SELECT `posts`.* FROM `posts` WHERE `posts`.`id` IN (32, 277)

If the posts table is large, this technique is still wasteful (comparable to the more obvious and very memory intensive Post.all.sample(count)).

For large collections of data, more efficient alternatives use the database to choose records or use a search engine to randomly choose IDs from its in-memory index.

You can now read Emerging Technology 2011 in what looks like greek to me. (The original publication is on developerWorks.) Enjoy.

Ruby code isn’t the only asset in a Rails application. It’s common to also have Balsamiq sketches, Photoshop files, HTML mockups, documentation, shell scripts, system configuration files, and data. Git can store and track all these.

However, if you use Heroku, you don’t want supplemental files to be included in your slug. Currently, Heroku limits the application slug to 100 Mb. If you store a good size video in your Git repo, you’ll likely eclipse 100 Mb easily.

To omit files from your application’s slug, maintain a .slugignore file in the root directory of your repository. Each directory named in .slugignore is excluded from the slug.

Here is a sample .slugignore:

doc/
log/
spec/
tmp/
www/

You can find more information about slugs and .slugignore on the Heroku Dev Center.

Controller actions often update time stamps. A controller might mark the time when a record is viewed or capture the time when a record is deactivated. One technique to “touch” or update a time stamp uses update_attribute.

update_attribute :deactivated_at, Time.now

A more terse approach uses ActiveRecord’s built-in touch method. With no arguments, touch sets the record’s updated_at attribute to the current time.

(rdb:1) p book.updated_at
Mon, 23 May 2011 22:00:28 UTC +00:00
(rdb:1) p book.touch
true
(rdb:1) p book.updated_at
Mon, 23 May 2011 22:01:00 UTC +00:00

If touch is successful, it returns true. If the model lacks an updated_at attribute or if touch fails, it returns nil.

touch can update any time stamp, too — simply specify the attribute to update.

(rdb:1) p message.time_last_xmit
Mon, 23 May 2011 22:00:28 UTC +00:00
(rdb:1) p message.touch :time_last_xmit
true
(rdb:1) p message.time_last_xmit
Mon, 23 May 2011 22:02:24 UTC +00:00

One word of caution: touch invokes after_save callbacks. If a model performs considerable work after an update, touch may not be apt. Obviously, if any callback fails, the record is left unaltered. An arguably simpler and faster alternative to touch is update_all.

Book.update_all "deactivated_at='#{Time.now.utc}'", :id => book.id

The mysql2 gem is leaner and faster than its predecessor, mysql. However, adding it to a Rails 3 project can be a little maddening. Moreover, using the mysql2 gem to connect to Amazon RDS via Heroku requires additional configuration. Here are step-by-step instructions to adopt mysql2.

1. Edit the project’s Gemfile, remove any references to the mysql gem, and add the line:

   gem 'mysql2', '
       For now, the <0.3 specifier
       is necessary, as later versions of mysql2 cause this
       error at boot:
   
   Please install the mysql2 adapter: `gem install activerecord-mysql2-adapter`
   (no such file to load -- active_record/connection_adapters/mysql2_adapter
   

2. Edit config/database.yml and replace all references to mysql to mysql2. This is a rudimentary example:

   development:
     adapter: mysql2
     database: myproject-development
     password:
     username: root
   
   test:
     adapter: mysql2
     database: myproject-test
     password:
     username: root
   
   production:
     adapter:  mysql2
     database: myproject-production
     password:
     username: root
   

3. Regenerate the bundle with bundler.

   $ bundle install

4. Finally, to connect to Amazon RDS via Heroku, change the DATABASE_URL to use mysql2. Currently, the Heroku user interface for Amazon RDS does not accept mysql2 as a valid protocol. Configure the database connection via the command-line.

   $ heroku config --long --app myapp
   DATABASE_URL => mysql://login:password@myrdsserver.us-east-1.rds.amazonaws.com/mydatabase
   
   $ heroku config:add \
   DATABASE_URL=mysql2://login:password@myrdsserver.us-east-1.rds.amazonaws.com/mydatabase --app myapp
   

Solr and Sunspot make search and fulltext search in Rails a snap. Each ActiveRecord model can be individually tailored for search; each model instance is indexed whenever its persisted.

Oftentimes, an application must search heterogeneous models. For instance, a social networking site might search users, blog posts, and image metadata, such as a title or geocode stamp, and present the combined results. Further, an application must often restrict search results based on rules or roles. In such cases, it’s often necessary to fine-tune the parameters of the search itself.

To enable the process, use Sunspot’s (internal, unofficial) introspection feature. Call Sunspot::Setup.for(MyModel) to get an object you can inspect.

For example, if the Blog class is indexed via…

searchable do
  integer(:account_id, :multiple => true)   { accounts.map(&:id) }
  time(:created_at, :trie => true)
  integer(:group_id, :multiple => true)     { groups.map(&:id) }
  text(:owner)                              { owner && owner.name }
  boolean(:published)
  integer(:site_id, :multiple => true)      { sites.map(&:id) }
  integer(:user_id, :multiple => true)      { users.map(&:id) }
  string(:tag, :multiple => true)           { tag_list }
  text(:tag)                                { tag_list.join ' ' }
  time(:updated_at, :trie => true)

  text(:messages)                           { messages.map(&:body).join ' ' }
  text(:subjects)                           { messages.map(&:subject).join ' ' }
end

… retrieve the list of non-text fields indexed with…

Sunspot::Setup.for(Blog).field_factories.map(&:name)

Running this in the console would produce:

> Sunspot::Setup.for(Blog).field_factories.map(&:name)
=> [:group_id, :updated_at, :class, :tag, :published, :account_id,
    :site_id, :created_at, :user_id]

Additionally, retrieve the list of fulltext fields with Sunspot::Setup.for(MyModel).field_factories.map(&:name).

The object returned by Sunspot::Setup.for() also permits rudimentary queries.

> Sunspot::Setup.for(Blog).text_fields(:messages)
=> [#<Sunspot::FulltextField:0x104090f88 @multiple=true, @default_boost=nil,
 @more_like_this=false, @indexed_name="messages_text", @boost=nil, @stored=false,
 @type=#<Sunspot::Type::TextType:0x103d89088>, @name=:messages>]

If the field :messages is indexed as a text field, .text_fields(:messages) returns an object. Otherwise, the method throws the exception Sunspot::UnrecognizedFieldError.

Query stored fields with Sunspot::Setup.for(Blog).stored_fields().

Peer into the Sunspot code with bundle open sunspot.

Rails is chock full of convenience functions for constructing views. One example is truncate, which prunes text to a specific length, if needed. Imagine the variable @message is set to This message is long. Very, very, very, very long. and the partial _message.html.haml contains this snippet:

%p
  A shortened message:
  = truncate @message

%p
  The shortened message at a natural break:
  = truncate @message, :separator => '.'

%p
  A shorter message, natural break, with a custom indicator:
  = truncate @message, :length => 40,
    :omission => '... (portions elided)'

The partial would display output such as the following (the HTML has been omitted for brevity):

A shortened message: This message is long. Very,...

The shortened message at a natural break: This message is long...

A shorter message, natural break, with a custom indicator:
This message is lon... (portions elided)

truncate has three options: :length, :omission, and :separator.

• :omission => string specifies what to show when text is truncated. The default string for :omission is ….
• If :length => limit is given, the resulting string is no more than limit characters, including the text specified in the :omission. The default :length is 30.
• If :separator => string is given, it defines a natural break. However, if length is insufficient, truncate ignores the separator.

To try truncate and the other text helpers, launch the Rails console and include the ActionView::Helpers::TextHelper module.

$ rails console
> include ActionView::Helpers::TextHelper
> truncate 'This message is long. Very, very, very, very long.'

Rails 3 introduces a publish/subscribe mechanism called notifications. (View this Railscast for a great introduction.) Rails itself uses notifications to emit each SQL query to the log. Find the implementation in ActiveRecord::LogSubscriber.

It is fairly easy to mimic ActiveRecord::LogSubscriber and create another subscriber to show where each query is called from.

class QueryTrace < ActiveSupport::LogSubscriber
  def sql(event)
    return unless logger.debug?

    debug caller.
      select {|stack| stack =~ /\/app\//}.
        map {|stack| stack.gsub(/^.*app\//, '')}.
          join("\n")
  end

  def logger
    ActiveRecord::Base.logger
  end
end

QueryTrace.attach_to :active_record

Install the code as a Rails initializer, say, in config/initializers/query_trace.rb and launch the application. Each Active Record query calls QueryTrace#sql. In the method, the actual SQL is ignored since it is emitted by ActiveRecord::LogSubscriber. Instead, the code extracts the call stack, filters out frames attributed to the framework, and finally emits a backtrace with the leading path of the application truncated for readability.

The output resembles this:

Feature Load (0.1ms)  SELECT `features`.* FROM `features`
WHERE `features`.`name` = 'Stores' LIMIT 1
  models/feature.rb:16:in `to_feature'
  helpers/application_helper.rb:139:in `feature_available?'
  helpers/application_helper.rb:591:in `show_menu'
  helpers/application_helper.rb:582:in `each'
  helpers/application_helper.rb:582:in `each_with_index'
  helpers/application_helper.rb:582:in `show_menu'
  views/shared/_tabs.html.haml:2:in
    `_app_views_shared__tabs_html_haml__796547580_2224868320_2407870'
  views/layouts/application.html.haml:51:in
    `_app_views_layouts_application_html_haml___1975730980_2228964600_0'
  controllers/sites_controller.rb:32:in `show'

Combined, Faker and Factory Girl make fixtures obsolete and provide ready analogs for actual data in specs. For instance, a stand-in for a User instance can be generated with little code.

Factory.sequence :user_name do |uid|
  "user#{uid}"
end

Factory.sequence :email_address do |e|
  Faker::Internet.email.gsub('@', "#{e}@")
end

Factory.define :user do |u|
  u.confirmed_at          { Time.now }
  u.email                 { Factory.next :email }
  u.first_name            { Faker::Name.first_name }
  u.last_name             { Faker::Name.last_name }
  u.password              { 'password' }
  u.password_confirmation { |p| p.password }
  u.user_name             { Factory.next :user_name }
end

The Factory Girl sequence user_name produces unique user names, user1, user2, and the like. Similarly, the sequence email_address produces unique email addresses, such as mary1@example.com and joe2@example.com. Calling Factory :user produces an entire, life-like record.

$ rails console
> Factory :user
=> #<User id: 6,
  confirmed_at: "2011-04-12 21:08:37",
  email:        "archibald_runolfsson1@hartmannorn.net",
  encrypted_password: "XXX...",
  first_name:   "Skylar",
  last_name:    "Parisian",
  user_name:    "user1",
  created_at:   "2011-04-12 21:08:38",
  updated_at:   "2011-04-12 21:08:38" ...>

If the User model has an attachment, say, for an avatar, the factory can be extended to assign a sample image. Assume the attachment is processed with Paperclip and the attachment field is called image. The following factory creates a user with an avatar.

Factory.define :user do |u|
  u.confirmed_at          { Time.now }
  u.email                 { Factory.next :email }
  u.first_name            { Faker::Name.first_name }
  u.image                 {
    File.new(File.join(Rails.root, 'public', 'images', 'avatar.jpg')) }
  u.last_name             { Faker::Name.last_name }
  u.password              { 'password' }
  u.password_confirmation { |p| p.password }
  u.user_name             { Factory.next :user_name }
end

Paperclip is incredibly flexible. u.image can also be assigned any image URL.