¿Cuáles son los beneficios de Ruby on Rails? Después de dos décadas de programación, uso Rails

A veces oigo a gente quejarse de sus clientes, diciendo que insisten en usar Rails, que han tomado demasiado Kool Aid. Si son reclutadores, casi se sienten mal del estómago por tener que encontrar otro desarrollador ‘primadona’ de Ruby on Rails. Entonces sacan algo similar a esta comparación increíblemente ignorante entre Git y PHP para demostrar su punto. «No saben ni lo que piden», dicen.

Para nosotros, como programadores, a veces sí parece que nuestros clientes no tienen ni idea. Nos encanta exagerar casos como este. Cuando lo piensas un poco, no parece correcto pensar que una persona que me está dando dinero para construir cosas está de alguna manera limitada y ‘simplemente no lo entiende’. De hecho, creo que la mayoría de los clientes conocen perfectamente sus opciones y aún así se deciden por Rails.

Intentaré explicar lo que, en mi opinión, hace que Rails sea lo suficientemente beneficioso como para ser considerado seriamente para una plétora de proyectos y necesidades.

Beneficios de Ruby

Es posible que nadie conozca los beneficios de Ruby si no fuera por el propio Rails. A algunas personas les gusta menospreciar a Ruby diciendo que es «tan fácil para Ruby» con su «caballero de brillante armadura llamado Rails» y que sin Rails, «Ruby sería irrelevante». No puedo asegurar si eso es cierto o no, pero sí sé que sería una gran pena que el mundo se perdiera un lenguaje tan magnífico. El hecho es que el autor de Rails eligió Ruby deliberadamente, y su apuesta «salvaje» se saldó con un enorme interés. Lo que él vio entonces, muchos otros pueden verlo hoy. Ruby permite a los programadores de una manera especial que es muy difícil de explicar a las «masas». Entonces, ¿por qué usar Ruby on Rails? Ruby hace felices a los programadores, tal y como se anuncia.

Aunque la mayoría de los desarrolladores están de acuerdo en que Ruby es práctico, algunos lo ven como algo excesivo. Se preocupan por lo que podría pasar con todas las libertades que permite Ruby, todo el potencial de mal uso. Permítanme ilustrar con un poco de parcheo de mono:

"1".to_i #=> 1class String def to_i raise 'foobar' endend"1".to_i #=> RuntimeError: foobar

Es así de fácil: con sólo cinco líneas de código, hemos tomado una clase existente y anulado su comportamiento. Nada es sagrado, ni siquiera un String. Este error en particular sería fácil de detectar, pero las cosas pueden ser mucho más siniestras:

class String def to_i self.to_f - 1.13 endend"2".to_i #=> 0.8700000000000001

Así de fácil, hemos introducido un error en la clase String que podría ser envuelto y ocultado por una capa tras otra de complejidad.

Así que, podrías estar pensando: ¿Puede todo el mundo y su madre estropear mi preciosa aplicación? Aunque este comportamiento parece realmente aterrador, en realidad no lo es. En cinco años de uso de Ruby, he tenido exactamente cero problemas con este comportamiento. Puede parecer contrario a la intuición, pero también lo es conducir coches a 60 MPH en direcciones opuestas separados sólo por una fina línea blanca en medio de la carretera. En la práctica, ambos funcionan notablemente bien.

Otra ventaja es que Ruby es una herramienta versátil. Como tal, tiene bordes afilados como un cuchillo. Me gusta pensar que los adultos pueden manejar los cuchillos muy bien – la protección de los niños es para, bueno, los niños (Tweet). Y ser tratado como un niño en la informática te convierte en víctima de la paradoja del Blub de Paul Graham: crees que estás mejor sin ciertas características que no entiendes o que alguien te ha dicho que son demasiado peligrosas. Por supuesto, hoy nos preguntamos «por qué usar Ruby on Rails»; por tanto, este es un debate para otra ocasión. Hay que reconocer que Ruby echa de menos algunas características que tienen otros lenguajes (Lisp hmm, hmm). En general, Ruby está cerca de la cima del «continuo de poder del lenguaje».

