semanticart blog

How do you handle Page titles in Rails? I use SmartMeta

2010-02-06T00:00:00-06:00

How do you handle Page titles in Rails? I’ve tried a few different methods over the years. I could never really settle on where I thought the data should go. I’ve set instance variables in controllers, I’ve set instance variables in views, I’ve used content_for in views… etc.

Once Rails implemented I18n support and starting using locale files, I finally felt like I’d found a good place to put this data. I started doing things like this:

en:
  default:
    title: "My default title"
  users:
    index: "My Awesome User index"
    show: "{{name}}'s page!"

And the nice thing is that since you’re already putting all this in the locale files, internationalization is easy. I’d then use something in my views like:

<% content_for(:html_title, t('users.show', :name => @user.name)) %>

and something like

<title><%= yield(:html_title) || t('default.title') %></title>

in my layouts.

It worked out pretty well, but the translations are dumb. I ended up having to specify several cases in my locale file dependent upon how the controller actions were used. If my action was nested, I might want my page title to reflect that. The YAML locale file didn’t really allow for this easily so I used some conditional logic in my helpers.

This approach worked but it wasn’t pretty. There was also a lot of redundancy.

SmartMeta

Now I’m using SmartMeta, a plugin that is just a simple extraction of my most recent pattern. There are other plugins out there that assist in storing titles in YAML, but with SmartMeta your translation entries can access your instance variables and your methods.

As an example, you can do things like:

en:
  users:
    show:
      title: "{{@user.name}} has {{@user.hair.color}} hair"
      description: "{{@user.name}}'s page on my site"
      keywords: "user, {{@user.name}}, {{page_keywords}}, etc. etc."

and

<title><%= yield(:html_title) || smart_title || t('default.title') %></title>

I’m making use of the @user variable. You can send message after message – in the title, we’re going through the user association “hair” to get the color. In keywords, I’m using a page_keywords method which I can define in UsersHelper or ApplicationHelper. I make use of such methods to handle logic considering nesting, etc.

The benefits of this approach is that you can keep all your titles and other metadata in your locale files and out of your views without sacrificing the accessibility of your instance variables.

This isn’t a catch all solution and I’ll still have to use content_for in places to specify alternate titles… but it works well enough that I thought it would be worth sharing.

Back to the question: How do you handle page titles in Rails?

Killing is_paranoid

2009-10-13T00:00:00-05:00

Intro

In short, I’m killing is_paranoid. It’ll still exist as a github repo (mostly as an example of hack-ery and buffoon-ery) and you’re still welcome to use it if you insist. However, I’m no longer going to support it or continue development on it. I’m sorry to anyone this affects.

Why

I created is_paranoid as an example of using “default_scope” to simulate acts_as_paranoid. It was a proof-of-concept and a toy that caught on for whatever reason. I liked it because the original version was ridiculously simple to grok and it was a fun example of the power of default_scope.

But over time, I found out that default scope isn’t as default as I had thought, and is_paranoid became a pile of hacks upon hacks to overcome unexpected behaviors in ActiveRecord and unexpected, complicated use-cases. It became a pain and a mess.

A few examples of the train-wreck

About default_scope not being default-enough for is_paranoid: Imagine you have a product model with a default scope that specifies that only products with in_stock = true should be selected (we don’t want to show out-of-stock products by default). Cool, that works on simple finds. Now let’s imagine we have categories which have many products. Category.find(:first, :include => :products) works, but it doesn’t respect the default_scope on the eager-loading of products so you get out-of-stock items. This applies to all relationships that are eager-loaded, not just has_many. It also isn’t respected on has_many :through relationships (eager-loaded or otherwise). It also probably isn’t respected in a few other places I can’t recall offhand.

Don’t get me wrong, I’m not claiming ActiveRecord or default_scope should be implemented differently or that I could do it better. It just turns out that even though you can implement a rudimentary soft-deletion with default_scope I don’t think you should do it. The problem wasn’t ActiveRecord, the problem was how I was using default_scope. It just doesn’t hold up long-term.

