In this rather long article, I’d like to talk about what you should know about Rails to became more indipendent in its use. This is not a how-to use this or that; it’s more of a checklist based on my past and ever evolving experience on this framework. I did probably wrote this one for myself, but I hope you’ll find something useful too.

How do you know, you master something? Maybe you simply “feel” to grasp every single bit related to that thing, and you feel comfortable when thinking about that; you even honestly suppose you could teach the tecniques to someone else, or give a speech to an entire class for 2 hours. Aight.

When it comes to Ruby On Rails, you need to know a quite big stack of things (rails itself is defined, well, as a stack). Depending on how much you know every single element of the stack, you relatively know Rails as a whole; think of it like you just sum the experience on every Rails aspect. You can’t say “I master Rails”, if you don’t master every little fragment of it. This is because, imho, Rails being a stack, there are many single point of failure: you can’t fail when switching on or off a light switch, but you could fail badly, if you had to build the switch from scratch and don’t know how it works.

I’m NOT a Rails master, but I’m a wannabe: there are some things I’ve not yet tested myself (even in a development enviroment, at least). But I know my limits :) So, here is a list of things that you should know, if you intend to use Rails and, why not, master it. I was tempted to title this article: What you should know about rails and you don’t CARE to ask.

The MVC design pattern

“Model, View, Controller” is a good (not the only one) method of doing things The Right Way. Every framework that uses it implements it in a sligthly different manner. You need to know what MVC is, basically at least, and how Rails implements it. Which are Rails “models”, “views” and “controllers”? How they interact?

When you are there, keep some time to look very deeply to the rails project directories; learn and ponder their layout. Ah, btw, learn what exactly an “helper” is, what they are for and how to write them: you’ll find them everywhere, in a Rails project.

Active Record

Your web application is mostly database driven; what do drives Rails database models? ActiveRecord. AR is then the most important thing, in Rails. You could not manage sessions or caching, you could know nothing of JavaScript, you could even don’t know what a template is but you could still build a simple Rails application. AR is another story: if you don’t know how to set up your database and your tables relationships with AR DSL, you’re out of the game.

You absolutely have to understand the AR DSL. At a first level there’s nothing really difficult: has_many, belongs_to, has_and_belongs_to_many and such, are very simple concepts giving you have, at least, a mininum DB designer skill (normalization, anyone?). Things get nasty when you leave the tables-are-a-storage-media mental model and get to the table-are-objects one. From that moment (you have been enlightened by the OR/M tecnique, and AR is an OR/M, btw) you get the need to do complex things with AR (and leave SQL)… That table, that once drove a simple n-n relationship (authors_books), now become an object itself (contributors)… you then can’t (should not!) rely on the relatively simple habtm… you need something more powerful… go and read about :through.

Rails 1.1.x and Rails 1.2.x are quite different (being the latter more powerful, of course) in its AR DSL and concepts. You’ll get a lot of deprecation notice when running a 1.1.x application with Rails 1.2.x. Learn from the deprecation notices: do read them, intepret them, and consequently apply patches to your code.

Rails Active Record implementation itself also implements another very useful pattern, that is Single Table Inheritance (aka STI). Must be noted, though, that another useful pattern (the Class Table Inheritance) is unfortunately not implemented.

Another AR related thing are migrations; learn how to use them to share database schema updates with your development partners.

Bottom line is: AR is kindly enough to give you a run from the first date… but you HAVE TO learn every aspects of it; there are not so many things to learn, I swear; but concepts are only apparently simple: when you try to apply them to a real world example, you’ll get stuck. RTFM and try to imagine yourself what is a polimorfic association, and what it can do to your application foundations.

References:

• The active record design pattern
• Active Record API
• Migrations

Sessions

Rails use sessions. The default Rails sessions behaviour is quite “raw”. Default session store is “filesystem” (namely, PStore) but there is no session garbage collector. Coming from PHP (it has, by default, its session GC) you could be surprised, when your /tmp will be filled by 25000 session files (I was). This is the first thing you learn about Rails sessions, but then you’ll learn that you could use at least other 5 methods for session storage: ActiveRecord, raw SQL, memcache, DRb and memory. What you should choose and why is out of the scope of this article. Remember that only memcache has it’s own “automatic expiring” mechanism; for the others you have to write something yourself.

