From: David Heinemeier Hansson <david@...>
Date: 2004-11-26T19:39:27+09:00
Subject: Re: rails is awesome

> But it's the same fundamental problem, how often you poll for code 
> changes.
> I remember Ara or Carl (on that rubygarden fastcgi page) had a trick 
> that
> let your fastcgi classes detect when their *.rb file had changed and 
> reload
> themselves, I'm assuming that might have benn involved here.

That would be auto-reload.rb. I'm not using that here as it had a bunch 
of other issues. And frankly, I could get away with way Less Software. 
All the framework code and infrastructure is loaded using require, 
which is then cached for the remainder of the interpreters life cycle.

But all the application code is using "load", which means that it'll 
reevaluate everything on each request. This turns out to be pretty 
cheap even for "big" applications like Basecamp. It was much more 
expensive to parse the Rails framework AND create a new Ruby process.

There are a few drawbacks to this approach, but all something that can 
be learnt to live with:

1) Load is just reopening existing classes and overwriting behavior. 
This doesn't work for removing methods. You'll still have to restart 
the server there. Luckily, the times where it makes a difference 
whether a method was actually removed (instead of just not used) are 
few and far in between.

2) Your model class definitions have to be idempotent (it doesn't 
matter for controllers since they're defined in an anonymous module for 
other reasons). Passing the class definition twice must not have 
side-effects. Currently, I lack to deal with one case in Active Record 
where this is not the case (using the macro-based callbacks).
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://macromates.com/       -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain