Getting Rails 3.0 running with “My Stack” on Ruby 1.9.1

I’m pretty excited about Rails 3.0. It really feels like a polished version of the framework, much like Snow Leopard was for Leopard OS X.

At this stage in the game I really don’t want to be starting any new projects with Rails 2.3.5, so I thought I would see if it was possible to get Rails 3.0-beta running with “My Stack”—a set of gems/plugins used on all of my projects. Admittedly, there are probably some others that I should be using, but these are definitely the essentials:

• haml (with sass)
• compass
• authlogic
• shoulda
• factory_girl
• will_paginate

Just to keep things interesting I thought I would throw Ruby 1.9.1 in there to mix things up.

First, stop was to check out railsplugins.org. A registry setup by Engine Yard to track which plugins are Rail 3, Thread Safe, JRuby, and Ruby 1.9 compatible. Let’s see how my stack faired (note, I’m only interested in Rails 3 and Ruby 1.9):

• haml (with sass): Rails 3, Ruby 1.9
• compass: Rails 3, Ruby 1.9
• authlogic: Rails 3, Ruby 1.9
• shoulda: (no record)
• factory_girl: Rails 3, Ruby 1.9
• will_paginate: Rails 3, Ruby 1.9

OK, let’s look at each plugin, step by step:

Haml (Confirmed to work)

Installing Haml was pretty straight forward:

# Gemfile
gem "haml", "2.2.21" 

# command line (rails root of course)
bundle install
haml --rails . 

Compass (Confirmed to work)

Install Compass was also straight forward:

# Gemfile
gem "compass", "0.10.0.pre9" 

# command line
compass --rails -f blueprint . --css-dir=public/stylesheets/compiled --sass-dir=app/stylesheets

Authlogic (Unknown to work)

While Authologic is officially “not working”, reports from end users suggest it is. Following along with Ryan Bates screencast, you just need to translate the script/generate commands to rails generate and also check for new options. To setup Authlogic with your application, add it to your Gemfile.

# Gemfile
gem "authlogic", :git => "git://github.com/binarylogic/authlogic.git" 

Shoulda (Unknown to work)

