Ruby 3 y el diseño por convenio

Ruby On Rails
Ruby On Rails es una de esas tecnologías que despiertan pasiones (a favor y en contra). Lo que le ha sucedido a Ruby es que como todos los nuevos paradigmas ha pasado por el ciclo enunciado por Nicholas Klein en 1914 y popularizado por Gandhi: primero te ignoran, luego se ríen de ti, a continuación te combaten, hasta que por fin ganas y te erigen un monumento. Solo que Ruby saltó entre los visionarios del “te ignoran” al “ganas” casi sin estados intermedios (los conservadores y excépticos aún lo siguen ignorando por completo).

En España hemos sido pioneros en Ruby, como en tantas otras cosas. En ASPgems, probablemente trabajen los que más saben del tema, y Juantomás, un visionario, fue de los primeros en evangelizar sobre las virtudes de RoR.

Agustín lanzó un software como servicio para PyMEs escrito en Ruby cuando todavía no se había ni siquiera inventado la palabra software como servicio, además fue quien persuadió al Ayuntamiento para abrir el centro Madrid On Rails. Y Juantomás anda ahora involucrado en Bazar una estructura distribuida para generar mercados de la Fundación Garum que a mi me recuerda mucho al recientemente creado marketplace de Redepyme, escribiré sobre las redes sociales de empresas más adelante, tema que seguro dará mucho de qué hablar, pero por ahora me gustaría seguir comentando acerca de Ruby.

En KnowGate, una empresa de perfil mucho más mainstream en lo referente a tecnología hemos empezado a experimentar con Ruby On Rails apenas el otoño pasado tras la aparición de la versión 3. Como casi todas las innovaciones en KnowGate, Ruby era defendido por los becarios. De hecho sólo he conocido a una persona en toda mi carrera, Roberto Canales Mora, quien me haya dicho que en su empresa Autentia la iniciativa de la innovación la llevan los seniors apoyándose en herramientas de compartición de conocimiento como Adictos al Trabajo. ¿Qué nos movió a empezar con Ruby? Si tuviera que reducirlo a un único factor diría que fue su diseño por convenio ¿En qué consiste esto? Resulta que cuando un puñado de sesudos ingenieros de software crean un nuevo lenguaje típicamente tratan de hacerlo lo más flexible y genérico posible. En el transcurso de dicho proceso de diseño el lenguaje gana una gran potencia pero al mismo tiempo se vuelve extraordinariamente complejo. La quintaesencia de dicho fenómeno es Java y el Java Community Process (JCP). Como hay que mantenerlo todo abierto y flexible, los APIs tienen tendencia volverse bastante abstractos y contraintuitivos, exponentes de estos APIs horrendos son por ejemplo JDBC y JavaMail. En Ruby, por contra, muchas funciones usadas casi siempre están empotradas dentro del lenguaje. Al principio encontrar integrado de forma natural el acceso a bases de datos relacionales no sorprende demasiado, a fin de cuentas ¡ya era hora de que alguien lo hiciese! Pero a reglón seguido te empiezas a percatar de que en RoR 3 otros problemas que habitualmente plagan a todos los desarrollos, como el cross site scripting por inyección de JavaScript (XSS), la gestión de ficheros adjuntos o los embellecedores de URLs están también resueltos en unas pocas líneas de código.

En el caso de KnowGate, sólo hemos usado Ruby para unas pocas cosas pequeñas, y dudo de que vayamos a cambiar de rumbo a corto o medio plazo, principalmente porque muchas de las cosas que ofrece ya las resolvimos a pedal hace años (cada maestrillo tiene su librillo). Pero me parece que Ruby es el sucesor natural de PHP. Ningún producto puede satisfacer todas las necesidades, ni Ruby, ni Java, ni PHP, ni ningún otro… pero se desarrolló muchísimo con gran éxito en PHP y no me sorprendería para nada que en el futuro próximo asistamos a una etapa igualmente floreciente para RoR.

Post relacionado: El zoo de nuevos lenguajes (Versión Cerø)
Artículo relacionado: Does Heroku really give Salesforce.com a developer market? (Savio Rodrigues)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Tecnologías Libres. Guarda el enlace permanente.