Another issue is that once a scope is applied (default, named, otherwise), it isn’t possible to easily subtract that scope. is_paranoid used with_exclusive_scope to find soft-deleted items, but with_exclusive_scope makes things like Person.female.with_destroyed break since with_exclusive_scope undoes the female scope. There’s no obvious easy way to just pop out the is_paranoid scope and leave the other scopes.

And you can overcome these things (and you can surely do it more cleanly than I did), but it will always be a hack because in the end you’re trying to make ActiveRecord behave differently than it wants to in several different places.

Moving on…

More than just is_paranoid becoming hacky, I’m also subscribing to Rick Olson’s reason for not using acts_as_paranoid anymore (even though he’s the author). This is a sentiment echoed by Ben Johnson in his post about discontinuing Resourcelogic. Simply put, you lose intent by relying on magic. It makes a lot more sense to just be explicit about things using named_scopes or something similar.

I’m biting the hand that feeds me to an extent here since is_paranoid has been my most popular open source project. But I’d rather not be known than be known for something I don’t believe in.

Remember that just because you can do something doesn’t mean you should.

I wouldn’t recommend using is_paranoid unless you want to fight with it. And make sure you write a lot of tests :/

I do want to thank the people who reported bugs and contributed solutions to is_paranoid. I genuinely appreciate it.

Well, now that I’ve sufficiently bummed myself out, I’m going to go back to hacking (the good kind, heh) on a fun little project that should be announced here in a day or two. Ob-la-di, ob-la-da, right?

Using default_scope to recreate acts_as_paranoid

2009-03-22T00:00:00-05:00

Intro

Rails 2.3 gives us “default_scope” which was described by Ryan Daigle as allowing you to “specify default ordering, and other scopes, in edge rails directly in your ActiveRecord model.” Ryan’s post gives some good examples of when you might want to use this (specifically on models where you always want them sorted in a specific manner). In the comments of that post, Ryan Bates suggests that this might be useful for “simulating destroying a model (like acts_as_paranoid).” Indeed this is possible and the idea of using scoping to create this is both present in acts_as_paranoid itself and also has been brought up before.

In this article I’m going to reinvent the wheel using default_scope to illustrate how powerful default_scope is and how trivial it makes this task. You can keep track of the finished product in my is_paranoid gem.

Getting started

The syntax for declaring a default_scope is simple. Here’s what Ryan D. uses in his article:

class Article < ActiveRecord::Base

  default_scope :order => 'created_at DESC'

end

To break this down, every time we use ActiveRecord to query our database, it will add the “created_at DESC” order to our query. Here’s a sidebar word of warning about default_scope: That’s every query, so you’re incurring some unnecessary overhead if you haphazardly set default scopes when you don’t really need them. As a trivial example, the show action on our articles controller doesn’t need to sort the articles by created_at since it should only be finding one article anyway.

If you’re unfamiliar with acts_as_paranoid, it allows “you to hide and restore records without actually deleting them.” The plugin uses a timestamp field on your table to specify whether an item should count as deleted or not; if the deleted_at timestamp is nil, it is not deleted, if the timestamp is not nil, it is deleted. The migration for articles with our deleted_at column looks like this:

class CreateArticles < ActiveRecord::Migration

  def self.up

    create_table :articles do |t|

      t.string :name

      t.text :body

      t.timestamp :deleted_at, :default => nil

      t.timestamps

    end

  end



  def self.down

    drop_table :articles

  end

end

And our default scope should look like:

class Article < ActiveRecord::Base  

  default_scope :conditions => {:deleted_at => nil}

end

Now in script/console if you do Article.first, you can see the effects in your log: "SELECT * FROM “articles” WHERE (“articles”.“deleted_at” IS NULL) LIMIT 1"

We’ll need to redefine destroy if we want it to mark an item deleted instead of actually deleting it.

class Article < ActiveRecord::Base  

  default_scope :conditions => {:deleted_at => nil}



  def destroy

    self.update_attribute(:deleted_at, Time.now.utc)

  end

end

Let’s give it a spin:

>> a = Article.create(:name => "Test Article", :body => "some body")

=> #<Article id: 3, name: "Test Article", body: "some body", deleted_at: nil, created_at: "2009-03-22 16:08:00", updated_at: "2009-03-22 16:08:00">

>> a.destroy