There are no reports regarding shoulda (as there is no version number assigned to, and you can't comment without a version number). Although there is a rails3 branch, it hasn’t been touched since mid-January. Well let’s give it a go and see how far we get:

# Gemfile
gem "shoulda", :git => "git://github.com/thoughtbot/shoulda.git", :branch => "rails3", :group => :test

A couple of options to note. :branch specifies the branch of the git repo, and :group the environment. You won’t be needing shoulda in production.

So how did we get on? Trying rake test... Boom!

DEPRECATION WARNING: RAILS_ROOT is deprecated! Use Rails.root instead. (called from join at ~/.bundle/ruby/1.9.1/bundler/gems/shoulda-b78dbf514bbce3272023d3a4742474857c2eb3c3-rails3/lib/shoulda/autoload_macros.rb:40)
  ~/.bundle/ruby/1.9.1/bundler/gems/shoulda-b78dbf514bbce3272023d3a4742474857c2eb3c3-rails3/lib/shoulda/autoload_macros.rb:40:in `join': can't convert #<Class:0x1297f3c> into String (TypeError)  

OK, let’s remove shoulda gem from:

rm -rf ~/.bundle/ruby/1.9.1/bundler/gems/

And let’s try a more up to date fork. This looks like it:

# Gemfile
gem "shoulda", :git => "git://github.com/bmaddy/shoulda.git", :branch => "rails3", :group => :test

You get this message but it doesn’t appear to be anything to worry about (I hope):

shoulda at ~/.bundle/ruby/1.9.1/bundler/gems/shoulda-87e75311f83548760114cd4188afa4f83fecdc22-rails3 did not have a valid gemspec.
  This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
  The validation message from Rubygems was:
    ["test/rails_root/db/development.sqlite3", "test/rails_root/doc", "test/rails_root/log/development.log", "test/rails_root/log/production.log", "test/rails_root/log/server.log", "test/rails_root/log/test.log", "test/rails_root/test/fixtures", "test/rails_root/test/functional", "test/rails_root/test/integration", "test/rails_root/test/unit"] are not files

And running rake test works. Let’s convert a controller over.

context "create card" do
    setup { post :create, :card => cards(:one).attributes }

    should_change "Card.count", :by => 1
    should_redirect_to("new card") { card_path(assigns(:card)) }
  end  

Almost works, but dies on the should_change marco.

1) Error:
test: create card should change Card.count by 1. (CardsControllerTest):
NoMethodError: undefined method `call' for #<Arel::Value:0x172eba8>
      ~/.bundle/ruby/1.9.1/bundler/gems/shoulda-87e75311f83548760114cd4188afa4f83fecdc22-rails3/lib/shoulda/macros.rb:45:in `block in should_change'
      ~/.bundle/ruby/1.9.1/bundler/gems/shoulda-87e75311f83548760114cd4188afa4f83fecdc22-rails3/lib/shoulda/context.rb:360:in `call'
      ~/.bundle/ruby/1.9.1/bundler/gems/shoulda-87e75311f83548760114cd4188afa4f83fecdc22-rails3/lib/shoulda/context.rb:360:in `block in create_test_from_should_hash'  

Looks like a change in ActiveRecord is causing a few problem there.

Conlusion on Shoulda: OK, it might be the only macro failing, but I think at this stage i will leave shoulda at this point. I’ve filed an issue and if I have some time I will look into it myself.

Factory Girl (Unknown to work)

While the owner says it’s “not working”. A commentator says it does. Let’s give it a go:

# Gemfile
gem 'factory_girl', :git => 'git://github.com/szimek/factory_girl.git', :branch => 'rails3', :group => :test

# command line
bundle install

And convert a controller over to use factories instead of fixtures (yuk!).

# factories.rb

Factory.define :card do |c|
  c.name 'Lorem ipsum dolor sit amet'
end

# cards_controller_test.rb
require 'test_helper'

class CardsControllerTest < ActionController::TestCase

  setup do
    @card = Factory(:card)    
  end

  test "should get index" do
    get :index
    assert_response :success
    assert_not_nil assigns(:cards)
  end

  test "should get new" do
    get :new
    assert_response :success
  end

  test "should create card" do
    assert_difference('Card.count') do
      post :create, :card => @card.attributes
    end

    assert_redirected_to card_path(assigns(:card))
  end

  test "should show card" do
    get :show, :id => @card.to_param
    assert_response :success
  end

  test "should get edit" do
    get :edit, :id => @card.to_param
    assert_response :success
  end

  test "should update card" do
    put :update, :id => @card.to_param, :card => @card.attributes
    assert_redirected_to card_path(assigns(:card))
  end

  test "should destroy card" do
    assert_difference('Card.count', -1) do
      delete :destroy, :id => @card.to_param
    end

    assert_redirected_to cards_path
  end
end

Yes, it’s a very simple example of using a factory. So there might be some bugs lurking around. But I’m guess it’s safe to say this is usable.

Will Paginate (Confirmed to work)

This looks promising.

# Gemfile
gem "will_paginate", "3.0.pre"  

# command line
bundle install

Again, it’s a simple example, but I think it’s safe to say we’re good to go.

# cards_controller.rb
@cards = Card.paginate :page => params[:page], :per_page => 1

# index.html.haml
= will_paginate @cards

Conclusion

Well it is marked Beta for a reason—and that’s for the gem/plugin ecosystem to catch up. With my limited playing with Rails 3-beta I would be confident writing applications with it, and while most plugins seem to be compatible, I feel a little uneasy doing production projects until there is a broader range of plugins compatible with it. Looks like I will be staying with Rails 2.3.5 a little longer.

Get Sass and Compass running on Heroku with Rails 3.0-beta

Heroku is read-only file system causing a little havoc for runtime compilation of Sass files into CSS. In my recent trial of running a Rails 3.0-beta application on Heroku with MRI 1.9.1 I came across this issue.

Doing a google on “heroku sass” will bring you to this post which leads you to sass_on_heroku plugin which is deprecated. The current plugin is Hassle, but unfortunately this hasn’t been touched for a few months. There are some current issues with this plugin and Compass. But all is not lost! Jacques Crocker has forked the plugin and made a fix for this. Get a compatible version of Hassle that works with Compass from his repo.

Now, there’s one change that needs to be made to get Hassle working with Rails 3.0-beta. As Hassle is a piece of Rack middleware, the configuration has changed and must be configured using the Railtie class based on this documentation. Admittedly, this is a little hacky, but gets things going. Placing the Railtie file in it’s own file and namedspace would clean things up.

# init.rb

# Rails 2.3.x style
#
# if RAILS_ENV == 'production'
#   ActionController::Dispatcher.middleware.use Hassle
# end

require 'hassle'

class HassleRailtie < Rails::Railtie
  config.middleware.use Hassle if Rails.env == 'production' 
end    

And, that’s it! With this you should be able to get Sass and Compass running on Heroku with Rails 3.0-beta.

Getting Rails 3.0-beta running on Heroku

I wanted to test out Rails 3.0-beta and see how far I could get with developing an application with my stack of gems/plugins. I hadn’t checked out Heroku either, so it gave me an opportunity to try out their new stacks with Ruby 1.9.1.

First, I installed Rails 3 Beta and RVM outlined in Ryan Bate’s screencast. If you haven’t installed RVM yet, you will be wondering why it’s taken you this long. I did.

Once you have Rails up and running, you can following with their quick start guide. There’s a couple of things to take note when deploying for Rails 3.0-beta, but it’s all pretty straight forward.

As mentioned in the documentation you will need to add the “pg” gem to your Gemfile as Heroku runs Postgres database on their servers; i.e. not MySQL.

  # Gemfile
  group :production do
    gem "pg" 
  end  

By placing it in the “production” group you won’t need to install it locally.

I’m super impressed by Heroku, and look forward to get a production application running on their platform. It’s simply awesome.

Focus Website Content on your Customers' Knowledge Gap

The biggest hurdle when developing a website is producing the content. All of us who have experienced the process of launching a website will probably agree that it was the content development stage that dragged out forever, that delayed the launch. Even deciding what content should be on the site is difficult. Over the last two posts¹, I have highlighted the importance on focusing on your customer first, and outlined strategies to identify their needs.

Identify your customer’s knowledge gap

Another strategy is to identify your customers’ knowledge gap. The concept of the knowledge gap was presented by Jared Spool (of UIE fame) in his presentation “What Users Want”². The knowledge gap is the gap between two points on a spectrum, the current knowledge and the target knowledge.

The current knowledge is the information your customer already knows about your business domain: your company, service, product, industry and market. The target knowledge is what your customer needs to know to make a decision.

Spool suggests your website content targets the knowledge gap. It is a wasted effort to develop content before current knowledge and after target knowledge.

How to find the knowledge gap?

A quick start on identifying your customers’ knowledge gap is to create two lists side-by-side. List 20 items your customer knows about what you are trying to sell—their current knowledge. Then, list 20 items your customer needs to know to make a decision—their target knowledge. You can help refine this list by visiting forums where your customers engage, and observe the questions that are being asked.

What is your customers’ knowledge gap?

[1] Create a Sketch of your Customers’ Needs and Ask 20 Questions to Build Customer Empathy

[2] What Users Want

Create a Sketch of your Customers’ Needs

Flickr Photo Credit: ruimtevolk

Last week I wrote about Asking 20 Questions to Build Customer Empathy, a quick start guide to Customer-Centered Web Design. This week, I want to expand on that, and help you create a sketch of your customers’ needs.

A “sketch” is a perfect noun for what we want to achieve. From my Mac dictionary:

“a rough or unfinished drawing or painting, often made to assist in making a more finished picture”.

Exactly. We want to make a sketch of your customers’ needs before we start on the finished picture, in this case, your website. This sketch will assist you in developing the finished picture.

Ok, let’s get started. Here are five areas that you can brainstorm to start developing the sketch of your customers’ needs. Brainstorm 20 answers for each area (see Why twenty questions?).

1. Goals: What problem are your customers trying to solve? Alternatively, what opportunity are they trying to capitalize?
2. Motiviation: Why are they motivated to use a product or service like yours? Sure consider the typical carrots and sticks¹, but also consider other motivating factors such as autonomy, mastery, and purpose².
3. Outcomes: What is the successful outcome? Paint a detailed picture of what this looks like.
4. Pain: What is stopping your customer from solving their problem in their current situation? Think money, attitude, misconceptions, and values.
5. Emotion: What do they need to enjoy the service or product? Sure, a problem might get solved, but it needs to address the emotional needs of your customer as well. Why can’t it be fun?

Now you have this sketch, what content will you develop for the website that addresses their goals, motivations, outcomes, pain and emotions? How will you structure the website to present this content?

I’m all about finding quick ways to help you shift your focus from what you are trying to sell, to the needs of your visitors, the customers of your website. It doesn’t necessarily mean you need to have a huge external research project. The people in your company, such as sales and support representatives have a huge body of knowledge about your customers that needs to be tapped. Get them involved in this brainstorming process.

[1] http://en.wikipedia.org/wiki/Carrot_and_stick

[2] Dan Pink on the surprising science of motivation

Ask 20 Questions to Build Customer Empathy

Flickr Photo Credit: horiavarlan

This morning I wanted to write a post providing a quick start guide for Customer-Centered Web Design. The main principle of this technique is to build empathy for your customer before designing your website. When you empathize with your customer, you will understand their goals. When you design your website to meet their goals, you will achieve your business objectives. (The term customer is inclusive of all visitors to your website, including prospects and leads).

Creating provisional or ad-hoc personas (user profiles)[1] was one direction I started with. This would involve brainstorming your customers’ goals, motivations, outcomes, pains and emotions. But as soon as I started that blog post it just didn’t feel quick enough! I’ll keep that for a future posting.

So here’s the super quick start guide for Customer-Centered Web Design:

List 20 questions your customers are asking about the problem they are trying to solve.

Simple, yes? Let’s break this super quick start guide down.

Why questions? At the end of the day that’s why people are searching on the Web. There are even websites dedicated to answering questions such as Yahoo! Answers[2] and Stack Overflow[3]. They are trying to solve a problem. “How do I solve this?” “How do I do that?” “Why is this happening?” Your website should answer the questions your customers have. If it doesn’t, then your customers will go somewhere else.

Why twenty questions? Years ago, I attended a Brian Tracy program called the Phoenix Seminar. In the program, Brian recommended generating twenty ideas when brainstorming. Typically the first ten will be easy, while the last ten will be more difficult. But often the most valuable. Was the first twenty easy? Well try another twenty. No, I’m not being mean. It’s amazing what happens when you start thinking beyond the obvious.

Over the last few weeks I have been assisting with several graphic design and communications companies on proposals. The proposal process always starts with “what shall we do for this website?” For me that always feels like the wrong starting point. The website becomes ego-centric or design-centric (design for designs sake). Quickly brainstorming twenty questions from the customer’s perspective helps build empathy and achieves a website that will be successful for your business.

[1] About Face, Alan Cooper

[2] Yahoo! Answers

[3] Stack Overflow

Want a simple way to get more out of your time? Try the Pomodoro Technique

About one month ago I started using the Pomodoro Technique, a simple time management tool. The process is simple: pick a task to focus on, set your timer for 25 minutes, and go. The idea is to avoid any other distractions as possible. Don’t check your email. Don’t answer that telephone. If something comes to mind, write it down and return to your focused task. Of course, if the fire alarm starts ringing, I suggest your change your focus.

Once the 25 minutes is up, walk away, take a five minute break and return for another 25 minute “Pomodoro”. After 4 Pomodoro’s, take a longer break (15-30 minutes).

Why am I so hot on this technique?

1. More mental energy throughout the day: working in 25 minute increments, and taking a five minute break I find that it creates a sustainable pace. Coding does drain the grey matter, well at least for me, but using this technique extends my productive hours later in the afternoon than without it.
2. Reduces procrastination and anxiety: don’t want to start something? Just try it for 25 minutes. Starting something new or difficult can be accompanied by procrastination and anxiety. For example, writing, hence blogging doesn’t come naturally to me. But break it down in 25 minute chunks makes it hell of a lot easier. Of course getting started is the killer, but I know I can do something for at least 25 minutes. And once I’m started, it’s normally a breeze.
3. Improves visibility of how you spend your time and track interruptions: being a freelancer, selling my time, obviously time tracking is important. But it also gives me a good feeling that when I’m billing the client, I have given them focused, uninterrupted time. When interruptions occur, these are also tracked and reviewed at the end of the day. The goal of course it to do as many uninterrupted Pomodoros that make sense, and devise strategies to avoid interruptions.

For more information checkout the website. There is also a book written about the technique. While the technique itself is super simple, the book “Pomodoro Technique Illustrated” does give you some insights into why the technique works and dives into topics such as the mental cost of context switching.

There is also a free book in PDF format available online written by the creator.

Oh, and you are probably asking yourself, “Why Pomodoro?” The creator of the technique, “Francesco Cirillo”, used a kitchen timer in the shape of a tomato.