You may learn that in Rails, sessions are enabled by default (the exact opposite then PHP, where you have to explicity enable session support). This is quite bad, imho, because sessions use cookies and to be polite you should give someone browser’s cookie only when needed. You can switch off sessions completely (no, not really unless you use some sort of hack), and then enable them on a per-controller or even per-action basis. Beware that there is a session :off, but not a session :on; you have to “session :disabled => false” it.

References:

• Nice article about all session storage options
• Rails session management

Templates (views)

This is the funny part. Templates are very similar to plain HTML files, but you can embed some Ruby code into them to have them “compiled” in pure HTML at run time :) This is how PHP or ASP Classic work (they are, all in all, template languages). In Rails this magic is provided by ERb, that could represent the Rails “template engine”.

What is to be noted here is that ERb is only the default template engine. Like many other things, you can choose at least from other four additional template engines for you application: Liquid, HAML, Markaby and Masterview . Another noticeable thing is that you can mix them… write some templates in ERb, and others in Liquid… Why? It’s up to you; Rails gives you options (and this is not the usual way to think about it).

References:

• Rails Action View
• Liquid (used by MephistoCMS)
• HAML
• Masterview
• Markaby

Caching

Ruby is slow. Period. What you can do if you need performance? Caching, of course. Rails does a lot, in this sense. First, if you run in “production mode”, many things are read or calculated one time only and then statically stored in memory; models, for example. This is why you need to “restart rails “when updating a production server codebase (never happens in PHP, for example).

When this “native” caching does not suffice anymore, you need to rely to an explicit cache mechanism, where the developer tells Rails “Ehi, this page has to be cached”. When cached, Rails stores the page in its temporary directory as HTML, where it can be reached even from the frontend server (Apache, for one).

Every time the page is served Rails is not even touched. You can’t be more aggressive, you can’t be more quick. This comes at the cost of the page being cached as a whole. In real world, in a dynamic site, not many pages could be cached that way.

Fortunately, Rails provides two more options here: you can cache page “sections” built by your actions or even cache single fragments from inside your templates (think about this: build a select options list for a form from the database, and then save it in the cache: next time, the select will be rendered directly and the database will not involved at all). This is a trade off: with action or fragment caching Rails has anyway to be involved when serving the page.

In Rails lingo, cache expiring is called “cache sweeping”.

References:

• Rails Caching
• Rails Action Caching
• Rails Fragment caching
• Rails Page caching
• Rails Cache sweeping

JavaScript

Not many options here, that’s the news. Rails uses Prototype as its JavaScript framework of choice, and that’s all. I’ve only heard of some experiment trying to adopt Yahoo! YUI as an alternative framework (oh yes, please). On the jQuery side, nothing. You can, of course, use YUI or jQuery but then you can’t rely on the (many) Rails provided JavaScript helpers. YUI and Prototype can happily live togheter… but I’m not a big fan of Prototype and I’d like to use YUI for all the helpers.

Application deployment

Oh-oh… that’s the worst thing in Rails. Or, perhaps, this have nothing to do with Rails, if you think about it. There are SO MANY options that I can’t even build a list here (because I’m lazy, and I’d search the best page describing every single approach). What is to figure here is that you always need a “frontend” accepting HTTP requests, and a backend which in turns runs you rails application, gets the request forwarded by the frontend and then move the response to the frontend to have it sent to the user browser. This is the schema shared by (practically) all the production environments out there. The frontend could be Apache or other http demons (like Lighttpd or Litespeed), or balancer like Pond or ngix. The backend of election is, by now, mongrel or fastcgi.

Frontend servers are also sometimes responsible for serving Rails cached files.

Internationalization

Rails does not provide a native support for i18n nor for localization. There are many options here, as usual. The Big One is Globalize, that I’ve used and I’m happy with. If you need something smaller, take a look at Localization plugin or the evergreen gettext.

In the Rails wiki there is an entire page dedicated to the list of the internationalization approaches and plugins.

References

• Nice introduction to Globalize (italian)

Test your models and your controllers

Well, what I’ve missed? Oh, yes, TESTS! I’ve only recently dove into them, I confess. So, for now, I can only forward you to the pages on testing rails application in the ruby on rails “wiki” site. I beg your pardon, for this :)