An interview at RubyInside recently suggested that Rails developers who want to be hired should maintain a Rails-related blog.

I’ll add to this and say that every beginning Rails developer should write their own blog software. It’s a great learning experience and you can try things that aren’t possible with just an app running on localhost. It’s also a great environment for learning without the pressure of a mission-critical app. When you’re working for a client and deploying an important application, you’ll have made all the beginner mistakes on your own time (hopefully).

This blog started on shared hosting with Typo software. I later switched to a VPS with 128 MB RAM and currently run on a RailsMachine VPS with 512 MB RAM.

In the process, I’ve learned a lot about

• Running Rails on a shared host (don’t do it!)
• Deployment and automation with Capistrano (do it!)
• Unix server administration
• Process monitoring and uptime
• Rails development
• Merb development
• Application design and asynchronous processes
• Optimizing for speed
• Reporting and log parsing

If you need a blog for your business or for a client, I would definitely check out Mephisto, Radiant, or Simplelog. But if you’re thinking about starting a blog for yourself, you should write your own from scratch. It only requires 2 controllers (Articles and Comments) and apparently some guy even filmed a screencast showing you how to start one in only 15 minutes.

Every developer’s favorite topic: Performance

A Wordpress lecture mentioned the fact that a standard Wordpress install on a given server only achieves about 8 requests per second. The way they get it up to 300 req/sec is not by profiling loops and optimizing method calls, but by caching as much as possible.

The biggest speed benefit you can get is from page caching. However, that entails writing a bunch of code to expire the cached pages when articles are edited, comments are made, or templates are changed.

Expiration by Key Name with Memcached

Recently, I decided to try out some caching strategies I had read about¹. The idea is to use memcached to store objects with keys that will automatically expire when the item changes.

For example, this page you are reading needs to expire if the article is edited or if new non-SPAM comments are posted.

So I’m caching the entire rendered page in memcached, with the article’s ID, timestamp, and number of comments in the key. In memory, that’s something like

"Articles:show:11097:1197661574:11"

This way, there’s no need to explicitly delete cached items. The application will ask for a new page when the data changes, and if memcached is full it will clear out the older, unused items.

Implementation

NOTE: You’ll need to have a memcached server running. I wrote a previous article about how to do that.

I’m using this technique both on my blog and at PeepCode.

First, I’ve put most of the key logic into the Article model.

class Article < ActiveRecord::Base
  def cache_key
    "#{self.class.name}:#{id}:#{updated_at.to_i}:#{ham_comments.length}" 
  end

For this blog (using Merb), the controller is pretty simple since render returns the HTML that was generated.

# Articles controller
def show
  @article = Article.find params[:id]
  Cache.get("Articles:show:#{@article.cache_key}", 1.hour) do
    render
  end
end

I’ve also wrapped it in some extra logic that doesn’t use the cached version if there is a flash message to display.

For PeepCode (using Rails), I wrote a render_cached method in the ApplicationController that handles more of this automatically. It takes a key, an expiration time, and a Hash of options that will be sent to the Rails render method.

Here’s how it’s called:

render_cached(@article.cache_key, 1.hour, :action => "show")

The render_cached method does several things:

• It builds a key that includes the controller name, action name, and format being rendered. This ensures that HTML is cached separately from XML.
• It uses the render_to_string method to generate the template as a string, or render :text to send back the cached version.
• If checks a should_cache? method to see if caching should happen. This is different from Rails’ internal development/production caching. Instead, it’s a controller-specific method that can turn off caching in some circumstances. By default, I use no caching if someone is logged in or if there is a flash message to display.

def render_cached(key, expiration, render_options)
  return unless perform_caching
  if should_cache?
    combined_key = [
      'controller',
      controller_name,
      action_name,
      params[:format] || 'html',
      key
    ].join(':')
    output = Cache.get(combined_key, expiration) do
      render_to_string render_options
    end
    render :text => output
  else
    render render_options
  end
end

The should_cache? method looks like this:

def should_cache?
  (current_user.nil? && current_order.nil? && flash[:notice].blank?)
end

Summary

Overall, this has worked quite well. The most frequently accessed pages turn out to be pretty responsive. The cached versions perform much faster and there’s not a single line of cache-expiring code.

Raw performance numbers from pl_analyze (requests per second, controller and action names omitted):

And a word from our sponsor…

I’ve got several authors working on some great PeepCode PDF books. They will be published in the next few months.

Currently, many people have found Ryan Daigle’s Rails2 PDF to be useful for getting up to speed with Rails 2.0.1. It’s even available in Español and will soon be available in a few other languages, too.

I refilmed the Capistrano 2 screencast from scratch. It’s mostly the same content as the first Capistrano screencast, but is up to date for the new namespaces, callbacks, and other features of Capistrano 2.

The Rails from Scratch series has been updated with code and notes about Rails 2.0.1 compatibility. It’s a free update if you purchased it in the past.

Finally, I published a screencast on Git a while ago. I’m using Git wherever possible and really love the speed, easy branching, and flexibility in areas that were frustrating in Subversion.

Resources

¹ Articles about auto-expiring memcached keys:

• The secret to memcached
• Clever caching
• Caching makes your brain explode
• Intelligent fragment cache