Veerasundaravel's Ruby on Rails Weblog

October 10, 2012

Rails Caching With Query Parameters

Filed under: Caching, Rails3, Ruby On Rails — Tags: , , , , , , , , — Veerasundaravel @ 2:17 pm

Rails has various effective ways of caching contents like page caching, action caching, fragment caching etc. But some time we may need to use low level caching of Rails.cache in order to store some HTML fragments or some hash values etc that can be used some where else later on.

Rails.cache.write takes two value: key and a value
> Rails.cache.write 'foo', 'bar'
=> true

# We can read an object back with read
> 'foo'
=> "bar"

# We can store a complicated object as well
> hash = {:this => {:is => 'a hash'}}
> Rails.cache.write 'complicated-object', object
> 'complicated-object'
=> {:this=>{:is=>"a hash"}}

# We can use fetch as the combination of write and read.
Rails.cache.fetch 'complicated-object', object


Params as Cache Key:

Most of the Rails actions comes with multiple parameters, so when we cache any result inside the controller’s action we may need to assign the parameter values as cache key. So that we will get unique key combination for different action parameters.

Rails.cache.fetch(params.sort.flatten.join("_"), object)

Assume that the following params:

params = {:controller => 'books', :action => 'index', :status => 'stock-avail', :start_price => '$100'
, :end_price =>"$200", :delivery => 'by-post', :discount_start => "10%", :discount_ends => "20%",
 :language => 'english', :cover => 'available', :sort => "posted_date", :preface =>
 "available-on-request", :ebook => 'available-on-request'}

Then our cache key will become very unique for the supplied params as below:


But cache key should be less than 255 characters long to keep the file system happy. If cache key is greater than 255 chars, then it will throw an error like Errno::ENAMETOOLONG (File name too long) etc.


How to avoid too long cache key:

One of the best option to shorten the cache key would be, simply have the generated cache key run through a hash like MD5 or SHA1. This way we can get predictable cache key lengths.

Rails.cache.fetch(Digest::SHA1.hexdigest(params.sort.flatten.join("_")), object)

It will modify the cache key as follows:

Rails.cache.fetch('5c059024747e813d0fa5ec8fab890be473eab63a', object)

July 25, 2012

Rspec Shoulda-Matcher made Unit testing as easier one

Filed under: Rails3, Ruby, Ruby On Rails, Testing, Unit Test — Tags: , , , , , , — Veerasundaravel @ 12:37 am

Shoulda matcher is a library that enables to write better and more understandable tests for Rails application. It is Test::Unit- and RSpec-compatible one-liners that test common Rails functionality.

Here few very easier example of shoulda-matchers for Unit Testing.

Test model fields:

it {should have_db_column(:login)}
it {should have_db_column(:salary).of_type(:decimal).with_options(:precision => 10, :scale => 2) }
it { should_not have_db_column(:admin).of_type(:boolean) }

Test db indexes:

it { should have_db_index(:age) }
it { should have_db_index([:commentable_type, :commentable_id]) }
it { should have_db_index(:ssn).unique(true) }

Test validations:

it { should validate_uniqueness_of(:title) }
it { should validate_presence_of(:body).with_message(/Enter the message/) }
it { should validate_presence_of(:title) }
it { should validate_numericality_of(:user_id) }
it { should validate_uniqueness_of(:title) }
it { should_not allow_value("blah").for(:email) }
it { should allow_value("").for(:email) }
it { should ensure_inclusion_of(:age).in_range(1..100) }
it { should_not allow_mass_assignment_of(:password) }

Test associations:

it { should belong_to(:parent) }
it { should have_one(:car)
it { should have_many(:friends) }
it { should have_many(:enemies).through(:friends) }


Further reading:

Shoulda-Matcher home page –
Shoulda-context home page –
rspec_shoulda cheat sheet –


December 2, 2011

Change browser URL without reloading the page – jQuery – HTML5

Filed under: jQuery, Ruby On Rails — Tags: , , , , — Veerasundaravel @ 4:14 pm

The traditional way of changing the browser url is just adding hash to the end of current URL like window.location = “#q=test&sort=date”;

But if you want to change complete url like window.location = “/profile/show/1”; will redirect the user to that page but it will reload page. So how we can change browser URL with reloading  the page. The better solution is HTML5 History API. More ever the jQuery plugin History.js provides lot easier configuration and options to achieve this.


History.js gracefully supports the HTML5 History/State APIs (pushState, replaceState, onPopState) in all browsers. Including continued support for data, titles, replaceState. Supports jQuery, MooTools and Prototype. For HTML5 browsers this means that you can modify the URL directly, without needing to use hashes anymore. For HTML4 browsers it will revert back to using the old onhashchange functionality.

Download & Installation:

  1. Download History.js and upload it to your webserver. Download links: tar.gz or zip
  2. Include History.js
    • For jQueryv1.3+
      <script src=""></script>
    • For Mootoolsv1.3+
      <script src=""></script>
    • For Right.jsv2.2+
      <script src=""></script>
    • For Zeptov0.5+
      <script src=""></script>
    • For everything else
      <script src=""></script>

Note: If you want to only support HTML5 Browsers and not HTML4 Browsers (so no hash fallback support) then just change the /html4+html5/ part in the urls to just /html5/. Why supporting HTML4 browsers could be either good or bad based on my app’s use cases

Working with History.js:

once after including the javascript you can change the browser URL just by calling any one the js statement.

History.pushState({state:1}, “State 1”, “?state=1”); (or) History.replaceState({state:3}, “State 3”, “?state=3”)


    // Prepare
    var History = window.History; // Note: We are using a capital H instead of a lower h
    if ( !History.enabled ) {
         // History.js is disabled for this browser.
         // This is because we can optionally choose to support HTML4 browsers or not.
        return false;

    // Bind to StateChange Event
    History.Adapter.bind(window,'statechange',function(){ // Note: We are using statechange instead of popstate
        var State = History.getState(); // Note: We are using History.getState() instead of event.state
        History.log(, State.title, State.url);

    // Change our States
    History.pushState({state:1}, "State 1", "?state=1"); // logs {state:1}, "State 1", "?state=1"
    History.pushState({state:2}, "State 2", "?state=2"); // logs {state:2}, "State 2", "?state=2"
    History.replaceState({state:3}, "State 3", "?state=3"); // logs {state:3}, "State 3", "?state=3"
    History.pushState(null, null, "?state=4"); // logs {}, '', "?state=4"
    History.back(); // logs {state:3}, "State 3", "?state=3"
    History.back(); // logs {state:1}, "State 1", "?state=1"
    History.back(); // logs {}, "Home Page", "?"
    History.go(2); // logs {state:3}, "State 3", "?state=3"


How would the above operations look in a HTML5 Browser?


Note: These urls also work in HTML4 browsers and Search Engines. So no need for the hashbang (#!) fragment-identifier that google “recommends”.

How would they look in a HTML4 Browser?


For further detailed documentation and queries you can refer :

« Newer PostsOlder Posts »

%d bloggers like this: