So if execution time isn’t important, why Ruby then? Why not use Java, C or Erlang? I think there are two main reasons. The first is Ruby’s ability to easily access and transform data and Ruby’s ability to integrate with almost anything.

En el trabajo llevo varias semanas trabajando en una herramienta que ayuda al departamento comercial, se trata de una serie de proramas situados entre facturación y ventas que les ayuda a analizar costes y realizar una oferta comercial lo más ajustada. Para ello los distintos programas trabajan con varias decenas de listas de coste, cada uno con miles de precios, para intentar unificarlas y generar una lista de venta que tiene unas centenas de precios.

Siento ser tan vago en detalles, pero diré que se manipulan listas de códigos telefónicos, destinos y precios/costes. Para ello se necesitan transformar muchas filas almacenadas en bases de datos mediante árboles y algunos otros algoritmos más o menos complejos. Todo ello empecé a programarlo en Ruby, que es un lenguaje que permite un prototipado muy rápido, llevandome una grata sorpresa ya que los cálculos se hacían en segundos.

Al ver que los tiempoes eran muy manejables, cree una aplicación Rails, metí las librerías en lib/ y doté de un frontend vía web a la aplicación. Por ahora ha seguido creciendo, y en total el proceso que realizan mensualmente lleva unos 10 minutos. En un principio había pensado reescribir la aplicación, o las librerías, en C# para ganar velocidad, pero ¿realmente merece la pena el esfuerzo? Como mucho, podría ganar 10 minutos cada mes, suponiendo que el proceso pasara a ser instantáneo al reescribirse en un lenguaje compilado.

Más de una vez todos nosotros nos habremos encontrado con la situación de que se necesite alguna herramienta interna, y puesto que los requisitos de ese tipo de aplicaciones suele ser muy diferente, en la mayoría de ocasiones nos vale tener una aplicación con calidad de prototipo que podamos desarrollar rápidamente utilizando un lenguaje/plataforma que quizás no sea la ideal, pero es lo suficientemente rápido y nos permite agilizar la creación de nuestro pequeño monstruo.

Supongo que da para otro post hablar de esos pequeños monstruitos que van creciendo y acaban convirtiendose en algo que no es lo que estaba pensado ¡cuánto echaremos de menos no haberlo planteado y desarrollado de otra forma en esos momentos!

Es más, creo que gran parte de esa invisibilidad del problema puede deberse a la existencia de UTF-8. Uno de las características de UTF-8 es su compatibilidad hacía atrás con ASCII extendido, y he ahí la fuente de gran parte de los problemas, ya que mucha gente cree no tener un problema haciendo pruebas, hasta que de repetne aparecen unos acentos, eñes, ß, umlauts o signos arábicos y todo deja de funcionar tan bien.

¿Y qué tiene de malo utilizar UTF-8? Intentaré explicarlo con un ejemplo. Supongamos que el nuevo presidente del mundo, Barack Obama decide reformar la constitución norteamericana y le envía el fichero que contiene tan sacro texto a 2 grupos de trabajo para que hagan sus modificaciones, y pasado el periodo de trabajo el señor Obama recibe los 2 ficheros de vuelta, y puesto que ha decidido hacer una apuesta fuerte por la tecnología decide que lo mejor es usar una herramienta automática para hacer merge. Obama decide revisar el nuevo borrador de la Constitución y ¡horror! hay partes que se han convertido en signos indescifrables ¿es que esos expertos no saben hacer su trabajo o qué?

Posiblemente el problema haya venido a la unión de 2 factores: la compatibilidad de ASCII con ISO-8859-1 y la compatibilidad de ASCII con UTF-8. La antigüedad de la constitución americana nos garantiza que no estaba escrita ni en ISO ni en UTF-8, lo que nos deja nada más que pensar que estaba redactada en un .txt en ASCII :-). Ese fichero ASCII se pasó a los 2 grupos de trabajo, cada uno decidió utilizar un método distinto. El primer grupo publicó el fichero de la Constitución en la portada de Slashdot para que todos los comentaristas aportaran sus modificaciones. Puesto que /. utiliza ISO-8859-1 como encoding, al pegarle todos los bytes de la constitución se sigue leyendo perfectamente. El segundo grupo decidió editar el texto en una Ubuntu usando vim, como mandan los cánones. Puesto que Ubuntu por defecto viene configurado en UTF-8 y que hay una compatibilidad, vim leyó correctamente el fichero como UTF-8 ya que la ristra de bytes es la misma.

¿Y eso que tuvo de malo? Puesto que Obama apostó por la participación de las minorías se han introducido palabras españolas, de hecho el documento que venía de Slashdot contenía la palabra América (con tilde) y en el segundo documento incluyeron la expresión "¡viva el presidente!" (abriendo exclamación). El documento resultado final puede ser ASCII, ISO o UTF-8, pero de cualquiera de las 3 formas se verían mal el la é o la ¡ (las 2 en caso de ASCII).

Moraleja

¿Cuál es la moraleja de todo esto? Que cuando estamos trabajando con textos en ISO-8859-1 y UTF-8 la compatibilidad de UTF-8 nos puede hacer creer que todo está funcionando bien sin tener que recodificar las cadenas, siempre y cuando estemos utilizando caracteres ASCII (escribiendo en ingés, no acentuando y todas esas cosas). ¿Qué ocurriría si no existiera UTF-8? Si por ejemplo las cadenas estuvieran codificadas todas en UTF-16, en nuestras pruebas sin recodificación ni un mísero "Hello world" funcionaría correctamente.

Admito que es probable que sin la compatibilidad de UTF-8 quizás la adopción de Unicode sería mucho más lento, pero también seríamos mucho más conscientes de los problemas, ya que detectariamos los problemas con las primeras pruebas, y veriamos que "simplemente no funciona", que posiblemente sea mejor que un "parece que funciona" como primer paso para resolver un problema.

Y toda esa parrafada es la explicación a porqué creo que UTF-8 tiene gran parte de culpa de que aún hoy en día haya tantos problemas trabajando con codificaciones y existan tantos problemas que desconozcan totalmente el problema.