Rails - Day 3 - Rails environments

So far in the series we have:

Rails  - Day 1 - The RubyGem Love Story

Rails  - Day 2 - The Power of Consistency
Rails -  Day 3 - Rails environments

Rails -  Day 4 - Rails Generators

Rails  - Day 5 - Rails Migrations

Rails  - Day 6 - Blueprint, Compass, SASS and HAML
Rails -  Day 7 - Our first View
Rails -  Day 8 - Down and Dirty with HAML and SASS
Rails -  Day 9 - Rendering Content

Rails -  Day 10 - Testing Rails Controllers

Rails -  Day 11 - Model Testing and 101 ActiveRecor

Rails -  Day 12 -ActiveRecord Relationships Part I

Rails -  Day 13 -ActiveRecord Relationships Part II

Rails -  Day 14 - Rails Forms Part I

Rails - Day 15 - Rails Forms Part II

Rails - Day 16 - Validation

Rails - Day 17 - Update and Delete

In my last post, I started to bring on the concept of why rails genuinely is an opinionated framework because of the way it pushes its opinions on you.  Being a highly opinionated person myself, the attraction was instant.

I also brought on board the rails project structure.  Below you can see how rails has created an environments folder for us in the config folder of our rails project:

Here we see rails pushing us down the path to righteousness with its ever so pushy personality.  We are instantly forced to think in terms of having different environments for development and production.  We also have a test environment which is awe inspiring.  

In .NET, the blank slate new project approach leaves these decisions up to the developer.  We end up wasting time rolling our own environmental build scripts that have to do things like update the web.config etc.  This is of course time consuming and tedious and every project could potentially have a different approach.  Rails has rightly taken this responsibility away from the developer.  It goes without saying that the less conscientious amongst us will simply make changes to the web.config by hand and have no clear distinction of which environment is which.

Rails Application Start Up

The first Ruby script that is the starting file for all Rails applications is config/boot.rb which you can see above.  boot.rb loads all the dependencies needed to start your rails application, including loading the Rails gem itself.  boot.rb then goes on to execute all the code in environment.rb which is code we want to run regardless of which environment we are currently in.  I hope it is obvious that environment.rb contains configuration that is common to all environments.  

Lastly rails will look for environment-specific code that should be executed.  As noted above, Rails uses the following convention to find the correct environment configuration file config/environments/{environment}.rb for example config/environments/development.rb.  Because Ruby is a scripting language, whatever code comes last wins and is executed.  So, a method that is defined in environment.rb will be overriden by a method with the same name if it is defined in our environment specific code.  Likewise, since the environment.rb and environment specific files are loaded after the rails framework code, we can override anything in Rails at this point as well.

Xml is currently desperately out of fashion, at least in the high falutin ALT.NET circles where I get most of my daily blogging nourishment from.  So if you too are currently scoffing and snorting at angle bracket configuration files then you will probably have noticed already that these environment files end with an .rb extension and as such are unadulterated ruby code.  Below is a look at the development.rb file:

This very fact of there being no xml in the environment configuration files will make you the talk of the next ALT.NET open spaces meet up!!

In all seriousness though, the point I am hoping to illustrate by shinning a light on this configuration mechanism is that this is made possible because of the guaranteed folder structure.  Rails knows where to look for its files.  We are not configuring the location.  Of course this is only one such example but I really want to push forward this notion of a guaranteed folder structure that is, to borrow one of the most over used terms in architecture astronaut circles, opinionated.

I will further go onto say that Rails is VERY opinionated,  much of the magic of Rails is dependant on conventions.  I do not get the argument of developers who feel threatened by not having the power(?) to place their files where they please.

Grasping this concept alone should free you from the mental slavery of over configuration that certainly makes JAVA a less than appealing platform to the young and trendy.

Configuring Data Access

To finish this post, I want to briefly touch on configuring data access.  In ASP.NET, I am sure you are familiar with the cruditity of the <connectionstrings> element.

In rails, information about data access across all the environments is contained in a single file, the config/database.yml file.  Here is an example:

Each environment must have an entry in this file to let the application know how we'd like to access the data for the environment.  

The yml extension of database.yml is a format named YAML and stands for YET ANOTHER MARKUP LANGUAGE.  YAML is represented in a simple hierarchical structure which is python-esque due to the significant whitespace that denotes structure.

Get the message kids, XML is out, out, out!!!  We use YAML, we are coooooollll!!!

In this post, I have tried to present the importance of the guaranteed folder structure that allows Rails to find its bits.  Instead of relying on external configuration, we rely on conventions.

On my next post, I am going to touch on the concept of generators in Rails which will further expand on the rails mantra: convention over configuration.