Don Denoncourt expounds on why Rails has become the hottest technology in the web development industry.

I worked the PowerRuby booth at the spring COMMON Conference this year. Many of our booth visitors asked, "Why would I use Rails over Java, .Net, or PHP?" Each time I was asked that question, I seemed to respond with a different answer. So I decided to compile my top ten answers into this article:

1. Convention over Configuration
2. Community
3. Interchangeable programmers
4. Ruby
5. No vendor lock-in
6. Domain-centricity
7. The console
8. Develop production-quality apps while learning Rails
9. Clean integration with HTML, JavaScript, CSS, XML, and JSON
10. Rails works natively on the IBM i

1) Convention Over Configuration

Convention over Configuration (CoC) is an application framework strategy in which well-known and popular industry conventions and best practices are configured automatically. CoC was the brainchild of David Heinemeier Hansson, the creator of Rails. David is a super-techy who knows how to cobble together utilities, frameworks, and design patterns in the construction of a Web application. This complex configuration was discoverable as there were plenty of books and articles and blogs on conventional best practices. The problem was that it often took years to learn those best practices, and even then, it still took days to configure new applications. What David did was automate configuration to use well-known best practices. Now, with Rails, you can configure an application in seconds. The rails new command fleshes out a directory tree of an easily extensible Web application with conventional settings.

Because of CoC, a Rails newbie can generate a Rails application that is ready to scale. Understand that Rails makes it very easy to modify the configuration to do things like specifying the use of IBM DB2 for i as your relational database.

After generating your Rails application, you can then use Rails utilities to generate database tables and conventional Model-View-Controller (MVC) code to maintain those tables. The generators even create sample unit tests. The generated code not only provides usable code, but also demonstrates best practices on development. The hard part is not Ruby or Rails coding but business programming, which you're already good at.

If you compare the Rails CoC development strategy to a PHP application slapped together by someone trying to learn Web development and PHP while coding a real-world business application, you'll find that the PHP app will scale. It also won't be maintainable. To be able to code that PHP application to be scalable and maintainable requires the manual configuration and implementation of complex design patterns.

Because of CoC, Rails is a true Rapid Application Development (RAD) tool. I've been able to develop faster in Rails than with any other tool/language I've used.

2) Community

Community? No, I'm not talking block parties with hot dogs and beer. I'm talking about huge numbers of programmers contributing to open source. The Ruby language has a brilliant strategy for adding language and framework features dynamically. Those pluggable Ruby features are called gems. In fact, Rails itself is a gem. When you're developing a Rails application and you discover that you need to do something that's not in the core Rails features, the first thing you do is look around to see if someone has already published a gem that resolves that issue. To paraphrase Apple: "There's a gem for that."

Now, here's the thing: If, by chance, there isn't "a gem for that" and you want to be an all-round great guy—or, more likely, want to pad your resume—you put your application's required feature into a Ruby gem and open source it. Note that Rails job ads also contribute to gem expansion because they expect applicants to have open-source applications available on code repositories like github.com or bitbucket.org. In short, the Ruby ecosystem coerces viral development.

Ah, you say, but I'm not an expert Rubyist, so I can't contribute. Not true. Newbies provide excellent contributions to open-source Ruby gems. They begin by correcting and enhancing documentation. Then, as they get more sophisticated, they write blog posts and tutorials, maybe do a seminar, and some eventually write a book. As a result of this viral strategy of contributions, Ruby and Rails are very well-documented.

3) Interchangeable Programmers

The interchangeability of Rails programmers reminds me of the glory days of the System/38, when developer salaries were climbing and coders received calls from headhunters on a daily basis. The reason for that boom was because the S/38's RPG development strategy—with things like subfiles and the world's first relational database—was standardized. And Midrange Computing was the bible for best practices.

But the popularity of C, C++, and Java wreaked havoc on the interchangeability of programmers. C, C++, and Java are really systems programming languages. To use them to build business applications, you needed to be an expert, not only in a complex language, but also in a labyrinth of design patterns. I wrote a whole bunch of Java-based web applications myself. The problem was that every time I would begin an app start, I would research the most current best practices. And I'd end up configuring and coding those applications differently each time. So it was difficult for someone else to maintain my applications.

With Rails, new coders are able to get up to speed on existing applications more quickly than with any other framework. Anyone knowledgeable with Rails can maintain an existing application. More than that: even programmers who don't know Ruby and Rails can maintain a Rails application. All they need is to read one or two of the wealth of books on Rails.

4) Ruby

Ruby is a cool language. It's my favorite. Its concise syntax is easy to learn, yet it's the most powerful and flexible language I've ever used. It has a cleaner syntax that the darling child of the IBM i community—PHP. I'm not saying this as someone who played with a couple of languages. I've put food on the table by writing applications in RPG, COBOL, C, C++, Java, PHP, and Groovy.

