Railsdog Blog

Deploying Spree on Heroku

2011-06-20T18:00:00-04:00

People are often asking us about how to install Spree on the popular Heroku service. For those of you who don't know what Heroku is, its a popular cloud-based hosting choice for Rails applications. The reason why people have a lot of questions about Heroku specifically is due to the unique design of the Heroku platform which presents a few constraints not found in a typical Rails hosting environment.

Assumptions

This is not a how-to guide for Rails applications in general. So lets start off with a few assumptions about your system. You can easily Google for some additional information if you do not have the following installed on your system:

Ruby
ImageMagick
Git
Rubygems
bundler gem
heroku gem

ImageMagick is not strictly necessary - it is only needed if you plan to upload new pictures for your products. It is also installed by default on Heroku so it will only be a limitation for you in terms of testing the product image upload locally.

Amazon S3 Account

The primary limitation of Heroku is that it contains a read-only filesystem. This means that you cannot simply upload images to the server for your products. The images need to be stored on a third-party service such as Amazon's Simplified Storage System (S3). We will save the details for configuring Spree to work with S3 for a separate blog post. For now we'll just be satisfied to deploy a basic Spree store.

Creating a Basic Spree Application

We'll start by creating a basic Rails application.

$ rails new spree_demo
$ cd spree_demo
$ bundle install
$ git init
$ git add .
$ git commit -m "First commit"

Now we'll add the Spree gem by editing the Gemfile in the spree_demo application as follows:


gem 'spree'

Once this is done we can install the necessary migrations, etc.

$ rails g spree:site
$ rake spree:install
$ rake spree_sample:install
$ rake db:bootstrap

Now we'll do another git commit to save our progress.

$ git add .
$ git commit -m "Added Spree"

Heroku Code Tweaks

Now comes the stuff that is specfic to Heroku. We'll start by editing edit config/environments/production.rb as follows:


config.action_controller.perform_caching = false

This tells Rails that the stylesheets and javascript stuff should not be cached in the read-only filesystem (which is not possible on Heroku.) Once again we perform a git commit to save our progress.

$ git add .
$ git commit -m "Heroku tweaks"

Creating the Heroku App

Its pretty simple to create a new Heroku application from an existing Rails application already under source control with Git.

NOTE: The following example uses an application name of heroku-spree. Each Heroku application needs a unique name so you will have to choose your a name that is not already in use.

$ heroku create heroku-spree
Creating heroku-spree....... done
http://heroku-spree.heroku.com/ | git@heroku.com:heroku-spree.git
Git remote heroku added

Now we'll deploy the Heroku application:

$ git push heroku master
heroku db:push
heroku restart

Heroku Configuration

Spree requires SSL for checkout in production mode (and this is the default mode for Heroku applications.) So we'll use the Heroku gem to configure a simple wildcard SSL certificate. We'll also enable the Sendgrid add-on to send emails.

$ heroku addons:add piggyback_ssl
$ heroku addons:add sendgrid:free

These are free add on services for testing purposes. You will need your own SSL certificate eventually when you deploy to production.

Spree Configuration

You should now be up and running on Heroku! The final step is to configure Spree itself so that you can do a complete checkout. To do this, just log into the admin interface and create a production payment method that uses the Gateway::Bogus gateway. For more information on configuring a payment method see the official Spree documentation.

Adding filter_parameters in an Engine

2011-06-04T18:00:00-04:00

Rails applications by default will log every parameter that is passed to a given controller. Normally this is desirable behavior but in the case of sensitive information (ex. passwords and credit card numbers) you should never log these values.

The recommended approach for this is to add a filter_parameters directive in your application configuration as shown below.


module SampleApp
  class Application < Rails::Application
    # Filter sensitive parameters from the log file.
    config.filter_parameters += [:password]
  end
end

But what if you are working within the context of a Rails Engine? For instance, in the Spree application there is an engine that has a controller responsible for posting credit card information (over SSL of course.) After a little bit of digging I came up with the following solution:


module SpreeCore
  class Engine < Rails::Engine
    # filter sensitive information during logging
    initializer "spree.params.filter" do |app|
      app.config.filter_parameters += [:number]
    end
  end
