It has been in Rails as long as I can remember, and is in Ruby 1.8.7 and 1.9.x. I love it to death and I use it everywhere I can.

It is actually quite simple, and you can implement it yourself:

It works because when you prepend an ampersand (&) to any Ruby object, it calls #to_proc to get a proc to use as block for the method.

What I always regretted though was not being to pass any arguments, so I hacked and monkeypatched a bit, and got:

So you can now write:

Not that this is any shorter than just creating the darn block in the first place. But hey, it’s a good exercise in metaprogramming and show of more of Ruby’s awesome flexibility.

After this I remembered something similar that annoyed me before. It’s that Rails helper methods are just a bag of methods available to, because they are mixed in your template. So if you have an array of numbers that you want to format as currency, you’d have to do:

What if I could apply some to_proc-love to that too? All these helper methods cannot be added to strings, fixnums, and the likes; that would clutter way to much. Rather, it might by a nice idea to use procs that understands helper methods. Here is what I created:

I used a clean blank class (in Ruby 1.9, you’d want to inherit it from BasicObject), in which I will provide the proper proc-object. I play around with the argument list a bit, handling multiple arguments and blocks too. You can now use this syntax:

That is a lot sexier if you as me. And you can use it in any object, not just inside views. And lets add some extra arguments and some Enumerator-love too:

In case you are wondering, the position you can specify is to tell where the arguments need to go. Position 0 is the method name, so you shouldn’t use that, but any other value is okay. An example might be that you cant to wrap an array of texts into span-tags:

So there you have it. I’m probably solving a problem that doesn’t exist. It is however a nice example of the awesome power of Ruby. I hope you’ve enjoyed this little demonstration of the possible uses of to_proc.

presence

First up is Object#presence which is a shortcut for Object#present? && Object. It is a bit of a sanitizer. Empty strings and other blank values will return nil and any other value will return itself. Use this one and your code might be a tad cleaner.

"".presence # => nil
"foo".presence #=> "foo"

# without presence:
if params[:foo].present? && (foo = params[:foo])
  # ..
end

# with presence:
if foo = params[:foo].presence
  # ...
end

# The example Rails gives:
state = params[:state] if params[:state].present?
country = params[:country] if params[:country].present?
region = state || country || 'US'
# ...becomes:
region = params[:state].presence || params[:country].presence || 'US'

I like this way of cleaning up you’re code. I guess it’s Rubyesque to feel the need to tidy and shorten your code like this.

uniq_by

Another funny one is Array.uniq_by (and it sister-with-a-bang-method). It works as select, but returns only the first element from the array that complies with the block you gave it. Here are some examples to illustrate that:

[ 1, 2, 3, 4 ].uniq_by(&:odd?) # => [ 1, 2 ]

posts = %W"foo bar foo".map.with_index do |title, i|
  Post.create(:title => title, :index => i)
end
posts.uniq_by(&:title)
# => [ Post("foo", 0), Post("bar", 1) ] ( and not Post("foo", 2) )

some_array.uniq_by(&:object_id) # same as some_array.uniq

exclude?

And the final one for today is exclude? which is the opposite of include?. Nobody likes the exclamation mark before predicate methods.

# yuck:
!some_array.include?(some_value)
# better:
some_array.exclude?(some_value)

And it also works on strings:

# even more yuck:
!"The quick fox".include?("quick") # => false
# better:
"The quick fox".exclude?("quick") # => false

The full release notes of Rails 3 can be read here.

This time it’s an old one: http_accept_language

• Splits the http-header into languages specified by the user
• Returns empty array if header is illformed.
• Corrects case to xx-XX
• Sorted by priority given, as much as possible.
• Gives you the most important language
• Gives compatible languages

For more information, read the README on GitHub.

Basic Usage

I was fed up with writing:

Post.all(:conditions => { :published => true },
  :select => :title, :include => :author)

So with BasicNamedScopes, you can now write:

Post.conditions(:published => true).select(:title).with(:author)

All named scopes are called the same, except for include, which is now called with, because include is a reserved method.

Reuse them by making class methods:

class Post < ActiveRecord::Base
  def self.published
    conditions(:published => true)
  end

  def self.visible
    conditions(:visible => true)
  end

  def self.index
    published.visible
  end
end

Also, the all-method is a named scope now, so you can chain after callling all, for greater flexibility.

Post.all.published

Arrays can be used as multple parameters too, sparing you some brackets.

Post.with(:author, :comments).conditions("name LIKE ?", query)

The read_only and lock scopes default to true, but can be adjusted.

Post.readonly         # => same as Post.all(:readonly => true)
Post.readonly(false)  # => same as Post.all(:readonly => false)

Why?

NamedScopes are really handy and they should play a more central theme in ActiveRecord. While I heard that Rails 3 will support similar syntax, there is no reason to wait any longer.

I find defining named scopes very ugly, especially when dealing with parameters. Just compare the amount of curly braces!

# Using normal named scope:
named_scope :name_like,
  lambda { |query| { :conditions => ["name LIKE ?", query] } }

# Using BasicNamedScopes
def self.name_like(query)
  conditions("name LIKE ?", query)
end