In short, Ruby allows you to do more with less. With Java and C++, you can code anything. I'm good enough with both Java and C++ to know how to code cool features. But, all too often, I knew it would take too much time to code those features. There's an old saying: "Go the extra nine yards." But who has the time? Ruby makes it easy to code cool things. With Ruby, you go the extra nine yards in one or two steps.

Ruby's conciseness allows you to write better code that's more easily understood. I always say, "Less code, less bugs." Case in point: I recently replaced eight Java files consisting of several hundred lines of code with 112 lines of Ruby. Keep in mind that code is read far more often than it is written, so a concise language makes for more-maintainable applications.

Ruby's flexibility also obviates the need for many design patterns. Rather than learning and using a complex design pattern, you simply use a standard Ruby idiom.

And the last point I want to make about the Ruby language is that it allows Ruby experts to easily create domain-specific languages (DSLs). Now, you may not be writing a DSL anytime soon, but without knowing it, you'll be using DSLs when coding Rails applications. Rubyists write DSLs to make it very easy for newbies to use what otherwise might be complex features. For example, there's a file in all Rails applications called routes.rb in which you specify what controller method is to handle various URL requests. For example, the following statement from routes.rb tells Rails to forward all HTTP GET requests with the URL containing the string "ticket" followed by an integer to be handled by the show method of the TicketsController class:

get '/tickets/:id', to: 'tickets#show'

It's pretty easy to understand what the above statement does, but it's not standard Ruby. It's using a DSL that Rails seamlessly adds to the Ruby runtime so, you, the programmer, needn't learn the complexity of HTTP routing and I/O redirection.

5) No Vendor Lock-In

Rails can be deployed on all mainstream servers using any popular database. All for free. If you don't like something, you can change it. It's open source. By the way, you can also use whatever editor you want. Many Rails developers use text editors, but there are also plenty of integrated development environments (IDEs) for Rails.

6) Domain-centricity

Domains, in Rails, are Ruby classes that wrapper access to your database. Rails domains are the model in the MVC pattern. The following, for example, is a Ruby class that wrappers access to the TICKETS table:

class Ticket < ActiveRecord::Base

end

You might think—because the above class has no code—it's incomplete, but it actually is a powerful class with the ability to create, read, update, and delete rows in the database table called TICKETS. For, example, suppose the tickets table had been created with the following SQL:

CREATE TABLE TICKETS (

   id INTEGER GENERATED BY DEFAULT AS IDENTITY,

   consumer_id     INTEGER,

   sales_person_id INTEGER,

   tax             DECIMAL(7,2),

   cash_in         DECIMAL(8,2),

   updated_at       TIMESTAMP,

   created_at       TIMESTAMP,

   CONSTRAINT tickets_prikeychk CHECK (ID IS NOT NULL)

);

Rails picks up the attributes of the TICKETS table at runtime (using the Active Record design pattern). And so, using the seemingly empty Ticket class, the following Ruby code works just fine:

Ticket.create(consumer_id: 321, sales_person_id: 2, tax: 0.06, cash_in: 1.50)

# list all sales to client number 321

Ticket.where(consumer_id: 321).each {|t| puts "#{t.created_at}: #{cash_in}"}

# chain to ticket number 32, remove the tax, and update the database

t.Ticket.find(32)

t.tax = 0.0

t.save

# delete all tickets for client number 567

Ticket.destroy_all(consumer_id: 567)

Rails applications are written using domain-driven design (DDD). DDD's strategy is to place business logic–associated objects stored in a table in the Rails domain class. Delving a bit further: A sales ticket must have items, so there must be a TICKET_ITEMS table, and the Ticket class should reference it:

class Ticket < ActiveRecord::Base

has_many :ticket_items, dependent: :destroy

end

class TicketItem < ActiveRecord::Base

   belongs_to :ticket

end

Rails makes it easy to retrieve and manipulate objects of tables that are associated with a domain. DDD then goes far further—both with embedded features of Rails and common strategies for developing your domain classes. After using the Rails implementation of DDD for a short time, you'll begin to love it.

7) The Console

I have my Rails console open all day. The Rails console gives you immediate access to your Rails application models. And, because of DDD, that's huge. For example, say I need to look at the last sales ticket for a customer with the the name of Swartzbaugh. In the Rails console I would enter the following:

>> Ticket.where(consumer_id:

                           Consumer.where(name: 'Swartzbaugh').first.id)

                     .last.ticket_items.each{|i| puts "#{i.descr}:#{i.quantity}"}

The console would then respond with this:

KETTALUX PLUS TABLE, 63"X38":1

TIFFANY H/B CUSHION:4

