DAVID RICE

Last year was a long year of upgrades for a lot of our clients at Rumble Labs. Going into this year, most of our Ruby work is all running on Ruby 1.9.2. A lot of those projects are Rails applications and we managed to have most of those running on Rails 3.0.x. From an OCD point of view, this pleases me.

Some of the applications we’re working on for clients are now pretty big, Rails is getting bigger and there are more libraries out there. The combined effects of which are starting to feel a little slow.

Ruby 1.9.3

Ruby 1.9.3 is the latest stable release of the 1.9.x series. It’s been great to start taking advantage of a few of the niceties in Ruby now since the move from 1.8.x.

With Ruby 1.9.3 it’s all about the speed. I tested running time rake -T before and after the upgrade in a number of our projects. Roughly speaking I saw a reduction of 50% in the time it took. This is great! If you use RVM (and I would recommend you do, or something like it) you can install with the following

rvm install 1.9.3

Bundler

A quick aside in case you haven’t heard. The latest beta version of bundler is super fast compared to the current stable release. You can install the latest version of bundler (in your global gemset) with the following.

rvm gemset use global
gem install bundler --pre

Rails 3.2.0.rc2

The latest version of Rails 3.2.0.rc2 has a few changes, the biggest of which is some performance improvements to boot time, development mode and asset compilation. For our applications running on 3.1 it was quite a painless upgrade (unlike going from 3.0.9 -> 3.1).

# add to your Gemfile
gem 'rails', '3.2.0.rc2'

# I like to create a new gemset for each specific Rails version
rvm gemset create rails-3-2-0-rc2
bundle update

Heroku

What would be the use of upgrading all these apps if we can’t try them out, in production! Thankfully it is possible to run both Ruby 1.9.3 and Rails 3.2.0.rc2 in production on Heroku thanks to their new Heroku Labs features, specifically their user_env_compile which allows us to set configuration that will be respected by the heroku build packs.

Note: not for the fainthearted Heroku mention they may remove any feature of Heroku Labs without warning, so be careful!

# Enable Heroku Labs
heroku plugins:install http://github.com/heroku/heroku-labs.git

# Enable the user_env_compile add-on (for each app)
heroku labs:enable user_env_compile -a myapp

# Enable 1.9.3
heroku config:add RUBY_VERSION=ruby-1.9.3-p0

That should be your Heroku app enabled to run on Ruby 1.9.3. Next time you push to heroku you should see something like the following in the compile output.

-----> Heroku receiving push
-----> Ruby/Rails app detected
-----> Using RUBY_VERSION: ruby-1.9.3-p0

Conclusion

I’ve upgraded about 10 apps so far and have yet to come across any showstopper bugs. It doesn’t take too long to do either. So, definitely worth the performance improvements you will gain! Happy upgrading.

So, I’ve recently joined up with the guys at Rumble Labs as their new Technical Director. Over the past two years I had been working self employed as a consultant for several local and international companies (Which was an enjoyable change from being a company director before that). However late last year as work was coming in thick and fast and I needed to collaborate with a few local freelancers more and more. I decided it was probably about time to start a another company. However at around about the same time Simon (from Rumble) asked if I’d be interested in joining the team.

It was pretty good timing as coincidentally our lovely old office building in Belfast’s Linen Quarter was being condemned (sad face). So we decided to share a new office together and knuckle down on a few collaborative projects. After a good few months of that, things were working well so we decided to start the long process of merging companies.

The paperwork was the easy part! Now we have to start all the technical side of things. For one, I’m very happy about being able to cross off a life goal of starting a software development hub in my home town!

The Rails 3.1.0 Release Candidate dropped a few days ago and thought I’d give it a try on an application I was busy upgrading already. Before starting you’ll probably want to check out the Release Notes or the railscasts overview video first.

1. Upgrade the Gemfile

source 'http://rubygems.org'

gem "rails", "3.1.0.rc1"
gem "mysql2", "0.3.2"
# Rails 3.1 - Asset Pipeline
gem 'json'
gem 'sass'
gem 'coffee-script'
gem 'uglifier'
# Rails 3.1 - JavaScript
gem 'jquery-rails'

# Rails 3.1 - Heroku
group :production do
  gem 'therubyracer-heroku', '0.8.1.pre3'
  gem 'pg'
end

Needed specifically the latest version of mysql2 as the earlier ones are incompatible. To get the asset pipeline working on heroku you’ll need therubyracer-heroku. Another issue with heroku, it appears you now need to be explicit about using postgres in production.

2. Config File Changes

Update config/boot.rb

require 'rubygems'

# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)

require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE'])

Update application.rb

In config/application.rb add the following line.

# Enable the asset pipeline
config.assets.enabled = true

Update development.rb

I seemed to have to remove the following line from config/environments/development.rb

config.action_view.debug_rjs             = true

Update production.rb

Add the following lines to enable asset compression in config/environments/production.rb.

# Compress both stylesheets and JavaScripts
config.assets.js_compressor  = :uglifier
config.assets.css_compressor = :scss

3. Move Assets

Move the Folders

mkdir app/assets
git mv public/images app/assets/images
git mv public/javascripts app/assets/javascripts
git mv public/stylesheets app/assets/stylesheets

Fix Image References

Use your favourite find and replace, check judiciously.

find: /images/
replace: /assets/

Make CSS and JavaScript Manifest Files

I already had an app/assets/application.js file so I added this to the top of mine and moved the code in there out into separate files with app/assets/javascripts.

