Professional Ruby on Rails™

2.6. Living on the Edge

One of my favorite decisions that the core Rails team made when designing the Rails architecture was to allow each individual Rails project to easily maintain its own copy of Rails, thus making it trivial to have multiple projects require different versions of Rails. In particular, it's no trouble at all to have a new project use the cutting-edge version of Rails right off the trunk of the main Subversion repository, while every other project on your machine continues to use version 1.2.

Five Other Great Rails Architectural Decisions: A Subjective List The base idea that default behavior could govern 95 percent of relationships between database tables and objects, or between a URL, a method in the controller, and the view file that renders that method. If you've ever worked in a framework that made you spell all that out explicitly, time and time again, this feels like heaven. Having a separate database for tests, automatically populated by fixtures. This makes unit testing of complex data interactions not just possible, but easy and fun. Allowing access to raw SQL for powerful queries. I've tried the web-framework game in the past, and the temptation to wall off SQL is pretty strong. But SQL already exists, has tons of power and flexibility, and people already know it. No need to reinvent query languages. The ease of having a known public directory for images, JavaScript, CSS, and static text files. If you've ever played the game of "guess which directory ...