=> true

>> Article.first

=> nil

But the log shows it actually just did "UPDATE “articles” SET “updated_at” = ‘2009-03-22 16:08:02’, “deleted_at” = ‘2009-03-22 16:08:02’ WHERE “id” = 3" so our article is still there, we simply can’t find it because of our default_scope.

Sadly there’s something we’ve broken already, though. Because we redefined destroy, we can’t use our destroy callbacks, like before_destroy, anymore. We can fix that by changing the way we implement destroy. You should check out lib/is_paranoid.rb in the repo to see how this is implemented. Let’s move on.

Now we need to add a method to help us find things that have been marked deleted. To do that, we’ll need to bypass our default_scope by using with_exclusive_scope.

def self.find_with_destroyed *args

  self.with_exclusive_scope { find(*args) }

end

Essentially this takes whatever arguments you provide as finder conditions (and/or order, includes, etc.) and passes them to the find method after first specifying that we should ignore the default_scope. Now we can find our destroyed items as well as our non-destroyed items.

>> Article.find_with_destroyed(:first)

=> #<Article id: 3, name: "Test Article", body: "some body", deleted_at: "2009-03-22 16:08:02", created_at: "2009-03-22 16:08:00", updated_at: "2009-03-22 16:08:02">

There’s still a few features to add, like count_with_destroyed and a restore method, but this should give you a good intro to the power of default_scope. Both those features are added in the current version of is_paranoid and we’re still sitting on less than 40 actual lines of code to accomplish the core functionality of acts_as_paranoid.

Why you might not want to use default_scope

There’s the previously mentioned overhead incurred with applying order or conditions to every interaction ActiveRecord has with your database, but beyond that, some people in the community feel that overriding find methods can add unnecessary complexity to your code and make debugging more complicated. In fact, Rick Olson, the author of acts_as_paranoid, no longer uses AAP in favor of hidden and visible named scopes on his models.

Granted, it is more readily apparent that you’re in a named scope since they’re explicitly called, but if you have a good number of models that you want to be able to soft-delete or hide, then it seems that declaring those scopes on each model isn’t very DRY. I’d wager most people end up using a mixin to prevent repetition. I don’t feel that using default_scope in a manner such as this is far beyond simply DRYing things up.

Besides, anyone should be able to easily grok the code in is_paranoid, as brief and simple as it is. Ultimately it comes down to personal preference. As always, makes sure you know your toolset.

In praise of ActiveRecord (rat-hole)

As a quick rat-hole, ActiveRecord implements destroy and delete_all fantastically. Basically Model.destroy and Model.destroy_all both internally call instance.destroy and Model.delete and instance.delete both internally call Model.destroy_all. Because of this, you only have to redefine delete and destroy once for them to take effect across the other methods. Awesome.

In closing

If you’re looking for a light-weight acts_as_paranoid replacement and you’re on Rails 2.3+ then give is_paranoid a look. The readme should give a decent overview, but beyond that, check out the specs and read the source.

I want to keep is_paranoid light-weight, but if anything important is missing or if you uncover any bugs, please let me know.

Comparing Thinking Sphinx And Acts As Ferret For Full Text Indexing In Rails

2009-03-05T00:00:00-06:00

This will by no means be an exhaustive list of differences between using Sphinx and using Ferret, but we’ll look at a few major differences between the way these two search engines are implemented via acts_as_ferret (AAF) and Thinking Sphinx (TS).

Active Development

First thing is first, TS is in much more active development. At the time of writing, TS last had a commit to the offical repo 13 days ago in comparison with three months ago for AAF. And it shows. acts_as_ferret discussion these days is minimal online and most of the tutorials are rather old. Meanwhile, Thinking Sphinx has a very active google group and several more recent tutorials including a fairly recent Railscast.

So Thinking Sphinx wins in terms of active development.

Speed, Reliability, and Resources

Another place TS blows AAF out of the water is in speed and resource usage. Sphinx uses kilobytes of memory where a ferret daemon will sit on megabytes, having to load your entire Rails app into memory. For example, on my machine, the Sphinx daemon sat at 376 KB while my ferret process ate 57.69 MB. Not kidding.

