La Cara Oscura
del Desarrollo de Software

Esto viene de Ni Ruby ni Rails son para todos ni para todo - 1ra parte y atajando al loco del Sebastián que no se tomó su medicación y brincó con Rubíes, perlas y granos de café donde concluyó lapidario (y seguramente muerto de la risa) con "Ruby rulez!!! Rails rulez!!! Java sux!!! Perl sux!!! Python sux!!! (y Php no es digno de mención)" (cita textual ;-)

La verdad es que yo me he preguntado varias veces ¿Por qué tanto alboroto por Ruby y Rails? ¿Cómo es que a estas alturas del partido surge un lenguaje/framework nuevo que logre abrirse paso entre los pesos pesados del desarrollo de aplicaciones (particularmente en la categoría web) y captar tanta atención?

Así que les cuento como llegamos a Rails y a Ruby, que fue por un camino un poco particular, porque estábamos evaluando combinaciones de lenguajes de programación y frameworks (bajo licenciamiento libre/abierto) que soportaran nuestro proceso de desarollo que sistemáticamente había producido aplicaciones robustas, escalables y mantenibles para ambientes J2EE.

Una de las cosas importantes a considerar era la gente, parte de nuestras oficinas son un típico manicomio de desarroladores de software donde la gente brinca de un computador a otro practicando algo parecido al peer-programming, las actividades se paralizan si hay un buen partido del fútbol, las pizarras blancas están llenas de diagramas en pseudo-UML y los horarios son una cosa que le pasa a otra gente pero no a los programadores.

Así que la alternativa a Java/J2EE/etc que se escogiera tenía que ser algo interesante y divertido para trabajar, al mismo tiempo que se siguieran produciendo aplicaciones de calidad enterprise, por llamarlas de alguna manera.

Bueno, sobre las experiencias intermedias no voy a hablar, pero consistentemente se nos atravesaba en el camino Ruby On Rails, desde el famoso video y los controvertidos números de productividad se discutieron en The Server Side el tema no dejaba de aparecer en blogs y artículos técnicos del área. Algo así como las móscas en una zona agrícola.

En un chat le propusimos a Sebastian hacer drop del código de BagOfBlogs de PHP y arrancar "from scratch" con Ruby On Rails. Para ese momento él ya se había convertido y votó +1 ya que en lo que a él se refería no quería trabajar con otro lenguaje de programación que no fuera Ruby.

¿Sebas dropping Perl y CPAN? ¡Vaya! Eso es algo así como San Pedro convirtiéndose al Budismo, y fue el empujoncito que nos hacía falta para probar Ruby On Rails, proyecto al que siempre habíamos visto en forma despectiva, ustedes saben "Pana, eso no tiene ni máquina virtual es ¡Sálvese quien pueda! interpretado".

Así que empezamos a leer en línea el "Programming Ruby: The Pragmatic Programmer's Guide", "Agile Web Development with Rails: A Pragmatic Guide" y el texto más demencial del programación que haya leído alguna vez: "Why’s (Poignant) Guide to Ruby".

En este último "libro" (por llamarlo de alguna forma), es cuando uno ve la luz con un "Whack in the side of the head" que me permito citar textualmente:

Read the following aloud to yourself.

¡¡¡¿¿¿QUEEEEEEE???!!! Eso definitivamente convierte el calificativo de "expresivo" (en relación a un lenguaje de programación) en algo que está más allá de una cuña de detergente, pero lo mejor es que siendo Ruby altamente expresivo después uno se da cuenta de que el código se mantiene inteligible (del latín intelligibilis) salvándonos del Lado Oscuro de la Sintaxis, y de la Pesadilla del Mantenimiento en la Aplicación del Perlfierno.

En ese momento fue donde pensé "me gusta", y el "pequeño programador" que llevo adentro y que estaba sepultado bajo llamadas telefónicas, correos y presentaciones se despertó y empujó a un lado la tapa del ataud.

Mientras tanto, otras personas hacian el tutorial de Ruby on Rails y me llamó mucho la atención que programadores altamente productivos y fóbicos a la lectura de tutoriales estuvieran clavados en los PDFs y menearan la cabeza de vez en cuando diciendo "Que arrecho, que arrecho, ...".

Y cuando al cabo de poco tiempo estos mismos programadores empezaron a producir aplicaciones web, y a hackearlas para resolver problemas que son comunes en nuestros desarrollos, brincándose el tutorial sin tener mucha idea de lo que estaban haciendo pues ni un barniz de Ruby se habían dado, no pude menos que conceder que Rails es un framework productivo.

Durante la mesa redonda en la RubyConf 2005 le preguntaron a Matz (Yukihiro Matsumoto, creador de Ruby) cuál era el motivo del incremento en la popularidad de Ruby a lo que él contestó, en primera instancia, en tono de broma y fuerte acento japonés: "¿Dails?".

Y lo cierto es que Rails es muy bueno, y tanto que en cada uno de los principales lenguajes de programación comúnmente usado para la web hay al menos un clon de este framework. Lo que además demuestra que en Rails no se está haciendo nada que no se pueda implementar en Java, Perl, PHP o Phyton por decir algo.

Pero, por otra parte una vez que uno se mete en el código no puede dejar de apreciar la forma en que Ruby se siente como un guante. No necesito un IDE que me genere los pares de métodos getters/setters, uso:

Y ya tengo los métodos que me permite hacer la asignación y la consulta, nada que ver con el idioma get/set, si ya vieron el operador de asignación por ahí les adelanto que todo en Ruby es un Objeto incluyendo las Clases, que no se corresponden con el concepto de tipo como lo manejamos en Java.

Ruby está lleno de buenas ideas, propias y tomadas de otros lenguajes (de Lisp en este caso), como los bloques que no son más naturales porque no es posible:

¿Quién es responsable de abrir y cerrar el archivo? La clase File, sencillo y natural. La lógica del proceso que se quiere hacer con el archivo, en este caso imprimir cada línea prefijada con un ">" está en el bloque asociado al método open.

Rails y Ruby tienen una sinergia que hace muy "sabroso" trabajar con ellos, cuando se viene del mundo Java/J2EE es como si a uno le quitaran la camisa de fuerza, esto sí es orientación a objetos, no el guarapito aquel.

Sin embargo, ni Ruby ni Rails son para todos ni para todo, y eso lo justificaré en la que será 3ra parte de esta novela por entregas.