A raíz de mi post anterior y algunos comentarios expresados en él acerca de la complejidad para tener una aplicación de Ruby On Rails funcionando con MongoDB, he decidido escribir este post, el cual lo voy a tratar desde la vista de un ex(o casi)-desarrollador de .NET y aunque quizás algunos de mis comentarios parezcan un ataque a un .NET, no es esa mi intención, así que por favor tomenlos relajados. Ni tampoco es mi intención decir cual es mejor o cual es peor, ese es un ejercicio que cada quien forma personal debe de realizar
Comencé a desarrollar en .NET desde las versiones beta del mismo, ya hace mas de 10 años, e inclusive desarrolle para Web desde antes, ya sea con código escrito en C a modo de cgi-bin o Perl, al igual me toco desarrollar para Web en Visual Basic 4 - 6. En esos tiempos era realmente algo complejo hacer paginas dinámicas y era muy sencillo tomar decisiones incorrectas y hacer que el desarrollo se complicara enormemente.
Con la llegada de .NET Microsoft proponía otro paradigma un tanto diferente de como desarrollar a Web, proponía hacerlo tal y como se escribían aplicaciones de escritorio, solo haciendo "drag and drop", "right click", configurar aqui y alla y listo, tener aplicaciones sin - o casi sin - escribir una linea de código, digo cuantas veces no hemos visto a empleados de Microsoft haciendo este tipo de demos en eventos de la empresa.
Desde mi punto de vista - si desde mi punto de vista y experiencia - esto funcionada super bien para aplicaciones muy simples y predecibles, mi problema siempre venia cuando se quería hacer "algo mas" con la aplicación, la complejidad de desarrollo iba en aumento y en ocasiones se convertía en algo nada trivial. Durante ese tiempo también me toco hacer desarrollo con Java, varios frameworks para Web y Tomcat, y la experiencia no fue mejor.
Llego un punto en el cual casi casi decidí dejar de escribir aplicaciones para Web y únicamente escribir aplicaciones para escritorio, pero los clientes seguían solicitando aplicaciones Web, así que busque alternativas en .NET - PHP realmente nunca me gusto ni me gusta, quizás no tengo argumentos técnicos para decir porque, simplemente no me gusta -.
La alternativa que encontre fue MonoRail, comencé a ver los ejemplos y a entender sus dependencias, MonoRail es un framework para ASP.NET que trabaja con los patrones de MVC y ActiveRecord, inspirado por Action Pack. Al investigar que es Action Pack, descubrí Ruby On Rails, pero en ese momento le encontre un problema, tenia que aprender otro lenguaje de programación y tenia algunas semanas para entregar una aplicación Web para un cliente.
Así que me decidi por MonoRail, pero había algunos "detalles", tenia muchas dependencias, no tenia "Wizards" ni componentes o controles como se les llama en ASP.NET WebForms, en lo personal no lo vi como problema ya que en lo personal es raro que use los "Wizards" o que utilice controles de 3ros, así que para mi no había perdida ahí, aunque si me ha tocado conocer y dar cursos a desarrolladores de .NET que si no tiene un "Wizard" o no pueden poner su "Grid" súper "fancy" no son capaces de desarrollar una aplicación.
Por otro lado, si bien la configuración de un ambiente de trabajo con MonoRail requeria de un poco de trabajo y entendimiento por arriba de "Drag and Drop" y "Right click", no me pareció gran cosa y mas cuando es algo que solo haces una sola vez. MonoRail me permitió entregar varias aplicaciones de manera muy rápida, quede impresionado y eso me llevo a investigar sobre Ruby On Rails. Por cierto hace algunos días anunciaron, parte de "Roadmap" de MonoRail.
El motivo por el cual MonoRail me permitió entregar aplicaciones muy rápido fue porque no tuve que tomar decisiones, MonoRail lo hizo por mi, por ejemplo no tuve que decidir como organizar mi aplicación, no tuve que decidir como conectarme a la base de datos, todo lo decidió MonoRail, así solo tuve que enfocarme en la funcionalidad que era importante para mis clientes y ya. MonoRail al igual que Ruby on Rails es opinioted software.
Al llegar a Ruby on Rails, obviamente la primera barrera fue el lenguaje Ruby, pero es muy facil acostumbrarse a el, aunque todavia escribo código a la C#, pero creo que voy mejorando.
Para la gente acostumbrada a los IDEs hay una gran variedad de opciones a elegir, en lo personal no soy fan de las IDEs, prefiero ambientes mas ligeros y que me hagan usar la consola de comandos, por lo tanto en Windows se puede seguir esta guia y en Linux estas dos guias, puede parecer complicado, pero es algo que solo se tiene que hacer una vez, si se usa un IDE en cuestión de minutos se tiene un ambiente complete y configurado.
Es muy sencillo crear una nueva aplicación con Ruby On Rails (RoR) haciendo uso de las decisiones que el framework hace por nosotros, por ejemplo:
$ rails new mi_super_app
$ cd mi_super_app
$ rails generate scaffold client name:string, address:string
$ rails server
Dirigimos nuestro navegador a http://localhost:3000/clients y listo ya podemos comenzar a dar de alta y modificar clientes, simple, fácil y rápido.
Si bien esto funcionara tal y como esta en un gran numero de casos, la gente en RoR pensamos en la regla 80/20, hay momentos en que se tiene que hacer algo un poco diferente para configurar nuestra aplicación, donde podemos cambiar las decisiones que RoR hace por nosotros y adaptarlas al 100% de nuestras necesidades, como las modificaciones propuestas en mi post para usar MongoDB en lugar de una base de datos relacional.
Si bien la intención de mi post es servir como una guia o receta, paso a paso de como hacerlo, también podemos hacerlo sencillo con el uso de Templates - así como existen también templates en Visual Studio para crear aplicaciones con ciertas características y defaults -, en e siguiente video de Railscasts se explica el concepto. De hecho existe ya un template para pre-configurar una aplicación de RoR para usar MongoDB y Rspec, con el cual se puede omitir mi post y solo ejecutar:
$ rails new mi_super_app -JOT -m ~/path_a/mongodb_template/templater.rb
Ya viendolo así, ¿ya no se ve que sean muchos pasos no?
Sobre el tema de las dependencias, al igual que en cualquier otro framework o lenguaje podemos tener dependencias a librerías de terceros o podemos elegir no hacerlo. En el caso de Ruby y sus diferentes frameworks, hay librerías para casi todo lo que nos podamos imaginar, RubyGems es un buen lugar para descubrirlas y Bundler nos permite manejar esas dependencias de forma sencilla y a nivel aplicaciones, es decir podemos tener la misma dependencia pero hacia diferentes versiones de la librería sin conflictos, no hay "DLL Hell".
Para determinar como elegir que dependencias tener en nuestra aplicación, va en relación directa de nuestras necesidades, pero creo que puedo sumarizar algunos criterios:
- Librerías que fueron extraídas del framework de RoR
- Librerías mantenidas por miembros del equipo de desarrollo de RoR
- Librerías que son tan viejas como el mismo framework de RoR y que evolucionan paralelamente
- Librerías mantenidas por empresas de desarrollo en RoR
- Librerías populares y que tengan pruebas
Con respecto al soporte de los librerías disponibles en Ruby, este varia, pero el común denominador es que son OSS y el código de casi todas esta disponible en Github. En experiencia personal no he tenido problemas con esto, ya que a través de los grupos, IRC, reportando bugs o correo directo he tenido solución cuando se me ha presentado algún problema, inclusive, he enviado parches que han sido aceptados y generalmente la corrección a mi problema puede llevar algunas horas en lugar de tener que esperar días si fuese un bug en una librería comercial.
De las librerías que he utilizado realmente no me ha tocado alguna que pierda el soporte, cuando el desarrollador principal se retira generalmente sale alguien a continuar trabajando en ella, lo que si me ha tocado experimentar es el reemplazo de librerías por otras mejores, por ejemplo, cuando entre a RoR restful_authentication era "la librería" para el manejo y autentificacion de usuarios, posteriormente authlogic la reemplazo y actualmente devise es la librería popular, no es que las otras tengan algo malo o funcionen mejor o peor, es solo la manera en como evolucionan las cosas.
Creo que personalmente lo que encontre en RoR es que no me tengo que pelear contra el framework para poder entregarle aplicaciones a mis clientes, todo lo contrario, me puedo olvidar un poco del framework y dedicarme a implementar la funcionalidad que le da valor a mi trabajo.
Y afortunadamente puedo decir que aquí en Tijuana no he sido el único que ha encontrado este valor, ya que desde que comencé a platicar sobre RoR varios amigos implementaron soluciones para sus empresas y clientes de estas que están en linea y en tiempo record, y traen todavía mas proyectos nuevos que están siendo desarrollados en RoR, de mi parte igualmente tengo un par de proyectos en RoR que pronto verán "la luz", proyectos para mis clientes. Al mismo tiempo se de empresas que están tomando cursos y evaluando RoR para el desarrollo de nuevas versiones de sus productos, todo esto solo en Tijuana.
Creo que después de esta explicación algunos estarán de acuerdo conmigo y otros no, a final de cuentas debemos de ser apasionados con el lenguaje/framework que elijamos para trabajar, porque para bien o para mal a estos le vamos a dedicar nuestro tiempo laboral; pero el ser apasionados también implica el ser críticos de lo que usamos y si es posible conocer y probar otras herramientas, aunque si trabajamos para una empresa "casada" con una compañía/tecnología va a ser un poco difícil cambiar su visión, ya que generalmente se usan x tecnología por cuestión política o de mercadotecnia o gusto personal de la persona que toma las decisiones.
Tentativamente el miércoles 1 de Diciembre sera la tercera reunión de Tijuana.rb, una vez mas será en la oficinas de Ingenia Creative, ubicadas en:
Al parecer un mes mas activo en cuanto a mis actividades en Ruby y Rails este mes de Noviembre.
Inclusive mejor aun, desde nuestro editor - en mi caso 
Así es, leyeron bien, el evento de iWeekend viene a Tijuana este próximo 26, 27 y 28 de Noviembre.
Pero Heroku no tiene soporte directo para bases de datos MongoDB, aunque si ofrece un addon para integrarse con 
Hasta aqui todo bien, mi detalle vino al revisar la documentación de Heroku de como configurar la conexión a MongoHQ, ya que se requiere de una variable ambiente MONGOHQ_URL donde se coloca una URL que MongoHQ proporciona para cada base de datos, la forma de agregar esta variable en nuestra aplicación de Heroku es la siguiente:
Ven y asiste a la primera reunion del grupo de usuario Ruby/Rails de Tijuana, tijuana.rb, este proximo miércoles 22 de Septiembre en el Starbucks Lucerna de la Zona Río, a partir de las 7pm. 
Este próximo sábado 28 de Agosto estaré participando en el evento en línea "
Ademas, los chicos del 
Así que si les interesa Ruby On Rails, no lo piensen y acompañenme en ambos o alguno de los eventos. Adicionalmente y de manera no-oficial, los invito a la Comunidad Tijuana.rb, comunidad sobre Ruby y Ruby On Rails de Tijuana, aunque aun no tenemos sitio web, ni reuniones, ya hay actividad en el 
Gracias a