Ezra Zygmuntowicz said

Ferret is unstable in production. Segfaults, corrupted indexes

galore. We’ve switched around 40 clients form ferret to sphinx and

solved their problems this way. I will never use ferret again after

all the problems I have seen it cause peoples production apps.

Plus sphinx can reindex many many times faster then ferret and uses less cpu and memory as well.

Anecdotally, that’s my experience as well. Thinking Sphinx can index my database in less than a minute, while acts_as_ferret can take up to 30 minutes or more.

The Level of Interaction with Rails

Simply put, acts_as_ferret obeys ActiveRecord, while Thinking Sphinx goes low-level.

In his Thinking Sphinx Peepcode PDF, Pat Allen writes “For those familiar with Ferret, Sphinx is quite similar, except that Sphinx talks directly to database servers – both MySQL and PostgreSQL – to obtain the data to index.”

This is largely what gives Sphinx its speed advantage, but it also makes Thinking Sphinx dumb as far as your ActiveRecord models are concerned.

For instance, this means that TS isn’t aware of your acts_as_paranoid models until you add the deleted_at conditional to your define_index block.

define_index do

  indexes [:body, :title]

  where ['deleted_at is NULL']

end

This also means that TS can’t index computed values as easily. In AAF you can index methods on your object, so you could index a method like the following

def ordinalized_names_of_children

  ordinalized_children = []

  self.children.sort_by(&:birth_date).each_with_index do |child, i|

    ordinalized_children << [child.first_name, i.to_ordinal]

  end

  ordinalized_children

end

This is a silly example, but to accomplish the same with TS you need to use db-specific string transformations and add all your conditional logic to the query as well. And you can easily imagine more complicated examples. Where with AAF you have the entire landscape of Ruby to use and abuse and you’re instantly inheriting the constraints of ActiveRecord, with TS you’re limited to what can be done solely on the database level. Luckily this is usually enough.

Indexing Changes to Your Models

As far as ease of handling updates goes, acts_as_ferret has a big initial advantage. From Gregg Pollack

the index gets modified every time you add/edit/remove the ActiveRecord model it’s associated with. You never have to worry about doing this yourself, it happens automatically, so your search index is always 100% accurate. No rebuilding needed.

With Thinking Sphinx, you need to specify something called delta indexes on the models you want to keep up-to-date for searches between index rebuilds. This is a little more intrusive than AAF’s approach since you also have to add a field to your table called “delta” to track what has updated… but a single boolean field doesn’t incur much overhead. You’ll still need to periodically rebuild your indexes regularly as the delta indexes can slow things down over time.

In both AAF and TS, deleted models are immediately removed from the index.

To sum up the differences:

AAF requires less work on your part to keep an accurate running index, but the overhead involved in updating the index on each record update can be painfully slow over time.

TS requires more work to specify delta indexes and requires you to add a column to your database, but provides you with options on how often incorporate the changes so that you’re not waiting on a change to be indexed on every model save.

From my experience, very few model updates need to be instantly available for search, and both approaches have their pros and cons. Though it requires slightly more work on your part, I feel TS puts more control in your hands.

The Overall Winner

The winner here is obviously Thinking Sphinx. You use less resources and get better speed, reliability, and the future looks a lot more sure for support. Sure, you may have to get your hands a little dirtier with some SQL, but the benefits more than make up for it.

Also (and I get nothing out of this), you should buy the Peepcode PDF as it will give you a huge head start on Thinking Sphinx.

An aside on Sphinx’s Treating of Primary Keys

There’s another thing Ferret can do that Sphinx cannot. As Section 3.5 of the Sphinx documentation states, “ALL DOCUMENT IDS MUST BE UNIQUE UNSIGNED NON-ZERO INTEGER NUMBERS (32-BIT OR 64-BIT, DEPENDING ON BUILD TIME SETTINGS).” And Thinking Sphinx enforces this in its config file by performing math on your table’s id column to help create unique sphinx index ids.

99 times out of 100 this is fine since most tables just have auto-incremented integer ids anyway, but what if you have tables with ids of significant value? That’s the situation I found myself in when adopting Thinking Sphinx on my current project. We have a ton of external data coming in and much of that data already has a GUID so we decided early on to use the GUID as a primary key and foreign key as that would allow us to later recreate any table without having to worry about the foreign key integrity issues that can sometimes be a taxing side-effect of using auto-incremented ids.