// This is a manifest file that'll be compiled into including all the files listed below.
// Add new JavaScript/Coffee code in separate files in this directory and they'll automatically
// be included in the compiled file accessible from http://example.com/assets/application.js
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// the compiled file.
//
//= require jquery
//= require jquery_ujs
//= require_tree .

I did the same for app/assets/application.css

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree . 
*/

Fix the CSS and JavaScript references

Instead of requiring multiple files you’ll want to require the manifest files created above.

<%= stylesheet_link_tag    "application" %>
<%= javascript_include_tag "application" %>

Success!

On an app with good front end conventions established, already using a method of asset bundling, etc. this isn’t a big task.

However I do find that because Rails has set such good conventions it’s hard for people to go too wrong. Of all the applications where I’ve taken over from another developer over the years. Rescue missions, etc. It’s the prospect of looking in the public/ directory that scares the bajaysus out of me.

Thankfully with all this great new front end stuff I’m hoping that in the future, rescue missions into interface land will suffer less casualties.

There are two common payment models in the software as a service industry.

1. Feature stratification based price plans
2. Usage based price plans

With price plans based on feature stratification being the most common (this is something I believe has it’s roots in the mobile industry or similar) but software as a service developers should beware to carefully consider their business models than just come up with a price plan.

A long time ago while I was funding my degree studies by working in mobile (at Orange) there was very popular phone contract of the time called the Virgin tariff. So called because it was brought out on Orange to compete with a similar tariff offered by Virign Mobile, the difference between this and the now standard contract tariffs is this;

• No set monthly cost or limits.
• You pay monthly for what you use at set usage costs (at a fair price, not like Pay-as-you-go)

Now over time at Orange the mood quickly changed about the Virgin tariff and the large numbers of customers it was bringing in and this was made official by Orange HQ lowering the margins on phones sold attached to a Virgin plan. Why? The reason is very simple, the margin for network operators is a lot less when you only pay for what you use. Let’s look at the following simplified example;

Imagine Vapourware Mobile provided a plan and a usage based model. The plan with 100 minutes 50 cross network minutes and 100 texts for £35/month, they offered the same unit prices for the usage based model so if a user actually were to be on that plan and use exactly the ammount of service as is allowed on the plan it would cost them £2.50 extra. I also made-up some numbers as to what the actual cost to the network is per unit, these aren’t exactly real figures if anything in real life it is bound to be lower.

	Plan	Unit price	Usage	Unit cost	Cost / User
Minutes	100	0.1	10	0.025	2.5
Other Network Calls	50	0.35	17.50	0.1	5
Texts	100	0.1	10	0.01	1
	£35		£37.50		£8.50

So this is the part where the real economic genius comes in to play. In general, every single customer is not actually on a tariff that suits their needs correctly. So the stratified price plan approach gives every user a monthly target of free usage to achieve for every facet of their service to you, the problem for the customer lies in the fact that modern phone contracts have so many extra charges built in and it is very difficult for the customer to know and to use exactly what is in their contract every month.

What will tend to happen to every customer is under use or over use. In every scenario with the fixed price contract model, the mobile provider is the winner. They have very seriously thought about their cost per user and it is built into their business model.

The Evil Capitalist

Well there are two sides of the coin, if you’re an evil capitalist at heart and would like nothing more than taking every opportunity to make a quick buck then it’s obvious that you want to structure your pricing like a mobile phone contract. As a mobile exec was once quoted saying “Text Messaging is the purest form of profit ever created”.

As a quick aside it’s also worth noting that SMS was actually invented as a by-product of creating the system for wireless voice calls. Spare bandwidth in the system they created that in turn could be used to generate profit, akin to what Amazon are doing today with their cloud computing platform.

Up or Down

This behaviour in the mobile industry is somewhat similar to the feature stratification of paid web software, a lot of the time the user will be hovering around plan limits and so be forced to make a decision, do they upgrade their plan? or downgrade their usage?

As pricing is usually quite a jump between levels it is usually unfair to the user as to get their value out of the expense they need to use the system as much as possible to reach the next level at which point they are at that upgrade decision time again. How modern web apps differ from mobile contracts would largely be around their ability to bill users for usage above their current plan without forcing an upgrade.

A Better Way

So if you’re more of a hippy idealist you probably want to structure your plans more like a true Pay as You Go contract (in-fact a little more like Amazon). A lot more companies are taking on a more usage based model these days but the numbers are still quite slim.

I think the usage model as a whole lot fairer on the users, you don’t make swathes of cash on unused systems but it still stands to be potentially more profitable. Think about it, rather than charging users in narrow bands of pricing where they are likely to try and conserve their usage to avoid upgrading, you have users paying vastly varying ammounts depending on their usage, users who don’t care about the price anymore because they are getting great value for money. Users who don’t have to worry about being locked-in and when that next big upgrade spike is going to hit, who tell their friends about this great service they are using that is cost effective to get started with, who are having better love lives and generally being better people…

I do not have exact statistics on this but have done research for previous Web Applications I have created, all signs point to more profit. Not to mention the karma. I’d love to have some hard data for you, perhaps soon.

At the end of the day, if I had to choose it would obviously be usage based pricing. The main problem and also the reason why there is such a proliferation of feature stratification based pricing is that tracking and calculating usage is a hard problem.

Ask me in a few weeks if I’m enjoying the taste of my own dog food, or not.

What do you think?