Migrando a “Ruby on Rails” desde ASP.NET sin retorno.

En 2008, al graduarme en la Universidad ya era un seguidor de .NET. Empecé en un puesto de trabajo interesante en el que se trabajaba con VB.NET y quedé formándome como un conocedor del framework. Pude desarrollar en equipo usando el Team Foundation Server con todos sus servicios, incluyendo su herramienta para el control de versiones.
Trabajé durante un año en un proyecto ERP llamado iAra para el comercio de nickel (aplicaciones desktop, sitios web, servicios web). Al salir de la empresa me sentía listo para emprender el camino del Freelance: administrar mi propio tiempo, autoaprendizaje constante, búsqueda de proyectos, solución de problemas en solitario, participación en comunidades online y tiempos de entrega apretados. El framework .NET ha sido hasta hoy un buen compañero.
¿Entonces que ha causado esta migración definitiva desde .NET hacia Ruby on Rails?

Primero que todo, aunque me lo propongo, no creo que sea del todo definitiva: la experiencia de estos años como desarrollador .NET es una fortaleza que seguiré usando en algún que otro proyecto. El motivo principal es que mientras leía y estudiaba sobre las características del ASP.NET MVC, muy satisfecho por todas las nuevas bondades y facilidades del framework, siempre aparecía alguna cita o comentario:
(…) Ruby on Rails (o simplemente Rails, como se le llama comúnmente) adoptó una arquitectura MVC (Modelo-Vista-Controlador). Mediante la aplicación del patrón MVC y trabajando en sintonía con el protocolo HTTP en lugar de en su contra, por la promoción de las convenciones en lugar de la necesidad de configuración, y mediante la integración de una herramienta ORM (Object-Relational-Mapping) en su núcleo, las aplicaciones con Rails empezaban a sentirse, algo natural, era como si el desarrollo web siempre tuvo que haber sido de esa forma; como si nos hubiéramos dado cuenta de repente que habíamos estado luchando contra nuestras herramientas todos estos años y ahora la guerra había terminado.(…) 
Este párrafo traducido (por mí, y lo siento mucho) desde el libro “PRO ASP.NET MVC 4” despertó una chispa de curiosidad en quién había oído mencionar este framework en muy pocas ocasiones. Pero fue el siguiente párrafo quién me llevó directamente a la página de Ruby on Rails, y ya luego tuve que seguir regresando:
(…)Rails nos muestra que el cumplimiento de los estándares web y el uso del REST no tiene por qué ser difícil. También muestra que el desarrollo ágil orientado a las pruebas (Test Driven Development) funciona mucho mejor cuando el framework está diseñado para apoyarlo. El resto del mundo del desarrollo web se ha estado recuperando desde entonces.(…) 
 Unos días más tarde ya podía explicarles porque el framework Rails ha tenido tanta aceptación y porque su eslogan es: “Desarrollo web que no molesta”. Veamos algunas:

Lenguaje Ruby

El lenguaje Ruby fue creado por el japonés Yukihiro “Matz” Matsumoto, quién mezcló partes de sus lenguajes favoritos (Perl, Smalltalk, Eiffel, Ada, y Lisp) para formar uno nuevo que incorporara tanto la programación funcional como imperativa. (Tomado de www.ruby-lang.org/es ) 
Ruby es completamente orientado a objetos. Se siente como un lenguaje muy natural, muy cercano al inglés pero es muy complejo en su interior. Es muy divertido ver su código, y a menudo nos puede parecer magia. Sin más, les dejo un ejemplo de código:

Con solo saber programación orientada a objetos y un poco de inglés ya sabemos lo que hace este código:
Declara un clase “Micropost” que hereda del ActiveRecord (ORM por defecto), lo que la convierte en el Modelo de MVC, luego las validaciones a sus campos y luego el método belongs_to te dice claramente en inglés que un Micropost pertenece a un Usuario. Y el código de la clase User más claro no puede ser. Luego de ambas declaraciones es muy fácil acceder a los microposts de cada usuario:
@user.microposts
Et voilá! Todos los micropost de este usuario a nuestra disposición. ¿Se fijaron que no es necesario declarar el tipo de dato de esas variables? El framework Rails las reconoce inmediatamente. Esto es a lo que se le llama en Ruby on Rails “convenciones”, ya veremos que son más adelante.

Ruby on Rails es Ágil 

El framework está concebido siguiendo los principios del desarrollo ágil planteados en el Manifiesto de Desarrollo Ágil:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

En “Ruby on Rails” todo se basa en las interacciones de los desarrolladores entre sí y con los clientes, como resultado se obtiene software funcional sin necesidad de diseñar o planificar procesos complejos.
Aunque Rails no renuncia a la documentación, nunca encontrarás cientos de páginas en un documento contándote como está diseñada una solución o cuáles son sus principales procesos, actores y demás. En contraste, tendremos herramientas de documentación HTML ó HAML usadas con inteligencia en todo nuestro código. Los equipos de trabajo exploran las mejores maneras de solucionar problemas y aprenden entre sí, sin que la documentación se interponga en lo más mínimo y sin que les encasille en un guión a partir del cual deben desarrollar. Algunas de estas herramientas son Rdoc, Yard ó apipie-rails.
Para ser verdaderamente ágil es necesario tener al cliente abordo todo el tiempo. Su aporte y colaboración brindará soluciones más rápidas y confianza en todo el equipo. El cliente al sentirse parte, puede ver como efectivamente su proyecto avanza y es entregado en tiempo. La vínculo que se desarrolla entre cliente-equipo es invaluable.
Rails favorece el principio de “No te repitas” (DRY Don´t Repeat Yourself) con el objetivo de que los cambios que inevitablemente surgen, tengan el mínimo impacto en el código.

