Mostrando entradas con la etiqueta Reflexiones tecnológicas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Reflexiones tecnológicas. Mostrar todas las entradas

miércoles, 2 de septiembre de 2009

Stroustrup y la enseñanza de la programación ...

... o la ciencia de la vida.

Sí, tal rimbombante extensión del título de esta entrada ha pasado por mi cabeza, aunque la he omitido no tanto por pretenciosa, que lo es, cuanto por evitar una cabecera demasiado larga para Blogger.

¿A qué viene este embrollo? La cosa es que durante algunos días de este verano y, aprovechando, cómo no, el tan preciado descanso, me ha dado por hincar ligeramente el diente al nuevo libro del maestro Bjarne Stroustrup. Para quien no sepa quién es Stroustrup, baste decir que no sólo es el creador del lenguaje de programación C++, sino seguramente una de las personalidades más valoradas del mundillo de la informática.

Pues bien, resulta que Stroustrup ha sacado tiempo, entre sus muchas dedicaciones y responsabilidades de experto, para escribir nada menos que una introducción a la programación, un buen tocho de más de 1000 páginas titulado Programming -- Principles and Practices using C++. No he leído más que la primera parte, algo más de unas 300 páginas espléndidas en más de un sentido.

No es mi propósito hacer una reseña del libro ---por lo demás, imposible, dado que sólo he leído un fragmento---, ni siquiera una reseña de esta primera parte, que ya de por sí la merecería. Lo que, más bien, me interesa es reflexionar sobre mi experiencia al topar con sus capítulos sexto y séptimo (especialmente, el sexto).

Téngase en cuenta que mi punto de vista no es sólo el del entusiasta en estos asuntos técnicos, ni siquiera el del propenso a encontrar placer en la didáctica de la programación, sino más bien el de quien enseña algo, si bien de una índole en apariencia muy diferente. Porque, al cabo, el problema del aprendizaje va mucho más allá del objeto de la enseñanza, o sea, de la materia que se imparte, y se concentra, en particular ---si se me permite el juego de palabras, en su objetivo; y éste, cuando se entiende en su mayor generalidad, es común probablemente, a todas las formas de aprendizaje.

Pues bien, los capítulos en cuestión enseñan cosas como:

  • Diseño de una gramática abstracta para interpretar el input que procesará un programa de cálculo aritmético (una calculadora).

  • Implementación de esa misma gramática a través de funciones recursivas, mutuamente relacionadas.

  • Creación de tipos en C++ y manipulación del input a través de un tipo stream creado por el usuario.

  • etc.



Sorprende, ciertamente, que un libro de introducción ponga sobre la mesa del aprendiz una tarea de esta complejidad a unas pocas páginas de distancia de su presupuesta total ignorancia sobre la programación. Es evidente, sin duda, que Stroustrup trata a sus alumnos como adultos capaces de asumir retos difíciles desde el primer momento.

Pero lo verdaderamente sorprendente es la forma como Stroustrup plantea el ataque a este problema de programación, el diseño e implementación de una calculadora. Muchos se quedarán en la superficie y verán tan sólo un caso más ---no muy frecuente, por cierto, en textos introductorios--- de la práctica de un diseño e implementación incrementales. Pero la cosa, a mi modo de ver va más allá.

Hay algo en esas páginas que trasciende la cuestión relativa a conceptos y técnicas de programación. Dicho en pocas palabras, lo que Stroustrup una y otra vez trata de hacernos comprender es que el verdadero meollo de la programación no es otra cosa que el de pensar a fondo sobre un problema, el de acercarse, mientras hacemos el camino, a la naturaleza misma del problema inicial, cuyo sentido y complejidad se va haciendo cada vez más presente ---aunque, quizá, me atrevería a decir, nunca completa y enteramente presente---, gracias a nuestros ingenuos errores iniciales, a nuestros pasos en falso y a toda esa serie de tentativas aparentemente infructuosas y, sin embargo, imprescindibles, de las que consta todo proceso de investigación lanzado hacia lo nuevo, hacia lo desconocido.

La excelencia del maestro se mide no por la cantidad o, incluso, calidad de las cosas que enseña ---que también---, sino sobre todo porque nos hace comprender que el aprendizaje no termina nunca y que, nosotros, por muy arriba que estemos en nuestra destreza y conocimientos, somos esencialmente aprendices a la hora de enfrentarnos a nuevos retos ---los únicos que al cabo interesan---, esencialmente falibles, incorrectos, tentativos.