Mis primeros años con Ruby fueron humildes. Aprendí mucho simplemente leyendo el código de otros. A veces, me asombraba; a veces, me enfadaba; pero finalmente, este conocimiento me permitió comunicarme con mi ordenador de forma mucho más efectiva que antes. Casi siento pena por otros lenguajes «burocráticos» que te hacen pasar por el aro sólo por pasar por él, mientras te dicen «¡sólo estoy haciendo lo mejor para ti, es por tu propio bien!»

Pragmatismo

Hay un profundo respeto por el pragmatismo tejido en el ADN de Rails al nivel más bajo posible. En combinación con las ventajas de Ruby, este pragmatismo produce soluciones elegantes y anima/inspira a la comunidad de desarrolladores de Ruby on Rails a hacer lo mismo. El pragmatismo se anuncia a menudo como una tienda de Rails, así que esta afirmación no es nueva, pero me recordaron su veracidad hace poco cuando un amigo mío intentó mostrarme lo «genial» que es Hibernate. Estaba luchando. Pude sentir su dolor mientras era incapaz de establecer una miríada de opciones y parámetros de configuración que deberían haber sido predeterminados por el marco en primer lugar.

Con la edad, mis estándares de complejidad artificial han crecido más y más. Teniendo en cuenta que empecé a escribir código de producción en 1989 a la edad de 11 años (comenzando con un proyecto para mi vecino de al lado en Clipper Summer ’87), tengo casi cero tolerancia a las complicaciones innecesarias. Y Rails tiene una puntuación muy alta en ese departamento. Es algo más que «la convención por encima de la configuración»; me refiero a toda la mentalidad pragmática que se valora mucho dentro de la comunidad Rails y que se extiende por ella.

Expresividad

Rails es lo más parecido al inglés (a no ser que uses COBOL). Utiliza lo que se conoce como un DSL interno, extendiendo Ruby con su propia semántica. Construir un DSL es siempre peligroso, ya que estás desarrollando un nuevo lenguaje. Al ser interno, no es necesario usar un analizador externo, pero en cierto sentido se siente como un nuevo lenguaje. El equipo de Rails ha conseguido un buen equilibrio con su DSL, utilizándolo cuando tiene sentido y sólo en raras ocasiones exagerando, demostrando un excelente autocontrol. Creo que cualquier programador, independientemente de su experiencia con Rails, (e incluso algunos no programadores) podría entender esto:

De hecho, si no estás familiarizado con Ruby, esto podría parecer extraño, es casi como si no fuera un lenguaje de programación. Una vez que te das cuenta de que sólo son llamadas a métodos sin paréntesis, ya estás listo. Aun así, el DSL de Rails parece un lenguaje especial para describir requisitos cuando en realidad es sólo una nomenclatura inteligente y un uso inherente de la excelente sintaxis de Ruby.

Comunidad

Rails tiene un ejército de committers que se aseguran de que se mantenga en perfectas condiciones. Muchos proyectos se van apagando con el paso del tiempo, pero en Rails todavía saltan chispas cuando hay que tomar decisiones. Da la sensación de que los mantenedores (todavía) se preocupan de verdad y quieren que la gente use Ruby on Rails y entienda sus beneficios.

Debajo de Rails, como guinda, está Ruby con su formidable gestor de paquetes, RubyGems, comparable a CPAN en términos de número de paquetes, y teniendo en cuenta la edad de CPAN, esa afirmación es (por decirlo suavemente) muy impresionante. Rails tuvo un breve descarrilamiento cuando intentó crear sus propios «plugins Rails». Afortunadamente, esto no se mantuvo, por lo que RubyGems sigue siendo la fuente unificada y magnífica de código programado por individuos muy brillantes.

La sinergia entre un lenguaje genial, un marco de trabajo web pragmático y una comunidad magnífica da a Rails un resultado mucho mejor que la suma de sus partes.

