Phil Burrows, Ruby on Rails Web Developer

Designing and Printing the Burrows + Gaskill Letterpress Invitations

Thu, 29 Apr 2010 16:59:57 GMT

I’ve had a letterpress for a couple years now; I absolutely love the thing, but rarely do I get the opportunity to put it to good use. Luckily, I’ve got four siblings, and [thusfar] they’ve all asked me to (or I’ve convinced them to let me) design and print their wedding invitations.

Designing the Burrows + Gaskill Letterpress Invitations

I've had a letterpress for a couple years now; I absolutely love the thing, but rarely do I get the opportunity to put it to good use. Luckily, I've got four siblings, and [thusfar] they've all asked me to (or I've convinced them to let me) design and print their wedding invitations.

The process of designing something for the most important day of someones life is a bit daunting in and of itself, but that task becomes even more so when that "someone" just happens to be a member of your family. In such situations, a part of me thinks: Gosh, if these don't look good or I screw this up, I'm gonna hear about it for the rest of my life.

Maybe I'm being a bit dramatic, but I take this stuff kind of seriously. And there's always (no matter what the project) a little part of me that wonders if I can produce something I'll actually be proud of — something that I know others will think is as good as I think it is. That kind of worry occasionally weighs heavy on my mind, and I think it might have been a bit of a hindrance in the early stages of this process. Let me explain…

Frustrating Beginnings

When the time came to begin work on my sister's invitations, I was eager but a bit hesitant; it took me a while to get fully motivated to begin, because nothing spectacular was coming to mind — everything I created in Illustrator or Photoshop looked awful, and no amount of pixel-pushing seemed to help. Normally, when a design doesn't seem to be working, brute force over a period of time — trying every different thing I can think of — eventually seems to get it to a point I'm satisfied with, but that just wasn't happening this time.

I went through half-a-dozen different mockups, and each new one was just as bad as the ones before. I wasted countless hours (days, really) on things that I hated. I'm pretty opinionated about design — either I love it or I hate it — and, I hated everything I produced.

