Rails Deployment | 315

Ruby and Rails extensions
Any project of reasonable size usually accumulates a series of extensions, anno-
tations, and utility functions that supplement the Ruby and Rails core. Exam-
ples of Ruby extensions:
class String

"Frequently - Asked Questions!" => "frequently_askedquestions"

def toslug
self.downcase.gsub(/[^a-z0-9]+/, "")
end

# 12345678.to_s.with_commas => "12,345,678"

def with_commas

self.reverse.gsub(/\d{3}/,"\\&,").reverse.sub(/^,/,"")

end

end

Because these utility functions are usually widely applicable, it is useful to share

them between projects. I usually keep them underlib/extensionsandrequire

them from an initializer.

ActiveRecord models
Some situations call for two or more separate applications sharing the same data.
While this is usually accomplished with one Rails application and judicious sep-
aration of concerns, occasionally the purposes for the applications will diverge
and it will make sense to split them up. In that case, the models can be placed in
ashared_models directory and shared out among the applications.

Test fixtures
If you share a data model between applications, you will usually want to share
any test fixtures you have between those applications as well.

Rails Deployment

As a full-stack web framework, Rails can require some work to deploy an applica-
tion from the ground up. Rails, unfortunately, has a bad reputation for being hard to
deploy, mainly due to problems with the preferred deployment environments when
Rails was young (2004–2005). But Rails has grown up, and Mongrel came along in
2006 and made things much easier. There are now good sets of best practices for
deploying Rails applications, from the smallest development environments to huge
multi-data-center worldwide clusters.