When we release a SaaS web application, such as IntuitionHQ, it’s inevitable that there will be two parts that make it up. The main part is the application itself. The second part is the marketing site that goes with it. The marketing site includes the content, and usually a way to sign up. It normally requires some integration with the application.

We choose Radiant for our CMS when working on internal projects. The reason we like it is for it’s simplicity and power. In this post I’ll go through the different ways we’ve experimented with to integrate our SaaS applications with Radiant based websites.

1. Completely separate

The first scenario is the simplest. We just keep the website and application completely separated. When the user clicks to sign up they are taken to a form running in the application.

Example: www.sonarhq.com

Pros

• Very easy.

Cons

• We have to make a sign up form somewhere. In this scenario it’s easier to do that on the application side, but that means getting the design of that page to match with the website. Doing it this way means that you can’t really have the sign up form on the homepage.
• You can’t edit the sign up page content through the CMS.
• Having two separate administrative interfaces, one for editing the CMS and one for the SaaS application. This is okay, but it involves more work setting up. For an application where users sign up for an account it also means having that extra admin layer, which is a bit confusing.

2. Completely integrated

Radiant’s extension system is very powerful. You can actually write a whole Rails application as an extension. This makes it really easy to integrate both the public side and the administrative side of the site.

For some applications this method works very well and reduces complexity.

This recent blog post by Jim Gay, the lead developer of Radiant addresses some of the issues with integrated applications.

Example: www.smartmove.co.nz

Pros

• It’s reasonably easy to set up.
• Everything is completely integrated. You can have the sign up form anywhere you want. You can create Radiant tags to integrate with editable content. You can add tabs to Radiant’s admin interface for your own admin pages.

Cons

• You have to battle with a slightly different setup. It’s not too big a of a deal, but it does have an effect. For example, I’ve found it harder to get the specs running.
• You’re effectively tied to the version of Rails used by Radiant. You can’t upgrade Rails without updating Radiant, and you can’t update Radiant without updating Rails.
• Radiant has built in user and role models, which you have to work around to avoid conflicting with the way you want to set up models for your own application.
• You have to careful that you don’t end up customising Radiant. If that happens you might find yourself in the position of never being able to upgrade it, and being stuck with that version forever.

3. Admin API and Radiant extension

With this method your application exposes a locked down administrative API. A simple Radiant extension uses the API to allow sign ups and perform administration.

While this is a more complex solution, it really provides the best of completely separate and completely integrated. You can maintain different Rails and Radiant upgrade paths, but you can still have all of the administration happen in the Radiant backend. You can even build it out to do other interesting things. For example, having a Radiant website that administrates several applications.

Example: www.intuitionhq.com

Pros

• Separate codebases.
• Single place to administrate both applications.
• Sign up form can be placed anywhere on the marketing site.

Cons

• Complicated to setup.
• You must consider the security of your administrative API.

Conclusion

I would avoid having a completely separate website and SaaS application again – it seemed like a good idea, but ended up not working that well.

Integrating with Radiant is a really nice solution. I would consider it for any application that fits the following:

• Can and will be developed very rapidly
• User/Role system fits in with the one provided by Radiant

For all other cases I would expose an admin API and write a simple Radiant extension around it. This seems to be the most future proof, while not taking away any flexibilty. I’d be interested to hear how other people integrate a marketing site with their SaaS applications.

It’s been a busy time here at Boost, and we have just released our new web usability testing application IntuitionHQ. I’ll be writing a post about IntuitionHQ soon, but today I’d like to talk about hosting.

When we launched SonarHQ in April we decided to host on Slicehost. There were two main reasons we went with a virtualised hosting solution. The first was that we were not sure whether we would be scaling vertically (bigger, faster servers) or horizontally (splitting different functions onto different servers), and the second was the we wanted to be able to scale up and down in a fine-grained way.

