Ruby On Rails impressions
I recently had the opportunity to write a web-app in Ruby on Rails at work for a developer contest. Despite having a steep learning curve, it was a very good experience.
Ruby, the programming language is a dynamically typed language, similar in some ways to python. Rails is a web development framework written in Ruby that is very popular with the Web 2.0 and agile folk; it lets you develop web applications extremely quickly, making frequent, small iterations.
My only experience with web development before this challenge was an ill-fated one for a potential employer written in Java. I had to attempt to learn Struts and Freemarker at the same time, on a very tight deadline. It was one of the most frustrating experiences in my life, and the end product didn’t run on their end.
Developing in Rails is the antithesis of developing in Java. Any time I go from Java into a looser programming language like Python, or AWK, or now Ruby, it’s a truly liberating experience. Java, for all its good features, is just so verbose to do simple things. Furthermore, the levels of abstraction with Struts seem all wrong; you still end up having to write SQL code yourself and insert it into code, executing it through Java.
Rails hides a lot of the complexity from you, which lets you focus on the task at hand. A defining credo of the Rails folk is “Convention over configuration.” Whereas you might have hundreds of lines of XML configuration for a Java web-app, there is little to none in a Rails app. If you follow naming conventions, the framework will automatically hook together your loosely coupled components.
The framework has as its central design pattern the Model View Controller paradigm, which strictly separates the Data (model) from the representation of the data (view). The controller acts as an intermediary between the two, fetching the desired items from whatever database or flat file your objects are stored in, and routing users from page to page. Fortunately, I was already well acquainted with the design pattern, so this was not a significant stumbling block.
While I really enjoyed learning the basics of Rails, I won’t pretend it was always easy or painless. I was stuck for around 2 hours one day with a problem where my web-app would hang, run out of memory, and fail when I went to a certain page. I went through the log file and I noticed it doing the same SQL query thousands of times before running out of memory. Fortunately I have a rails expert in my office, but even he was stumped. We went so far as to replace the SQLite database with a MySQL one, but the problem still occurred.
Eventually I discovered that the problem was that the method I had defined in the controller class was overloading one of the base class; it was named “request” and there was already a method named request. As such, even though I was never explicitly calling the request method, it was implicitly called, and ended up getting into a loop as the action contained therein must have triggered another “request” action. This was one time in which not knowing the proper convention and reserved names really bit me in the ass.
In conclusion, developing a web app in Rails was extremely rewarding and eye-opening. It’s going to be hard to go back to Java after seeing what can be accomplished so quickly by having some extremely intelligent default behavior, rather than having to specify everything yourself.