This course will become read-only in the near future. Tell us at if that is a problem.

Chalk Board


At this point, we should assume that everyone has RAILS up and running on their computers. And for some if not all, you’re flying through the and surpassing the class schedule…

I would like to take some time to try to really understand RAILS advantages and disadvantages by sort of dissecting the Chapter: What is RAILS.

Let us look at the first definition of Ruby on Rails in the website:

“Rails is a web application development framework written in the Ruby language.”

The keyword is framework and according to Wikipedia, the definition for this is as follows:

A web application framework is a software framework that is designed to support the development of dynamic websites, web applications and web services. The framework aims to alleviate the overhead associated with common activities performed in Web development. For example, many frameworks provide libraries for database access, templating frameworks and session management, and they often promote code reuse.[1]

  So with this in mind, not only do you have to learn how this type of system works, you must also understand the programming language, Ruby, which is an Object Oriented Programming Language in order to use Ruby on Rails.

Seems a little intimidating, but with anything new to learn – we are all intimidated by some degree. I can’t wait to take advantage of learning all this further!

Let’s move on with website description of RAILS.

“It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Experienced Rails developers also report that it makes web application development more fun.”

Sounds familiar… pretty close to Wikipedia’s definition, and I must say that I am definitely looking to have some fun!


Note: what you’re about to read is my take/understanding of the concept of MVC. Comments and corrections are most welcome…

The MVC is independent from a programming language, therefore, in this case - independent from the Ruby language.

The Model, Viewer and Controller (MVC) architecture is a concept of order and expectation associated with patterns to build and manage a repetitive job task.

The Model is responsible for production or service.

The Viewer is responsible for communication.

The Controller is responsible for direction of interaction.

Let’s look at an example: A Car

Application Domain: Transportation.

The Model is the car.

The Viewer is the dashboard.

The Controller is you.

One repetitive job task out of many while operating a car is to move the car at a certain speed to get from point A to point B. But let’s break it down even further to one simple task, to move the car from speed 0 to 55mph.

As the controller, you step on the gas. As the model, the car starts moving at a speed relevant to the amount of gas injecting into the engine. As the viewer, the dashboard’s speed meter displays the speed at which the car is moving. You react to what is displayed on the meter by pressing the gas pedal controlling the inject gas amount into the engine. The car moves faster, the dashboard displays the difference in speed, you push the pedal more until… voila! The car speed is 55mph. A repetitive and expected outcome to a common task has now just been completed.

I hope that this was a good example in breaking down the concept of MVC architecture.

For further reading and diagrams, I recommend:

Up next, I would like to share on RAILS directory structure using MVC design pattern for organization.

11/11/11 (How often do you see this date format: The day of ONES)

I came across this learning website which to me seem easy to understand and well organized. Even though it is based on RAILS 2.1, the fundementals seems the same.

Every little bit helps-No? Check it out:

Love it, - I have finally found a very well organized explanation on RAILS functionality, methodology and philosophy!!! Again, even though it is referring back to RAILS 2.1, the foundation should still be the same (i.e. I don’t think they would reface the entire structure). This tutorial seems to break down every component of RAILS method, structure, function and philosophy hands down. Great in understanding the fundamentals – that I sincerely recommend reading. I just love free and easy, don’t You!?!?

How much easier to explain the directory structure:

Cheat Sheet Download

I don't know about you, but I know myself and I cannot remember all the commands of a program unless I've done it hundreds of times. This is why I recommend using a cheat sheet for ease of reference. You can download at:

This was written by Greg Pollack. Those who have done or is doing the free Rails for Zombies will recognize the name as he is the instructor and an expert on Ruby on Rails. I am going to cheat a little...

The command window

Also, those who hate squinting your eyes from reading or feel a little confined from the command window can adjust the window by right clicking it and going into properties.

 jEdit and the Directory Pane

For those of you who are using jEdit, the editor comes with a floating directory pane/ file browser which you can attach/dock to the main editor module by doing the following: Go to Utilities>Global Options. On the right hand side, select File Browser and choose Docking position. There are other modules to dock as well and if you find any well worth using for our group, please share!

I also came across "jEdit tips" which is mainly for beginners. Perfect for me, might be for you:

Task Discussion

  • tangram   Dec. 3, 2011, 9:24 p.m.

    That's a good definition of a framework.  Here's my take from the ground level.

    A lot of website functionality is the same.  Say I have two sites, one that sells coffee, and one that sells bacon.  Most of the site behavior is the same.   Functions include things like: show a list of all the coffee/bacon products I sell;  show one particular kind of coffee/bacon; edit the product's description; delete a coffee/bacon product.   There are some small differences, but 95% of the code is the same.

    It's REALLY TEDIOUS to write this stuff over and over.  Each time you write software, you risk bugs.

    A framework is a set of tools that does a lot of the drudgework for you.  Rails will generate a lot of the create-show-edit-delete-list  code.  You can focus on writing the unique parts, and sip pina coladas in all the time the framework saved you.