A quick background lesson: Obviously, not every part of the world is in daylight at the same time, when it is the middle of the day in Australia, it’s the middle of the night in the United States. To make sure midday means the same thing in Perth as it does in Atlanta, the world is broken up in to timezones revolving around Coordinated Universal Time (UTC) that runs through Greenwich, UK (which is why UTC is also called Greenwich Mean Time or GMT), ranging from -12 GMT to +14 GMT.

Since every timezone is defined in respect to this imaginary zone time, it would make sense to use that as a base in our timezone coding adventure. In Rails, you can tell ActiveRecord to save all dates as UTC by setting the following value in your /config/environment.rb:

config.time_zone = 'UTC'

The most obvious and simple way to calculate localtime, would be to add the offset to the current time in GMT - and if that is all you needed to do, I could conclude this article right now, but alas, it’s not always that easy because of daylight savings.

The theory behind daylight savings time (DST) is to shift the localtime forward an amount of time (usually an hour), making the sun seem to rise and set later, meaning you have more time to do stuff after work. Unfortunately, it just means you stay at work longer trying to work out all this timezone stuff. It wouldn’t be so bad if every country adopted DST on the same day, but the reality is that not all countries have it, each one adopts it at different times (in fact, it’s not uncommon for regions WITHIN a country to adopt it at different times), and not all countries advance it by a standard hour.

So what are we to do? Thankfully, there are a set of libraries called the zoneinfo database (or Olson database) that basically documents each and every DST transition for each country. The gem tzinfo is the Ruby version of this library, and before Rails 2.1, you would need to work with that library (maybe with the help of a plugin) to make timezones work, but now it is baked into Rails 2.1 and above.

The first step would be to store your users timezone information. The simplest way to do this is to store their timezone string against their user details, which I like to do using a grouped select tag:

<select name="user[timezone]" id="user_timezone">
  <%= option_groups_from_collection_for_select TZInfo::Country.all.sort, "zones", "name", "identifier", "friendly_identifier", @user ? @user.timezone : nil %>
 </select&gt

Which will save entries like “Australia/Melbourne” or “America/Los Angeles”. Next, you just need to tell Rails what timezone each request is in, which is now extremely simple using the Time.zone= method. Call this method in a before_filter in application.rb and it will set the timezone for each request:

def timezone_manager
  Time.zone = current_user.timezone if current_user && current_user.timezone
end

Nice and easy! Every time you user or print out a timezone, it will be in the users local zone.

If you want to find out about more of the stuff you can do with the Rails 2.1 timezone support, check out the fantastic tutorial at: http://mad.ly/2008/04/09/rails-21-time-zone-support-an-overview/

So what is meta programming? It is basically a way of modifying programs dynamically, like adding or changing methods AFTER the program has started running (or at runtime as we like to call it).

A great example of this is the find_by_* methods in rails. If you have a model called “User” that has a column called “age” you can search your records by age using the magic method User.find_by_age. This is accomplished using the method_missing method.

If you call a method that doesn’t exist, Ruby will call the method_missing method, and pass the name of the method and any arguments you supplied, which means you can dynamically handle the method.

class MyClass
  def find(name, value)
    puts "You want results from #{name} with a value of #{value}"
  end

  def method_missing(id, *args)
    return self.find(Regexp.last_match(1),  args[0]) if id.id2name =~ /find_by_(.+)/
    raise NoMethodError
  end
end

m = MyClass.new
m.find('name', 'madpilot')
> You want results from name with a value of madpilot
m.find_by_name('madpilot')
> You want results from name with a value of madpilot
m.search_by_name('madpilot')
> NoMethodError: NoMethodError

As you can see, there is definitely no “find_by_name” method, yet Ruby is smart enough to call the find method with the correct parameters. What we have done is to run a regular expression against the name of the method, and if it matches the pattern find_by_[string] then it calls the find method with the [string] part as the first parameter and the first argument as the second parameter. Pretty powerful, don’t you think?

Just a tip though - be careful of endless loops - if your method_missing method doesn’t terminate and you call a method that doesn’t exists inside method_missing, you’ll be in all sorts of trouble!

Whilst on the topic of speed, using static pages for any pages that need to be, well, static is always a good idea. Railscast has a new screen cast entitles Semi-Static Pages.