end

It turns out you can dynamically declare an initializer in your Railtie and then just add the filter there.

Callbacks in jQuery-ujs in Rails 3

2011-02-28T17:00:00-05:00

Deleting a record using ajax

The rails scaffold produces following code for deleting a record.

  
<%= link_to 'Destroy', user,  :confirm => 'Are you sure?',
                              :method => :delete %>

I want to delete the record using Ajax so that the whole page is not reloaded after every single delete. Since I use jQuery, I would add following line to my Gemfile.

  
gem 'jquery-rails', '>= 0.2.6'

And then I would run

  
rails generate jquery:install

Now I am all set. Howeer if I click "Destroy" then record is getting destroyed but the browser version is not being removed. Let's fix that.

First thing I need to do is to respond_to "ajax" requets in destroy action. After changing the controller the method looks like this.

  
def destroy
  @user = User.find(params[:id])
  @user.destroy
  respond_to do |format|
    format.html { redirect_to(users_url) }
    format.js { render :text => "alert('user has been deleted')" }
  end
end

And in application.js I would add just one line.

  
$('a[data-method="delete"]').live('ajax:success', function(){});

Then index.html.erb will look like this.

  
<%= link_to 'Destroy', user,  :confirm => 'Are you sure?',
                              :method => :delete,
                              :remote => true
%>

Now when you delete a user, the user record will be deleted using ajax and an alert will come up with the message user has been deleted.

Deleting record using JSON data-type

JSON is the currency of communication in JavaScript world. So let's say that I want ajax request to respond with the name of the user who is being deleted and then I would construct the message on the client. Changed code would look like this.

  
    def destroy
      @user = User.find(params[:id])
      @user.destroy
      respond_to do |format|
        format.html { redirect_to(users_url) }
        format.js { render :json => {:name => 'John'} }
      end
    end

And in application.js I would have following lines.

  
$('a[data-method="delete"]').live('ajax:success',
  function(data, textStatus, jqXHR){
    alert(data.name + ' has been deleted');
  });

Then index.html.erb will look like this.

  
<%= link_to 'Destroy', user,  :confirm => 'Are you sure?',
                              :method => :delete,
                              :remote => true,
                              'data-type' => 'json' %>

Now when you delete a user, you will get the message undefined has been deleted. What's going wrong.

Notice that the function that is invoked when ajax:success callbacks happen has three parameters. The order of the parameters matches with the order of the paramers in jQuery ajax call for success.

In order to solve the problem you need to know how rails.js invokes the callbacks. The relevant code in rails.js is

  
element.trigger('ajax:success', [data, status, xhr]);

When trigger is used then the very first parameter passed is the event object. The function that is invoked will get the event object as the first parameter and then rest of the parameters are passed. This is just the way trigger works in jQuery.

Based on that information the JavaScript code should be changed to following in application.js .

  
$('a[data-method="delete"]').live('ajax:success',
  function(e, data, textStatus, jqXHR){
    alert(data.name + ' has been deleted');
  }
);

You can follow this issue to see a real world example of this topic.

Cucumber Testing Tips

2011-02-22T17:00:00-05:00

Here are some of the testing related tips I use while working on Spree.

Stop in rails console if something fails in cucumber test

If a cucumber test fails then one of the first things I check for is the state of current data. In order to do that I used to put debugger statements. I still use this technique but here is a much better approach.

Create a file called stop.rb and put this file at features/support/stop.rb.

The contents of stop.rb are as follows:

  
    # Usage:
    #  @wip @stop
    #  Scenario: change password
    #    ........................
    # $ cucumber -p wip
    After do |scenario|
      if scenario.failed? && scenario.source_tag_names.include?("@wip") && scenario.source_tag_names.include?("@stop")
        puts "Scenario failed. You are in rails console becuase of @stop. Type exit when you are done"
        require 'irb'
        require 'irb/completion'
        ARGV.clear
        IRB.start
      end
    end

At the end of features/support/env.rb add the following line

  
    require File.expand_path(File.dirname(__FILE__) + '/stop')

