A Little Ruby on Rails Warm-Up

As stated previously, Ruby is the object-oriented programming language, and Rails is the framework used to develop applications. Let's say, for example, that I want to create a mad scientist application using Ruby on Rails. The steps would be something like the following:

1.

If it doesn't exist, create a folder/directory to hold each of my Ruby on Rails applications. In this example, I created a folder called rails on my C: drive.

2.

Using the command prompt, enter cd rails. This changes the current directory to C:\rails.

3.

Create an empty web application by running the command rails madscientist, as shown in Figure.

Shutting down the WEBrick web server at the command prompt

Well, we're only partway there; in fact, we should consider ourselves lucky that there is anything at all to show. Satisfied? Neither am I, so to progress further, we need to understand where things go in a Rails application.

The rails madscientist command created a number of folders and files that perform various functions. Take, for example, the database.yml file in the config folder; its purpose is to provide the application with details regarding the database to be used by the application. This is an example of the Rails "place for everything and everything in its place" approach. Personally, I wish this idea was more widespread. It would have gotten me out of some embarrassing moments in the past.

Another folder that is of interest is the public folder. Along with its three child folders, images, javascripts, and stylesheets, it provides a standard location for stashing the aforementioned. In most other environments, locating these types of files is more akin to a treasure hunt than web development.

The final folders that I'll cover are the app folder, along with the child folders called: controllers, helpers, models, and views. Still feel like you're in the dark? Give me a moment to illuminate. The first directory, controllers, contains classes that handle web requests from the visitor. The helpers directory holds helper classes, which are used by other classes, such as controller classes. Model classes, contained in the models subdirectory, are used to wrap the data stored in a database. Personally, I think that this is where application development can get really messy and often goes wrong. Finally, there is the views subdirectory, which holds the views. Views are the templates that are converted to HTML and returned to the visitor's web browsers.

Although at first glance it might seem that the application is spread around a bit, that really isn't the case. Instead of the normal "I know it is around here somewhere" approach usually associated with web development, Rails provides a consistent location for each class. If only this approach could be applied to the real world, I would spend a lot less time looking for my watch.