My first approach to overcoming this limitation was to add an auto-incremented column named “id” to the table and then make use of set_primary_key in Rails. Unfortunately, once you do that, Thinking Sphinx tries to call that primary key you specified. So Thinking Sphinx had to be patched. Essentially, I added a method set_sphinx_primary_key to allow you to specify a primary key that TS should use regardless of what the ActiveRecord model specifies as its primary key.

So in the example:

class Robot < ActiveRecord::Base

  # The key ActiveRecord will use on joins, map to id, etc.

  # Setting the primary key isn't necessary for set_sphinx_primary_key to work

  set_primary_key :internal_id



  # The key sphinx will use for indexing, must be a unique integer

  set_sphinx_primary_key :alternate_primary_key



  define_index do

    indexes :name

  end

end

ActiveRecord will use the field internal_id on the “robots” table (the set_primary_key could just as well be left out and ActiveRecord would use the default “id”). But while ActiveRecord uses internal_id, Thinking Sphinx will instead use alternate_primary_key. So our robots can internally use a GUID string while Sphinx is still provided with the integer column it needs to index the robots.

You can find these updates in my github branch of Thinking Sphinx. I have no idea if Pat will ever merge these into the main repo, as it is admittedly a niche need. But if you find yourself in the situation I found myself in, it can really help you overcome this limitation of Sphinx.

Update: Due to popular (or at least some) demand, my changes are merged into the Thinking Sphinx master branch. Enjoy.

CsvMapper gets a little more magical

2009-02-06T00:00:00-06:00

Have you checked out CsvMapper by Luke Pillow? It makes some of the drudgery of CSV parsing fade away. It really is a fantastic library. As an example from the doc:

Given the csv


First Name,Last Name,Age

John,Doe,27

Jane,Doe,26

Bat,Man,52

...etc...

you can do

include CsvMapper



results = import('/path/to/file.csv') do

  start_at_row 1

  [first_name, last_name, age]

end



results.first.first_name  # John

results.first.last_name   # Doe

results.first.age         # 27

Cool, right? There’s a lot of magic built in, but I felt there was an extra-mile left to go… By default CsvMapper requires you to specify the columns you want. Most of the time you want to do this, but it doesn’t really feel DRY in cases where the column names are made redundant by matching those on the first line of the file. And its a pain to reproduce column names when there are many, many fields. So, presto:

include CsvMapper



results = import('/path/to/file.csv') do

  read_attributes_from_file

end



results.first.first_name  # John

results.first.last_name   # Doe

results.first.age         # 27

Sweet, you say, but what if my field names are something absurd and clunky? Fine, say I, just specify an alias for them.

results = import('/path/to/file.csv') do

  read_attributes_from_file('First Name' => 'what_my_friends_call_me')

end



results.first.what_my_friends_call_me  # John

What about more realistic example with a bigger csv file? OK, here’s one from Subsidyscope:

results = import('subsidyscope-tarp.csv'){read_attributes_from_file}

results.first  # <OpenStruct type_of_institution="holding company", city="New York", 

               # description="Preferred Stock w/Warrants", 

               # total_assets="1856207282000.00", date="2008-10-28", 

               # fdic_number="1039502", ots_number=nil, transaction_type="Purchase",

               # price_paid="25000000000.00", state="NY", 

               # name="JPMorgan Chase & Co.", stock_symbol="JPM",

               # pricing_mechanism="Par", regulator="Federal Reserve">

We didn’t have to define a single attribute name; the csv file did it for us.

Ok, I’m sold, you say. Where can I get this? Try my CsvMapper github fork until it maybe gets merged into the official branch.

Ruby Idioms from Open Source, Volume One - Seinfeld

2008-11-29T00:00:00-06:00

This is the first in what I hope to be a series of articles looking at different open source projects and pulling out various ruby idioms.

We’re looking at Seinfeld which powers Calendar About Nothing. If you haven’t signed up yet, you should definitely do so. It is a fantastic way of keeping yourself motivated and contributing.