Conventions over Configuration 

 Las convenciones o (conventions en ingles), son una serie de reglas preconcebidas que permiten entrelazar los componentes de la aplicación con el menor esfuerzo. Veamos un ejemplo:
resources :microposts
La línea anterior pertenece al fichero config/routes.rb de una aplicación (donde se preparan las Rutas y URLs) y se encarga por si sola de preparar nuestras URLs para modelar a los “Micropost” como un recurso que puede realizar todas las operaciones CRUD (Create, Read, Update and Delete), esto es lo que llamamos REST (REpresentational State Transfer), que a su vez usa los métodos HTTP (GET, POST, PUT, DELETE) de una manera mucho más eficiente.
De manera que solamente la línea anterior, nos prepara las siguientes URLs: Asumo que el lector está familiarizado con el patrón MVC y conoce los términos Modelo, Controlador, Action method, Vista, Ruta, etc. Las rutas tiene una convención principal: {Controlador}/{action}/{id}, a partir de la cual sabemos que controlador y que action-method atenderá cada petición.
Bien, en todo esto ¿Cuál es la convención a seguir? – La respuesta es: Todo!
Con la línea de código anterior tenemos ya listas las URLs para interactuar con nuestros microposts, todas las URLs van dirigidas al controlador: MicropostsController que a su vez debe tener listos los action-methods para atender las peticiones. Para las peticiones GET que pueden devolver un resultado HTML, el action-method correspondiente buscará las plantillas HTML en la carpeta:
views/microposts/_{action-method}.html.erb 
De manera que la petición GET:  http://nuestraapp.com/microposts/new
Será respondida por el controlador MicropostsController, el action-method "new", que a su vez renderizará automáticamente la plantilla:
views/microposts/_new.html.erb
Quizás parece muy difícil de digerir, pero no lo es. Se trata de convenciones que hay que estudiar una a una, pero que poco a poco todo va pareciendo muy natural y veremos cómo, en el ejemplo anterior, una sola línea de código puede adelantarnos el trabajo de un medio día en cualquier otro framework… ups, vale vale, no tanto, pero si un par de horas.
En vez de usar configuraciones Rails se apoya en las convenciones de nombres y estructuras comunes siguiendo el principio de “Menos sorpresas” (POLS Principle of least surprise) donde los elementos se comportan de la forma esperada y son muy fáciles de leer y entender.

Comunidad en ascenso

La comunidad de “Railers” está en aumento. La mayoría de los programadores que migran hacia este framework ya conocen al menos un lenguaje de programación y han tenido necesidad de disminuir sus tiempos de entrega. La curva de aprendizaje del Ruby es mucho más corta si ya se conoce algún lenguaje y el paradigma de la programación Orientada a Objetos, pero es importante decir que Ruby puede ser muy frustrante para principiantes. Entre las comunidades recomendadas está: “Ruby on Rails talk” en Google Groups .
Cada cuál debe escoger su manera más rápida de empezar, dependiendo del nivel que tenga y del lenguaje/ framework que provenga. En mi caso, lo primero que hice fue tutorial Rails for Zombies y un vistazo por los screencasts Zombies OutLaws.
En este punto ya tenía una noción de cómo lucía Ruby y que elementos había dentro de Rails. Así que me monté en lo que un lector describió como el Formula 1 del aprendizaje de Ruby on Rails: el Ruby on Rails Tutorial. Este tutorial es un viaje rápido por todo el framework, vas desarrollando una aplicación real paso a paso y el resultado final es que el framework empieza a verse muy familiar. Terminé con ganas de hacerlo de nuevo.
El próximo paso fue Ruby, es curioso que Ruby haya sido el tercer paso de mi aprendizaje siendo el lenguaje sobre el cual está construido el framewok, pero realmente no es necesario para pasar el Tutorial ni para empezar con los screencast. Como iba en serio con migrar a Rails busqué el libro: Programming Ruby 1.9 and 2.0 y descubrí la magia de Ruby, realmente no encuentro otra palabra para describirlo.
Y finalmente quise ir más sobre terreno seguro así que tomé el libro: Beginning Rails 2.

Conclusiones

Como pueden ver este artículo no pretende denigrar al framework .NET, mi compañero durante muchos años. Tengo mucho respeto por Microsoft y por su comunidad. Solo quise contarles mi experiencia personal.
Es muy excitante aprender un framework nuevo y de vez en cuando sientes que perteneces a esa comunidad y decides quedarte. Nos ha pasado a todos. A mí me sucedió con Ruby on Rails.