A Simple explanation of a MVC Ruby on Rails App

This post attempts to explain in layman’s terms how a Ruby on Rails Web application works. In keeping with Rails tradition I will try to illustrate the principles of MVC using a simple blog site application as an example

The Ruby on rails framework is based on MVC architecture:

• M is for model
• V is for View
• C is for Controller

I will discuss each of these elements role in a web application, however, one should first look at the key ingredient of the web application: the Database. A database is simply a set of tables with rows of data indexed (identified) by a unique key value (such as a number).

The term relational database refers to that the different tables in the database reference each other and that there is some sort of data hierarchy in place.

In Rails, data in the table rows relate to objects – an object is a collection of data that is type specific.

Objects are governed by models, which lay down the rules of how the database data should be interpreted and how data types (tables) relate to each other. Models can also define custom behaviour or methods for extraction information from objects.

When a request comes in from the web, the request is interpreted and a command is sent to a controller. A controller is fetches data from the database and knows which view should be rendered, the object (or objects) needed are fetched from the database and passed on to the view.

Views are simple templates. By feeding rails’ rendering engine the view and the relevant data objects (provided by the controller). HTML (web browser mark-up language) is generated and sent back to the browser that made the request in the first place. The browser receives an HTML file and is none the wiser.

The schematic below attempts to illustrate the entire process.

This is just a basic explanation of the process; there is a lot more detail to it. However, I hope this post has been able visualise the process of how a rails app works.

For more information refer to the excellent Rails Guides: Getting Started with Rails

Reasons why Ruby on Rails is the next BIG framework

At Prodispace we do development on Ruby on Rails. We have chosen this framework because we firmly believe that there is nothing better out there.

“Ruby on Rails is astounding. Using it is like watching a kung-fu movie, where a dozen bad-ass frameworks prepare to beat up the little newcomer only to be handed their asses in a variety of imaginative ways.”

-Nathan Torkington, O’Reilly Program Chair for OSCON

The elevator pitch:
Ruby on rails is an open source framework that’s optimised for programmer happiness and sustainable productivity. It lets you write beautiful code by favouring convention over configuration.

Five reasons to use Rails:

1. Convention is favoured over configuration – This means putting everything in its correct place, using proper naming conventions etc. It also means:
   • Project teams work better because developers can understand what the other team members did
   • Source Code (Read intellectual property) is more maintainable and or sell-able.
   • Coders spend less time coding and more time developing because they don’t have to re-invent the wheel.
2. Rails uses a MVC (Model View Controller) architecture. This allows developers to extract logic into Model Classes keeping Controllers skinny and View stupid i.e. keep all the logic of your application where it is maintainable and at its most powerful because you are as close as possible to the actual data.
3. Test Driven development friendly obsessive architecture that helps you to manage change and improve quality
4. An open-minded, helpful, motivated, excited community is continuously improving and expanding the technology
5. Great version control of not only the core framework code, but also of code extensions called Gems (most often written and maintained by the community). Ruby and Rails and GIT – a source code versioning and management system – are synonymous. It is easily possible to sustain legacy software developed in older versions of ruby on rails indefinitely, something that is absolutely critical if you want to do business with large companies.

Blankbook Media

One of the business relationships we benefit most from is our partnership with Blankbook Media.

Experts in both online marketing and web-site design, Blankbook has really given us an edge in marketing our solutions online using a WordPress solution.

Through their help we have set up the Prodispace website. They are great at coming up with fresh ideas and great design, but also do not shy away of the complex and confusing world of WordPress and other technologies such as the 100 different google tools needed for SEO (search engine optimization).

We also use Blankbook as an interface design consultant. They have a keen eye for what make interfaces work and look great. They also have a very professional work ethic. Interestingly enough the owner Wim van Schalkwyk is also an engineer (industrial) which makes working together on engineering related projects so much easier.

Visit the Blankbook website

Excel has its limits

As an engineer, I have built many a spreadsheet in my career. Some basic, some with macros and some just plain enormous. I am convinced that because of the low cost and relative ease of use excel offers to the engineer, it has become the leading engineering instrument in the world today.

Should engineers be using excel so much? I am not so sure… It is definitely a great tool, especially at the beginning stages of a project. Its quick and inexpensive to make changes, which is exactly what you need in the conceptual phase of developing calculations.

My main grievance with using Excel is that these spreadsheets grow and become extremely valuable but also completely unmaintainable. These large spreadsheets hold managers hostage as empires are built. Could you imagine figuring out a 20 sheet monster built by someone that has left the company?

Based on my experience, I have identified some pitfalls of using Excel:

1. File based version control is always a problem, as its nearly impossible to build up calculation histories.
2. Hidden logic and hard to read IF statements.
3. Split logic and calculation between spreadsheets and macros (if and when used). It is a primary programming principle to keep logic in one place.
4. If you are using pivot tables you should seriously consider using a database.

However, in this post I would like to focus on the following flaw: data duplication due to lack of data relationships and lack of object abstraction.

A database is purely a set of tables that are interconnected by data relationships. A set of rules are established which define the nature of the data contained in each row and how inter-table connectivity is managed, these rules are called Classes or Models. The name says it all: these rules classify the data.

We try to abstract all logic and calculations to the model, thus keeping things neat and organized. However in a spreadsheet the logic and data governance is scattered all over the place – even worse – it is hidden by default and you have to click on a cell to see what the logic or governance rules are.

If you are developing large spreadsheets and are frustrated by how difficult they are to maintain and manage, you should seriously consider looking at a more formal development tool.