Running out of time, I finally decided to begin work on something completely different than anything I had mocked-up to that point: a hand-drawn, flowery design. Things started out promisingly, but after finishing it up, I decided I hated it. It was unoriginal, rough and not very "wedding-y" for lack of a better word. Another two days wasted. This was, by far, the most frustrating design process I had been through in a long time (of course, the fact that I don't design nearly as often as I used to (or would like to) probably contributed to this).

After days of tedious failures, something finally clicked, and I had an idea.

A Breakthrough ( AKA: Freaking-A, Finally! ~or~ It's About Time )

The lightbulb finally came on around 11:30pm, two days before I needed to have the design completed. Knowing it could be awesome if done right, but horrible if not perfected, I needed to get approval from the sis before I moved forward. I quickly sketched something up and showed it to her. This was the initial sketch that she said "yes" to:

Looking back on that sketch, I have absolutely no idea why she said yes. I must have talked her into it (I did my best to convince her it would look much better when completed), but that sketch is awful. If the final invitations would have turned out looking like that, I would have been a little embarrassed. Luckily, Emily trusted me, and I began moving forward with new motivation and exuberance.

Long Hours

I've always believed that, if given enough time, I can do anything — I can perfect anything. I think to be brilliant at something, you have to have that kind of confidence. Confidence not just in your abilities, but confidence in your work-ethic and perseverance & persistence. You have to be willing to out work everyone else; you have to understand that perfection and greatness in something come with absolute hard work, and nothing less. Call it cockiness, call it whatever you want, but I think it's absolutely necessary if you're going to achieve great things.

A bit of an aside: John Nunemaker (of RailsTips & MongoMapper fame) has a great article (and a follow-up) that talks about the importance of hard work and how "talent" doesn't really matter if you have perseverance. When you're finished reading my article, you may want to head over there for a more complete thought on this side-topic.

The problem I had with these invitations was that I wasn't sure I had "enough time" to perfect them. Getting things right was going to take quite a while, and I was just going to have to make time — so that's what I did. I went to work immediately, and two long nights later, this is what I had:

Something I could be proud of. I was proud of both the effort I put into it and the final outcome. But my favorite part about it is something most people probably won't even notice: the peacocks. See, Emily's wedding colors are "peacock colors" (genius, really), and most everything she's done for the wedding has had some sort of peacock connection. I was able to pull four peacocks into the design. Check it out:

And the artwork for the RSVPs was more of the same (notice the more obvious peacock on the top of the "R"):

The Payoff

Finally, it was printing time. And rather than continue to rant about this thing, I'm just going to show you in pictures how they turned out. Letterpressed with love. Enjoy.

If you want to see more pictures of the invitations and RSVPs, there's a Flickr set up here.

Need Invitations?

If you're looking for custom wedding invitations, save-the-dates, baby announcements or anything else, I'm currently available for hire; you name it, I'd be happy to help. Send me an email at design@philburrows.com, and we can discuss the details of your project.

Posted by Phil Burrows on April 29th, 2010.

Comments

Robert Monday, May 03, 2010

VERY Cool Phil...
Steve Odom Wednesday, May 05, 2010

Wow, these are really good looking.
Pat Thursday, May 27, 2010

Found this on Dribbble, and wow… what you came up with is breathtaking. Great work! I bet they look even better in person.
Cary IT Consulting Tuesday, May 17, 2011

Wow this is great! Its like you just made some scribbles and out comes a work of art. Where do you artists, designers get your ideas from? Or, is it just pure natural talent.
Thomas "Tom" Johnson Wednesday, October 05, 2011

Nice one Phil, nice one.

my charity: water campaign

Fri, 26 Feb 2010 12:47:49 GMT

Please go to http://mycharitywater.org/phil26 and help raise money for people who are suffering without clean water.

EDIT:
I’ve just made a decision about my commitment to this campaign. And it goes a little something like this:


Donations.all.each do |d|
  @phil.donations.create(:amount => d.amount) if @campaign.total < @campaign.goal
end

# translation: **I'll match all donations**
# until we reach the $1000 campaign goal

On March 12, 2010 I’m turning 26.

Let’s be honest: most of you reading this wouldn’t normally buy me a birthday present (and I wouldn’t expect you to). But this year, I’m trying something different for my birthday, and I’m hoping maybe you will try something different as well.

A billion people in the world are living without clean water. Millions contract deadly diseases from contaminated water. 45,000 people will die this week alone. The lucky ones won’t, but still walk hours each day to get dirty water to give to their families.

So, this year, instead of asking for gifts for myself – things I don’t need, things I won’t use, things that won’t help anyone – I’ve decided to give up my birthday to help people who actually NEED it. I’m asking for $26 or more from everyone I know, and people I don’t know. It’s not going to me, though. All of it is going to build freshwater wells for people in developing nations.

I’ve donated and plan on continuing to donate throughout the year. Please join me by visiting my birthday campaign page.

Thank you in advance for any amount you can donate to give clean and safe drinking water to some of the billion living without it.

please note: Because of charity: water’s unique model, 100% of all donations go directly to direct water projects costs, and each donation is “proved” and tracked to the village it helped when projects are complete.

New Christmas EP from The Merry Gentlemen's Club

Wed, 16 Dec 2009 19:37:10 GMT

I now present you with the NEW Christmas EP ( here) from my holiday band, The Merry Gentlemen’s Club!! Enjoy!

The Merry Gentlemen's Club - New Song (Lover's Choral)

Fri, 11 Dec 2009 14:50:50 GMT

Uhm, it’s Christmas time, which means new music from The Merry Gentlemen’s Club (me and Josh Hollis). Enjoy the first song from the upcoming EP:

Daily Design - Explosions In The Sky

Tue, 29 Sep 2009 15:18:52 GMT

As promised, my latest daily design foray into motion graphics: all with Webkit CSS Transitions.

28 September 2009 – “Explosions In The Sky” by peburrows, on Flickr

Rails Logging With MongoDB

Mon, 28 Sep 2009 12:20:43 GMT

I've been playing with MongoDB a bit lately, and have been pretty impressed both with its simplicity and usefulness. There seem to be quite a few uses for a document-oriented DB, and, as the MongoDB team mentioned on their blog, logging is one of those things that MongoDB is perfectly suited for.

EDIT: 9/28/2009 I’ve fixed the Github repo link

Log files can be kind of a pain to peruse in the first place, but things become especially annoying when you’ve got multiple servers on which your app is running, and you have to tail / grep multiple Rails logs just to find a single request. Not only that, but there’s no concept of a “request record” in a flat text file, it’s just a stream of log messages, one after the other. AND, if (in the case of Rails) you’re running multiple mongrels (which you probably are), all of which are logging to that single log file, then things become even more frustrating as request messages can potentially be intertwined with each other. I can tell you from experience, grep-ing a bunch of HUGE log files in an attempt to find a single request can be a bit of a nightmare.

Enter MongoDB.

I’m not going to spend too much time in this post going into the details of Mongo – that’s what their website is for. And, there are also plenty of introductory articles and presentations outlining the basics of MongoDB / Ruby interaction.

Now that we’ve gotten that out of the way, let’s move on to how MongoDB can cure all your Rails log-perusing headaches.

I just finished up a Rails plugin to allow apps to log to a centralized MongoDB. To start, the code’s here on Github: http://github.com/peburrows/mongo_db_logger. Usage is pretty simple – once you’ve installed the plugin (script/plugin install git://github.com/peburrows/mongo_db_logger.git), the first thing to do is put the following line in your ApplicationController:


include MongoDBLogging

And then, to actually use it in your different environments, add the following line to your app’s "config/#{environment}.rb" file so Rails knows to use the MongoLogger:


config.logger = MongoLogger.new

Finally, in your config/database.yml file, you’ll need to add mongo settings for each environment in which you want to use MongoDB for logging, like so:


development:
  adapter: mysql
  database: my_app_development
  user: root
  mongo:
    database: my_app
    capsize: <%= 10.megabytes %>
    host: localhost
    port: 27017

The only required setting is database (probably just the name of the app) – everything else will just choose a sensible default if not specified. capsize determines the size of the capped collection (think of a capped collection as a db table that has a max size and auto-flushes old records as necessary to make room for new records) and defaults to 250.megabytes in production and 100.megabytes in all other environments (if you’re testing locally, there’s probably no need for it to be 100.megabytes, so you can change that in your config/database.yml file as shown above).

And that’s all. With that in place, a new MongoDB document (record) will be created for each request and, by default will record the following information: Runtime, IP Address, Request Time, Controller, Action, Params and All messages sent to the logger. The structure of the Mongo document looks something like this:


{
  'controller'    : controller_name,
  'action'        : action_name,
  'ip'            : ip_address,
  'runtime'       : runtime,
  'request_time'  : time_of_request,
  'params'        : { }
  'messages'      : {
                      'info'  : [ ],
                      'debug' : [ ],
                      'error' : [ ],
                      'warn'  : [ ],
                      'fatal' : [ ]
                    }
}

Beyond that, if you want to add extra information to the base of the document (let’s say something like user_guid on every request that it’s available), you can just call the Rails.logger.add_metadata method on your logger like so:


# make sure we're using the MongoLogger in this environment
if Rails.logger.respond_to?(:add_metadata)
  Rails.logger.add_metadata(:user_guid => @user_guid)
end

The benefit of using MongoDB for logging (especially when adding extra, custom data like @user_guid to documents) is pretty significant:

you have a centralized logging system for all application servers, so you’re no longer required to look in multiple places for log messages

that centralized log DB can be indexed and searched using MongoDB’s [simplistic but pretty powerful] query language.

each request is a single record, so ALL the information about the request in contained in that one “document”

And now, for a couple quick examples on getting ahold of this log data…

First, here’s how to get a handle on the MongoDB from within a Rails console:


>> db = MongoLogger.mongo_connection
=> #<Mongo::DB:0x102f19ac0 @slave_ok=nil, @name="my_app" ... >

>> collection = db[MongoLogger.mongo_collection_name]
=> #<Mongo::Collection:0x1031b3ee8 @name="development_log" ... >

Once you’ve got the collection, you can…

Find all requests for a specific user (with guid):
```
>> cursor = collection.find(:user_guid => '12355')
=> #<Mongo::Cursor:0x1031a3e30 ... >
>> cursor.count
=> 5
```
Then, you can just iterate over the records returned by the query like any other collection.

Find all requests that took more that one second to complete:


>> collection.find({:runtime => {'$gt' => 1000}}).count
=> 3

Find all requests that passed a parameter with a certain value:


>> collection.find({'params.currency' => 'USD'}).count
=> 22

Perform any other query on the data that you like.

Feel free to play around with it and let me know if you have any questions / suggestions. Also, the mongoDB site has some good resources and the documentation (although slightly lacking in some places) is pretty straightforward as well.

One other thing that I should mention: currently, this does NOT replace the normal Rails logging that happens in "log/#{environment}.log", but is just a supplemental addition. There’s no real reason not to replace the file-based logging, except that with MongoDB capped collections, it will only store a certain number of requests – a flat file doesn’t really have a limit on the number of requests it will store. Sure, it’ll get HUGE if you don’t roll it / truncate it occasionally, but it could [potentially] keep a record of every request ever if that’s what you want.

Daily Design - City And Colour

Wed, 16 Sep 2009 18:19:10 GMT

Nothing much here, just my daily design for Sunday, September 13, 2009.

13 September 2009 – “City And Colour” by Phil Burrows (peburrows), on Flickr

Daily Design Update

Fri, 21 Aug 2009 00:55:48 GMT

After a very long [unplanned] hiatus, I finally started doing a bit of daily design again (see this post for a bit of background).

It’s been good to get back into it a bit, so I thought I would share some of my latest creations. In case you can’t tell, I’ve been going with a band / music theme. As with the first time around, this forced creativity has been easy at times, and horribly difficult at others. What follows are the past three days in this experiment.

18 August 2009 – “Bon Iver – For Emma, Forever Ago” by peburrows, on Flickr

19 August 2009 – “The Anniversary” by peburrows, on Flickr

Some javascript animation: This next one showcases some animation I built with javascript. Unfortunately, I think the design suffered a little bit (it doesn’t look exactly like I wanted it to), but I thought the waves animation turned out really well. I think I’m gonna do the next animation piece using only CSS transitions.

20 August 2009 – “Right Away, Great Captain” by peburrows, on Flickr

Goodbye OtherInbox, hello Gmail IMAP via Ruby

Fri, 17 Jul 2009 01:12:37 GMT

For a while now, I’ve used (and, for the most part, loved) OtherInbox. It’s a really handy service – just create a new email address for each site instead of giving out your main address for those sites to sell and then spam. But I’ve been using it since the beta, and have been increasingly annoyed by certain features that have been removed or withheld from the free account. For example, IMAP access is only available to pay accounts, as is the ability to read any message you received more than 30 days ago.

I’m not faulting OtherInbox for this – I get it, they need to make a profit. Heck, I would probably take the same approach they have. But, I finally decided there was a better solution for me. So goodbye OtherInbox, hello to the exact same functionality (and then some) via Gmail. Let me explain…

EDITS: 18 July 2009 – I’ve made some changes to the script to cover some edge case errors.

So, I thought about my approach for a few minutes and decided that I ought to be able to do the same thing OtherInbox does by using Google Apps for my domain and a simple IMAP poller. The first step was simple: just signup for Google Apps (which I had already done some time ago) and setup a catch-all email address (see this page for details). So, with that done, it was on to some scripting.

I have to be honest: I thought this was going to be harder than it was. But, as it turns out, Ruby already offers a really simple way to interact with an IMAP server (Net::IMAP). After a little digging through the Net::IMAP documentation, I was off and running.

All I needed to do was write a script that would poll the IMAP server every so often checking for new messages. When the script noticed that there were new messages, it then just needed to move each of those messages to the proper mailbox (i.e. apply the proper label in Gmail).

And here’s the end result:


#!/usr/bin/env ruby

require 'rubygems'
require 'net/imap'

CONFIG = {
  :host     => 'imap.gmail.com',
  :username => 'catch.all@domain.com',
  :password => 'my-pa55word',
  :port     => 993,
  :ssl      => true
}

$imap = Net::IMAP.new( CONFIG[:host], CONFIG[:port], CONFIG[:ssl] )
$imap.login( CONFIG[:username], CONFIG[:password] )

# select the INBOX as the mailbox to work on
$imap.select('INBOX')

messages_to_archive = []

# retrieve all messages in the INBOX that
# are not marked as DELETED (archived in Gmail-speak)
$imap.search(["NOT", "DELETED"]).each do |message_id|
  # the mailbox the message was sent to
  # addresses take the form of {mailbox}@{host}
  mailbox = $imap.fetch(message_id, 'ENVELOPE')[0].attr['ENVELOPE'].to[0].mailbox

  # give us a prettier mailbox name -
  # this is the label we'll apply to the message
  mailbox = mailbox.gsub(/([_\-\.])+/, ' ').downcase
  mailbox.gsub!(/\b([a-z])/) { $1.capitalize }
  
  begin
    # create the mailbox, unless it already exists
    $imap.create(mailbox) unless $imap.list('', mailbox)
  rescue Net::IMAP::NoResponseError => error
  end
  
  # copy the message to the proper mailbox/label
  $imap.copy(message_id, mailbox)

  messages_to_archive << message_id
end

# archive the original messages
$imap.store(messages_to_archive, "+FLAGS", [:Deleted]) unless messages_to_archive.empty?

$imap.logout

After setting this up as a simple cron task to poll the server and cleanup my inbox periodically, I can get the exact same functionality as OtherInbox. Plus, I can access the account via IMAP through something like Mail.app, and I can read all my messages regardless of how old they are. Not only that, but I can use the great Gmail web UI (which is much better than the one offered by OtherInbox).

With that script setup to poll the gmail IMAP server, there was only one obstacle left: responding to email from each of the different addresses. Fortunately, Gmail makes this super easy as well. While logged in to Gmail, just go to “Settings” > “Accounts” > “Add another email address you own” — it couldn’t be easier.

Never change your hashing algorithm. Please.

Mon, 18 May 2009 12:45:02 GMT

I'm not the first to say this (http://www.cubik.org/mirrors/taligent/Docs/books/WM/WM_144.html), but it needs to be said again: Please, never change your hashing algorithm. I'm looking at you memcache-client ruby gem...

We have a certain setup (the details of which I will not fully delve into) that shares data across a couple different apps via Memcache. It’s a handy (although, maybe not ideal) setup that provides speed and scalability. Basically, it does a good job of solving the problem we wanted to solve. However, we ran into an issue the other day with one app not being able to reliably retrieve info the other app had set in Memcache. A bunch of debugging later, we realized it came down to the fact that one app was using memcache-client-1.5.0, and one was using memcache-client-1.7.2.

Ideally, we would keep both apps on the same version of gems that are used for communicating information between apps, but, a simple memcache get / set should not break because of minor version differences.

Specifically, our issue came down to this: these two snippets of code are not the same, and that’s not good at all…


# in get_server_for_key method, memcache client 1.5.0
20.times do |try|
  server = @buckets[hkey % @buckets.nitems]
  return server if server.alive?
  hkey += hash_for "#{try}#{key}"
end


# in get_server_for_key method, memcache-client 1.7.2
20.times do |try|
  entryidx = Continuum.binary_search(@continuum, hkey)
  server = @continuum[entryidx].server
  return server if server.alive?
  break unless failover
  hkey = hash_for "#{try}#{key}"
end

Please, seriously, don’t change your hashing algorithm.

Comment Away

Tue, 31 Mar 2009 19:29:30 GMT

After over a year of promising it, I finally sat down last night to enable comments on this "blog" of mine. Turns out, the process was actually pretty easy and painless, and there was really no reason I shouldn't have done it earlier (except for the fact that I doubt anyone will actually care about commenting on this thing).

If you’re interested, I’m using the alno branch of the Radiant Comments Extension – it seemed to be the one with the most active development, and appeared to be the most up-to-date. Installation is pretty straight forward (like any other radiant extension), so just follow the instructions in the README.

Anyway, while I was messing around with things, I decided to upgrade to Radiant 0.7.1 and also move from mongrel to passenger. I hardly ever re-deploy this thing, but when I do, I’d like the restart process to be as painless as possible, and what’s easier than touch tmp/restart.txt?

The whole process was pretty painless, and I actually did most of the work last night, long after I should have been asleep (but that proves how mindlessly simple it was). For those interested, upgrading radiant was as easy as installing the latest version of the gem (and also, I unpacked it into vendor/radiant with rake radiant:freeze:gems), and then:


rake radiant:update
rake production db:migrate

For those of you planning to do this yourself, I should probably advise you to back up your database before you do anything drastic like upgrading your blogging engine, blah, blah, blah. Meh, consider yourself warned. I didn’t have any issues (and I didn’t bother backing up my db before-hand), but YMMV.

So go ahead, comment away – put all my ~~hard~~ work to good use.

Go Buy Macheist 3

Wed, 25 Mar 2009 10:10:35 GMT

The Macheist 3 bundle is now available. 12 Mac apps (a combined value of over $550) for only $39! How can you pass that up? Plus, 25% of every sale goes to charity. So go ahead, purchase the bundle, there are some great apps in there.

It's time...for a redesign

Mon, 23 Mar 2009 14:32:38 GMT

I’ve had this ugly, default theme for far too long; unfortunately, laziness has gotten the better of me over the past year when it came to redesigning this blog. But, this past weekend, I decided to bite the bullet and do what I’ve been avoiding for a while. So, I’ve redesigned (to be more accurate, I’ve really just “un-designed”) my blog.

It’s a work in progress, but a few hours Saturday afternoon proved to be rather productive. I’m using Cufón for text replacement, and have been really happy with how easy it’s been to set up. That being said, I am seeing a few strange things happening with it. If you’ll notice, some article headlines have strange word-spacing. Letter-spacing within words seems to be just fine, but the space between words occasionally gets devoured. From what I’ve seen, it may be an issue with the font I’m using (Fontin Sans SC), because the issue does not seem to affect the site title which is Calgary Script. Still looking for a solution though.

Anyway, like I said, the redesign still needs quite a bit of polish. Some things, like the footer, are just plain ugly, and I’ll be working on those as time permits.

CSS Variables With Rack Middleware

Wed, 18 Mar 2009 14:09:28 GMT

I know I'm not the only one that has, for years, longed for variables in CSS. It's been a much discussed and debated topic; in fact, someone has even gone to the trouble to write up a proposed spec. There have been plenty of solutions, but, as a Rails developer, Rack Middleware seemed like the perfect place to hack together a quick solution for CSS variables.

Before I continue, I should mention that this problem has [in one sense] already been solved. SASS, which is a completely different way of writing CSS (based on HAML), gives us as Rails developers, the ability to have the much-desired variables in our CSS. And, SASS definitely has its benefits: variables, nesting, etc. But, it all just seems like a bit of overkill; I don’t want to change the way I write CSS, I just want to add variables. Plus, I really don’t like the fact that it’s whitespace-sensitive and that I can’t mix in regular CSS.

Enter CSSVariables middleware. It’s pretty basic and, as I mentioned, pretty quickly put together (at the time of this post, I still need to add tests), but it does what you think: it allows you to use variables in your CSS files. Basically, it just parses your CSS “templates” with ERB. Eventually, I’ll do a better job of adding support for other parsers, but right now, I can only guarantee that ERB will work.

In development, the middleware will re-render your CSS file on every request. In production, it will render and write to disk the first time the file is requested, so the very minor performance hit of rendering the template will only be felt the first time the file is requested.

Using the middleware is pretty straight forward:


config.middleware.use 'CSSVariables', :templates => "#{RAILS_ROOT}/app/views/css"

There are other configuration options, but the :templates setting is the only required one and simply specifies the directory your templates reside in (check out the source for more options). Within your templates directory, you can also create a variables.rb file that will be loaded, and will give your templates access to any methods defined in the variables.rb file.

That’s about it. There’s some possibility that this would work better within a Rails project as Rails Metal (which is basically just fancy middleware) instead of just adding it to the middleware stack, but there are certain things that would need to be modified before it would work properly as metal (i.e. returning a 404 when the file isn’t found, instead of just sending the request up the middleware stack with @app.call).

I don’t currently have comments on this blog, so just drop me a line if you find a bug / have a suggestion / hate this idea. Or, you can find me on Twitter.

Passenger 2.0.6 is not compatible with Rails 2.3.1

Thu, 12 Mar 2009 17:40:25 GMT

Ryan Schwartz thinks I should actually use this blog of mine once in a while. Well, that makes one of us ;)

However, consider this a public service announcement for all those people who might have run into the problem I did with Rails and Passenger (modrails) compatibility.

An introduction before we begin: 99% of the time I use mongrel in development, because that’s what I use in production and that’s what has become my habit. However, for a new project I’m working on, we’ve discussed trying Passenger in production. So, more recently, I’ve been using passenger some in development for that project (I still, out of habit spin up script/server when starting work in the project).

As of a few days ago, this new project was running Rails 2.2.2 with Passenger 2.0.6 (when I remembered to got to http://go.local instead of http://localhost:3000). However, always wanting the apps I’m developing to stay up to date with the current version of Rails, I upgraded one to the latest, greatest Rails 2.3.1RC. A few Rails compatibility / deprecation issues, but everything was still working just fine — or so i thought. I didn’t notice anything strange because I was still developing with mongrel; I would still spin up script/server and hit http://localhost:3000. Late last night though, I remembered to use my passenger virtual host, and the following error pops up:

Ruby on Rails framework version 2.3.1 seems to be corrupted?! Please reinstall it?! Wha??

Anyway, it was a little frustrating as I tried a number of things to fix it, but the ultimate solution was simple: upgrade to Passenger 2.1.1, and voilá! Everything’s fixed.

The end.