Walking the edge

Rails 3.0, HTML5, Unobtrusive JavaScript, Grails, No-SQL databases…These are some of the web technologies that have exploded recently, and with them the promises for better, stronger, faster tools that will improve the end user experience. However, from the programmer’s perspective, transitioning to these new technologies, which usually happens shortly after you start telling yourself “I think I finally got a hold of this previous release”, can be time-consuming and may, at times, drive you to reconsider career choices. At Mythic, we believe in the power and promises of open source solutions, including the Ruby on Rails train. It is through our experience in moving from Rails 2.3.5 to Rails 3.0 that I propose to discuss the ups and downs of making your company edgy.

I don’t think anyone will disagree that the web and its now countless actors have immensely benefited from the industry’s pursuit of technology. It has never been as true as today, as the open source model is quickly becoming the reference, and a great number of talented programmers share through Github and similar community code sites the frameworks, modules, plugins and other gems which allow less talented programmers such as myself, to rapidly build functional applications with features that were unthinkable of 5-10 years ago. That being said, keeping up with all the updates and dependencies is no easy task, and transitions are not always as smooth as they seem.


Easy update? The case of Rails 3.0

I don’t know if you’ve heard, but Rails 3.0 is officially out. Great series of tutorials are freely available (thank you Mr. Bates and everyone I forget) and people seem excited about Unobtrusive JavaScript (UJS, think CSS for JavaScript). So since we like living on the edge, I figured we should make the transition. We have a relatively heavy-weight application that has been in the making for about 18 months in Rails 2 that we like to think is in what-s-the-letter-before-alpha version. Turning this juggernaut into a Rails 3.0 application thus became an option. Take our 3 billion lines of code, install that new gem, restart the server and voila! Even I, the eternal optimist, was not naïve enough to believe that would work. So instead we took advantage of a smaller project with much simpler requirements to spawn a brand new Rails 3.0 application.

While the general idea remains the same, Rails 3.0 introduces a set of new concepts that will likely make copying and pasting code from an old Rails 2 application a vain attempt. This is particularly true about JavaScript and the ensuing AJAX functionality I liked so much in Rails 2. Rails 3.0 was built to deal with Rails 2’s quasi-dependency on Prototype and allow connectivity with other JavaScript frameworks such as JQuery or MooTools, transforming it into a JavaScript-agnostic framework. This resulted in the deprecation of a set of simple Rails wrappers that were making AJAX fun and easy in the 2.x days, and the obligation to rewrite a fair amount of code to retain functionality. Another issue stems from having too much choice. As cool as each of these JavaScript frameworks are, I promise you some headaches if you try to combine their functionalities, as they tend to conflict here and there. For that reason, I decided to avoid mixing them up and opted for JQuery as my single JavaScript framework. Finally, opting for Unobtrusive JavaScript really means that you need to become a better JavaScript programmer, which is great for personal improvement, but does require time and effort.


Small steps

So this all sounds very negative and if you haven’t experienced Rails 3.0 yet, you may now be thinking “Not with a 10-foot pole”. Well don’t. What I am saying, and I believe it applies to most fast evolving web technologies, is that the transition will not happen overnight. What it means for internet companies that rely on such technologies to support their applications is transitioning to the next major release of a programming language or a framework is no small task and does require significant time and resource investment. And having the right people to plan and implement your migration is key to this process. We found ourselves happy to push forward with a smaller application to wet our toes, while preparing for the migration of larger ones.

I believe this is a good way to begin the transition process. I will discuss migration strategies in more depth in the next episode. Stay tuned for: Can living on the edge throw you over the edge? Part 2: Coming of Edge