Road to Rails

Disclosure – I am what you would call a .Net developer. That is what I use professionally, and more often than not it’s my first choice. Go with what you know, right? Well, no, not religiously.

My first task when joining Qworky at fall of 2009, was to develop the very first Qworky meeting prototype. Going with my comfort zone, I used .Net, MS SQL Express and a chat service from chatterous. That was a two week project. Soon, we discovered other engineering members were having difficulty compiling the solution, mainly because the right set of tools were not installed. Also, it turned out that a majority of the open source engineering team came from a UNIX and OS X background.

As a result, we sprung on a quest to find an environment which could work better for us. After a couple of days Jon came with a Ruby on Rails recommendation. Then homework for all (three engineers at the time) was to see how we liked it.

Easy Setup

That weekend I picked up Ruby on Rails. To my pleasant surprise, it was very easy to spin up a blog-like application. Incidentally, most Rails examples on the Internet revolve around blog-like apps.

I had a few hiccups while setting up Rails. The annoying one was on mismatched versions. I wasn’t clear which component (gem in Rails lingo) went where. Perhaps this was also aggravated by the fact that I was using an unfamiliar system – OS X. I owned a MacBook Pro for close to two years now. It is boot camped with Windows and, get this, I almost exclusively boot into Windows. This time around I had the bright idea of learning Rails on Mac. Long story short, I had two learning curves; Rails and OS X. All the same, I had a pleasant experience.

Why Rails?

Besides the reason above, let’s look at some of the technical requirements.

• First, it needs to support multiple interfaces while maintaining a shared business logic and database. Content needs to be served in different formats – for web, mobile and/or desktop. This situation lends itself well for Model-View-Control (MVC) design pattern. Rails is also modeled around MVC coupled with a RESTFul interface.
• Second, the project had short development time. And guess what? Rails supports rapid development. It comes with tools to generate boilerplate code, has rich libraries and out-of-the-box testing framework.
• Thirdly, another equally important reason presented to me (which I took at face value), is that the Rails community has excellent organization and documentation.

In fairness, Rails isn’t the only technology we could use. Yet, when evaluating based on our most important criteria- Rails seemed the best match.