OnRails.org

The application

The application is composed of the Store and the Order processing application. The Store allows selecting 4 T-shirt designs each in 5 sizes, to add the ones you like to shopping cart and finally go to a checkout page where shipping and billing information can be entered. Payment processing is done using the payment ruby library that supports Authorize.net merchant accounts (that’s just the one we needed and we go the credit card payment processing integrated in 10 minutes :-). All in all we built the most basic on-line store that one can build. Nowadays such a store can certainly be setup for a couple of dollars with yahoo and other providers. But the fun part was to do it and learn from that. Maybe if Shopify was open for business we wouldn’t have tried to write our own on-line store…but then again we wouldn’t have learn as much.

There are many things that can be improved and we are already planning for next year to add support for more products, designs and configurations to support things like Mugs and Long-Sleeve Shirts. So there will quite some refactoring for the next iteration.

The development process

Well…we where not too formal I believe, we used Basecamp to communicate ideas and create todos and then we just jumped in. Lee’s approach is usually more intellectual and he wants to get things pretty nicely laid-out before starting and I like to start and learn from what we discover and improve has we move along. Together we got a good mix. Lee’s dad just wants to sell his t-shirts. Now regarding Basecamp, if first thought it would be “overkill” for such a small project but it’s really a nice communication tool and helped us out getting organized without having to really think about it.

The look and feel

It’s got to work well, but that doesn’t matter if it’s not looking good. It’s got to look good. Well…we are software programmers, software designers, software architects, but even thought I don’t like to admit it, pretty lousy graphic designers. My first attempts to prototype the site gave a good feel of the structure and style…but just didn’t cut it. On the side for simple html work I use RapidWeaver, a cool tool on OSX to rapidly build html website of predefined types. This tool does a great job of separating content and style and provides a bunch of pretty nice html design that rely heavily on css. Well it took me about five minutes to get a pretty nice proto for the store using that tool and that’s what we went with. The nice part is that is was pretty straight forward to change the static site into dynamic .rhtml pages. Layouts in Rails are just awesome. From an usability point of view, we still have one step to much as the cart and checkout page should really become one. For the next version, we will try to have it similar to the Panic’s Good Store.

DataModel

The data model was fairly straight forward mostly consisting of an Order having many LineItem.

show larger image

Architecture

Although a file structure of an application doesn’t depict an architecture, Ruby on Rails really provides a nice starting point for organizing your code in a clean MVC (model-view-controller) manner and really makes it straight forward for a simple application like this one.

show larger image

Credit Card Payment

Let’s look at some code. First we need the payment gem.

require 'payment'

Then we just need to submit the transaction. I was really as simply as that. Of course you need a merchant account.

def process_payment(order, credit_card_number, credit_card_expiration_mmyy )
    @transaction = Payment::AuthorizeNet.new(
                      :prefs       => "#{RAILS_ROOT}/config/payment.yml",
                      :amount      => @cart.total_price,
                      :expiration  => credit_card_expiration_mmyy,
                      :first_name  => order.bill_to_last_name,
                      :last_name   => order.bill_to_first_name,
                      :card_number => credit_card_number,
                      :invoice     => order.order_number,
                      :test_transaction => RAILS_ENV != 'production'   
                     )

    @transaction.submit
    @transaction.authorization
end

Migration

We went only through the following database schema migrations:

001_initial_schema.rb
002_add_order_ship_date_and_status.rb
003_add_order_date.rb
004_add_users.rb
005_add_product_options.rb

However writing migrations in Ruby is just such a simple solution and make so much sense that I am surprised that there is no standard tools like that in the Java world.

Let’s look at migrating the schema to version 2. We need to add two columns to the orders table and default existing values to ‘Open’. No to move from version 1 to 2, simply issue the command rake migrate. If for some reasons we wanted to revert to version 1, we could issue the command rake migrate VERSION=1.

class AddOrderShipDateAndStatus < ActiveRecord::Migration
  def self.up
    add_column :orders, :shipped_at, :datetime, :null => true
    add_column :orders, :status, :string, :limit => 40, :default => 'New', :null => false

    execute "UPDATE orders SET status = 'Open'"
  end

  def self.down
    remove_column :orders, :status
    remove_column :orders, :shipped_at
  end
end

The “Ajax” thing

Of course we had to play with this. We only used the no page refresh approach when updating the cart. Note when you change the quantity of a given item, the Cart and Checkout tab both get updated dynamically, as well as the total of the order. Note that I only found after the fact the “right” way to update multiple ids from a single server call using evaluate_remote_response instead of our custom solution. In addition with the new javascript supported template (.rjs) all that will be cleaned up for our next iteration.

Testing

We didn’t take a fully Test First Development approach, but Rails makes it so much fun to test that we quickly went back to writing tests while we where developing some of the classes like the cart model and the store controller.

Hosting

I believe that deploying a Rails application in a hosting environment is the weakest point of Rails today. We are using two hosts for different matters, TextDrive and Dreamhost. On other projects we are working with Tom who also happen to have helped Dreamhost setting up Rails on their server and made it pretty easy to deploy a Rails application. So Dreamhost is the route we went, however the application doesn’t always respond nicely and at least not in a consistent manner. I guess that’s maybe what we deserve by using a $9/month hosting plan. Let’s hope that http://railsbase.com from TextDrive will provide a more compelling experience where we don’t have to regularly kill ghost fastcgi processes.

Conclusion

It was a fun learning experience and Rails made it just enjoyable. Ruby and Ruby on Rails forces you to write clean and simple code, encourages you to write unit tests and to refactor stuff as you move along. It’s impressive when comming from a java enterprise background how much more enjoyable and faster development becomes when using Rails.