If are a Capistrano n00b, or you have been meaning to have a look at it, why don’t you join the Online Capistrano Tutorial Session, held via Campfire next week. It will be on July 15 at 7pm MDT (what ever timezone that is) and will be given by Rails core-contributer Jamis Buck. I’m personally intrigued as to how this will work, so I might even log in to check it out.

Until next time!

Simon Harris from My hovercraft is full of eels describes a simple way to break up you tests into DRY, manageable chunks: http://www.redhillconsulting.com.au/blogs/simon/archives/000429.html

Ben Mabey shows you how to use Macros in RSpec, using Shouda. Macros are as old as the hills, but can be really handy to organise many tasks simply: http://www.benmabey.com/2008/06/08/writing-macros-in-rspec/

Michael Ivey reminds us why we should use tests. Not only are they a nice support net, but they encourage us to write better code. It’s like extreme programming without the other programmer: http://gweezlebur.com/2008/6/13/tests-make-you-write-better-code

Outside of the testing arena, a new version of Capistrano — possibly the coolest tool for Ruby — has been released. If you haven’t had a play with Capistrano yet, go and install it and try it out.

And finally for this week, if you have ever been perplexed about whether pieces of code belong in the Model, View or Controller, Starjuice has an article that may give you a clue or two, so you can ensure you code is separated properly: http://starjuice.net/2008/6/model-view-or-controller

This week saw the release of of version 2.1 for Ruby on Rails. You can see the announcement on the official Rails blog.The new major features are:

• Time zones (by Geoff Buesing)
• Dirty tracking
• Gem Dependencies:
• Named scope (by Nick Kallen)
• UTC-based migrations
• Better caching

IronRuby runs Rails

The IronRuby team also announced this week that they managed to get a “Hello World” example running on an unmodified Rails stack. Although it’s not yet ready for prime time, we are one step closer to being able to run Rails on .NET. See the announcement on Jon Lam’s blog.

RailsConf

RailsConf was held in Portand this week. Unfortunately a trip to the US was stretching the budget a little, so if you were like me and unable to make it, check out Gregg Pollack’s video compilation of a number of interviews he had with some of the speakers. RailsConf in 36 Minutes.

Until next time Railers!

In the past month, record downtime has prompted fresh outcry within its ever-growing user base. This, along with increased attention from mainstream media has forced Twitter to publicly acknowledge these issues, and to reveal a few details about the source of these problems.

Though there has been much speculation about the source of Twitter’s performance issues, the closest we have had to a real peek under the hood has been this Twitter Developer Blog post:

Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency’s sake, Twitter was built with technologies and practices that are more appropriate to a content management system.

But wait, what exactly do they mean by “technologies and practices”? Could they mean Ruby on Rails?

Twitter and the Curse of the Framework

Ruby on Rails is a Model-View-Controller (MVC) framework. To build an application in Rails, you start by defining a collection of objects that model the things your application will do, then you write controllers that juggle your model in response to user requests, and finally you write the views that present your application to its users.

As separate as these three elements are, the performance of an app can depend largely on how they work together. If your model isn’t optimized for the way your controllers will use it, you could find yourself facing some surprising performance issues. This is the kind of problem that I expect Twitter is faced with.

Let’s look at a simplified example of what Twitter’s problem might look like on the inside.

Twitter is a site where users post short messages called Tweets, and follow the Tweets of other users. When the original developers behind the site first sat down to define their model, the simplest thing to do would have been to have a database table for all the Tweets, another table for all the users, and a third table to keep track of who is following whom.

This approach closely resembles the model you might build for a content management system (CMS) like a blog: each post has an author, so you can easily get a list of all the posts (i.e. Twitter’s public timeline), or just the posts in a given category (e.g. my tweets).

What this fails to take into account is the most common type of request that Twitter receives: show me the most recent tweets from just the users that I’m following. With a CMS-style model, this common request will generate a lot of work for the application, as it has to filter the timeline of Tweets for each individual user.

If the original developers of Twitter had realised just how many requests of this type it would be fielding, Twitter’s model would probably have been designed very differently. As mentioned in the blog post quoted above, Twitter really is a messaging system, and its model should reflect that.

Here’s how the model of a messaging system might look: whenever a user posts a Tweet, the model looks up which users are following the author and places a copy of the Tweet into those users’ private timelines. Tweets are queued up for their recipients when they’re posted, shifting the processing burden away from the more common “show me my tweets!” request.