Also, regular named scopes don’t support using other named scopes at all!

I found myself implementing these named scopes (mostly conditions, but others too) so often, that a little gem like this would be the obvious choice. Use it if a gem like searchlogic is overkill for your needs.

Installing

The gem is called “basic_named_scopes”. You know how to install it.

gem install basic_named_scopes

Use it in Rails:

config.gem "basic_named_scopes"

I had figured that the supplied dutch keywords in languages.yml were not very practical. It supplied “Gegeven” as a naive translation of “Given“. Although this is correctly translated, it is very unpractical to form Dutch sentences with it. The only to really start a sentence with “Gegeven” is to write “Gegeven het feit dat…” (“Given the fact that…“). It’s very strange to say “Gegeven dat ik een profiel heb” (“Given I have a profile“) in Dutch.

I decided to use the synonym “Stel” like in “Stel ik heb een profiel“. Not entirely correct either because it misses a comma after “Stel“, but much better, in my honest opinion. So I forked cucumber, changed languages.yml and used this as custom git repository in my Gemfile.

Apparently I was in the middle of a Release Candidate, so what I had committed on github. The Rails integration was extracted out in that version (like RSpec does) to the “cucumber-rails” gem. This gave about an evening of confusion, but I got it to work eventually.

Two days later, we had visitors at our company, from another Ruby company, talking about cooperation on future projects. I introduced myself and he was trying to remember if he’d seen anything on the interwebs by me. That seems to be common. When meeting people on conferences it’s always the same question: “Do I know any of your gems?”.

Anyway, he had actually read my name recently, namely in the commit log of cucumber. Without asking or sending a pull request, they had added my commit to the 0.5 release of cucumber. A pleasant surprise! Aslak Hellesøy, you’re a very observant GitHub user!

By the way, you can still use “Gegeven“, as it is just an alias.

I am constantly wrestling with the best way write cucumber features down. Does anyone have Dutch features? Do you write them down with your customers or are they for developers only? Can you share some of them? Here are some of mine:

Scenario: Inloggen
  Stel ik ben uitgelogd
  En ik heb een account voor "gebruiker@test.com" met het wachtwoord "geheim"
  En ik ben op de inlogpagina
  Als ik de volgende velden invul:
    | E-mailadres | gebruiker@test.com  |
    | Wachtwoord  | geheim              |
  En ik op "Inloggen" druk
  Dan zie ik de melding "Je bent ingelogd"

Scenario: Verkeerd wachtwoord
  Stel ik ben uitgelogd
  En ik heb een account voor "gebruiker@test.com" met het wachtwoord "geheim"
  En ik ben op de inlogpagina
  Als ik de volgende velden invul:
    | E-mailadres | gebruiker@test.com  |
    | Wachtwoord  | verkeerd            |
  En ik op "Inloggen" druk
  Dan zie ik de foutmelding "Ongeldig e-mailadres of wachtwoord"

By the way, don’t forget to order the RSpec and Friends book. It’ll be released this februari and is a really good read if you want to learn BDD, RSpec or Cucumber.

This has been mentioned somewhere on some mailinglists, but to make it a bit more findable, I’d thought I’d post it here.

The solutionworkaround is to set the server protocol, like this:

    it "should show the pdf" do
      request.env["SERVER_PROTOCOL"] = "http"
      get :show, :id => "report", "format" => "pdf"
      response.should render_template(:show)
    end

I also do TDD, which means that I write a failing test first, and then program until it passes. But Autotest’s flow is that, once you’ve fixed a failing test or spec, it reruns the entire the suite to see if you’re solution doesn’t have any side effects. Normally this is fine, but with this kind of test suite, I cannot afford to wait for it to complete.

So, after going through Autotest’s code, I’ve decided to stub out this behavior. You can still trigger a complete rerun of the entire suite by pressing Ctrl+C, but it doesn’t do that every time you go green. It’s a bit of a monkey patch, but it works just right.

The autotest-growl gem clears the terminal. I don’t like that, because I like to see a bit of history. That’s why I changed that behavior too.

Here’s my ~/.autotest file:

# Use file system hooks on OS X
require 'autotest/fsevent'

# Don't run entire test suite when going from red to green
class Autotest
  def tainted
    false
  end
end

# Use Growl support
require 'autotest/growl'

# Don't clear the terminal, when using Growl
module Autotest::Growl
  @@clear_terminal = false
end

While browsing through the code of Autotest I also found that it also looks for a .autotest file in the current working directory. So if you want to apply these changes to one project only, you can define this file locally for the project. I didn’t know that!

Red -> Green -> Eat... eh... Refactor

What I have so far is:

• Automatic validations and relations
• Completely configurable, with sensible defaults
• A management interface
• Works with acts_as_list and supports drag and drop sorting
• I18n support

Let’s take a tour of it’s usage.

Install acts_as_list, if you want to:

./script/plugin install git://github.com/rails/acts_as_list.git

Install root_table:

./script/plugin install git://github.com/iain/root_table.git

Make a model that needs a list to choose from, like a product that has a category:

./script/genetate model Product name:string category_id:integer

Make a model for the root table, category:

./script/generate model Category name:string position:integer

Make category a root table for product:

class Category < ActiveRecord::Base
  root_table_for :product
end

And let the product model know as well what is happening:

class Product < ActiveRecord::Base
  has_root_table :category
end

Let’s add a configured root table for good measure. Let’s convert the User-model to a root table. User is not a list, and doesn’t have a name-field to recognize it, nor does it have a position field. It requires some options to make it work.

class User < ActiveRecord::Base
  root_table_for :product, :to => :last_edited_by,
      :validate => false, :field => :login
end

And update the product model again:

class Product < ActiveRecord::Base
  has_root_table :category
  has_root_table :user
end

The relation is called last_edited_by, it doesn’t add any validations and the displayed (and thus sorted) field is login instead of name. It doesn’t have position field, nor do I provide it, so it’ll sort on login and won’t be manually sortable, as we’ll se in a bit.

Using the User model might not be the best example, but you’ll get the point.

Management in a Rails Engine

Visit the management interface at http://localhost:3000/root_tables and see something like this:

Since User has no position field, you’ll end up with a simple scaffold-like management screen for it:

However, the Category model does have a position, so the interface has drag and drop functionality:

It has a very simple new and edit screen, just as you would with scaffold:

This is all done with a layout that Rails scaffold generates. If you have your own layout it might look completely different. The management pages are a Rails engine. This means that you can override any file by creating a file with the same name in your app-directory. Have a look at the code to see which files you can override.

Also, to enable the drag and drop interface, you’ll need to have prototype included. If you don’t want prototype be loaded everywhere, I’ve made it so that only drag and drop pages load the javascript. Please add <%= yield(:head) %> to your html header.

You can also override views on a table basis. That means that you might want a view that is different just in case of one table. The form for new users might want to have more fields than just the login field, but also include password fields. Create a view for that in app/views/root_table_contents/new_user.html.erb. Available for override per model are index, new and edit.

Using it elsewhere

But we’re not there yet. Now we’ve built a root table and filled it, we need to use it somewhere. The plugin provides a root_table_select helper, that renders a drop down. The first parameter is the root_tables (real) name, it figures the rest out automatically. You can pass any options as the options you would pass the other select helpers. Here’s an example:

<% form_for @product do |f| %>
  <p>
    <%= f.label :category_id %><br />
    <%= f.root_table_select :category, :include_blank => true %>
  </p>
<% end %>

Also for showing a delegate method is provided. This is how you can show the category name:

@product.category_name

That about wraps it up for root_table. Please provide me with feedback and report any bugs and improvements. You can use the comments on my blog, or the issues page on github.

Update!

I’ve made some tiny updates, most importantly reducing the amount of magic. Rails does a very nice job of lazy loading your models which can lead to some strange errors with the previous version of my plugin. These should be fixed now.

Lessons learned:

• A model does not know another model exist in development environment. Mentioning a model is enough to trigger Rails autoload and even constantizing a string works. Sweet!
• Don’t require a model again during a request. Some models will break. I found this to be the case with the session class needed by AuthLogic. Again, to know for sure that a model has been loaded, simply mention it in your code, usually that is enough.
• Tests are run in an environment very similar to production. I already knew that, but it’s worth mentioning that a stable development environment is also essential and you might not catch that with unit tests alone.

Rails.backtrace_cleaner.add_silencer { |line| line =~ /^\s*passenger/ }

Saves you scrolling through the endless backtraces passenger gives you for free

PS. A colleague tweeted this lovely backtrace of a spring with grails error. I say: backtrace cleaner FTW!

I like the method of using a named_scope and delegating to specified filters. This way, you can structure your filters properly and get clean URLs. Also, you can chain other named scopes to the filter.

If you find yourself making an administrative web application, with many tables and filters, here’s an example to make it a little more DRY.

Making a partial

First, make the filters a partial, in something like app/views/shared/_filters.html.haml.

%h3= t(model_name, :scope => :filter_titles)
%ul
  - model_class.available_filters.each do |filter|
    %li= link_to t(filter, :scope => [:filter_names, model_name]), url_for(params.merge(:filter => filter))

I’ve changed the translate-calls a bit, so they work with different models.

A helper method

Then, create a helper method:

def show_filters_for(model_name)
  render :partial => "shared/filters", :locals => { :model_name => model_name, :model_class => model_name.to_s.camilze.constantize }
end

Now you can render the filters like this:

= show_filters_for :person

And a module

On the model side, you can make a module, probably in lib/chainable_filters.rb.

module ChainableFilters

  def self.extended(model)
    model.named_scope :filter, lambda { |f| model.available_filters.include?(f) ? model.send("filter_#{f}") : {} }
  end

  def available_filters
    self.methods.select { |m| m =~ /^filter_/ }.map { |m| m[7..-1].to_sym }
  end

end

Use it in a specific model, by extending with the module you just made:

class Person < ActiveRecord::Base
  extend ChainableFilters
end

Or just every ActiveRecord class, by creating an initializer file (i.e. config/initializers/chainable_filters.rb):

ActiveRecord::Base.extend ChainableFilters

Now, that is some nice meta-programming, if you ask me!