Learning a new language and a new framework can sometimes be overwhelming simply because of not knowing where to start, and due to the large number of new terms and concepts. I hope to help ease the learning curve by presenting here a brief overview of the most common terms and concepts you will see as you begin your Rails learning adventure. I will then follow with another post called, How To Learn Rails, which will present the reader with some step-by-step suggestions for getting started.
Update: I do hope to get around to writing some helpful tutorials on Ruby on Rails, but have been overloaded with projects recently and haven’t gotten to it yet.
This is not a complete list of every term and concept, but I believe it is the right size list with the most important initial definitions.
Overview of Ruby on Rails
Ruby on Rails consists of two components. The core component is Ruby which is an object-oriented interpreted scripting language. It was created by Yukihiro Matsumoto and released in 1995. Rails is a web development framework built with the Ruby language. The framework was created by David Heinemeier Hansson, while working for 37signals on their product Basecamp, and released in July 2004.
In order to become a proficient Rails developer, you will need to learn both the Ruby language and the Rails framework, but it is such a well integrated framework that initially, you will be unaware of where one ends and the other begins.
By becoming familiar with the list below before proceeding on with further study, you’ll be more comfortable as these terms present themselves to you.
Usually referred to as MVC, this is a pattern that goes back beyond web applications, but today is most commonly used in reference to a web application. The idea behind this pattern is to have a separation in the application between three distinct functionalities: the Model, the View, and the Controller. The Model represents information that you are using in your application. In an Object Oriented language this is commonly represented by classes. The View is the user interface that is used to interact with that data. This could be an interface written in HTML, Flash, or any other technology used for the interface. The Controller responds to user interactions and in turn, performs various operations on the Model, including causing it to persist (such as in a database), be redisplayed in a different format, or any of a number of other functionalities.
All modern web development frameworks are based on MVC and Rails is no exception.
A framework means the foundational functionality or the “frame” for a web development platform. This frame is usually built on top of an existing language, such as Java, PHP, C#, and in our case Ruby. This frame provides the developer with the basic functionality needed to produce a web application. Rails is a framework for Ruby, thus the name Ruby on Rails.
The full-stack term is used by the Rails promoters and community to describe their belief that the Rails framework is complete and provides the normal functionality you will need while developing the majority of web applications. Many frameworks will not provide all the functionality needed, but only the core functionality. In many frameworks, you may spend a large amount of time getting, learning, and configuring third party libraries and solutions to fulfill very important elements of common web applications. But Rails’ goal is to provide functionality for the developer to eliminate the redundant development of the same web framework tasks over and over. This includes creating the user interface, dealing with business logic, persisting data into the database, and everything in between. All of it, already working together, without the need for the developer to figure out how to configure these elements.
Convention over Configuration
This is where one of the core principles of Rails comes in. Most web frameworks require you to make the same decisions over and over as each new web application is designed. Many IT departments will standardize on their own conventions, but these will vary widely from company to company. Convention is built into Rails, to save the developer the time in redundantly making these decisions, and to ease the transition as a Rails developer moves from project to project, even company to company. You will know where the models are kept; where the controllers are; where to configure the database; where to find the views; where to find the test cases and how they work, etc. and etc.
These conventions also eliminate the hours and hours of typical configuration that many web frameworks require. In many cases, a developer will spend a large portion of their web development in configuring their app and configuring different elements of the framework to work together. This is tedious and very prone to problems that occur from incorrect configuration that can be very time consuming to troubleshoot.
Another of the major principles that Rails is based on is the principle of DRY, or, Don’t Repeat Yourself. This isn’t a concept unique to Rails, as many development patterns are based on this principle. I would say that the entire purpose of Object Oriented (OO) development is based on this concept. However, it’s ironic that even within the world of OO, most web frameworks repeatedly fail the DRY test. Rails attempts to steer the developer into being DRY, due to the ease in which it can be done in the Rails framework, and again, due to the conventions chosen. As you learn Rails you will see how often decisions have been made in order to “force” the developer into developing in a DRY manner.
ActiveRecord is a technology delivered as part of the Rails framework that demonstrates both the DRY and the Convention over Configuration principles. The principle was described in Martin Fowler’s, Patterns of Enterprise Application Architecture. You can read the page from the book describing the ActiveRecord pattern online. ActiveRecord allows Rails to interact with your database, without the need for Database table to Object mapping. Rails is able to interpret your database schema because you create the tables according to convention. For example, the tables are named according to standard pluralization. If your model has the name Car, the table should be called Cars. If your model is Person, the table should be named People. As well, tables use a primary key of ‘id’, and foreign keys are named ‘tablename_id’, as in cars_id. This allows Rails to auto join tables based on the expected primary keys, table names and foreign keys.
There are other conventions and benefits of using ActiveRecord that are beyond this simple overview, including easy built-in validations and easy to use model associations that instructs rails how to use the foreign keys for table joining. ActiveRecord is supported by almost all databases now, including MySQL, SQLite, Postegre SQL, DB2, Oracle, Sybase, and more.
Migrations are a feature of Rails that allow the developer to avoid using SQL to build tables, and to easily move back and forth between various versions of your database schema with very little effort.
I’m not a developer who is against using SQL. I’ve been doing it for so long that it doesn’t bother me. On the other hand, I do believe that the less time you spend changing hats, the better. Even if you are excellent at each “hat”, its human nature to slow down simply when changing mental gears. With migrations, you can build your tables in Rails using a bit simpler syntax. As well, you can then build your database schema at the drop of one command from your Rails project (keeping everything in one place). You can also then roll back to a previous version of your database just as easily.
You are not forced to use migrations, and at first I chose not to. But upon trying them (more than through just a simple tutorial) I became hooked even despite my more than 10 years of SQL. They make database creation just too easy. I don’t have to switch tools, I don’t have to think in SQL, and rebuilding the DB is integrated right within the project.
First a note, that Rails uses three databases. A development, test, and of course, a production database. Each means exactly what it says. Fixtures are files used to provide data for your test cases. When you run your test cases, the data you have provided in the fixtures will be first loaded into the test database (after wiping it clean) in order to put the test database into the state you are expecting for your tests. Fixture data is formatted in the markup language called, YAML.
YAML (which stands for YAML Ain’t Markup Language, and thus is recursive) is a very simple data format. It is designed to be human readable and easy to implement. YAML files end in the extension yml. Rails uses YAML, as previously mentioned, in Fixtures and for the database description file. YAML is also a built in function on objects to allow for easy object representation in the console, in logs, or even for use in a web application. A YAML representation would look like this:
Person name: person's name birthdate: 01/01/2001 gender: M address: street: First Street N city: OverHere state: FL
Ruby Gems and Rails Plugins
A Gem is a package for downloading and installing Ruby code. After you install Ruby, you will install Rails by using the gem install command because Rails is packaged as a gem. You may download other gems at times, to install further Ruby libraries. As well, Rails has it’s own plugin system for installing extensions and modifications into the Rails core framework. These are simply referred to as Rails Plugins.
Rake is a build language for Ruby, similar to make and ant (often used for Java builds). You can study rake all on it’s own, but it doesn’t take long to use it for the standard tasks you’ll need for Rails. The most common uses are to run the db migrations (mentioned above), running tests, loading fixtures, and building documentation for your Rails applications.
WEBrick is a web server library written in Ruby. Rails uses it as a simple web server, not intended for production use, but only for development. It is started from the script/ folder in your rails app: script/server. You won’t need to know much more about that in order to use it for developing your Rails applications.
CRUD is an acronym for the basic operations performed upon a relational database for persisting data. They are: Create, Read, Update, and Delete. Rails provides extremely easy CRUD operations on a database, using the previously mentioned ActiveRecord and using Scaffolding. Often this is talked about as Rails greatest strength, but that is really only a superficial assessment of Rails. It does provide an almost development-free framework for performing basic CRUD operations, but, as you’ll find out, the benefits of Rails only start here.
When Rails first began receiving attention, Scaffolding was one if its most heralded features. Scaffolding is like a built in CRUD wizard. It quickly builds a simple but functional CRUD interface for each model in your application. In literally a minute or two after modeling your data in Rails, you not only have your objects and database created at the same time, but with scaffolding, you can have a fully working interface for manipulating that data. But, as I said under the CRUD term above, while this is very handy, it should not be viewed as the most important reason to use Rails. It’s cool, but by no means represents the full beauty and pleasure of using Rails.