Now, let me be clear: both models could be built with Ruby on Rails. The CMS-style model is just the direction that the framework will lead you in if you don’t stop and think about the characteristics of your application. Any good framework will handle for you the things that most web applications have in common, so you can focus on the unique aspects of your app. The curse of the framework is that it can be very tempting to let the framework take the lead in handling those unique aspects too.

The fact is, Twitter’s developers were in a hurry, and took every opportunity to let the framework do the thinking for them. Just about every general-purpose web framework out there would have led them down the same road. “The fault, dear Brutus, is not in our stars, but in ourselves.” The message here is not that Rails is a bad framework—just that no framework can do the important thinking about how an app should work. That’s what developers are for.

Like any framework, Rails has strengths and weaknesses. Those who love Rails believe that its strengths—the virtual elimination of the scutwork of building web apps using a fresh, expressive programming language—far outweigh weaknesses like scaling being a non-trivial undertaking. Truth is, if you’re building a service intended for mass adoption and you don’t design it to support that, no framework in the world is going to keep your app from collapsing in on itself.

SitePoint’s new book, Simply Rails 2 is now available. Get it, and build your own Twitter killer. :-)

It’s called Simply Rails 2 and is available for purchase right now in PDF or Printed format at sitepoint.com.

Grab the printed version for just $39.95 or the PDF version for just $29.95.

With Simply Rails 2 you’ll learn how to build bulletproof Web applications from scratch, with more features using less code.

Patrick’s updated the entire book to take advantage of all the new Rails 2 features. It’s the only beginner’s book we know that’s Rails 2 ready…

Inside the book you’ll learn how to:

- Build and deploy your own Rails web application.
- Reap the benefits of using best-practice MVC architecture.
- Use Rails’s Ajax features to create slick interfaces.
- Interact with databases easily using ActiveRecord.
- Add the magic of REST to your apps with Rails Resources.
- Use plugins to enhance your applications easily.

Simply Rails 2 will show you that there is a simple and easy way to build web 2.0 applications.

Grab yourself a copy today!

I covered some of the alternate Ruby implementations previously.

Congratulations to the team!

Updated timezone support

Timezones will finally become a first class citizen in Rails. You will be able to set the timezone, and all subsequent time calls will be with in that zone.

Time.zone = "Australia/Perth"
Time.zone.now # will return something like Wed, 24 May 2008 22:56:00 WST +08:00

Better Gem dependencies

If you rely on gems in any of your projects (and why wouldn’t you? Code re-use and all that), you may have come across the pain of gem versioning. Rails 2.1 will allow you to stipulate what versions of each gem you need.

config.gem "chronic", :version => '0.2.3'

It also adds a rake task that will automatically install the right gems for you.

rake gems:unpack

Improved caching

Previously, the only caching options Rails developers had was based around file fragments, which is fine for single server setups - but scaling that up to multiple servers could cause synchronisation issues, causing your cache to go stale. To combat this, you can now use a number of other shared caching systems including a memory store, drb store and a mem-cache store.

All very exciting stuff, and well worth a checking out. If you can download the beta gems by running the following from your trusty terminal window:

gem install rails –source http://gems.rubyonrails.com/

Although Mongrel did a sterling job, I have never been a big fan of having two points of failure - problems with either Apache or Mongrel would render your site unreachable. Not only that, adding capacity to your system required adding a number of mongrel instances, each with it’s own port and each with it’s own memory overhead, which can get very messy for shared hosting providers.

Passenger will allow hosting providers to install one Apache module, requiring the client to simply upload their application - no permission issues, or troublesome configurations files. However, it is also very useful for a developer - instead of having to run script/server when testing your application, you can install a local version of Apache, setup a few virtual hosts, and have instant access to your test sites.

Currently, Passenger only runs on *NIX type environments, eg Linux and OSX. The Phusion team have worked pretty hard to make the installation as simple as possible. Here are the basic steps:

1. Install Apache (check with your vendor for instructions)
2. Run gem install passenger
3. Run passenger-install-apache2-module

Passenger should now ask you a few questions, which if you answer correctly, should complete the installation.

Restart Apache and create a virtual host file, which points at your Rails application, and you are away! The following virtual host file will tell Apache to respond to the url http://test.localdomain with the Rails application in /home/sites/test.

<VirtualHost 127.0.0.1:80>
    ServerName test.localdomain
    DocumentRoot /home/sites/test
</VirtualHost>

If you are using passenger for development, make sure your apache2.conf file has the line RailsEnv development.