There are a number of alternative programming and scripting frameworks that can provide a web application to present data stored in a central database. So why use Ruby on Rails rather than JSP, ASP.Net, or PHP?
An underlying principle of Ruby on Rails is that of convention over configuration. Basically, this means that the designers of the framework have broken the workings of a web application into its core components. Conventions have allowed the core components to be standardized, and thereby access to them is greatly simplified.
For example, if you want to save data comprising details of a list of bags, the Rails convention is to save the list in a database table called bags. The convention then prescribes that each line of data can be represented by an object that is the singular of the table name. So if our table is bags, the object that can hold data from the tables is a Bag object. Fields in the table are automatically converted to properties of the object. So if there is a color field, the object will have this property; that is, bag.color. All you need is to create the database schema, define the database connection in a single configuration file, and your application will be able to create your bags table and use the data in the table as Bag objects. Saving a new bag to the database will be as simple as:
next_bag = Bag.new next_bag.color = "Black" next_bag.save
In three lines you've created a Bag object, defined the color as black, and saved it to the database. Thanks to the Rails conventions, the system knows automatically to save the data into a table called bags, and to enter the text Black into the color field. Programmatically, you do not have to open the connection to the database, define the database command that will input the data for you, and close the database connection; all of that is taken care of, for you.
By keeping to the conventions, the application developer is able to concentrate on the logic of an application and is freed from having to worry about the underlying nuts and bolts. So rather than wasting time repeating the code required for all the web applications, the developer can devote most of his time to work on the logic that makes the new application different from the rest, and address the problem at hand.
With the use of convention, everyday tasks such as page pagination, data validation, and search ahead AJAX tools, that can take tens of lines of code to write in other frameworks, can be added in two or three lines of code.
Underlying everything is Ruby. Ruby is an elegant language with syntax that is easy to understand and use.
The best way to demonstrate this is with an example:
this_day = Time.now next_week = 1.week.from_now seconds_between = next_week - this_day seconds_in_day = 24 * 60 * 60 days_between = (seconds_between / seconds_in_day).to_i print "There are " + days_between.to_s + " days between today and the day next week"
The code creates two times a week apart, and returns a short report describing the number of days between the two. It appears very simple, but in fact, there is a lot of work being done by Ruby:
First off, it has created five named objects. It was able to create these objects on the fly without the programmer having to pre-define them.
Ruby has created objects of four different classes:
this_dayandnext_weekare Time objects;seconds_betweenis a Float [decimal number];seconds_in_dayanddays_betweenare Fixnums [an integer type]; and the final output text is a String.In creating
days_between, Ruby compared two different types of objects, worked out the required class type to store the result (a Float), and then allowed that object to be converted to a Fixnum Integer, thereby discarding the unwanted decimal content (that is what the.to_iis doing).When printing, Ruby has converted an Integer to a String (the .to_s tells Ruby to do the conversion) and combined it with two strings to create a new String object. The new object is then output to the console.
This ease of use means that the code is easy to write, but perhaps (more importantly) it is easy to read. It means that you can easily understand code you wrote a year ago, and another developer can read your code, modify it, or fix bugs.
The other aspect of Ruby that plays an important role in defining the coding used in Rails, is that it is an Object Orientated Programming (OOP) language. Without going into details, the consequence is that sections of code are separated into discrete blocks each with well defined inputs and outputs. This helps to prevent spaghetti code with code pathways being difficult to follow. This does not mean that it is impossible to write gobbledygook in Ruby, but rather the structure of Ruby encourages the programmer to write well formed code. Well formed code is easy to read, understand, and modify. The creation of well formed code is the object of every competent developer.
Ruby on Rails applications are built using three types of text files: Ruby code files (.rb), HTML templates (typically rhtml files, but can also be rxml), and YAML configuration files. Being text files, they are easy to edit, move, deploy, and back up. No complicated development environment is required. Code does not require compiling before use. You can create these files in Notepad on a Windows system, edit them in Textmate on a Mac, and then deploy them on a Linux server, should you so desire.
Typically, open source software is considered a low cost option, though there is some argument as to the on-going support costs. Certainly open source solutions are not expensive and tend to be of good value. However, while the cost aspect is attractive, there are other features of open source software that have more compelling benefits to a business application developer.
Open access to source code: This allows you to read the underlying coding to gain better understanding of how the system: works, thereby making it easier to optimize your solution and more easily extend and customize the functionality. With Ruby on Rails, this is even easier as much of the underlying framework code is written in Ruby itself.
No vendor locks in: There are no hidden costs such as extra charges for upgrades and bug fixes. Your choice of software solution is not reliant on the status and expected longevity of the vendor. However, you are reliant on the life of the open source project. If the community moves onto something else, the project development can dry up. However, even in this case, the code is still available and there is nothing to stop you further developing it. If a vendor goes out of business, the code usually disappears too.
Written by and for the people using the software: Open Source applications are written by the people who use the software. OK, not all the people who use it, but a wide group of different users. This means that the resulting applications work the way a lot of people who use them, want them to work. They do not work the way a corporation has decided they should work and more importantly they do not require you to work the way some faceless corporate entity dictates, to get the best out of the application. This is one of the key reasons why open source software is so often user friendly and why so many people find using open source applications such a liberating experience.
As already mentioned, there is a rapid increase in literature base available for both Ruby and Rails. Online resources are plentiful too. For example, the site http://api.rubyonrails.com lists the frameworks, classes, and methods used by Ruby on Rails, allowing a developer to find the classes and methods they need, and dig into the underlying code to see how they work.
Being open source, the manuals are also written by the people who use the system. Too many manuals for commercial software seem more to be a list of functions, rather than a guide on how to use those functions. Good examples of these are instructions on how to install software. Help systems written by developers tend to skimp on this area, as the developers do not install very often and tend to install in a fairly limited environment. End users on the other hand have a wide range of installation issues. As users tend to write open source documentation, the resulting manuals often have the solutions to a range of installation issues. Such is the case for Ruby on Rails with there being guides and assistance to installing in a range of environments.
The test environment is built into the Rails framework, can be configured to populate a test database, and then run test procedures on that data, reporting back on their success. This means that you can safely test an application without adding live data to it, whether at the creation stage, while modifying, or further developing a production application, and during bug fixing. These tests are stored with the application code and therefore can be used to test the application after moving code to a new environment.
The test system encourages a developer to create test procedures early in the development process, and use the resulting test code throughout the life of the application. To detect system malfunction, test systems are used to help developers identify when the code they have created does not quite work the way they expect it to work.
The integrated test system can be used to ensure that applications are tested effectively and often.