martes, julio 22, 2014

El Pirata Viajero


La suave brisa del mar se mezclaba armónicamente con el impetuoso son de un viejo cantico marinero. ¿Qué haremos con el marinero borracho? cantaban algunos bravos tripulantes del "Tiburón del Caribe". Afeitar su vientre con una hoja oxidada replicaban los demás. Aquella popular canción irlandesa unida a la esperanza de alcanzar inhóspitos lugares, les daba la fuerza necesaria para realizar los pesados quehaceres de aquél fabuloso barco.

Se trataba de un bergantín robado hace años a un descuidado capitán de la armada española. Tras lograr la captura del terrible pirata apodado "El Jamaicano", éste se aprovechó de las ansias de aventura de un joven marinero. No hicieron faltas amenazas para ser liberado, tan sólo una simple promesa de viajes y aventuras. El resto lo cuentan las crónicas. Aprovechando la oscuridad de aquella noche sin luna, la tripulación fue pasada a cuchillo y sustituida por otra en la isla Tortuga.

Ahí me encontraba yo, de pie en el puente de proa observando orgulloso a mis hombres trabajar. Sí, aquel jovenzuelo aventurero se había erigido tras la muerte del Jamaicano en el dueño del "Tiburón del Caribe". No fue fácil. Mi mentor me enseñó con disciplina y paternal dedicación los secretos para convertirme en lo que soy. Sí, yo Miguel "el Vasco" me había convertido en uno de los más temibles tiburones que surcaban el mar Caribe.

Los relatos de viejos marineros que volvían de las Américas me habían llevado siendo un imberbe adolescente al Puerto de Palos para embarcar en un majestuoso bergantín. Mis primeros días fueron duros. No conocía nada de la mar y mis compañeros de viaje no parecían deseosos de compartir sus conocimientos conmigo. Además, el continuo vaivén del barco y la escasez de comida no ayudaban demasiado.

Un día, tras cruzarnos con una isla pregunté, ¿Podríamos fondear aquí y conocer esa isla? ¡Muchacho! ¿tanto calor te ha quemado la sesera? Me respondieron. Así, se fueron sucediendo los fabulosos lugares que no íbamos a visitar y las burlas de mis compañeros. Quería aventura. Quería descubrir mundo. Quería sentirme libre en el vasto océano. Quería lo que los demás no querían.

Conforme aumentaba la monótona rutina del mar, también lo hacían los inquietantes relatos de piratas. El Mar Caribe se iba acercando y con él el coto de caza de los llamados Hermanos de la Costa. ¡No hacen prisioneros! Decía un veterano marinero. ¡Los protege el mismísimo Diablo! decía otro.

De pronto, en el mediodía de un día soleado apareció lo que todos esperaban pero nadie quería. Un pabellón tan negro como el carbón guiaba una jauría de lobos de mar ansiosos por capturar una nueva presa. La calavera y los dos huesos cruzados no dejaban lugar a dudas. ¡Eran Piratas! ¡Preparados para el combate! ¡Todos a vuestros puestos! Voceaba de un lado a otro nuestro capitán.

Tras un tímido intercambio de cañonazos, aquellos filibusteros nos abordaron. Luchaban con mucho tesón y mucha virulencia, pero nuestro capitán con inteligencia. Sufrimos bajas, muchas bajas diría yo; pero ellos muchas más. Finalmente los temores de la tripulación se disiparon al comprobar que tan fiero no era el rival. Aquellos piratas fueron condenados al acero de nuestras espadas. Su capitán al hierro de unas esposas.

Quedaban pocos días para llegar a nuestro destino y mi ánimo iba mejorando. No por la cercanía del Puerto de la Española, sino por la conversación que me daba el malogrado pirata. Viajar por todo el mar Caribe descubriendo los más magníficos lugares, vivir sin las restricciones de la sociedad... La Armada nunca pudo ofrecerme lo que me estaba ofreciendo mi hermano de la costa.

El fin del cántico me devuelve a la realidad. ¿Qué haremos esta veraniega mañana? ¿Qué océano cruzaremos? ¿A qué inhóspitos lugares llegaremos? Me preguntaba cada vez que escuchaba esa canción. ¿Qué haremos con el marinero borracho? Volvió a gritar un pirata. ¡Afeitar su vientre con una hoja afilada! Respondí yo.

Chechu,
23/07/2014

Uso correcto de parámetros


Una de las heurísticas de diseño más importantes a la hora de desarrollar Software es aquella que nos propone parametrizar todo aquello que pueda ser susceptible de verse modificado en un futuro. De esa manera, se consigue facilitar en gran manera la labor del programador a la hora de cambiar partes del código.

En este artículo pretendo ahondar en la importancia de la parametrización y en cómo usarla adecuadamente, especialmente cuando atañe partes del nombre de un fichero. Así pues, voy a empezar tratando de explicar qué entendernos por parametrizar.

Parametrizar es sustituir trozos más o menos grandes de código fuente por un identificador. Posteriormente, ese trozo de código fuente sustituido es escrito en otro lugar y relacionado con el identificador dado. La idea básica de esto es colocar en un sólo lugar un trozo de código que se repite varias veces, para modificarlo en un sólo lugar en el momento que éste se tenga que modificar. Es decir, el clásico ejemplo de una aplicación que realice multitud de conversiones entre divisas. Si no parametrizáramos los coeficientes de conversión de divisas, cada vez que estos cambiaran (a diario) tendríamos que ir cambiándolos a mano operación por operación. En cambio, al parametrizarlos sólo tenemos que cambiarlos una vez.

Ahondando en el ejemplo, podríamos incluso ahorrarnos esa pequeña actualización manual si establecemos un proceso que actualice esos coeficientes cada vez que cambien. Por ejemplo a través del acceso a una base de datos actualizada constantemente.

