The Ruby on Rails mantra is known to favor “Convention over Configuration”.
What does that even mean? Coding is more simple? More efficient? Easier to maintain and scale? How does convention over configuration apply to a developer? An I.T. Director? Why should I adopt a convention over configuration mindset?
From an RPG Mindset
Coding green screen apps in RPG has to be one of the most efficient means to convey an interface to a user. When a single entity, IBM, can control everything from front to back a lot of complications can be hidden. For example, not many RPG programmers understand the intricate details of the 5250 data stream and instead expect the EXFMT keyword to reliably display a record of a DDS-based display file – no questions asked.
Green on black was all fine and good until the web came – and along with it the need to have our applications talk to the browser. This brought many horrible inefficiencies as things previously simple now became complex. We no longer have a stateful one-user-per-job environment. We, or IBM rather, don’t have control over the rendering client (internet browser). The technologies involved with writing web apps – namely HTML, CSS, and Javascript – were originally meant for conveying information rather than interacting with it. My teenage children would categorize this as a “hot mess”.
Technologists developing frameworks for the web have forever been trying to fix this situation. Initially it was good enough for languages to have the capability to talk to the browser, but that didn’t suffice for long because turn-around time wasn’t quick enough. Around this time Ruby On Rails came along with its Convention over Configuration concepts – CoC for short.
Tim O’Reilly, founder of O’Reilly Media, explains it best by saying, “Ruby on Rails is a breakthrough in lowering the barriers of entry to programming. Powerful web applications that formerly might have taken weeks or months to develop can be produced in a matter of days.”
So what exactly is convention over configuration? Wikipedia has a good starting definition stating: “Convention over configuration (also known as coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.”
That sounds an awful lot like where we came from with 5250 green screens. Glad they are heading in the right direction! Now, let’s take a look at some of the ways Ruby On Rails saves us time.
The creator of Rails, David Heinemeier Hansson, believed web frameworks should be opinionated and declare a best way to do web development – and that having too many options can sometimes be a bad thing. This is in contrast to the earlier efforts of Perl where statements of “there’s no right way” left many things open to interpretation and created a big wilderness for each developer to conquer. For the remainder of this article I’ll describe aspects of the CoC practices of Rails, including ones that take it much further beyond what we have today with RPG.
App Foundation
A new Rails app is created with a single command: rails new my_app_name
This will generate roughly seventy (70) files and folders that comprise the infrastructure and foundation for your Rails app. It includes folders to hold your models (database layer), controllers, and views. Folders to hold unit tests for your application. Folders to hold your web assets like Javascript and CSS files. Default files for HTTP 400 responses (i.e. file not found) and many others. Not only is this a big time saver to get projects started on the right foot, it also means all Rails applications are similar, which makes it easier for another developer to step in.
Environments
The rails new command also generates three separately configured environments: development, test, and production. More specifically, when a Rails application is started it will look to see what environment it is running in and load the corresponding configuration file. This simplifies things greatly because when in development I can declare Ruby programs shouldn’t be cached because I will be changing them frequently, but in production I do want caching to save on load times. Another feature is whether errors should be displayed to the browser. Obviously I never want users to see an error stack trace so this is turned off in the production config but turned on in development so I can more easily debug. Lastly there is a database config file that has separate entries for each environment which is handy so you never have to worry about changing data library names once an app is deployed to production.
Database
Rails has many code generators and one can generate a model (database table) and by default it will add two columns named updated_at and created_at because more often than not you always need that information for each row. Nice! If you come to a scenario where you don’t want them then you simply remove those references before running the command to actually affect the DB2 schema (aka library). That’s what’s nice about Rails – there’s always a simple way to go around the defaults if necessary. I didn’t have the same experience with JavaServer Faces (another web framework).
On the topic of database tables, another CoC is how Ruby model classes are named. For example, if the model class is named “Customer” then it will assume the corresponding database table is named CUSTOMERS and not require you to create an alias mapping. What? You call your DB2 table CUSTPF? No problem, it is simple to override the default.
To HTML or to JSON, that’s the question
Rails follows the MVC (Model, View, Controller) mindset of keeping things separated by concern – a very good thing. What this affords us is the ability to easily switch out what is delivered to the browser. For example, in some cases when I invoke the get_customer_list method I may want an HTML result that can be displayed in visual fashion to the user, and in another scenario I may need a more web services approach and require JSON to be returned. What’s cool is Rails supports this out of the box and you can declare you want a JSON response by simply appending .json to the end of a URL request (i.e. http://mydomain.com/customerlist.json).
Wrapping Up
We are just touching the tip of the iceberg concerning what Rails simplifies. Probably my biggest hurdle in learning Rails was because I had written so many RPG-CGI programs the “hard way” – the much longer way. I had to undo a lot of traditional thinking and realize things were simpler than I imagined.
Maybe your shop has been looking to get to the web and wants to learn more about whether Ruby On Rails is a good fit for your business. We can help. We offer professional services to implement web applications big and small – including training your staff so you can eventually take over development if you so choose. Contact us today to chat about your needs by sending an email to team@litmis.com.
Stay tuned for Part Two of our email campaign series, “A Gem of a Community”, coming next!
Good stuff! Looking forward to more!
Agree with Joe. Keep em coming!
Timely as our shop is evaluating Ruby vs PHP.