7.5' UMBR COVER W/VALANCE:1

ROMA HIGH-BACK CHAIR:4

CAST ALUM UMBRELLA BASE, 50LB.:1

The Rails console makes developing and debugging fun. Before coding complex expressions in your Ruby classes, you always try them first in the console. And, rather than using your favorite SQL client, you should use the Rails console. When I first begin mentoring developers on Rails, I find them regularly opening their favorite SQL client and typing complex SQL with JOINS and WHERE clauses. But, once I show them to how the Rails application model classes provide easy access to the complex relationships between objects, they drop their use of SQL clients.

Note too that the business models most always have business methods tied to that model. For example, in a K-12 online education application that I wrote, the course model had methods called total_seats, available_seats, and open_sections. It's a real time-saver to be able to invoke business methods right from the console when you're debugging production issues.

I've found the Rails console to be so handy that I've begun to add models to a utility Rails application merely to use the console to assist in the process of debugging non-Rails legacy applications.

8) Develop Production-Quality Apps While Learning Rails

You can install Rails, generate an app, and begin to code without cracking open a book on Ruby. Admittedly, it's also very easy to begin to write a usable PHP application. The difference is that the Rails application, because of CoC, is scalable and maintainable, whereas your PHP application will need to be rewritten after you learn how to do it right. With Java-based web apps, you need to learn Java, HTML, HTTP, JavaScript, and CSS before starting your first web application. As I'll cover in the next bullet, Rails makes it easy to use HTML, JavaScript, and CSS.

Case in point on the ease of the path of learning Rails: One of my Rails mentors was a realtor a mere two years before he became my mentor. He wrote a Rails application for his real estate group, took down his realtor shingle, and now writes Rails applications for Internet startups.

9) Clean Integration with HTML, JavaScript, CSS, XML, and JSON

Rails CoC puts JavaScript, CSS, and HTML into well-organized directories. For example, suppose you use the following three commands to 1) create a Rails application, 2) generate an RDB table and the associated model, and 3) run the Rails generator to create maintenance MVC files:

• rails new sample_rails_app
• rails generate model Post title:string text:text
• rails generate scaffold_controller post title:string, text:text

Your console, as shown below, will log the creation of Ruby, JavaScript, HTML, and even JSON generators.

mac ~> rails new top10

     ... some create logs omitted ...

     create app/assets/javascripts/application.js

     create app/assets/stylesheets/application.css

     create app/controllers/application_controller.rb

     create app/helpers/application_helper.rb

     create app/views/layouts/application.html.erb

mac ~> cd top10/

mac ~> rails generate model Post title:string text:text

     invoke active_record

     create   db/migrate/20140715022710_create_posts.rb

     create   app/models/post.rb

     invoke   test_unit

     create     test/models/post_test.rb

     create    test/fixtures/posts.yml

mac ~> rake db:migrate

== 20140715022710 CreatePosts: migrating ======================================

-- create_table(:posts)

   -> 0.0006s

== 20140715022710 CreatePosts: migrated (0.0007s) =============================

mac ~> rails generate scaffold_controller post title:string, text:text

     create app/controllers/posts_controller.rb

     invoke erb

     create   app/views/posts

     create   app/views/posts/index.html.erb

     create   app/views/posts/edit.html.erb

     create   app/views/posts/show.html.erb

     create   app/views/posts/new.html.erb

     create   app/views/posts/_form.html.erb

     invoke test_unit

     create   test/controllers/posts_controller_test.rb

     invoke helper

     create    app/helpers/posts_helper.rb

     invoke   test_unit

     create     test/helpers/posts_helper_test.rb

     invoke jbuilder

     create   app/views/posts/index.json.jbuilder

     create   app/views/posts/show.json.jbuilder

Take note that the first command, the rails new command, will create conventional JavaScript and CSS files in the appropriate directory. Furthermore, if you use a popular gem like twitter-bootstrap-rails or foundation-rails, you will find that it's almost trivial to make professional-looking pages.

Rails makes it easy to respond to HTTP requests with JSON, XML, or HTML because it follows a Representational State Transfer (aka RESTful) strategy in its application workflow.

And because everyone needs a bit of AJAX in their application, Rails has a set of helper classes that make it easy to provide AJAX features with little or no JavaScript coding.

One last thing about JavaScript and CSS: As web applications get more complex and we use more and more JavaScript and CSS files, browsers begin to become less responsive because they must download each of those files. Rails—when in production mode—uses something called the asset pipeline to compress all JavaScript and CSS into a single file, which substantially improves page load times.

10) Rails Works Natively on the IBM i

You're already on the world's most secure operating system with the world's best relational database. And now, on that same platform, you can use the world's hottest tool for web application development and hosting. How cool is that?