No es diferente lo que los grandes maestros han venido enseñando desde los albores de nuestra civilización. Piénsese, por ejemplo, en el método platónico-socrático del elenchos y la dialéctica; piénsese en el proceso de aprendizaje de cualquier artesanía compleja.

... Y piénsese ---por qué no--- en las propias cuestiones de la vida, las que nos azoran de continuo, desconcertantes, irresueltas y, a un tiempo y por ello mismo, fascinantes.

Mucho se gana ---diría, incluso, que todo se gana--- cuando se comprende que el experto no es nunca el infalible, sino el que asume con plena conciencia hasta qué punto el camino no es, ni debe ser, rectilíneo, sino más bien sinuoso, espiral incluso; y que, lejos de que ello suspenda el entusiasmo y el juicio, nos ata a la aventura del descubrimiento con la misma poderosa fuerza que el aprendiz siente en sus primeras andaduras.

Gracias, maestro Stroustrup, por recordarlo, incluso allí donde el lego quizá esperase, basado en peligrosos lugares comunes, justamente lo contrario.

domingo, 30 de noviembre de 2008

RTFM o de los malos hábitos

[ Advertencia: Esta es una entrada técnica. Absténganse de leerla los no interesados en los entresijos de Unix y sistemas afines. ]

Casi todo usuario de Linux o sistemas semejantes tiene que ser a la vez y en alguna medida ---lo quiera o no--- administrador de sus propias máquinas. Lo malo es que empieza a ser demasiado común emprender tales tareas administrativas con la mente idiotizada del luser, y así nos va, hasta que nos damos cuenta de nuestro pecado.

Os cuento un ejemplo de esto mismo que me acaba de suceder. Yo, convertido en luser, y perdiendo horas sin tino, por no darme cuenta, de que, cuando hay que ser admin, no hay coartadas que valgan.

Todo empezó con mi cortafuegos ...

El caso es que tengo una máquina independiente funcionando desde hace unas semanas como cortafuegos.

Una de las primeras cosas que quería hacer era que los logs del cortafuegos me llegasen a mi estación de trabajo, no sólo por razones de seguridad, sino también de comodidad. [ Sí, ya sé, lo mejor es que estén en un único servidor de logging, pero mi presupuesto no da para tanto, de momento ]. Además de eso quería utilizar logcheck ---por razones que omito--- como analizador de los registros.

El asunto no parecía difícil ---y no lo es, si uno se conforma con las configuraciones estándar. Pero a mí me interesaba una opción poco convencional.

