In today’s blog post, I show you how to get a Ruby on Rails based commerce app up and running in ten minutes. We’ll be using the Heroku (think Rails cloud) as the hosting service and Spree as the commerce platform.

Prerequisites

The “10 minute” claim assumes you already have a Heroku account and that you have , Ruby, Rails 2.1.2 and Gems installed locally.

You will also need to have git installed and a public ssh key. If you’ve been doing Rails development on a Mac or other Unix type system this shouldn’t be new to you. If for some strange reason you haven’t started using git yet, you need to do yourself a favor and look into it.

Step 1. Grab the heroku and spree gems.

sudo gem install heroku
sudo gem install spree

Step 2. Create the store

Use the Spree gem to create the store locally

spree footore

You will need to pick a unique name for your store for heroku so don’t call it foostore since that is already taken.

Step 3. Place your store under git source control

Heroku uses git to manage its deployment. So put your new Spree app under source control.

cd footore
git init
git add .
git commit -m "First commit."

Step 4. Unpack Gems

Heroku doesn’t seem to want to use its own gem repository. No worries, just unpack the gems that Spree requires using

rake gems:unpack
git add vendor/gems
git commit -m "Unpacked gems."

Spree itself also needs to be unpacked

rake spree:freeze:gems
git add vendor/spree
git commit -m "Froze Spree 0.5.0"

Step 5. Tweak the Rails Version

Unfortunately Heroku only supports certain Rails versions and they tend to lag behind the latest. Spree requires Rails 2.1.2 but Heroku only works with Rails 2.1. So we just need to modify Spree to work with Rails 2.1 instead.

Edit config/boot.rb and replace

load_rails("2.1.2")

with

load_rails("2.1")

Now commit these changes

git add config/boot.rb
git commit -m "Switch to Rails 2.1

Step 6. Add the store to Heroku

heroku create foostore

The first time you add an app into Heroku it will ask you for the email address and password associated with your Heroku account. Interestingly, the heroku gem also copies your public ssh key up to heroku so that you can authenticate with your private key going forward.

Remember to choose a unique name for your store since apparently Heroku requires all applications to have a unique name (otherwise it will warn you that the name is already taken.)

Step 7. Push to Heroku

git remote add heroku git@heroku.com:foostore.git
git push -f heroku

Through the magic of Heroku, your application is now deployed! It takes a while to run the migrations but you should get there eventually.

The git remote add and -f stuff is a onetime deal. Going forward you can update with just git push.

Step 8. Make the store public

The store is now technically deployed on Heroku but its not yet publicly visible. Using your browser you need to log into your Heroku account.

Click the “settings” link and the select the radio button to make it public as well as the radio button at the bottom to run in the much faster “production” mode. Heroku has some interesting abilities to edit online but I’m a big fan of local development on Textmate so I have no use for the development mode.

That’s it. You can now hit your webapp at http://foostore.heroku.com. Be sure to login (username: admin password: spree) and change the default password to something more secure.

There are several intersting aspects of Heroku which I’ll save for another blog post. One interesting thing I’ll mention here is the ability to run rake commands on the remote server in your local shell.

Conclusion

Well now you have your online store up and it only took you ten minutes (or so.) Time to show it to your prospective client and lock down that contract! Best part is that this cost you nothing (at least for now while Heroku is still free.)

On a recent project I came up with a cool way to do paginating find with my resources. I was able to combine resource_controller with acts_as_xapian for very DRY searching.

I simply override the collection method in the index view and I can then display a list of requests, eighteen per page, that are sorted by spec.

class RequestsController < ResourceController::Base
  include SearchableResource
  ...
  private
  def collection
    search_collection(:spec, {}, size=18)
  end
end

The bulk of the interesting code is in the SearchableResource module that is included by all of the controllers that need searching.

# Adds a collection method to a resource controller that
# is suitable for collections that can be optionally searched
module SearchableResource
  def self.included(base)
    base.class_eval {
      def clazz
        object_name.camelize.constantize
      end

      def filter_criteria
        return "" unless @search_filter
        return " #{@search_filter.query}"
      end

      def search_collection(order_by, find_options = {}, page_size=6)
        @search = params[:q] ||= ""
        @query = @search + filter_criteria
        if @query.blank?
          session[:query] = nil
          options = {:order => order_by, :page => {:size => page_size, :current =>params[:p], :first => 1}}
          options.merge!(find_options)
          @collection ||= end_of_association_chain.find(:all, options)
          @collection.sort
        else
          session[:query] = @query
          current_page = params[:p].to_i if params[:p]
          current_page ||= 1
          hits = ActsAsXapian::Search.new [clazz], @query, :limit => 1
          @collection = PagingEnumerator.new(page_size, hits.matches_estimated, false, current_page, 1) do |page|
            offset = (current_page -1) * page_size
            hits = ActsAsXapian::Search.new clazz, @query, :limit => page_size, :offset => offset
            # pull the models out of the results
            collection = []
            hits.results.each do |hit|
              collection << hit[:model]
            end
            collection.sort
          end
        end
      end
    }
  end
end

The only other trick is to modify resource_controller so that you can use the url helpers with parameters. This allows a single partial for the pagination that takes the search query as a parameter. But that’s a subject for another post.

I’m currently using Xapian for a client project and I needed to get the list of search terms for a given model. The idea was to present the user with a tool tip type window listing the possible valid search terms. Since the search bar was actually a parital and used for many different models, I wanted to dynamically discover the relevant search terms.

Here’s the simple way to get an array of the human readable search terms for the Project model:

Project.xapian_options[:terms].collect { |term| term[2] }

Since I was also using resource_controller, I was able to DRY this up nicely.

def search_terms
  clazz = model_name.camelize.constantize
  terms = clazz.xapian_options[:terms].collect { |term| term[2] }
  terms.sort
end