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:
this_day
and next_week
are Time objects; seconds_between
is a Float [decimal number]; seconds_in_day
and days_between
are Fixnums [an integer type]; and the final output text is a String. 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_i
is doing).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.
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.
3.142.199.184