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