Our initial approach with SonarHQ was to have 2 applications servers, 2 database servers and a utility server (for background tasks including mail). This approach gave us some redundancy and the ability to scale in either horizontally or vertically as needed. This has worked well, but we didn’t feel that the performance/price ratio is particularly good.

During our initial testing, we had IntuitionHQ setup at Slicehost in the same way. As we were preparing to launch, Engine Yard released Engine Yard Cloud. Built on top of the Amazon cloud infrastructure, Engine Yard Cloud provides a managed instance and configuration engine specifically optomised for hosting Ruby on Rails applications.

It was easy and painless to get IntuitionHQ up and running on Engine Yard Cloud – taking under an hour from start to finish. I don’t think it could have been any easier – everything just seems to work! We fired up a small instance and put through a quick series of load tests. It was evident even with casual clicking through the application that we were getting better response times. Working through the likely costs for hosting on Engine Yard Cloud, we found that we could use a 32bit, 5 ECU, 1.7GB RAM  instance for around the same cost as our previous setup and get a useful boost in both performance and manageability.

One of the most significant benefits is the ability to scale vertically all the way to a 64bit, 20 ECU, 68GB RAM instance with a simple restart. Scaling horizontally is just as easy, and Engine Yard Cloud really takes the pain out of this.

Another important benefit has been the streamlining of our deployment processes. Engine Yard takes care of everything needed for automated deployments, and any custom deployment tasks are easily handled with Chef recipes. Deploying multiple application instances is easy and works seamlessly, with Engine Yard implementing a proxying system with failover across all instances without the need for a separate proxy instance (and single point of failure) – a significant cost saving. Running a seperate instance (or set of instances) for the databases is as easy as ticking a checkbox.

The image used for the instance is kept up to date with the latest security and reliability patches and is used each time our application is deployed. This gives you a semi-managed hosting system without any of the associated costs.

The margin over standard Amazon EC2 is reasonably high for the small instances but reduces to a 10% premium on the biggest instances. This is very reasonable and for us makes a great deal of sense.

The one thing that would make this much more affordable is the ability to use Amazon reserved instances. These give you a discounted hourly rate for the instance once a one off payment is made. If you know what you need and can commit to a year, this can effectively half the hosting costs.

We launched IntuitionHQ a week ago and have been extremely happy with the performance and utility of Engine Yard Cloud. We are looking forward to growing IntuitionHQ and are confident that Engine Yard Cloud can grow with us.

I recently found squirrel, and I wanted to use it for a project we’re working on to simplify some complex finder statements. Squirrel allows turning something like this:

Task.find(:all,
  :conditions => [
    'active = ? and (updated_at > cache_version or cache_version IS NULL)', true
  ]
)

into:

Task.find(:all) do
  active == true
  any do
    updated_at > cache_version
    cache_version.nil?
  end
end

The problem is testing

Then I ran into a serious problem – how to test this piece of code using rspec? Here was my first attempt:

it 'should find all active tasks where updated_at is greater than cache_version or cache_version is null' do
  Task.should_receive(:find).with(:all).and_return(@tasks)
  Task.update_cache
end

This doesn’t test the search conditions at all. So I moved on to yield:

Task.should_receive(:find).with(:all).and_yield
 received unexpected message "active"

Then I started adding in the expectations:

Task.should_receive(:active)
Task.should_receive(:find).with(:all).and_yield

But how do I know that active is being compared to true? Now I’d have to use a mock to do that:

mock_active = mock(:active)
mock_active.should_receive(:==).with(true)
Task.should_receive(:active).and_return(mock_active)
Task.should_receive(:find).with(:all).and_yield

As you can see, this is getting quite painful. So it was time to abstract this out into something more meaningful. I created a class called FindWithSquirrel:

class FindWithSquirrel
  include Spec::Matchers
 
  def initialize(klass, expected)
    @klass = klass
    @expected = expected
  end
 
  def verify
  end
end

And I added a way to gain access to the class:

class Class
  def should_receive_squirrel_find_with(expected)
    FindWithSquirrel.new(self, expected)
  end
end

Now the new class needs to extend ActiveRecord to override find and record what happens:

class FindWithSquirrel
  def initialize(klass, expected)
    ...
    extend
  end  
 
  def extend
    @klass.class_eval %Q{
      def self.find_with_finds
        @find_with_finds ||= []
      end
 
      def self.find_with_find_with(*args, &blk)
        find_with_finds << find_without_find_with(:query, &blk).to_find_conditions
        find_without_find_with(*args, &blk)
      end
 
      class << self
        alias_method :find_without_find_with, :find
        alias_method :find, :find_with_find_with
      end
    }
  end
end

So now I’ve got a variable on the model class holding an array of generated conditions. I can fill in the verify method:

class FindWithSquirrel
  def finds
    @klass.find_with_finds
  end
 
  def verify
    finds.should include(@expected)
  end
end

That’s all fine, but now I need to make rspec actually call my verify method. I can do that by reusing the way rspec mocks work. I can do that by adding my class instances to the same array that rspec adds it’s mock expectations:

class FindWithSquirrel
  def initialize(klass, expected)
    ...
    $rspec_mocks.add(self) unless $rspec_mocks.nil?
  end
end

Now the rspec mock framework is expecting to call the methods ‘rspec_verify’ and ‘rspec_reset’, so:

class FindWithSquirrel
  alias_method :rspec_verify :verify
  def rspec_reset
  end
end

Now I can run this spec, and it works great. But it seems to break all the subsequent specs that also use the find function. I have to flesh out that reset function a little. Remember my earlier extend function – I need to remove my ActiveRecord extensions:

class FindWithSquirrel
  def unextend
    @klass.class_eval %Q{
      class << self
        alias_method :find, :find_without_find_with
      end
    }
  end
 
  alias_method :rspec_reset, :unextend
end

So what does my spec look like?

it 'should find all active tasks where updated_at is greater than cache_version or cache_version is null' do
  Task.should_receive_squirrel_find_with(
    ["(tasks.active = ? AND (tasks.updated_at > tasks.cache_version OR tasks.cache_version IS NULL))", true]
  )
 
  Task.update_cache
end

So the class is testing that squirrel is outputting the correct conditions. You could argue that squirrel’s own tests fulfill this testing need, but this class gives a good jumping point to testing that squirrel is receiving the correct parameters. The full file can be found here. Just include it from your spec_helper.

When writing a Rails application, how do you decide on the best indexes to add to your database? It might seem obvious, especially if you work on a project from scratch. The problem is a little harder when you come to optimize an existing codebase.

New Relic

Recently I’ve been using two methods to work out where to put indexes. Firstly I’d strongly recommend using New Relic RPM in development mode. When running your application you can visit /newrelic to get all kinds of useful information. Here you can see the most recent rails calls:

And you can drill down to see the database calls:

And then you can drill down further to see a statement analysis. This will give you information like so:

So this will tell you that there are no keys used, and no possible keys to use. If you now create a migration as follows:

class CreateIndexes < ActiveRecord::Migration
  def self.up
    add_index :projects, :account_id
  end
end

Now run the query again after migrating:

But we could do better. Notice that in the extra field it says “Using filesort”. This means that MySQL is doing a normal sort using the row data. If projects are usually selected by account_id and ordered by position then we have a good case for sorting by index. We can’t just add an index on the position column as this won’t be used (try it and you’ll see exactly the same results). Instead we have to add an index that covers both account_id and position:

add_index :projects, [:account_id, :position]

Now looking in RPM again you’ll see things change to:

Overriding execute

I talked about using two tools to work out where to put indexes. New Relic is great and gives lots of useful information, but I wanted to see what queries were running without indexes as the application was used, in order decide if they required optimizing. I placed the following (ugly) snippet of code into the development or staging environment file:

config.after_initialize do
  unless ActiveRecord::Base.connection.respond_to?(:old_execute)
    ActiveRecord::Base.connection.class.class_eval do
      alias_method :old_execute, :execute
 
      def log_explain(str)
        if str =~ /^SELECT.*WHERE/i
          results = old_execute('EXPLAIN %s' % str)
 
          while row = results.fetch_row
            if row[5].blank?
              File.open(RAILS_ROOT + '/log/sql.log', 'a') do |f|
                f.puts str
                f.puts row.inspect
              end
            end
          end
        end
      end
 
      def execute(*args)
        log_explain(args.first)
        old_execute(*args)
      end
    end
  end
end

This performs a similar task to RPM in that it runs MySQL’s EXPLAIN statement on each SELECT statement that runs. However, I’ve set it up to filter out any statements that are already using keys (if row[5].blank?). Now by tailing the file log/sql.log I’ll be able to see any unindexed queries that are running on the database. I can use this information to quickly run through the whole application to find any problem areas.

What not to index

Most of the database calls from a rails application are going to be quite generic, the same thing over and over, and indexing is good in this situation. Some database calls are going to be a little different – think search, statistical count, etc. You’ll need to think careful if these require indexes or not, considering how often they’re run, and how fast they need to be. Caching can be a good replacement in these areas. Also take into account that indexes slow down database writes, and indexes on string columns are going to be much more intensive that indexes on integer columns.

Load testing

Of course you might not find all problem areas, or you might not be optimizing the correct queries. These methods should give you a good idea, but they’re no replacement for doing good load testing on your application. We’ll be posting more about load testing a rails application in the future.

We’ve just released a new client library for accessing the digitalnz.org’s search API. This library uses nokogiri for speedily parsing the XML, making it faster than an existing dnz client library using JSON parsing.

Installation

sudo gem install dnz-client

Or for the bleeding edge (if there is one):

sudo gem install boost-dnz-client

You’ll need to have an API key from digitalnz.org

Examples

Simple search

require 'dnz/client'
 
client = DNZ::Client.new('api_key')
search = client.search('otago')
 
search.results.each do |result|
  puts result.title
end

Fetch all categories

require 'dnz/client'
 
client = DNZ::Client.new('api_key')
categories = client.categories
 
categories.each do |category|
  puts "Category %s has %d results" % [category.name, category.count]
end

Fetch a facet

require 'dnz/client'
 
client = DNZ::Client.new('api_key')
search = client.search('otago', :facets => ['category'])
 
search.facets['category'].each do |category|
  puts 'Search for otago has %d items in category %s' % [category.count, category.name]
end

On several occasions we’ve looked at Rails projects with no tests, or very low test coverage. Trying to write tests when you didn’t write the original methods is difficult. Here are some tips that we’ve found useful.

Use your favourite framework.

If there is a large body of existing tests using a particular framework, write your new tests in that framework. If there are few or no tests then strip out anything already there and replace it with your preferred framework. At Boost we’ve decided to use RSpec for all our projects. Your objective here is to write tests, not to learn a new way of writing tests.

Don’t fix bugs!

If you discover what you believe to be a bug while writing tests, consider that you don’t know why the bug is there. You should write your test to pass the code as is. Describe the bug in your bug tracker and move on. I’ve fixed bugs while writing tests only to find that the side effect breaks something else – but I had no tests so there was no way to know.

Start with the basics

The easiest way to get started is to write a test for every method, action and view that just runs without asserting anything. This will get your test coverage up. Running over the whole code base allows you to catch exceptions caused by typos. Doing this will also give you a good starting overview of the code base. Using a tool like ZenTest, or a recently posted rake task unspec’d, will help find everything to test.

Mocks and Stubs

Obviously you’ll be using mocks and stubs, but be careful not to stub out too much. Get a test in for every public method, and don’t stub out private methods.

Test your own code

Make sure that you write comprehensive tests for any code you add to the project. Never use the lack of existing tests as an excuse for not writing your own.

Any finally, don’t give up hope! For any reasonably complex project it is nearly always faster to implement the tests/specs than to rewrite the whole thing from scratch. Writing tests is actually a really good way to learn a foreign code base.

Getting user and group information from Active Directory via LDAP is nearly easy, but I came across one hurdle. If you retrieve a user, you might get something like this:

{
  :smaccountname => ['jeremy'],
  :dn => ‘["CN=Jeremy Wells,CN=Users,DC=domain,DC=boost,DC=co,DC=nz"],
  :primarygroupid => ['1114'],
  :objectsid => ["010500000000000525000000\210B ?\23302r\255ոT040000"]
}

If you then wanted to get the users primary group, you’d need to search using that primary group id. But you’d find there is no corresponding id on the group object, which looks as thus:

{
  :samaccountname=>["Students"],
  :dn=>["CN=Students,OU=Groups,DC=domain,DC=boost,DC=co,DC=nz"],
  :objectsid=>["010500000000000525000000\210B ?\23302r\255ոZ040000"],
  :name=>["Students"]
}

But notice the binary field :objectsid. This is the binary form of the string you may see sometimes when using AD, called SID, and it looks something like “S-1-5-21-123-456-789″. In order to find the users group you would take the :primarygroupid and the users :objectsid to generate the groups SID.

Space Intruder Detector (SID) UFO © ITV Global Entertainment

Only the last group of numbers in the SID corresponds to the current object, so to find the SID for another object we can just take off the last number group and replace it with the :primarygroupid, 1114. However, first we need to convert the binary string into a SID string.

The binary form of the SID is as follows:

• byte 1: SID structure revision (always 1, but it could change in the future). This becomes the first number group.
• byte 2: The number of sub-authorities in the SID. This is discarded for the string, but you can use it to work out the number of number groups ahead.
• byte 3 – 9: Identifier Authority. This field should be converted to hexadecimal as the second number group.
• byte 10 onwards: A variable length list of unsigned 32bit integers, the number of which is defined in byte 2.

Here is ruby code for doing the conversion:

def get_sid_string(data)
  sid = []
  sid << data[0].to_s
 
  rid = ""
  (6).downto(1) do |i|
    rid += byte2hex(data[i,1][0])
  end
  sid << rid.to_i.to_s
 
  sid += data.unpack("bbbbbbbbV*")[8..-1]
  "S-" + sid.join('-')
end
 
def byte2hex(b)
  ret = '%x' % (b.to_i & 0xff)
  ret = '0' + ret if ret.length < 2
  ret
end

Note: Originally I was using unpack with L* instead of V*. My tests were passing fine on my machine, but not on our CI server. As it turns out the endiness of L is dependent on the processor, and the CI is an old PPC G4.

Using the SID string you can now do an LDAP search with Net::LDAP::Filter.eq(“objectSID”, sid_string) to find the user. Replace the last number group with that from :primarygroupid and it’ll find the group. So if the user SID is S-1-5-21-123-456-789 and the :primarygroupid is 1114, the group’s SID will be S-1-5-21-123-456-1114.

On the 25th of February ’09 I did a brief JRuby presentation on JRuby and how we’re using it at Boost. We’re really excited about some of the capabilities of JRuby.

We’re running a client deployment on Tomcat fronted by IIS, and it was really easy to get everything set up. We wanted to try another deployment on Glassfishv3 with no webserver in front. Unfortunately (and glassfishv3 is still in development) there were two barriers that prevented us doing so :

• Exessive memory consumption: 2 rails apps + the admin interface = more than a 1G slice could handle.
• SSL: I was so close to getting this working, but several hours of working on this is too much, it should be easier.

In conclusion, JRuby isn’t quite ready for our in house projects where we control the deployment, but it is great for Windows deployments. We’ll keep an eye on it. JRuby 1.2 was released just a few days ago with performance increases.

Download the presentation.