String Substitution

You can find the first bit of interesting code at line 37¹ of seinfeld_calendar.rb in the page_title method:

def page_title

  "%s's Calendar" % @user.login

end

Here we see String formatting substitution. You could also do sprintf(“%s’s Calendar”, @user.login), but why would you? Use an array if you have more than one value for substitution.

Date Manipulation

now        = Date.new(params[:year], params[:month])

prev_month = now << 1

next_month = now >> 1

Around line 58 of seinfeld_calendar.rb, we see that for the calendar’s next and previous month links to work properly, Seinfeld uses the << and >> methods which are described to

Return a new Date object that is n months earlier/later than the current one.

These methods were new to me, but they’re easy enough to remember if you think of them as looking like fast-forward and rewind.

Determining if a string is empty… wait, what?

Line 120 of /lib/seinfeld/models.rb gives us

  return if login_name.size.zero?

Which looks nice, but one can’t help but wonder why they didn’t use login_name.empty? instead. My benchmarks show .empty? to be trivially faster, but I may be missing something. Any ideas? My money is on it simply being the author’s preferred idiom. I think .size.zero? may be more readable, but I’ll stick with .empty? for the near future.

If you like learning by examining good examples of ruby code, I highly recommend David A. Black’s Ruby for Rails: Ruby Techniques for Rails Developers

If you have any suggestions for a future project to look at, please let me know.

¹ Because projects are always changing these line numbers are just provided as-is at the time of writing.

Driving Sinatra Without A Browser

2008-11-28T00:00:00-06:00

Intro

I’ve been hacking on leethal’s stuff-site (the software that runs this blog) recently and adding a good number of features to my fork. One item I recently added is pushing everything out to a static version of the site. This allows you to run the app on any hosting and bypass Sinatra altogether on the host side. To borrow the motto from merb, “no code is faster than no code.” I’m not using anything that has to be dynamic, so let’s remove all the moving parts and just use the Sinatra part for development and testing.

There are a plethora of ways to make static sites. I didn’t want to rely on outside resources like wget or curl and I wanted to avoid using any html parsing/spidering if possible. Since this is a very simple app with only 4 types of pages (index, rss, article, topic), it made sense to borrow from whatever magic Sinatra’s specs are using to make test requests and throw the task in the Rakefile.

Let’s do this already

Sinatra’s rspec suite provides get_it, post_it, etc. methods, so we first search for where these methods are defined and see if we can piggyback off of whatever process they use. You can find them (as of this publication) on line 35 of /lib/sinatra/test/methods.rb but the lines we really care about are 36 and 56

@request = Rack::MockRequest.new(Sinatra.build_application)

# ...

@response = @request.request(http_method, path, opts)

So let’s try this¹

@request = Rack::MockRequest.new(Sinatra.application)

puts @request.request('get', '/').inspect

yields


#<Rack::MockResponse:0x1031f28 @body="(...)", 

@errors="- - - [28/Nov/2008 12:29:02] \"get / \" 200 1511 0.0034\n",

@original_headers={"Content-Type"=>"text/html"},

@headers={"Content-Type"=>"text/html"}, @status=200>

We really only care about the response body. To dump out the index of our site, we just use

File.open(File.join(static_dir, 'index.html'), 'w') do |f|

  f.print @request.request('get', '/').body

end

Then we continue with this process for each section of the site we want to make static. Now uploading new content is as easy as running our rake task and then using rsync.

Obviously you can set up your webserver to serve static content when it is available and then fall back on Sinatra when the static content isn’t present.

You can see the full code in the rake file of my repository or check out an archived gist version.

Nice, what’s actually happening here?

Sinatra is a DSL built upon Rack, so we simply leverage Rack’s built-in methods to drive our web app without ever touching the browser.

From the documentation for Rack:MockRequest

Rack::MockRequest helps testing your Rack application without actually using HTTP.

Note that it is the HTTP part of the request that is being mocked here. Your app is receiving the request in the same way that it would if the request were triggered from the browser.

¹ : though the test/methods.rb isn’t updated as of publication of this article, Sinatra.build_application is deprecated and it is now recommended you use Sinatra.application instead