logcheck envía mensajes de correo al administrador cada cierto tiempo (via cron), sobre los registros almacenados en los /var/log/* que uno desee analizar. En debian ---que es mi distro--- los ficheros de registro que se quiere que logcheck analice se definen en /etc/logcheck/logcheck.logfiles. Ahora bien, lo que a mí me interesaba es que logcheck me enviase mensajes diferentes para cada máquina, o sea, uno para la máquina local y otro distinto para el cortafuegos o cualquier otra máquina remota.

El problema empezaba con que los registros del cortafuegos iban al mismo fichero que el de mi máquina local. Lo primero que pensé fue en sustituir syslog por syslog-ng, el cual permite una definición más versátil de los ficheros de destino, por ejemplo, permite (gracias a la variable $HOST) crear ficheros de logs diferentes para distintas máquinas. Así lo hice, y tras configurar adecuadamente syslog-ng tenía un fichero de registro independiente para los logs procedentes de mi cortafuegos. Ya sólo faltaba que logcheck analizara también ese fichero y quedase configurado para que me enviase, además de un mail sobre mi máquina local, otro distinto sobre mi cortafuegos.

Hasta aquí los preliminares. Y ahora empieza la anécdota propiamente dicha. Busqué rápidamente en la documentación de mi distribución del paquete logcheck ---esto es lo primero que leo cuando instalo un paquete que no conozco--- por si existía alguna información para lograr mi objetivo. No encontré nada ahí, y me fui directamente a google. Y ya se sabe que googlear puede consumir mucho tiempo. El caso es que tampoco encontré nada en google. O sí, encontré un programa newlogcheck, que envía cada cierto tiempo un único mensaje con un sumario del análisis realizado, dividido en tantas secciones como máquinas emisoras de registros se quieran controlar; algo parecido, pues, a lo que yo pretendía.

Pensé para mis adentros que si alguien se había tomado la molestia de escribir esto, había pocas esperanzas de que logcheck, por sí mismo y sin modificaciones del código, pudiera hacer lo que yo deseaba. Parece que tenía sólo dos opciones: adoptar newlogcheck o desisitir. No me apetecía introducir un nuevo programa en la jerarquía de mi distribución, pero tampoco desistí. Porque, de repente, algo en mi interior se sublevó: "pero, chaval, si ni siquiera te has leído con atención la página de manual de logcheck. Quién te ha visto y quién te ve". Era mi propia conciencia BOFH irritada, con razón, contra la pereza y desidia de mi personalidad luser. Hice caso a mi BOFH y me leí con atención la página logcheck(8). Y ahí estaba la respuesta a golpe de vista. Con un poco más de trabajo, que consistió en pasar por las páginas cron(8) y crontab(5), tenía el problema resuelto. Algo que, si lo hubiese hecho desde el principio, me habría llevado no más de media hora de investigación y ese algo menos de un minuto que cuesta añadir esta línea a /etc/crontab [ Debe ser una única línea, aunque puede aparecer dividida en los navegadores. El nombre/IP real de la interfaz de red local del cortafuegos ha sido omitido ]:

4 * * * * logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -l /var/log/[mi-firewall]/kern.log -H firewall; fi


La anécdota concreta es lo de menos, pero sí importa ---y mucho--- la moraleja: "el luser es el único ser que tropieza siempre en la misma piedra: no dejes que tu estúpido Jekyll se apodere de tu 'buen' Hyde". O, dicho de modo más lacónico, pero no menos expresivo: RTFM!!

lunes, 20 de octubre de 2008

Mis programas de consola

En mi último envío propuse argumentos en defensa del uso de las aplicaciones de consola, con independencia de que se ejecuten desde la consola propiamente dicha o en un entorno de escritorio típico a través de un emulador de terminal. Cité además algunas, a modo de ejemplo.

He pensado que puede ser interesante para mis posibles lectores dejar constancia de las que utilizo con frecuencia. Casi todas tienen una o varias alternativas dentro también del mundo de la consola, de ahí que la selección sea estrictamente personal y obedezca tanto a razones de gusto, como a aspectos específicos de mi forma de usar el ordenador. Por ejemplo, puesto que edito todo con vim, tiendo a escoger aplicaciones cuyos atajos de teclado sean semejantes a los de vim o se puedan configurar fácilmente para hacerlos semejantes. Por otra parte, suelo preferir aplicaciones sencillas, que hacen bien una cosa y sólo una y cuyo consumo de recursos es reducido (o sea, que mis elecciones suelen estar en consonancia con la forma de pensar característica de Unix).

No pretendo comentar por separado estos programas (cada uno de ellos merecería un artículo aparte como mínimo), simplemente referirlos, describir su propósito someramente y de modo informal, e indicar, donde lo vea conveniente, algunas de las peculiaridades suyas que más me interesan.

Por otra parte, y aunque nadie me lea, siempre es agradable hablar, aun para uno mismo, de las cosas que gustan.

Vamos allá.


  • screen: Gestor de ventanas en pantalla completa que permite multiplexar distintos procesos. Las nuevas versiones disponen también de una mayor versatilidad en la definición de la forma de presentación de cada ventana (layout), así como de la posibilidad de organizarlas en grupos diferentes. Quizá su característica más destacada sea la de que, desde cualquier máquina remota, se puede abrir una sesión completa (o varias) de screen, con todos sus procesos en la situación en que estaban cuando cerramos dicha sesión en otra máquina. Un ejemplo: si estoy en mi casa trabajando con mis programas habituales de consola en una sesión de screen, puedo cerrar esa sesión (no apagar la máquina, claro, porque los procesos implicados deben seguir ejecutándose) y acceder luego a ella desde el ordenador del trabajo o desde la casa de un amigo, aunque su sistema operativo sea distinto. Basta con disponer de un emulador de terminal en este sistema y tener abierto el puerto correspondiente de mi máquina de casa.


  • vim: Editor rapidísimo, al que se pueden añadir todas las extensiones imaginables que convengan (mediante plugins o scripts). Su rápidez se basa en usar combinaciones sencillas de teclado (fáciles para la mano) gracias a su diferenciación de modos de operación distintos.


  • mutt: Un cliente de correo muy potente y versátil. Puede usarse como sistema autónomo y completo de correo (las nuevas versiones disponen de opciones incorporadas para recepción y envío de email), o se puede utilizar en combinación con programas específicos de transporte, de recogida, de distribución de correo y de control de spam.


  • newsbeuter: Un lector/agregador de fuentes RSS y similares. Permite importar fuentes ya existentes. Es muy sencillo y fácil de usar y configurar.


  • w3m: Navegador web y paginador. Me gusta especialmente, aparte de las teclas de movimiento al estilo vi, su función para poder seleccionar distintos navegadores gráficos, lo que permite ver cualquier página rápidamente en modo texto y revisarla con más detalle en su forma gráfica a golpe de una tecla.


  • ikiwiki: Un constructor de wikis escrito en Perl y con soporte CGI (es decir, a la antigua usanza), pero con una filosofía peculiar y novedosa si se la compara con otros sistemas de wiki. Su extensibilidad (mediante plugins) y flexibilidad son muy notables. Aunque su uso común implica la necesidad de un servidor web, es posible configurarlo para que funcione sin tener uno instalado, siempre que se use w3m para editarlo, ya que este último posee un soporte CGI incorporado. Igualmente destacable es el uso de un sistema real de control de versiones independiente (svn, git, etc). Cuando madure el plugin para latex (se está en ello) tendrá todo lo que necesito y exactamente como lo necesito. Merece la pena echarle un vistazo, incluso aunque no se use.


  • vifm: Un gestor de ficheros sencillo y con atajos de teclado a la vi, de ahí su nombre.


  • cplay: Un reproductor de ficheros de audio. Consume muy pocos recursos y es muy sencillo de usar.


  • shell-fm: Una aplicación de línea de comandos para reproducir flujos de la radio last.fm. Sencillísimo y eficaz.


  • htop: Un monitor en tiempo real de los procesos del sistema en la línea del top original, pero con una interfaz más amigable.


  • trafshow: Un monitor en tiempo real del tráfico de las interfaces de red. Es de los pocos que conozco para consola. Me permite tener a la vista, siempre que quiera, cómo se desarrolla el trafico, sin necesidad de ejecutar netstat o similares aplicaciones de línea de comandos, que reservo para cuando necesito conocer más detalles. En mi distribución (debian) forma parte del paquete netdiag.


  • aptitude: El frontend moderno de debian para administración de los paquetes de sus ingentes almacenes de software. Conviene echar un vistazo a la página de manual en cada nueva versión que sale, porque casi siempre incorpora novedades interesantes.


  • devtodo: Una aplicación de línea de comandos bastante sencilla de usar y que va exclusivamente de lo que va: de organizar y llevar la pista de las tareas pendientes. Puede almacenar distintas series de tareas según el directorio en que se esté y mostrarlas al cambiar a ese directorio.


  • wodim: Forma parte del proyecto cdrkit. Todo lo que necesito para escribir CDs/DVDs desde la línea de comandos. Aunque k3b sigue siendo una maravilla que nunca sobra.


  • pdftex: Mi herramienta habitual para construir un documento pdf a partir de una fuente TeX/LaTeX. Porque vivir en el mundo de los procesadores de textos es casi como vivir en la edad de hierro en lugar de en la edad de oro ;-)



Omito el recuento de aplicaciones de línea de comandos de uso común y genérico en sistemas Unix o GNU: herramientas típicas de acceso y procesamiento de ficheros, de administración, etc., porque son muchas, porque ya hay cientos de miles de páginas escritas al respecto y porque están a la mano de todos los que quieran.

Espero que este repaso general por "mi" caja de herramientas siga siendo un acicate para los amantes o curiosos de la consola. Los primeros conocerán casi todas, pero quizá alguna no les resulte familiar o ni siquiera hayan oído hablar de ella; los segundos, tienen materia de sobra para investigar y hurgar. Por lo menos, antes de que me entren ganas de redactar artículos específicos y extensos sobre alguna y acabe poniendo todo el plato precocinado en la mesa electrónica. Quien sabe :-)

domingo, 12 de octubre de 2008

Y al final, la línea de comandos

La puerta de entrada de la informática fue durante unos cuantos años la línea de órdenes (CLI en inglés), es decir, commnad line interface o línea de comandos, si se prefiere una traducción menos correcta, aunque más difundida.

Pero desde hace tiempo la interfaz gráfica de usuario (GUI) parece haber desplazado casi por completo a la interfaz original de puro texto.

Y sólo digo casi, porque sigue siendo ampliamente usada por los administradores de sistemas, por algunos "gurús" informáticos y por unos cuantos "freakies" de los computadores, generalmente asociados todos ellos a plataformas de software semejantes a Unix u a otras rarezas equivalentes.

¿Pero es realmente tan extravagante y trasnochado preferir la CLI a la GUI en un buen número, no desdeñable, de situaciones de trabajo con el ordenador?

En absoluto lo es. Y como prueba se pueden esgrimir muchas razones. Véanse, por ejemplo, las estupendas argumentaciones de Neal Stephenson en su clásico In the beginning was the command line, del que, por cierto, hay traducción a la lengua de Cervantes.

Hay ciertos campos en concreto, por ejemplo, en la edición de textos, donde, a mi entender, el abandono de la CLI ha provocado y provoca graves perjuicios, como traté de argumentar en El qué y el porqué de LaTeX [ el primer artículo que aparece en el documento enlazado ].

Pero, incluso, en las tareas básicas (programas de correo electrónico, agregadores de noticias, editores, navegadores de ficheros, navegadores web, ...), las aplicaciones de línea de ordenes, son inmejorables en muchos sentidos. Citaré sólo unos cuantos:

  • Son mucho más rápidas, tanto porque tales programas consumen muy pocos recursos, como porque todas las operaciones se realizan comúnmente sin levantar los dedos del teclado.

  • Están disponibles para infinidad de sistemas operativos y arquitecturas de hardware.

  • Pueden ejecutarse en ordenadores realmente antiguos o con recursos muy limitados si se los compara con los actuales ordenadores de escritorio. Son por ello "ecológicas".

  • Son, en su inmensa mayoría ---como lo suele ser el software creado por los padres de la informática---, libres, en el doble sentido que la palabra inglesa free tiene de gratuito y abierto (el código permanece abierto a la inspección y, en su caso, a la oportuna modificación y mejora de cualquiera que lo desee). Aunque esto no es característica únicamente suya. Pues, como se sabe, el movimiento de software libre u open source ha creado también y sigue creando magníficas herramientas para la GUI.


Es difícil pedir más por menos. Y hay más, si se busca un poco. Por ejemplo, bajo una aplicación como screen se pueden ejecutar los típicos programas citados en un determinado ordenador, cerrarlos todos, y volver a abrirlos desde otro ordenador remoto regresando exactamente al mismo punto en el que estaban todas las aplicaciones que corrían sobre screen cuando abandonamos la sesión en la primera de las máquinas, y todo ello con indiferencia del sistema operativo bajo el que funcionen los susodichos ordenadores y con una fiabilidad que es difícil, si no imposible, encontrar en aplicaciones gráficas de similar propósito.

Se me dirá, con razón, que renunciar a las aplicaciones gráficas es locura allí donde son insustituibles, es decir, donde el dato manejado es justamente la imagen (programas de visualización o edición fotográfica, lectores de pdf, reproductores de vídeo, etc.).

Nada más lejos de mi intención. Sin embargo, es perfectamente posible y razonable permitir que convivan limpiamente unas y otras aplicaciones (CLI y GUI). Los entornos modernos de escritorio permiten hacerlo con facilidad a través de sus emuladores de terminal o consola. De forma que es perfectamente natural y absolutamente transparente al usuario la ejecución de aplicaciones gráficas desde nuestras aplicaciones de puro texto.

Para terminar, dejo aquí unos pantallazos de algunos de los programas CLI, ejecutados desde una sesión de screen, que yo mismo uso desde un único terminal en mi escritorio de KDE4 (se verá que es KDE4 por el icono de plasma que aparece en la parte superior izquierda). O sea, el escritorio de última generación conviviendo con algunos conspicuos miembros del CLI-clan. Por eso, de lo de predicar con el ejemplo ;-)

mutt, el cartero legendario:



w3m, el postrero de los clásicos:



htop, el joven domador de procesos:



nethack, el origen del submundo:

domingo, 31 de agosto de 2008

Futuro del libro electrónico

Ningún soporte electrónico de lectura puede, en la actualidad, compararse con un libro bien editado ---buen papel, buena impresión y diseño---, sigue habiendo ---es incuestionable--- una diferencia. Pero, con el papel electrónico, esta diferencia se va acortando. Curiosamente a propósito del iLiad, salió hace dos días esta reseña, donde su autor proponía una escala subjetiva de puntuación, de 1 a 10, sobre la calidad de visualización de los soportes de lectura actuales. Según él la escala, que comparto hasta donde conozco los dispositivos, sería la siguiente:

- Un portátil antiguo con pantalla LCD - 1 punto
- MacBook Pro - 3 puntos
- Nokia 770 - 5 puntos
- iLiad - 8 puntos
- Libro - 10 puntos

Es decir, probablemente no queda tanto para que, desde el punto de vista del hardware, lleguemos a emular la calidad de lectura sobre el papel, y quien sabe si hasta superarla.

Otro tema es el de los formatos con que se publican electrónicamente los libros. Se necesitan, sobre todo, dos cosas, que todavía no se tienen, al menos en el grado debido: libertad y versatilidad.

Falta libertad desde el momento en que no podemos hacer con nuestro libro electrónico lo mismo que hacemos con nuestro libro de toda la vida: llevarlo a cualquier parte, esto es, instalarlo en cualquier sistema electrónico que tengamos o vayamos a tener; prestárselo a un amigo; etc. Lo que significa que jamás lograremos aquello de lo que ahora disfrutamos con un libro si no se frena definitivamente la barbaridad del DRM y toda la patraña vertida para justificarlo. En este sentido, resulta paradójico, incluso irónico, que el empuje que podría haber dado la popular Amazon, cuando sacó su Kindle, a la implantación de esta tecnología tenga más bien el efecto contrario: ¿quién quiere una biblioteca cerrada con una llave prestada y que nunca será suya? Si éste es el futuro del libro, mejor huir de él cuanto antes.

En cuanto a la versatilidad, es necesario encontrar formatos que respeten el diseño de la página sin impedir su adecuada transferencia a dispositivos electrónicos con distintas dimensiones de pantalla. Lo más parecido a una página impresa, desde el punto de vista electrónico, es el pdf. Pero un fichero pdf está absolutamente limitado por lo que respecta a su capacidad de adaptarse a distintos dispositivos de visualización, básicamente porque nunca fue esa su intención. Últimamente se han diseñado otros formatos ---pienso, por ejemplo, en epub--- precisamente con el propósito de resolver estos problemas, formatos que deberían mejorar la situación en un futuro cercano, si los distribuidores de libros electrónicos los adoptasen masivamente.

No obstante, la mayor dificultad sigue estando justamente en los productores de libros. En primer lugar, las editoriales, reacias como nadie a cambiar su modelo de negocio ---aunque hay excepciones, como, por ejemplo O'Reilly, siempre a la cabeza en cuanto a adaptación tecnológica se refiere---; en segundo lugar, los propios autores, que como punto de origen de toda la cadena de producción del libro, son los que disponen de la principal palabra en este asunto. Es una pena, como ya he lamentado en otras ocasiones, que tanto aquéllas, las editoriales, como éstos, los autores, no estén, salvo casos contados, a la altura de los tiempos. Estoy convencido de que si se venciese la reticencia de creadores y distribuidores, estaríamos todos muy pronto leyendo una buena parte de nuestros libros y documentos en dispositivos electrónicos mejorados, tanto en su hardware como en su software. Falta, como siempre, la masa crítica que ponga en marcha el proceso universal de transformación, y que sólo los que están en los primeros puestos de dicho proceso pueden hacer caer del lado favorable, como de hecho lo están haciendo caer del otro, es decir, frenando con su actitud conservadora lo que supondría una mejora evidente para los lectores. Para todos ellos, también para los nostálgicos del libro, entre los que, dicho sea de paso, me sigo contando.

[ Este texto ha sido publicado también en Libertonia ]