Madurez

Rails ha dado la vuelta a la manzana. En un sentido hipster, ya ni siquiera es tan cool. Esto es algo bueno cuando se trata de elegir una pila tecnológica: quieres algo probado. Y Rails es precisamente eso. Hace poco escribimos un artículo hablando de la gran variedad de intérpretes y tiempos de ejecución de Ruby que hay ahora.

Mercadeo

Lo sé, lo sé. Como profesional de la informática, debería valorar las cosas «serias» e ignorar el «brillo». Puede parecer superficial, pero afrontémoslo:

1. Comparado con la competencia, el sitio de Rails se ve bien.
2. El primer screen cast de Rails, en su día, era simplemente impresionante. Puede que hoy no parezca tan impresionante, pero recordemos que la única razón por la que todos conocemos Java es porque todo el mundo estaba entusiasmado con la posibilidad de ejecutar un Applet de Java en el navegador. Esto resultó no ser tan importante después de todo, pero aun así, esto puso a Java en el radar. Del mismo modo, este screencast de 15 minutos sobre el motor del blog fue un gran éxito que entusiasmó a mucha gente.
3. Ni siquiera se trata de vanidad; se trata de involucrar a tanta gente inteligente como se pueda para llevar agua al molino. Cuando se consideran los frameworks, el mejor lugar para estar es entre la multitud. Elegir un marco en el que se centran estas personas inteligentes simplemente significa que mucho más terreno ya está cubierto para ti. Y esto me lleva a mi siguiente punto.
   

   (No) Reinventar la rueda

   Tengo una debilidad por los frameworks pequeños. Me gusta cuando puedo entender lo que hace un framework en particular y por qué. En este sentido, Rails es algo hinchado, e incluso abrumador a veces.

   El dilema aquí: ¿cuántas veces quieres escribir lo mismo una y otra vez? Algunas de ellas pueden reescribirse mejor, estoy seguro, pero lleva tiempo, mucho tiempo. Cuanto más permitas que Rails haga por ti, menos tendrás que preocuparte de reescribir o reimplementar tu funcionalidad.

   Rails es (como ellos dicen) ‘pilas incluidas’. Esto no es bueno si te gusta la escasez o si sientes la necesidad de tener un amplio conocimiento de cómo funciona todo. En la práctica, si te desprendes de tus miedos, parece que funciona. Rails tiene unos valores predeterminados razonables para casi todo lo que necesitas y es lo suficientemente modular como para no acorralarte en un aprieto.

   Conclusión

   Pregúntate de nuevo, ¿por qué usar Ruby on Rails? Rails es adecuado tanto para sitios web públicos de última generación que compiten con aplicaciones de una sola página en JavaScript, como para aplicaciones complejas de sistemas centrales empresariales que suelen tener un aspecto un poco más «feo» (con una interfaz de usuario más genérica y de menor fidelidad), pero que compensan este defecto con una tonelada de reglas y lógica de negocio complicadas. Su ventaja es que es versátil y capaz de competir tanto con los más elegantes como con los más poderosos.

   Para la mayoría de los problemas comunes, Rails tiene un componente a tu disposición casi nada más sacarlo de la caja con una documentación que está siempre por encima de la media (de alguna manera, el equipo del núcleo de Rails convenció a los colaboradores de que escribir documentación es genial (aunque todos sabemos que no lo es), lo que lleva a documentos bien escritos, concisos y que ahorran tiempo).

   Cuando dejas de lado los unicornios y los abrazos de los viernes, terminas con un poderoso framework que puedes utilizar tanto para tu futuro cambio de juego como para tu próximo sitio de negocios medio. Y con tu grupo de gemas de primera línea, tienes a tu alcance un arsenal que implementa algunas de las ideas más brillantes de la programación informática. Sin ningún problema.

   Relacionado: Timestamp Truncation: Un cuento de Ruby on Rails ActiveRecord