As mentioned in the Usage above, add tags @wip and @stop to a scenario. Now execute the cucumber tests using following command.

  
    $ cucumber -p wip

If your cucumber test fails then you will be taken to a rails console where you can do things like

  
    Scenario failed. You are in rails console becuase of @stop. Type exit when you are done
    ree-1.8.7-2010.02 :001 > p User.count
      SQL (0.2ms)  SELECT COUNT(*) FROM "users"
      1
    => nil

Running a single cucumber feature

If you want to execute only a single cucumber feature then the syntax for that is

  
    $ bundle exec cucumber features/products.feature --require features

Typing that long command could be tedious. This is what I do

  
    $ c features/products.feature
    $ bundle exec cucumber features/products.feature --require features

I typed the first line and the second line is what is actually executed. I have following lines in my ~/.bashrc.

  
    function c () {
      if [ $# -eq 0 ]; then
        local cmd="bundle exec cucumber"
      else
        local cmd="bundle exec cucumber $@ --require features"
      fi
      echo $cmd
      eval $cmd
    }

Do Not Require Using Expanded Path

2011-01-25T17:00:00-05:00

My previous blog post received some good comments. In this blog post I am going to further expand on what others are saying .i.e. using expanded path is a bad idea.

Ability to provide alternative implementation

Let's say I have two files.

  
    #main.rb
    require 'lib/util'

    #lib/util.rb
    puts "Hello World"

If you execute ruby main.rb you will see Hello World. No surprise there.

However let's say that I have another directory called common in my dev folder. In this dirctory create a directory called lib and then store a file named util.rb.

  
    #~/dev/common/lib/util.rb
    puts "Hello Common World"

Now let's say that for testing purpose I want main.rb to load util.rb from our common library. Here is how you have to do to ensure that util.rb is picked up from common directory.

  
    ruby -I/Users/nsingh/dev/common main.rb

This time the output I got was

  
    Hello Common World

Now let's change original main.rb to be use expanded_path. New code would look like this

  
    require File.expand_path("../lib/util", __FILE__)

Now let's try to use util.rb from common directory.

  
    ruby -I/Users/nsingh/dev/common main.rb

This time output will be NOT be what we saw last time.

  
    Hello World

This is exactly what Aaraon Patterson is talking about when he says if you use File.expand_path then others can't provide an alternative implementation.

In real life I have never done anything like providing alternative implemenation of an item. However I do understand that in theory it makes sense to not to use expanded path.

spec_helper

If you are testing using rspec then your specs will have require 'spec_helper' at the top of the file. If you want to run tests for an individual file then you can do

  
    ruby spec/models/user_spec.rb

Note that there are better ways to execute a particular rspec file. I am using the given case only to discuss about require using relative path vs require using absolute path.

However that code will fail since spec_helper is not in the path. One way to fix that would be to execute following command

  
    ruby -Ispec spec/models/user_spec.rb

Another way to fix it would be to change the user_spec.rb to require spec_heper using expanded path.

  
    require File.dirname(__FILE__) + '/../spec_helper'

Now you can run ruby spec/models/user_spec.rb and it will run fine. However declaring expanded path comes with a cost. Let's say that tomorrow I move user_spec.rb to spec/models/users directory. Now the expanded path is pointing to a wrong file. If I had used spec_helper.rb then this problem would have not been there.

Since usage of expanded path reduces the flexibility of providing alternative implementation and increases the cost of moving around files, I am changing my vote from using expanded path to not using expanded path.

requiring rubygems

Ryan Tomayko wrote about the need to not to require . Sintarta testing documentation follows that guidelines and does not require rubygems. Here is the issue. If a ruby newbie comes along and stores the test file in test.rb and executes the file with command ruby test.rb , then the user will get following error message

  
    `require': no such file to load 'sinatra'

Most likey user will do gem install sinatra and it will still not work. The user does not know that rubygems is not being loaded. The correct command would be

  
    ruby -rubygems test.rb

I like the approach taken by cucumber. If you look at cucumber/cli/main.rb you will see following code

  
    begin
      require 'gherkin'
    rescue LoadError
      require 'rubygems'
      require 'gherkin'
    end

The cucumber team is trying to not to require rubygems but in case rubygems is not already loaded then they load it for you.

I know this rubygems issue is not directly related to expanded path discussion but since it came in the discussion in the comments, I wanted to provide my point of view.

Require Using Expanded Path

2010-01-19T17:00:00-05:00

The require command is not suppossed to load a file that is already loaded. However while requiring a file, ruby VM looks at the path and the file name and it can cause some strange behavior.

Basics

Ruby allows two ways to load file: require and load. load will load a file every single time while require will not load already loaded file.

I have two files here in the same directory: main.rb and foo.rb . Here is what files look like.

  
    #main.rb
    require 'foo'
    require 'foo'

  
    #foo.rb
    puts "I am being loaded"

If you execute ruby main.rb you will see a single message "I am being loaded". That is because once a file is already loaded then it wil not be loaded second time.

Require using relative path

Now let's change the main.rb to require foo.rb using relative path. After the change file looks like this

  
    #main.rb
    require 'foo'
    require '../dev/foo'

If you execute ruby main.rb you will see the puts message twice. That is because ruby is loading foo.rb twice.

$LOADED_FEATURES - keeping track of what's loaded and what's not

ruby uses $LOADED_FEATURES , a global constant, to keep track of what's loaded and what's not loaded. Here is an updated version of main.rb.

  
    #main.rb
    require 'foo'
    require 'foo'
    puts $LOADED_FEATURES.inspect
    require '../dev/foo'
    puts $LOADED_FEATURES.inspect

If you execute ruby main.rb you will see following message.

  
    I am being loaded
    ["enumerator.so", "foo.rb"]
    I am being loaded
    ["enumerator.so", "foo.rb", "../dev/foo.rb"]

As you can see ruby while loading a file also stores the path that was provided. Now that we know that ruby looks at the path fix is easy. Here is fixed version.

  
    require File.expand_path('../foo', __FILE__)
    puts $LOADED_FEATURES.inspect
    require File.expand_path('../../lab/foo', __FILE__)
    puts $LOADED_FEATURES.inspect

If you execute ruby main.rb you will see following message.

  
    I am being loaded
    ["enumerator.so", "/Users/nsingh/dev/scratch/lab/foo.rb"]
    ["enumerator.so", "/Users/nsingh/dev/scratch/lab/foo.rb"]

As you can see foo.rb is being loaded only once and that is because $LOADED_FEATURES has the absolute path to foo.rb.

Summary

There is no need to have abosolute path in all the cases. However in a complex case where a number of different files are being required and some of the required files in turn require more files dynamically then it is best to have a policy of everyone requiring file using absolute path.

Recently in the Spree project, the tests started to fail with the message that factories are already loaded. This was because same factory was being loaded by two different gems using different relative paths. Once I converted the code to use absolute path this problem was fixed.

Sticker Mule Launches Rails3 Version of their Site

2010-10-31T18:00:00-04:00

Rails Dog is pleased to announce that the StickerMule.com site has been upgraded to Rails 3.0. This is a significant milestone because this is our first client site to run the new Rails3-compatible version of Spree. The site has been running for several days now with only minor issues. We've already fixed a few minor bugs in the Spree project as a result. We know that the Spree community is anxiously awaiting the official release of Spree 0.30.0 and this brings us one step closer.

We have upgraded several existing Spree extensions to be compatible with the new version of Spree and we've resolved several important issues that will help reduce the pain of existing sites that are looking to upgrade. We've also developed a series of database migrations that will help migrate existing Spree sites with minimal disruption.

With the successful upgrade of this client we are now ready to finalize the official Spree release. While we're working on that, feel free to checkout the new site, especially if you're looking for some high qualtiy custom stickers.

Redirect Non-WWW Requests the Rails3 Way

2010-10-29T18:00:00-04:00

Have you ever had a situation where you would like to redirect non-WWW traffic to a canonical WWW version? In others words you want visitors to http://example.com to be redirected to http://www.example.com. Until recently you basically had one of two options.

Option 1 - Server Configuration

One traditional way to achieve this redirect is via server configuration. For Apache this would involve something like the following:

  
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^example.com
    RewriteRule ^ http://www.example.com%{REQUEST_URI} [L,R=301]

For Nginx you would configure the same redirect using the following

  
    server {
      listen 80;
      server_name example.com;
      rewrite ^/(.*) http://www.example.com/$1 permanent;
    }

Using server configuration to achieve this has two significant drawbacks. The first problem is that the configuration is not typically stored with your source code and thus you're prone to lose/forget about it if you ever need to move your code to a new server. The second problem is that you may not have access to your server configuration. This is a particular problem when hosting with Heroku which does not allow users to configure their web servers (which are multi-tenant.)

Option 2 - Use Some Type of Rack Middleware

Another common approach is to use some type of Rack middleware to achieve the redirection. Up until recently I've been using this approach. Here's an example I found from a recent Stack Overflow search

  
    class CanonicalRedirect
      def initialize(app)
        @app = app
      end

      def call(env)
        request = Rack::Request.new(env)

        if request.host =~ /^example.com/
          [301, {"Location" => request.url.sub("//", "//www.")}, self]
        else
          @app.call(env)
        end
      end

      def each(&block)
      end
    end

You'll also need to tweak the configuration in your application.rb file.

  
    config.autoload_paths += %W(#{config.root}/lib)
    config.middleware.use "CanonicalRedirect"

This approach certainly works but it always left me wanting. Why do we need an entire class plus extra configuration just to do some simple redirects?

A Better Way: Use Rails3 Routing Awesomeness

Rails 3.0 offers a lot of cool new improvements to routing. The Rails documentation on routing is quite extensive but it doesn't cover all of the interesting cases. In fact, a basic Google search turned up nothing on this approach. After a little bit of experimentation I came up with a solution.

  
    Foo::Application.routes.draw do
      constraints(:host => /example.com/) do
        root :to => redirect("http://www.example.com")
        match '/*path', :to => redirect {|params| "http://www.example.com/#{params[:path]}"}
      end
    end

This is much better. Just five lines of code and completely portable no matter where you deploy your application!

Updated: Fixed the Rails 3 example to deal with "Regexp anchor characters are not allowed in routing requirements" exception in Rails 3.0.3 and greater.

Railsdog is Hiring

2010-04-06T13:00:00-04:00

We're now hiring experienced Ruby/Rails developers for full time positions. Developers will be working primarily on client work related to the Spree e-commerce project. This is a great opportunity to work for a company that is passionate about open source. MS Word is the only commercial software you are likely to encounter in our office! Come join our team and help shape the future of e-commerce.

Candidates must be local to the Washington, D.C. Metro Area. Developers will work on site but can expect flexible scheduling and the ability to work from home. Our office is located at the Friendship Heights Metro. Prior experience with Spree is not necessary but we do require at least 12 month of experience with Ruby/Rails. We offer full benefits including health insurance.

Please send an email to jobs@railsdog.com with your resume and/or LinkedIn profile.

StickerMule.com Has Launched

2010-04-01T16:00:00-04:00

We are pleased to announce the launch of our latest client site: stickermule.com. This is an e-commerce site where you can purchase custom stickers for just about every scenario you can think of. Customers upload their artwork and specify the exact size and quantity combinations they desire. The StickerMule artists will send you a proof which you need to sign off on before the stickers are printed. You can go back and forth with the designers until you are satisfied with the design. They also offer custom cut stickers so you can get stickers that are cut in the shape of your artwork. We have a bunch of them in the office with the Rails Dog logo.

There are several technical features of this site that we think are pretty interesting. The custom artwork is uploaded via a Flash uploader and the images themselves are stored remotely using Amazon's S3 cloud storage. The site itself is running on Spree with several custom screens on the backend to handle their specific business rules pertaining to artwork. We also deployed the site "in the cloud" using Heroku. Heroku is an excellent platform that we have been following for quite some time. We're quite pleased with Heroku so far and we'll be doing a more detailed write up on using Spree with Heroku in the near future.

If you're interested in getting some custom stickers made for your business or website be sure to pay these guys a visit. Use the promo code "SPREE" between now and April 31 and get $50 off your order.