by Mitchell Hashimoto on July 18, 2008
I’m a big fan of researching and playing with new technologies (hey! I remember rails 0.7) so its no surprise that I’ve been playing a lot with Ruby Enterprise Edition and Phusion Passenger (mod_rails) and researching it as a viable rails deployment solution. For those of you who are staying with the tried and true Nginx + Mongrel, let me offer a brief introduction to Phusion Passenger (mod_rails). But first… let’s take a trip down memory lane:

Phusion Passenger is super easy to install and setup as an Apache mod and immediately simplifies the deployment of rails. It allows you to deploy a rails application without splitting your attention between the web server and app server, such as Nginx and Mongrel. You literally upload a configuration which looks like the following block of code to Apache and it manages your rails application for you.
ServerName myrailssite.com
ServerAlias www.myrailssite.com
DocumentRoot /var/www/rails-project/current/public
Passenger gives rails the same ease of deployment as mod_php and mod_perl. And when you want, it will automatically reload your app if you deploy changes.
But the real gem is using Phusion Passenger with Ruby Enterprise Edition, which is a rewrite of the Ruby MRI with optimization for mod_rails in mind. The initial benchmarks show that using both together results in lower memory usage and increased requests per second. Since then, passenger has had a myriad of early adopters reporting their results. DreamHost praised Phusion for finally solving their rails deployment, after complaining only 4 months earlier of how rails deployment options were a joke. Other websites have boarded the Phusion Passenger train too, reporting easy setup and even easier deployment.
The results look good: Dead easy rails deployment with great performance.
So how do you get started? For dead easy server provisioning, check out Sprinkle, a gem which provisions servers for you. I’ve been hard at work implementing new features and patches to Sprinkle, which you can see in my fork. I have already created the sprinkle scripts to automatically setup this entire stack on a fresh ubuntu server:
- Rails (and Ruby, Rubygems)
- sqlite3 or mySQL
- Apache2
- Phusion Passenger (mod_rails)
- Ruby Enterprise Edition
If you’re interested in the automatic setup solution, I recommend checking out the screencast I made detailing the entire process. It requires a custom version of the sprinkle gem (from my fork), which the screencast covers.
If you plan on trying it out and have any questions, leave a comment or feel free to contact me at mitchell.hashimoto [at] citrusbyte [dot] com and I’ll happily provide any assistance you may need.
I am actively working on PoolParty, but the website doesn’t necessarily show that the project is in active development.
Luckily, it is hosted at github and they have an API to access their changesets. Now, on PoolParty’s website, I am surfacing the latest changeset’s time, message and author as well as a link to the changeset.
How?
Code (shortened for brevity purposes):
$:.unshift(File.dirname(__FILE__))
require "rubygems"
require "yaml"
require "open-uri"
class Grab
@url = "http://github.com/api/v1/yaml/auser/pool-party/commits/master"
@refresh_after = 20
def self.latest_commit_object
o = yaml["commits"][0]
{
:message => o["message"].gsub(/\n/, ""),
:date => Time.parse(o["committed_date"]).timeago,
:by => o["committer"]["name"],
:url => o["url"]
}
end
end
The github api is slick. As you can see from above, the format for the api url looks like
http://github.com/api/version/format/username/repository/type/object
Where the variables there correspond to:
- Current version: v1
- Acceptable formats: json, xml, yaml
- Acceptable types: commits, commit
Grabbing the latest changesets from the url as YAML format, we can quickly and easily parse the message into a useful hash.
I personally like the “# hours ago” syntax that 2.0 sites are popping up with everywhere, so I just added a timeago method that is very similar to the one included with rails. The source is attached.
Since I don’t want poolpartyrb.com’s load time to be dependent upon how fast it can hit github, I cache the variable so every 20 views it refreshes.
Use in Rails
Save both the files (attached below) to your lib directory.
Add this to your environment.rb
require 'grab'
Then add this helper to your application_helper.rb
def show_latest_commit
@latest_commit = Grab.latest_commit_object
<<-EOS
Latest commit
#{@latest_commit[:message]}
by #{@latest_commit[:by]}
#{@latest_commit[:date]}
EOS
end
I use this on poolpartyrb.com, which is a sinatra site. I do basically the same as above, but generally render the code in haml instead
$:.unshift(File.dirname(__FILE__))
require "sinatra"
require 'grab'
get '/' do
@latest_commit = Grab.latest_commit_object
haml :home, :layout => :layout
end
Then in my home.haml
.note
%strong
Latest commit
%br
==
= @latest_commit[:message]
.highlight
== by #{@latest_commit[:by]}
= @latest_commit[:date]
Get the code here
edit: updated location of code
April 5, 2008
The trouble w/ fixtures
I don’t use fixtures in my specs. At all. The fundamental issue with fixtures is that they setup a state for your database as a whole (or at least the tables you loaded). So when you use fixtures all your specs are running against essentially the same state. As you build your [...]
Read the full article →
April 3, 2008
Here’s a little chunk of code I’ve been using recently. It gives you .add
and .add! methods on your has_many relationships that work similar to the << method. The difference is that .add sacrifices chain-ability in order to return the object being added to the collection.
Adding instead of concatenating
Using book.authors ‘Geoff’) returns true [...]
Read the full article →