You are an established .NET programmer.
You have built too many web applications with ASP.NET.
You have spent many sleepless nights trying to understand, in advanced detail, how to leverage the event-driven model of ASP.NET control cycle to work the way you want.
You have gone deep into using design patterns like Presentation Model or Model View Presenter to properly layer your application, to make it more testable and maintainable.
You think Ruby on Rails is just like any other technology hype and you should not pay too much attention to it until they have a respectable market share.
Welcome to my world. If you are still reading this article you have my admiration, because you are curious enough to take a peek at how I, after merely a month into Ruby on Rails as an experienced .NET programmer, will say many applications I had previously built can be done in less time and coding, only if I had known Ruby on Rails.
To be fair, I still think .NET is great. It has offered me a place where I am consistently delivering great business value to my clients. However, I constantly remind myself that there are multiple ways and numerous technologies to solving a single problem, some better than others. By being loyal to one technology stack, I am bound to unconsciously make biased decisions, which will ultimately hinder my ability to deliver business value. For example, knowing a dynamic scripting language like Ruby makes me think that I can write simple batch/shell automation scripts in much less time, compared to using a compiled language.
So why not?
Here are a few things I have found that are a new paradigm shift for me as a .NET programmer learning Ruby, and that I hope you will enjoy.
Do not compile.
In Ruby, there is no concept of compilation. Everything runs at runtime. Some say code compilation is a guard against careless coding, but you may want to look at how test driven development, continuous code integration (no, it is not daily build), unit testing (tests that do not hit databases or web services), and dependency injection help you to produce code of good quality and enable you to flexibly change your code with confidence. Compiling your code all of a sudden becomes less useful as a safeguard.
Dynamically enhance the behavior of a class - without a Decorator.
Using the Decorator design pattern is one way to do it in a typed language (another might be Template Method). However in Ruby there are many more ways to dynamically enhance a class easily, just by the fact that the language itself supports it, without complicating your object design structure. Consider module mixins, class_eval, instance_eval, etc. In fact, one can even at runtime programmatically define methods on a class. Code generation in a typed language might be a way to achieve it, but simply knowing that other options exist makes you a better problem solver.
Slim down your code base 10-20% by stripping off all type declarations and interface declarations.
Ruby is a dynamically typed language. You do not need to declare the type of a variable before using it, or make your method signature parameters properly typed. This means your code becomes slimmer at the expense of harder to debug and trace for errors, right? Not so, if you believe in unit tests and good object oriented design concepts. If your classes are small and cohesive, and their methods are short and well-intended, and well unit tested, then debugging and tracing for errors is easy.
Ajax it in no time.
Ruby on Rails built-in has support for script.aculo.us, an Ajax library that has tons of flashy Ajax effects to make your application much more user-friendly. In many cases, it is equivalent in ASP.NET to dropping a control tag onto your html pages, then write a method in your code-behind (in Rails it’s the Controller) to handle the Ajax web request on the server side, and your web page now supports Ajax functionalities like Google Suggest’s autocomplete, or drag-and-drop sorting on a web page. It’s that easy.
With Rails, you don’t need an O/R Mapper.
By applying a few naming conventions while naming your database tables and columns, and your domain model objects, you can forget about the pain of implementing an O/R Mapper on your own. Ruby on Rails does it for you. In the simplest case, all you need to do to add a field in your view and persist it is to drop a textfield in your html, add the column you want the value to be stored in to the appropriate database table, then watch your user-entered text being persisted into that newly created column in the database. Really, that’s all you need.
Using Ruby script to build/deploy/release is better than using NAnt.
The standard build tool in Ruby on Rails development is Rake. Rake uses Ruby, and that means you will use Ruby to craft your build scripts for your various build and deployment needs. As a language, Ruby is so much better when it comes to handling string manipulation, file and directory creation, including superior regular expression support. Think about how many times in your batch or NAnt scripts you have done things like: for each file with extension ".sql" in directory "a", copy them from server A to server B, then execute them one by one. If you hate the programming limitation of batch scripting, or you don’t like to script things in NAnt’s xml format, chances are you will like Rake.
No pain no gain.
There are a few hurdles I had to go through in learning Ruby. First, I had to go through the emotions of accepting the fact that it will take longer to find a new Ruby solution than to use an existing technology that I am comfortable in. This is by far the most painful experience. But, after a while, you will start cherishing the fact that you are starting to develop multiple ways to solving different problems, and that’s where the pleasure comes in. Secondly, reading about Ruby/Rails only gets me so far. Practically using what I have learned helps me to remember what I have learned. Remember, use it or lose what you have invested time to read about.
About the author
Stephen Chu is a software developer consultant at ThoughtWorks. He is an experienced .NET developer and has recently caught on with Ruby on Rails. You may read about his everyday new enlightenments in his blog at http://wwwstephenchu.com.