From draft to launch: Helpful tools in Rails development (3rd tranche of Rails links)

To get a clue of how Ruby and Rails and all a Rails project’s parts intertwine, I had a look into the files tree of a dummy Rails project, i.e. into what it looked like just after creation using rails project name, i.e. without any modification. A lot I got just by reading the inline comments there, within the several files, but also from the main README file there.

Too sparse notes on what config/initializers is for made me google, so I found out: “config/initializers [is] where all ruby files within it are automatically loaded after the Rails configuration is done, so you don’t have to litter the environment.rb file with a ton of mixed stuff” (DHH, creator of Rails, quote taken from the Rails Trac). But on finding out about what libs/ is for I was unlucky so far (or at least don’t have anything I could quote here).

I also were interested in what is going on back stage, therefore I looked up the underlying Rails stub, the place where I can find the Rails framework classes right on my disk: /usr/lib/ruby/gems/1.8/gems, that’s where there are the Ruby gems stored, at least on Debian Etch. And their doc files can be found in /usr/lib/ruby/gems/1.8/doc/.
 

As much as I did you already might have figured out, that Active Record and all the other Acti.+ classes constitute the core of Rails. Therefore, I skip introducing or even discussing them here. Hence, for this post only developing and deploying of Rails applications remains. — To follow the first things first rule, let’s start by having a look onto some things you might come across when doing your first few Rails projects and might wonder what they mean.

Before you start it might be worth to consider whether or not to make use of Sake. Unfortunately Sake’s gem introduction revealed too little, so I have to rely on what I remember about Sake: If I remember correctly, Sake is a Make-like tool that helps in getting a new Rails project into a Subversion repository right from the beginnings on.

Having learnt of Rails’ Active Record you probably already have done your project’s models. Advancing to the view part of the model–view;–controller process it’s quite likely you might stumble upon the term “eRuby” or “erb”. Therefore a short explanation: “erb is an implementation of eRuby” [src], and on eRuby Wikipedia has quite a good introduction. It’s some kind of HTML scripting like PHP but doing it the Ruby/Rails way.
 

Developing a Rails application inevitably demands for testing it. The Ruby on Rails website features a guide to test Rails applications which I suggest to you to read. When you leave functional testing and want to see whether or how well your database programming works you might notice quite often the term “fixtures”. “Fixtures are a way of organizing data that you want to test against; in short, sample data.” [src (recommended read!)]

As I mentioned in an earlier post today, until Rails 2 (and unless you were using the Rathole Rails plug-in) making fixtures could be quite frustrating. But you’re lucky, Rathole made it into Rails 2, smoothing things out. Anyways, if you like, FixtureScenarios might be a viable alternative for you. Tom Preston-Werner introduced them and ErrTheBlog picked up FixtureScenarios for a blog post at the end of July 2007. — Anyways, the news about Rathole in Rails 2.0 was from October 26, 2007, so it’s unlikely that FixtureScenarios will be available by default; but of course you might want to install the matching gem.
 

Just to mention another great tool: When you’re done with your project you might want to deploy it onto some remote server. For that, Capistrano might be the right tool.

So, and when your project’s deployes — would you care about the performance of the application? Yes? So you’d be glad that some people already thought about that. So, there’s a general suggestion to make use of Ruby’s default webserver, Webbrick, only during development but to shift over to Mongrel for production use. Or even to Apache itself as it’s an optimized tool for doing nothing but efficietly delivering web pages. Even dynamic ones. To put it even farther, Rails folks came out with an implementation of ETags, a HTTP/1.1 feature to reduce the number of delivered web pages to a minimum. Chad Fowler and Assaf Arkin introduce you into the matters of ETags in two distinct but nevertheless brilliant ways.