Ruby on Rails: A Java Developers Perspective
by: Joshua Swan
Introduction
If you’re reading this, you’ve probably heard of the Ruby on Rails framework and the hype around it: it allows developers to develop code up to 10 times faster, it’s easier to use than other languages like Java, and it’s fun to develop in. Well, I’m a Java developer who ignored the hype for quite a few months thinking that was all it was, hype. I mean lets face it, how could it be better than Java with the use of lightweight technologies like the Spring framework and Hiberate? Well, this last year an opportunity presented itself allowing me to work with Ruby on Rails, and see what it is all about. In this paper I will discuss the challenges and benefits I found while developing a project using Ruby on Rail, and how it compares to Java. To organize things a bit I broke my experiences into four areas: the Ruby language, the Rails framework, the development environment, and the testing environment.
The Language
Benefits
When I started learning Ruby, I was pleasantly surprised that it has a lot in common with Java. Unlike Java, however, it is much less verbose. I was impressed with the languages ability to keep things simple and succinct. This is due to the fact that one of the differences between Ruby and Java is that Ruby is a dynamic language compared to Java which is a static language. I immediately noticed the amount of useless variable declaration I did not need to code, and I could get right to the meat of the coding.
I also noticed that Ruby’s built-in regular expression functionality came in quite handy in minimizing complex string logic, especially in condition blocks. The syntax for the regular expressions and the fact it is built-into the language itself made them easier to use than Java’s regular expression library.
One of the other things I noticed was that Ruby is a fully object oriented language, meaning event numbers are objects. It was nice not needing to worry about primitives and conversions from ints to Integers, etc. Ruby’s library also provided convent functions for converting between data objects such as Strings and Integers.
One of the big advantages I saw was with Ruby you can essentially simulate multiple inheritance without the hierarchy problems, etc., that come with it. This is achieved through mix-in inheritance which is accomplished using “modules”. A module is basically a namespace for methods and constants you want to add to other classes, and Ruby allows you to add multiple modules to a class. I found this mechanism easy to understand and organize. It also provided me with a flexible mechanism for adding or modifying the functionality of my classes. I could even add and remove methods at runtime by making use of Ruby’s reflection methods. Java with AOP can achieve the same results, but it requires much more code and configuration.
Another feature of Ruby that I found interesting is the concept of “blocks”. A block is basically a piece of code that can be passed as a parameter to other functions and executed. They are kind of like unnamed functions. I found this mechanism is commonly used to execute a block of code on each element in a collection such as an Array. They are very useful for simplifying looping code, and can often condense a for loop down to one line of code. The ability to develop functions that take in pieces of code provides a powerful mechanism for developing flexible code. The closest mechanism in Java is anonymous inner classes, which are much more verbose and not as developer friendly.
In general, I found Ruby is on par with Java in terms of ease of use. In terms of power and productivity, I think Ruby is a more powerful language given Ruby’s module and reflection features are inline with the direction the industry is going with AOP. I did see some productivity gains, mostly due to the reduction in code verbosity.
Challenges
I didn’t have many major challenges learning the language, because it is similar to Java in many aspects. However, it did take me some time to wrap my mind around some of the concepts such as mix-in inheritance and blocks, and how to use them effectively. Personally, I learn best by example, so I looked up some examples online and then programmed some of my own examples to nail the basic concepts home. With all of the possibilities available to you in Ruby, especially with the block mechanism, it can be hard to figure out the best way to architect your code. Finding materials on “best practices” in Ruby was sometimes difficult compared to Java where they have been established for some time. I’m sure this will change, though, as Ruby gains momentum.
The Framework
Benefits
Rails is the web framework that has really brought a lot of attention to Ruby lately. I’m a big advocate for Spring and Hibernate, and I found Rails, in comparison, is very similar to use. Rails uses convention over configuration so I had to do only a fraction of the configuration work I had to do with Java frameworks like Spring and Hibernate. The only thing I really had to configure was the database connection parameters; everything else has a default behavior based on the conventions Rails uses. A lot of “magic”, such as request routing, took place behind the scenes to handle a lot of things for you.
One of the things I liked right off the bat with Rails was I did not have to integrate a bunch of different frameworks to get thing rolling. Rails had each layer (i.e., web, business, and data access) built right into the framework, and yet the Rails development team did a great job of keeping the layers relatively separated. The data access layer has a built-in ORM class, ActiveRecord, which impressed me the most because I did not have to write much database access code. ActiveRecord uses meta programming to discover everything it needs to know about the database structures. I did not have to describe the structures for it like I would with a Java ORM such as Hibernate. That alone saved a huge amount of code and configuration, and the flexibility of ActiveRecord allowed me to handle most situations that arose.
One of the nice things about Rails is with the Ruby language I was able to override or add functionality to Rails if needed. Two mechanisms I found particularly useful were filters and plug-ins. Filters allow a developer to insert calls to methods before and/or after other method calls in a very AOP like way. I handled authentication to controller actions in this way and it worked very smoothly. I also used a couple of plug-ins to actually add methods to some of the base classes and modules in Rails. These mechanisms provided a great deal of flexibility without the configuration and coding overhead that most Java AOP frameworks have.
Another benefit of Rails is its built-in AJAX helpers that you can use to add AJAX to your web pages. With the increased interest in interactive web pages, I believe this is a big plus for Rails. The helpers allow you to switch sections of your page with the results of dynamic function calls. The nice thing about the Rails helpers compared to the Java third party libraries I’ve looked at is that I don’t have to write a single line of JavaScript to use them if I’m careful. Most Java AJAX libraries still require you to write some of the JavaScript yourself; granted most of the complex JavaScript is handled for you.
I found working with Ruby on Rails very enjoyable and less stressful than most Java frameworks I have tried. The framework makes many tasks, like creating data edit forms and url linking, easy. Due to the frameworks vast amount of useful functions, I did see a significant increase in productivity in comparison to J2EE frameworks. For simple and mild complexity apps, I probably saw a 5 – 10+ increase in productivity when sticking closely to the frameworks conventions. However, I noticed once I started using AJAX and began to move away from some of the frameworks conventions, my productivity started to drop slightly. I noticed as a project becomes complex and larger it is important to have a clear organization for your code and know what expansion paths are open to you in Rails. If you clearly plan how the application is going to grow, then I see no reason why Ruby on Rails wouldn’t scale for larger applications.
Challenges
The main challenge I encountered with Rails was the “magic” factor and wrapping my mind around how Rails worked. In Java, programming occurs at a slightly lower level than in Ruby. Everything is reasonably explained, you configure it the way you want things to work, and you integrate the layer and various Java frameworks together yourself. In Rails, most of this is done for you so you end up programming at a much higher level. The benefit is you don’t have to worry about configuration; the disadvantage is you sometimes do. Rails was so black box to me at first that I was actually uncomfortable using it. The problem was I wanted to know what it was doing behind the scenes, and later on I needed to know so I could alter it. Luckily, the Rails API does a good job explaining some of this, and you can always go directly to the source code if need be. Still, there is a bit of a learning curve if you want to do complex applications with Rails.
I came across another challenge when I started using the AJAX helpers. I first had to learn partials thoroughly, because AJAX makes extensive use of them. The problem came after I started using two or three AJAX calls on a page. Organizing the partials and the action calls in the controller started to become difficult and became extremely hard to maintain due to the complexity that ensued. In the end, I redesigned the system to use only one or two AJAX calls and only when necessary. The helpers are very good with simple straight forward AJAX calls, but it may be necessary to write some of your own JavaScript for really complex tasks. On the other hand, most applications don’t need to use AJAX except in very specific situations. In my application I was probably going a little overboard with it at first.
Development Environment
Benefits
When I developed in Ruby on Rails, I used Eclipse with the Ruby Development Tools plug-in. I configured my environment using the instructions provided by Brian Hogan at http://www.napcs.com/howto/railsonwindows.html. He also uses a basic set of plug-ins for database and subversion access from the eclipse environment. He provides a config file that has External Tools configurations for using the external Rails scripts from within Eclipse. I found this mechanism more than adequate for what I needed to do. He also provides a template file, adding common Rails functions to Eclipse’s code hints , that may be imported in the JSP Template area in Eclipse’s preferences area.
The thing I loved about Rails is all of your development needs are provided for you. Rails comes with scripts to handle everything from creating a new project to debugging your code. It also provides you with numerous wizard scripts for generating code structures. Rails provides a web server, WEBrick, for running and testing your code in a browser. Technically you don’t even need a development environment like Eclipse; you could just use the command line and a good text editor, which is what many people do. When it comes time to deploy your application to a testing or production server, you can either copy the code over manually, which is easy since it does not have to be compiled, or you can go download and install Capistrano. Capistrano is a tool for automating the deployment of applications to one or more web servers. It may be customized to handle most server configurations.
Challenges
The main challenge with the development environment is the lack of a good IDE. If you like using the command line and a text editor, then you are good to go, but personally I like my IDE environment. Brian Hogan’s article on setting up Eclipse to develop with Ruby on Rails was a very helpful, but it also requires some setup time. RadRails is another development environment for Ruby on Rails that is starting to mature, and I believe it also comes as a plug-in for Eclipse. The development environments for Java at this point are far superior. It would be nice to see some mature Ruby on Rails development environments with similar features. For instance, code hints for the Rails API would be a big help.
Conclusion
Being a Java programmer I have to admit I was very skeptical when I first started developing with Ruby on Rails, but I found that much of the hype surrounding it seems to be based somewhat in reality. The Ruby language itself has been around for a long time and is clearly a very powerful language. I could not think of anything I could develop in Java that I could not reproduce in Ruby. As for the Rails framework, it seems perfectly capable of handling medium to large projects, and can considerably improve developer productivity if you stick to its conventions. I think some clearer standards or practices would be helpful for code organization so large projects don’t become unmanageable. I would also like to see more enterprise features such as internationalization and distributed transactions. Admittedly, though, most organizations don’t require these features. With the increasing interest in Ruby on Rails, I believe features such as these will be added to the framework or developed as a Rails plug-in in the near future. In conclusion, I think Ruby on Rails is a worthy addition to any developer’s toolbox, and I would encourage developers to try it out before dismissing it, like I almost did.