De este modo, la parametrización es una técnica muy importante para aumentar la eficiencia en el desarrollo y mantenimiento de una aplicación.

Esta ventaja concebida en un principio para evitar trabajar más de la cuenta, se convirtió en la base del uso de funciones, procedimientos y demás mecanismos de abstracción. De los cuales sólo diré, para mostrar la importancia que tuvo esa técnica, que es la base teórica del paradigma orientado a objetos.

Volviendo a la parametrización pura y dura, hagámonos la siguiente pregunta. ¿Sólo se puede dar la parametrización si el valor parametrizado aparece muchas veces? No. Imaginemos un valor susceptible de cambiar en el futuro que se encuentre una sola vez en un código fuente de 2000 líneas. ¿Vamos a ir línea por línea buscándolo? Es una absurdez que conlleva un serio problema de eficiencia a la hora de realizar tareas ligadas al mantenimiento correctivo o evolutivo. Lo suyo, es parametrizar todo aquello que pueda cambiar en un futuro, y (muy importante) tener sus valores en un lugar fácilmente identificable. De nada sirve tener una parametrización maravillosa y tardar luego mil horas en encontrar el lugar en donde cambiar los valores, algoritmos, etc parametrizados. Un error, por cierto, muy habitual.

Ahora bien, no es oro todo lo que reluce; parametrizar no es gratis. El uso de la parametrización conlleva un coste asociado de tiempo de compilación y/o de ejecución; según dónde y cómo se haga la traducción del parámetro por su valor. Evidentemente, en un procesador actual, con un compilador moderno, y con un código normal ese tiempo adicional de procesamiento es prácticamente despreciable. Sin embargo, si hablamos, por ejemplo, de aplicaciones en tiempo real o aplicaciones con un gran volumen de cálculos, ese tiempo no es tan despreciable. Así mismo, por poner otro ejemplo, si hablamos de una máquina muy antigua con una limitación importante en términos de tiempo de procesamiento, tampoco.

Además de ello, hay que tener en cuenta el factor cognitivo. Es posible que en un primer momento pueda parecer una tontería, pero es un factor muy importante a la hora de mantener una aplicación informática. Es mucho más sencillo realizar tareas de mantenimiento cuando los nombres de los parámetros, variables y demás identifican claramente el elemento sustituido que si esos nombres se ponen aleatoriamente. Así pues, si sustituimos los valores de los coeficientes de transformación de divisas son más manejables nombres como:

coef_peseta_euro = 0,166;
coef_euro_dolar = 0,785;

Que si ponemos nombres como:

CPE = 0,166;
CED = 0,785;

Dicho todo esto, me gustaría centrarme en un ámbito en donde suele ser bastante común parametrizar. Los lenguajes de script que permiten manejar nombres físicos de ficheros y parametrizar parte de su nombre. La verdad es que soy bastante reticente a la hora de hacer uso de esa técnica en esas circunstancias. Tan sólo soy partidario de hacerlo para algunas excepciones como dotar al nombre del fichero de un identificador que lo diferencie de otros ficheros de las mismas características, por ejemplo de tiempo. En otras situaciones, creo que o bien se debe parametrizar el nombre completo del fichero o bien no se debería de parametrizar nada.

Ahí entra otra de las heurísticas fundamentales a la hora de diseñar una aplicación. Establecer eficientemente cómo se va a gestionar esa aplicación una vez en funcionamiento, es igual o más importante que su correcto funcionamiento. Hay que tener en cuenta que hoy en día las aplicaciones informáticas son enormes, con mucha casuística y con limitaciones importantes de tiempo y presupuesto en su fase de creación. Dadas las circunstancias, es muy difícil asegurar que vaya a funcionar todo correctamente a la primera. Por eso es importante establecer un mecanismo, ya en la fase de análisis, que permita analizar errores y hacer correcciones rápidamente sobre el código.

¿Qué implica eso en la parametrización del nombre de los ficheros? Pues que toda parametrización tiene que estar hecha con cabeza.

Una de las operaciones de mantenimiento más habituales en un código que maneje nombres de ficheros, es el análisis el contenido de los ficheros que aparecen. En el momento que se tarde más tiempo en buscar como se traduce cada parámetro del nombre del fichero que en realizar el análisis de los datos contenidos en el fichero, la parametrización no tiene ningún sentido. Te hace perder el tiempo y por lo tanto no es efectiva.

Por otro lado, si recordamos que la base de parametrizar es sustituir trozos de código susceptibles de variar en el tiempo, hay que pensar hasta qué punto el nombre de un fichero va a variar. Evidentemente, uno puede poner con calzador nombres de ficheros variantes... pero no deja de ser meter algo con calzador. Eso sólo tiene sentido cuando se les quiera dotar de una marca de tiempo o algo identificativo a un fichero resultado. Pero ahí entra otra heurística fundamental: buscar la máxima coherencia. La generación de esos ficheros se debe de hacer en un proceso aparte distinto del que haga las transformaciones de los datos. Es un sacrilegio mezclar una cosa que tiene una cohesión secuencial con otra que tiene cohesión comunicacional.

Así pues, recapitulando, podemos establecer los siguientes puntos:
  • Cualquier elemento susceptible de variar en el tiempo se tiene que parametrizar si la parametrización no supone un serio problema de rendimiento computacional.
  • Toda parametrización debe de responder a una política previamente definida de parametrización.
  • La modificación de los valores de los elementos parametrizados debe de poder hacerse de manera eficiente.
  • Los parámetros en nombres de ficheros sólo deben de ponerse en módulos comunicacionales.

Chechu,

23/07/2014