tecnolocuras

La enciclopedia hipertextual que sobrevivió a su autor

Sat, 09 May 2026 00:00:00 +0000

Le escribí a un muerto.

Don Markestein falleció en el 2012. Casi 15 años después le escribí un correo. Esperaba una respuesta a una pregunta tan sencilla como directa: ¿cómo creó Toonopedia? Una enciclopedia hipertextual que, desde 2001, se convirtió en uno de los repositorios más completos sobre el mundo de los dibujos animados en Estados Unidos.

Así presentaba Don Markstein su proyecto Toonopedia:

«Bienvenido a la primera enciclopedia hipertextual del mundo dedicada a los toons, la cual espero que pronto llegue a ser considerada la fuente de información más completa de Internet sobre el mundo de los toons en Estados Unidos.

Entonces, ¿qué es un toon?

Un toon es una caricatura o un personaje de caricatura. El término “caricatura” no se refiere solamente a las animadas, sino también a las “caricaturas estáticas”, como los comic books, las tiras cómicas de periódicos, las caricaturas de revistas, etc. Aquí, en Don Markstein’s Toonopedia, tenemos una visión muy amplia de lo que constituye un toon. La idea básica es cubrir todo el espectro de la caricatura estadounidense. Reconozco que todavía no he cubierto completamente el tema, pero creo que los más de mil artículos sobre toons que he escrito hasta ahora califican al menos como una cobertura ligera. Y seguirá volviéndose más inclusiva con el paso del tiempo, ya que tengo la intención de continuar agregando nuevos artículos y actualizando los existentes en el futuro indefinido.»

Este fue su manifiesto. Y lo cumplió.

Durante más de once años, y si las cuentas no me fallan, Markstein creó más de 1.800 fichas de dibujos animados, cada una con:

Una descripción clara y bien escrita
Una imagen de referencia
Datos del medio, fecha de aparición y creador
Enlaces internos a personajes relacionados

► Una ficha en Toonopedia.

La pregunta que surge luego de navegar un rato por Toonopedia es: ¿cómo hizo para crear tantas fichas, organizarlas y vincularlas entre sí? Es un esfuerzo significativo, y esto sin considerar el tiempo que implica investigar sobre cada toon que publicó.

Esa era la pregunta central del correo que le envié a Markstein. Nunca obtendremos una respuesta, pero hay elementos en el código y estructura del sitio que nos permite especular como podría haber sido su flujo de trabajo.

Esta “especulación educada”, está basada en evidencias técnicas del código HTML, patrones de escritura, estructura del sitio y el contexto tecnológico de la época (2001–2011). Pero antes, conviene decir que...

La experiencia

Don Markstein no era un novato en esto de los dibujos animados. Junto a su esposa, GiGi Dane, creó APATOONS, una Amateur Press Association (APA) dedicada al mundo de los cómics y la animación.

► Las APAs son redes de aficionados que se intercambian fanzines por correo postal. Cada miembro envía sus textos y un coordinador los compila en una publicación común. Veo a las APAs como una especie de proto-internet: generan comunidad, promueven el intercambio, incentivan la autoría distribuida y reúnen personas alrededor de intereses comunes. No faltara oportunidad para darle una mirada a todo ese curioso ecosistema.

Don Markstein tuvo además una larga trayectoria vinculada al mundo del cómic. Fue editor de la revista Comics Revue, colaboró en libros sobre historia de la historieta como The Prince Valiant Companion y escribió diversas historietas, incluidas algunas publicaciones de Disney destinadas principalmente al mercado internacional.

Lo técnico

Toonopedia está construido con HTML plano. Sin CMS. Sin base de datos. Sin frameworks. Casi sin JavaScript. Solo HTML, imágenes y algunos scripts clásicos de la era dorada, como ser:

Un anti-framing:

<body onload="if (self != top) top.location = self.location"></body>

Y un anti-click:

<script language="JavaScript"><!--
var message="Contact webmaster concerning permission to use images"; // Message for the alert box
function click(e) {if (document.all){if(event.button == 2){alert(message);return false;}}if(document.layers){if (e.which == 3){alert(message);return false;}}}if(document.layers){document.captureEvents(Event.MOUSEDOWN);}document.onmousedown=click;// --></script>

Estoy casi, casi seguro que Markstein pudo haber utilizado Microsoft Word (u otro procesador de texto) para la escritura inicial. Estas son las evidencias:

En el código HTML aparecen entidades como (apóstrofe tipográfico) y (elipsis), pertenecientes a la codificación Windows-1252, usualmente generados a través de Microsoft Word (cuando está activada la función de smart quotes) o un editor visual, como Microsoft FrontPage.

Rick O&#146;Shay
&#133; wasn't just the style that was emulated.

En el archivo strips.htm vemos el uso de &# 149; para viñetas:

&#149; <A HREF="strips.htm#abnslats">Abbie & Slats</A>

Existe una estructura repetitiva y consistente en todas las páginas:

Mismo orden de tags
Mismo bloque de anuncios
Mismo pie de página
Mismo script anti-clic derecho

Esto sugiere el uso de una plantilla base, una funcionalidad que proveen editores WYSIWYG como FrontPage.

El sitio no utiliza una hoja de estilos externa. En su lugar, el formato se define directamente dentro de las páginas mediante estilos embebidos y atributos inline. Este patrón era común en herramientas de edición visual de la época, como Microsoft FrontPage y Microsoft Word, aunque también podía ser el resultado de edición manual, como veremos a continuación.

Hay algunos errores en el HTML que sugieren que Don podría haberle “metido mano” al código generado. Posiblemente se necesitaba hacer ajustes a los enlaces, corregir errores o insertar bloques de código como anuncios o donaciones.

Otro aspecto interesante es la estructura del sitio. La mayoría de los artículos HTML se encuentran directamente en la raíz del sitio, en lugar de estar organizados en subdirectorios temáticos.

Lo que revelan las imágenes

No sin cierta ironía, uno de los detalles menos visibles, es cómo Markstein preparaba y optimizaba las imágenes que acompañaban sus artículos.

Si analizamos los metadatos de estos archivos, vemos que aparece un dato relevante en el campo Comment: LEAD Technologies Inc. V1.01

► Vista de los metadatos de una imagen disponible en Toonopedia. Cortesía de https://fotoforensics.com.

LEAD Technologies era un proveedor de bibliotecas de procesamiento de imágenes (LEADTOOLS), cuyas herramientas estaban integradas en múltiples aplicaciones populares de los años 2000.

Si bien esta “huella” no permite identificar con certeza qué programa utilizaba Don Markstein, si sugiere el uso de aplicaciones de Windows de la época, posiblemente un editor de imágenes, el software del escáner o alguna herramienta de oficina.

Entonces, basado en todo lo visto, podríamos especular que su flujo para crear una ficha era algo como lo siguiente:

Don escribía el artículo en Microsoft Word o en Microsoft FrontPage.
Escaneaba una tira cómica (o descargaba una ilustración), utilizando un escáner con software que contenía el SDK de LEAD Technologies (o guardaba desde un programa que lo incluía).
Insertaba la imagen y enlaces internos con FrontPage, de forma visual.
Ajustaba el código manualmente para corregir errores o añadir scripts.
Subía el archivo con algún cliente FTP al servidor, en la raíz.
Actualizaba el índice manualmente.

Manual, repetible, artesanal.

Un diario de vida

Toonopedia cuenta con una pequeña joya: su página Site History. Si bien es un registro técnico de cambios, en la práctica, funciona más como un diario personal de desarrollo donde Don Markstein dejó constancia de avances, frustraciones, alegrías y pequeños triunfos cotidianos.

O, visto de otra manera, es el registro de la actividad de una persona que dedicó una parte importante de su vida a sentarse frente a una computadora para investigar, escribir y organizar información sobre un tema que lo apasionaba, con el simple deseo de compartir ese conocimiento con los demás.

► Este registro histórico nos permite obtener algunas datos interesantes.

La constancia

El sitio abrió oficialmente el 13 de febrero de 2001 con 304 artículos ya publicados. Don llevaba más de un año preparando el proyecto y construyendo una versión preliminar llamada Cartoonopedia.

A lo largo de la década siguiente, el ritmo de publicación fue sostenido. Si se considera que el sitio alcanzó más de 1.800 artículos y que partió con 304, Don escribió aproximadamente 1.500 nuevas fichas en unos diez años, lo que equivale a:

unas 150 fichas por año;
alrededor de 12 o 13 por mes;
aproximadamente una nueva entrada cada 2 o 3 días.

Las frustraciones

El historial también nos deja ver momentos difíciles.

En enero de 2000, Don relata que visitó el sitio donde su enciclopedia iba a publicarse y encontró… nada. El primer editor potencial había fracasado.

Más adelante firmó un nuevo contrato con otro editor que, según sus propias palabras, «... desapareció de la faz de la Tierra».

A eso se sumó el colapso de las empresas puntocom, que redujo drásticamente las posibilidades de encontrar un socio comercial.

Frente a esa situación, Don tomó la decisión de autopublicar el sitio y promoverlo por su cuenta.

Las alegrías

El 19 de febrero de 2001, apenas seis días después de la apertura, Yahoo destacó Toonopedia como uno de sus “Daily Picks”. El tráfico del sitio se multiplicó por cinco y superó las 24.000 páginas vistas.

Entre los hitos más significativos registrados por Don se encuentran:

15 de enero de 2000: fracaso del primer editor.
2000: creación de la versión beta Cartoonopedia.
Última semana de enero de 2001: cambio de nombre a Toonopedia.
7 de febrero de 2001: registro del dominio.
13 de febrero de 2001: apertura oficial con 304 artículos.
19 de febrero de 2001: destacado por Yahoo.
20 de febrero de 2001: mención en USA Today.
9 de febrero de 2005: se registro el mayor ingreso diario por publicidad de toda la historia del sitio.

En los últimos años, el ritmo de actualización se vuelve más irregular. Recién con la información que se conoció después sobre su estado de salud es posible leer esas pausas bajo una nueva luz.

La última ficha

La última entrada registrada en el historial es: Mad Jack the Pirate, publicada el 9 de febrero de 2011.

Pocas semanas después, Don sufrió el accidente cerebrovascular que interrumpió definitivamente el proyecto:

«ACTUALIZACIÓN SOBRE DON MARKSTEIN: carta editada de su esposa a un amigo Viernes, 25 de noviembre de 2011, 12:01 a. m.

Gracias por tu preocupación por la situación de Don. Significa muchísimo para él saber que la gente lo recuerda. Han sido tiempos muy difíciles para Don. Después del accidente cerebrovascular que sufrió a fines de marzo, padeció prácticamente todas las infecciones hospitalarias imaginables. Tiene un seguro médico muy básico, por lo que recibe una atención mínima.

Tras pasar por una serie de hospitales y centros de rehabilitación, ahora reside en Capri at the Point, en 1501 E. Orangewood, Phoenix, Arizona. Habitación 104.

Don Markstein Capri at the Point 1501 E. Orangewood Phoenix, AZ 85020-5130

Don está lúcido, pero completamente paralizado del lado izquierdo. Respira a través de una abertura en la garganta y se alimenta mediante una sonda que va directamente a su estómago.

Sorprendentemente, su ánimo es bueno, considerando lo pocas opciones que tiene para aliviar el aburrimiento. Puede hablar con mucho esfuerzo cuando le colocan una válvula fonatoria, aunque esto le causa dificultades, por lo que el personal prefiere que la use lo menos posible y, en general, solo cuando recibe visitas.

Yo lo visito y le leo en voz alta. Actualmente estamos leyendo Wicked, la historia de la Malvada Bruja del Oeste. Para Navidad voy a pedir las secuelas. También le gusta escuchar emisoras de música clásica y disfruta mucho de las visitas de sus nietos.

Aceptar que ya no podrá seguir contribuyendo al sitio Toonopedia ha sido muy difícil para él.

Agradecería enormemente que sus viejos amigos le enviaran tarjetas y cartas.

Nuevamente, gracias por tu preocupación. Si su situación cambia, te lo haré saber.

Saludos cordiales.»

Don Markstein falleció el 11 de marzo de 2012 a causa de una insuficiencia respiratoria, tras una prolongada enfermedad.

Toonopedia sobrevivió a su autor

Tras la muerte de Markstein, varios sitios especializados en cómics y animación publicaron obituarios destacando el valor cultural de Toonopedia, como una obra monumental de documentación hecha prácticamente por una sola persona.

Mark Evanier, amigo de Don y una figura importante del mundo del cómic estadounidense, escribió que Markstein había dedicado décadas a construir una referencia única para generaciones de lectores, investigadores y fanáticos.

Poco después de su fallecimiento, la familia publicó una convocatoria invitando a lectores y colaboradores a escribir nuevos artículos, con la idea de mantener vivo el proyecto de manera comunitaria.

Pero eso nunca ocurrió. No hubo una nueva generación que tomara la posta.

La mayoría de los sitios desaparecen en silencio. Se vence el dominio, deja de pagarse el hosting, se rompe una base de datos o simplemente nadie continúa con el mantenimiento.

Por ahora no es el caso de Toonopedia. Sus allegados continúan renovando el dominio para mantener viva la memoria de Don.

Toonopedia sobrevivió quizás, en parte, porque fue construido de una forma sencilla. Nada que dependa de software complejo, frameworks de moda, servicios externos o de personas especializadas en una tecnología en particular.

Pero no es solo eso lo que hace especial a Toonopedia.

Toonopedia se siente diferente porque es la obra de alguien que dedicó una parte importante de su vida a documentar y compartir aquello que lo apasionaba. Y eso es, en gran medida, lo que hace de Internet un lugar maravilloso.

► Donald D. Markstein (21 de marzo 1947 – 11 de marzo 2012)

Gracias, Don.

Arqueología web

Publicado el 9 de mayo 2026

Headless Frankenstein CMS artesanal

Thu, 07 May 2026 00:00:00 +0000

Estoy convencido de que la pereza me ha llevado a utilizar generadores estáticos para encarar todo tipo de proyectos, incluso en escenarios donde construir algo utilizando esas herramientas podría considerarse una forma de autoflagelación.

El proyecto

Hace poco retomé un proyecto que había abandonado. Es una especie de portal / revista donde cubrimos noticias relacionadas con el acontecer literario uruguayo, entre otras curiosidades: Expreso Yatasto.

La naturaleza del proyecto requiere la creación de artículos, su categorización y cierta flexibilidad al momento de personalizar el look and feel del sitio, además de algunas funcionalidades extra, como la generación de un sitemap XML, RSS, etc. Todo lo anterior se puede lograr sin demasiado esfuerzo con un generador estático, pero…

Somos dos personas las que trabajamos directamente en el proyecto y es acá, en un escenario distribuido, donde las cosas se complican con los generadores estáticos. Seguro existen formas de crear un flujo de trabajo que permita distribuir las tareas. La más directa es usar un repositorio para gestionar los cambios y desplegar automáticamente el sitio. Eso funciona, aunque requiere ciertos conocimientos técnicos que pueden excluir a alguien interesado en colaborar y que no quiere convertirse en un experto en software de control de versiones. Entonces, sumar gente al equipo se vuelve un problema.

► Revista cultural. Literatura, teoría literaria, arte y filosofía, entre otras ociosidades…

Algo liviano por favor

Descartado el uso de generadores estáticos, me resigné a utilizar el mejor CMS que conozco: Bludit.

Bludit es rápido, amigable para alguien que solo quiere aportar contenido y lo suficientemente flexible como para personalizar el diseño general del sitio. También es sencillo de desplegar y (redoblantes, por favor) no utiliza una base de datos relacional; pertenece a lo que se conoce como flat-file database.

► Un screenshot de Bludit.

Pero, dicho lo anterior y para ser totalmente sincero, lo que más me importaba era que el hosting fuese lo más barato posible. Gratis. Cero pesos.

Bludit requiere PHP. Conseguir un alojamiento gratuito que soporte PHP es como dejar a tu hijo en una guardería con denuncias por maltrato: existen, pero no conviene hacerlo.

Luego de buscar durante un rato, encontré Alwaysdata. Alwaysdata ofrece un tier gratuito; aunque es generoso de su parte, estos muchach@s saben cómo «apretar la tuerca». Si queres vincular un dominio propio, te empiezan a cobrar, algo que no sabía hasta que pasaron unos meses.

No hay un mango

Personalizamos el sitio. Comenzamos con nuestra tarea «periodística» y esperamos a los auspiciantes… pero nunca llegaron, a diferencia de las facturas mensuales de Alwaysdata.

Visto lo visto, necesitaba sacar el sitio de ahí y encontrarle un nuevo hogar, es decir: pasarlo al plan gratuito de Netlify. ¿El problema? Netlify no soporta PHP.

Por un lado, no quería montar un proyecto nuevo utilizando algún generador estático. Además, hacerlo sería aceptar nuevamente todos los inconvenientes que ya mencioné. Por otro, las facturas seguían llegando. Algo tenía que hacer.

Atado con alambre

«Lo atamos con alambre» es una expresión que se usa en mi país (y posiblemente en otros) para indicar que algo fue reparado de forma precaria, aunque, a pesar de eso, funciona. La solución que encontré encaja dentro de esa definición: convertir Bludit en un rústico generador estático. Esta fue la estrategia que seguí:

Pasarme al plan gratuito de Alwaysdata. Esto implica quitar el dominio y comenzar a utilizar un subdominio .alwaysdata.net.
Continuar usando el backend de Bludit para subir artículos, administrar usuarios, etc.
Crear un proyecto en el plan gratuito de Netlify, asociándole el dominio del sitio.
Descargar el sitio desde el subdominio de Alwaysdata utilizando wget.
Convertir los enlaces del sitio descargado para que apunten al dominio principal.
Desplegar el sitio en Netlify.

El mayor desafío fue crear un script que manejara de forma razonable la descarga y procesamiento del sitio antes de subirlo a Netlify. Soy un feliz usuario de Fish Shell, así que opté por crear una función que se encargara de todo eso.

function yatasto
    set BACKEND "https://expresoyatasto.alwaysdata.net"
    set PUBLIC_DOMAIN "https://expresoyatasto.com"
    set OUTPUT_DIR "public"

    echo "Limpiando build anterior..."
    rm -rf $OUTPUT_DIR

    echo "Descargando sitio desde backend..."
    wget -m -k -E -p -np \
        --no-if-modified-since \
        --no-use-server-timestamps \
        $BACKEND

    echo "Reescribiendo dominio para producción..."
    find expresoyatasto.alwaysdata.net -type f \( -name "*.html" -o -name "*.xml" \) \
        -exec sed -i "s#$BACKEND#$PUBLIC_DOMAIN#g" {} +

    echo "Preparando carpeta final..."
    mv expresoyatasto.alwaysdata.net $OUTPUT_DIR

    echo "Renombrando archivos con ?page=n.html a formato web-safe..."

    for file in $OUTPUT_DIR/categoria/*\?page\=*.html
        if test -f "$file"
            set page (echo $file | grep -o 'page=[0-9]*' | cut -d= -f2)
            set base_name (echo $file | sed -E 's/\?page=[0-9]+\.html$//')
            set new_name "$base_name-$page.html"

            echo " $file → $new_name"
            mv "$file" "$new_name"
        end
    end
    
    echo "Normalizando enlaces de paginación..."
    find $OUTPUT_DIR -name "*.html" -type f | while read html_file
        sed -i -E \
            -e 's/href="([^"?]+)\?page=([0-9]+)\.html"/href="\1-\2.html"/g' \
            -e 's/href="([^"?]+)%3Fpage=([0-9]+)\.html"/href="\1-\2.html"/g' \
            "$html_file"
    end

    echo "Listo en ./$OUTPUT_DIR"
end

Lo más crítico fue usar wget de forma tal que generara un mirror estático completo del sitio, permitiéndome obtener una copia totalmente navegable:

wget -m -k -E -p -np \
    --no-if-modified-since \
    --no-use-server-timestamps \
    $BACKEND

Reemplazar todas las referencias absolutas al backend por el dominio público:

find expresoyatasto.alwaysdata.net -type f \( -name "*.html" -o -name "*.xml" \) \
 -exec sed -i "s#$BACKEND#$PUBLIC_DOMAIN#g" {} +

Un problema que no esperaba encontrar fue la falta de soporte de Netlify para URLs con parámetros, como las utilizadas durante la paginación: ?page=n

Al hacer una copia estática con wget de un sitio dinámico, se generan archivos físicamente inválidos para muchos hostings estáticos. Por ese motivo, es necesario recorrer las páginas del tipo categoría para «normalizar» los nombres de los archivos:

for file in $OUTPUT_DIR/categoria/*\?page\=*.html

Claro, ahora también es necesario buscar en todas las páginas que puedan contener enlaces de paginación y sustituirlos por los enlaces normalizados.

El resultado

Después de todo este periplo motivado por ahorrar unos pesos mientras esperamos tiempos mejores, lo que queda es un snapshot estático completo, compatible con Netlify, sin dependencia de PHP, sin base de datos y manteniendo Bludit como CMS editorial. O, dicho de otra forma: un «Headless Frankenstein CMS artesanal + generador estático vía wget».

¿Es una arquitectura minimalista, barata y sorprendentemente sólida para sitios editoriales? Mmmm… digamos que funciona.

¿Es elegante? Claramente no.

Programación

Publicado el 7 de mayo de 2026

El tiempo suspendido del Bosque Mynarski

Sat, 31 Jan 2026 00:00:00 +0000

Mynarski Forest fue, durante casi una década, un lugar al que se regresaba semana a semana. Una tira publicada en una web lenta, artesanal y sostenida en el tiempo.

A mediados de los años 90, algunos proveedores de Internet (ISP) comenzaron a ofrecer servicios de alojamiento web. Sus usuarios podían crear su propio espacio en este incipiente mundo digital simplemente subiendo archivos HTML vía FTP a un directorio.

Eso era todo lo que se necesitaba para compartir "algo" en línea, y así fue como el artista Richard T. Matheson dio sus primeros pasos en la web.

Los inicios

“Finalmente pude conectarme a Internet en septiembre de 1996. No tardó mucho en descubrirlo The OzFoxes´ Fox Web o Antti Remes´ Nimbl´s Den (de donde conocí The Fur Ring). Mientras veía el trabajo de estos dos artistas muy diferentes pero talentosos, finalmente me topé con el concepto (DUHHH!!!) que yo también podría usar la Web para infligir mis cosas al mundo. Con más de 30 millones de personas en Internet, ¡podría tener una audiencia potencial de casi media docena de personas! Empecé a trabajar de inmediato.”, menciona Richard en su sitio Tails From the Mynarski Forest

El 20 de mayo de 1997, bajo el nombre de “A Blatantly Obvious Trap”, Richard publicó la primera tira de Mynarski Forest. En ella introduce a los dos personajes centrales de su universo narrativo: Liska, una zorra, y Skippy, un conejo.

► Si no fuera porque no lo estaba buscando, podría decir que me llevó 29 años encontrarlo. Y me alegra que haya sido así. © Richard T. Matheson

Mynarski Forest es uno de los primeros webcomics, si consideramos como fundacionales aquellos que aparecieron en el período que va desde mediados de los años 80 hasta el año 2000. Pero… ¿Qué es exactamente un webcomic?

De forma resumida: un webcomic puede entenderse como una tira cómica creada específicamente para ser distribuida en medios electrónicos, primero en espacios como Usenet y, más tarde, a través de la World Wide Web.

► Podemos encontrar una definición más extendida en el siguiente artículo de The Comics Journal.

La historia

Mynarski Forest es un universo que se va enriqueciendo a partir de la paulatina incorporación de personajes, cada uno con personalidades bien definidas. La interacción entre ellos le permite al autor desarrollar situaciones que transmiten humor, muchas veces desde la ironía, con momentos en los que, sin necesidad de hacerlo explícito, se pone en juego la evolución de la relación entre los personajes principales: Liska y Skippy.

Para mi suerte, encontré una breve nota que el escritor Michael H. Payne, escribió sobre Mynarski Forest. Por temor a no poder articular con claridad los aspectos que hacen de esta tira cómica una joya, prefiero compartir sus observaciones, mucho más precisas que las mías:

“Mynarski Forest cuenta la historia de Liska y Skippy, una zorra y un conejo, mientras deambulan por un tramo ficticio de bosques canadienses. Liska es, por supuesto, el nombre del personaje principal de la ópera de Janáček: La pequeña zorra astuta, una de las dos únicas óperas de animales parlantes que conozco, pero aunque Matheson reconoce la inspiración, su Liska es más psicótica que astuta, y Skippy, bueno, está tan nervioso como debería estar un conejo cuyo mejor amigo es un zorro.

Ahora bien, no sé si este es un fenómeno común, pero he estado leyendo este cómic durante tanto tiempo que la pregunta de por qué lo estoy leyendo me hizo detenerme un momento y pensar. Lo disfruto, claro, pero ¿qué fue exactamente lo que disfruté? Y cuanto más lo pensaba, más me recordaba a lo que es esencialmente mi programa de televisión favorito, otra comedia canadiense, algo llamado The Red Green Show.

Como en Red Green, Mynarski Forest combina escenas individuales divertidas con un arco argumental general que se entrelaza a lo largo de cada episodio y le da a los chistes un tipo de estructura que de otro modo no tendrían. El cómic, entonces, combina los mejores aspectos de la tira de "broma al día" -o en este caso, una broma a la semana desde que Matheson publica una nueva página cada lunes- y una tira de historia en la forma en que los chistes de Matheson hacen avanzar la historia, de manera muy similar a como deberían hacerlo las canciones de un musical. Por supuesto, los chistes pueden volverse bastante cursis, pero eso en realidad es una ventaja para mí...”

La inspiración

En la página titulada Origin of the Species, Richard confirma que la inspiración inicial de Mynarski Forest, no es otra que la obra The Cunning Little Vixen:

“La primera inspiración para Mynarski Forest fue en sí misma una especie de tira cómica, que data de hace casi ochenta años. Primero leí la traducción de La pequeña zorra astuta allá por 1986. La novela fue escrita por el autor checo Rudolph Tesnohlidek y se publicó por primera vez en 1920 como una serie ilustrada en el periódico de Brno Lidove Noviny. La heroína de la historia era una zorra rebelde llamada Vixen Sharp-Ears, o Liska Bystrouska en el checo original. Si bien Sharp-Ears con frecuencia actuó de manera cruda o incluso francamente matona a lo largo de la historia, sin embargo se mostró con un gran encanto terrenal. Cuando terminé el libro, me encontré queriendo contar mis propias historias sobre ella. Desafortunadamente, la escuela no me dejó mucho tiempo para hacer un proyecto así y realmente no tenía las habilidades ni la audiencia necesarias para que fuera una experiencia satisfactoria. Así que me contenté con algún garabato ocasional y dejé la idea en suspenso.”

Es interesante notar que La pequeña zorra astuta fue publicada por primera vez en un formato muy cercano al de una tira cómica clásica. Años más tarde, este relato sería adaptado como ópera. En ese sentido, el trabajo de Richard puede verse -sin ser una adaptación directa-, como una suerte de regreso al origen en un nuevo medio: el webcomic.

► Según la entrada en Lambiek Comiclopedia, Stanislav Lolek fue un pintor, artista gráfico e ilustrador checo, mejor conocido por dibujar la historia ilustrada Liška Bystrouška (“Vixen Sharp-ears”) en 1920, publicada por entregas en el periódico Lidové noviny.

Los detalles

“El cómic se escaneó originalmente a partir de dibujos a lápiz y se presentó en formato .gif en escala de grises, adecuado para una época en la que el módem de acceso telefónico de 28,8 kbps era el método de conexión a internet predominante. Más tarde, comencé a colorear tiras entintadas y redibujé las primeras treinta aproximadamente para adaptarlas al nuevo formato y reflejar mi estilo en constante evolución.”, escribe Richard, al referirse al punto de partida técnico y estético de la tira cómica.

“Aquí hay algunos bocetos inéditos de Skippy. ¡Inéditos porque, como pueden ver, son bastante horribles! Son los primeros bocetos conceptuales del personaje que eventualmente se convertiría en Skippy Rabbit. Así que supongo que el 21 de diciembre de 1996 fue su cumpleaños, por si alguien quiere enviarle regalos.

Aunque bastante rudimentarios, creo que logran mostrar muy bien el origen de Skippy. Con el tiempo, el diseño se volvió mucho más expresivo, simplificado y refinado, y el personaje adquirió gradualmente su propia personalidad.”

► © Richard T. Matheson

A medida que la adopción de Internet crecía a finales de los años noventa, también aparecieron nuevos formatos y herramientas que habilitaron nuevas formas de compartir información. Esta evolución no fue ajena a Richard.

A partir del escaneo de sus dibujos a lápiz y su posterior procesamiento digital, las tiras comenzaron a ganar complejidad visual, llevándolo rápidamente a los límites técnicos de lo que podía representar. ¿El problema? La reducida paleta de colores del formato GIF, en el que publicó sus tiras hasta el 9 de octubre del año 2000. A partir de esa fecha comenzó a utilizar JPEG, y es ahí donde se percibe un cambio notable en la calidad de la obra.

► Esta tira es especial por marcar la transición de la presentación del webcómic en formato GIF a JPG. Para entonces, la complejidad del color era tal que JPEG se convirtió en la opción más efectiva. © Richard T. Matheson.

Con este nuevo formato, que le permitió disponer de una paleta de hasta 16 millones de colores, Richard fue capaz de desarrollar escenarios mucho más elaborados, incorporando elementos que parecen definir su impronta como artista. Colores vivos, paisajes con difuminados y un mayor nivel de detalle en la forma de pintar a los personajes, refuerzan los diálogos, dotando de más “vida” a toda la serie.

► Creo que "Don't Swallow the Black Ones" es la primera historia en la que podemos ver cómo el artista se escapa de los límites de las viñetas. Este “atrevimiento” en la composición es utilizado posteriormente con mayor frecuencia, lo que genera una sensación creciente de dinamismo. © Richard T. Matheson.

Las anotaciones

Un aspecto interesante que fue agregado posteriormente, son las observaciones o comentarios que el propio autor hace sobre algunas de las tiras. Estas notas suelen señalar detalles vinculados a decisiones narrativas concretas, como el remate de una historia o el uso de un personaje específico como contrapunto dentro de una escena.

También aparecen comentarios de carácter más personal, relacionados con el momento en que el episodio fue creado: recuerdos de su padre, menciones a su hermana —quien en algún momento le ofreció su feedback sobre la evolución del cómic— y otras observaciones que agregan contexto a la entrega.

► Este tipo de anotaciones permiten acercarse al proceso creativo del autor. © Richard T. Matheson

El diálogo

El sitio contaba con un foro, en donde Richard podía establecer un diálogo directo con sus lectores. Lamentablemente, ese foro fue dado de baja. Internet Archive —una vez más al rescate de la memoria— permite, al menos, obtener un pantallazo de algunos de los temas que se discutían en ese espacio.

► A juzgar por los últimos temas archivados, el spam en los foros parecía estar en pleno auge hacia 2010.

El dominio

Richard alojó su primer sitio en el proveedor canadiense telusplanet.net. La única referencia directa a ese período no proviene del propio autor, sino de Michael H. Payne, a quien mencioné anteriormente.

Payne señala que ya leía la serie cuando Matheson migró desde su antiguo servidor en telusplanet hacia purrsia.com, un cambio que sitúa alrededor de octubre de 1999. Y su sospecha es correcta.

Si observamos la tira "Sweet Revenge", fechada el 4 de octubre de 1999, se hace referencia explícita al dominio https://telusplanet.net/public/foxstar.

► "Sweet Revenge" publicada el 4 de octubre de 1999 en el dominio telusplanet.net. © Richard T. Matheson

En el episodio siguiente, correspondiente al 11 de octubre del mismo año, el sitio ya aparece alojado dentro de un directorio de purrsia: http://mynarskiforest.purrsia.com/xsl99_42.htm.

El sitio estaba "espejado", como forma de contar con una copia de respaldo:

“Por suerte, Jake McDermott de Skunked.com me ha informado que aún podrá alojar el Archivo Oficial de Tiras Vintage de Mynarski Forest. Entre Skunked y Purrsia, debería poder mantener cierta redundancia: si un sitio falla, ¡podrán encontrarme en el otro! También pueden consultar mi archivo de Yerf en http://www.yerf.com/mathrich/ para ver más material gráfico.”

► Yerf funcionó como un espacio de difusión para artistas y webcomics de la época.

El final

El 7 de septiembre de 2009, Richard publicó en su sitio lo siguiente:

“Estimados lectores:

Si están leyendo esto, saben que he decidido tomarme un descanso de medio año con la tira cómica y quizá les interese saber por qué.

Crear los cómics, aunque es muy gratificante, requiere una considerable inversión personal de tiempo y energía. Siempre ha sido así, por supuesto; sin embargo, en los últimos dos años he visto una mayor demanda de estos recursos en otras áreas de mi vida.

Como a mucha gente, la recesión ha afectado mis ahorros más de lo que me hubiera gustado, y he estado buscando un segundo trabajo durante el último año y medio para ponerme al día. No es un mal trabajo; sé que mucha gente ahora mismo ni siquiera puede encontrar uno, y mucho menos dos, así que no me quejo. Pero sí significa que entre los dos trabajos y la tira cómica he estado trabajando cerca de setenta horas a la semana, casi todas las semanas, durante los últimos dieciocho meses, y las grietas están empezando a notarse. Realmente necesito un respiro de la fecha límite semanal autoimpuesta, tiempo para relajarme, recargar las pilas y dedicarme a otros intereses por un tiempo. Cosas que me gustaría hacer... Pasar un par de fines de semana durmiendo hasta tarde sin tener que preocuparme por terminar nada... Ayudar a mi padre con algunos proyectos de la casa... Dedicar más tiempo a pasear a los perros; lo disfrutan y a todos nos viene bien el ejercicio... Experimentar con algunos programas de dibujo que he adquirido con los años, pero que no he tenido tiempo de aprender... Comprar una buena cámara y experimentar un poco con fotografía avanzada... Quizás hacer un poco de geocaching... Instalar algunos de los videojuegos que me regalaron las Navidades pasadas, pero que aún no he tenido tiempo de jugar... Pasar unas noches frías bajo las estrellas con el telescopio y un termo de chocolate caliente... Encontrar a una pelirroja guapa e invitarla a ver una o dos películas (¡incluso estaría dispuesta a renunciar al requisito de ser pelirroja a candidatas lo suficientemente guapas! ¡Escríbeme!)... :)

Suena muy divertido, pero poner la tira cómica en pausa ha sido una de las decisiones más difíciles que he tenido que tomar. Cuando inviertes tanto de ti mismo en una iniciativa creativa como Mynarski Forest durante tanto tiempo como yo, se convierte en parte de tu identidad. Dejarlo de lado, aunque sea temporalmente, es como renunciar a una parte de ti mismo; es casi como si se te hubiera muerto una mascota. Y luego está el sentido de obligación que siento hacia mis lectores. Soy muy consciente de lo valioso que es el tiempo de la gente hoy en día, incluso si solo hablamos de unos segundos para descargar y leer un cómic semanal. No tienes que volver aquí cada semana, así que que compartas un poco de tu tiempo conmigo y escuches lo que tengo que decir es un privilegio que no doy por sentado.

Sin embargo, cada vez soy más consciente de la necesidad de bajar un poco el ritmo y tomarme un tiempo personal. Espero volver, descansado y con ganas de ir, a principios de la próxima primavera, ¡y espero que vuelvas y me acompañes!”

Esos seis meses de pausa se convirtieron en diecisiete años de espera. El universo creado por Richard se detuvo, al menos, para nosotros. Quizás Liska, Skippy y los demás, siguieron con sus andanzas en la fecunda imaginación de su autor.

Quise contactar a Richard para preguntarle sobre algunos detalles técnicos relacionados con la creación de su sitio web y, de paso, hacerle la pregunta obvia: ¿vas a volver? El correo no rebotó, pero no obtuve respuesta. Era poco probable que respondiera, aunque a veces ocurren “milagros”, como el de John MacLeod.

Lo que importa es que, luego de casi dos décadas de haber dejado de publicar, aún tenemos la posibilidad de acceder al sitio Tails From the Mynarski Forest, que es mucho más que una web: son nueve años del trabajo de un artista; una ventana que nos permite asomarnos a su universo personal, creado y compartido a través de la red de redes. Quizás la ventana no se mantenga abierta por mucho tiempo, pero mientras tanto, disfrutemos de la vista que nos ofrece.

Gracias, Richard.

Imagen de portada basada en una fotografía del Monument of Bystrouška (ópera The Cunning Little Vixen, Leoš Janáček), Hukvaldy. Fotografía: Kazuo Ikeda. Licencia CC BY-SA 3.0 Unported.
Webcomic de © Richard T. Matheson. Reproducido parcialmente con fines de referencia y archivo.

Arqueología web

Publicado el 31 de enero 2026

El mito del SEO imprescindible

Tue, 13 Jan 2026 00:00:00 +0000

¿Qué tan firmes son muchas de las certezas que rodean al SEO?

Durante años se nos dijo que el search engine optimization era prácticamente una ciencia exacta. Que Google tenía reglas claras. Que habían “buenas prácticas” que, si se seguían con disciplina y sin chistar, volvían el contenido más relevante para el usuario garantizando miles de visitas.

Y sin embargo, existe Illinois Wildflowers.

Illinois Wildflowers (https://illinoiswildflowers.info/) es un sitio activo desde comienzos de los años 2000, con miles de páginas, ilustraciones, referencias académicas y descripciones detalladas de flora.

Si visitas el sitio, notarás enseguida que no estamos frente a un diseño web moderno y que, posiblemente, no hay un CMS detrás. No hay redes sociales integradas. No hay una estrategia de contenidos. No hay enfoque mobile-first. No hay titulares “SEO-amigables”.

Aun así, recibe más de 130.000 visitas orgánicas mensuales, se posiciona para decenas de miles de palabras clave, y acumula cientos de miles de enlaces entrantes. (Según datos de Ubersuggest).

► Datos de tráfico del sitio Illinois Wildflowers según Ubersuggest.

¿Qué nos dice esto sobre el SEO?

Un sitio que no “hace SEO”

Alguien podría objetar que “Ese sitio sí hace SEO. Solo que del bueno.”

Es una observación válida, dado que en Illinois Wildflowers encontramos títulos claros, contenido profundo, enlaces internos coherentes y HTML legible. Nada de eso contradice las bases del SEO técnico.

Pero el asunto es que muchas de esas “prácticas” existían antes de que el SEO se convirtiera en industria.

Escribir bien, describir con precisión, estructurar información compleja y enlazar con criterio, ciertamente no eran “estrategias de posicionamiento”.

Lo que hoy llamamos “SEO básico” es, en muchos casos, una apropiación posterior de hábitos editoriales que no nacieron para agradar a Google, sino, simplemente, para servir al lector.

¿Posiciona porque es viejo?

Alguien más podría decir: “El sitio funciona porque es antiguo. Google confía en él por el tiempo.”

El factor temporal existe, es cierto; negarlo sería ingenuo. Pero quizás la pregunta adecuada sería: ¿por qué tan pocos sitios logran perdurar?

Es importante mencionar que el ecosistema SEO moderno fomenta:

rediseños constantes
cambios de URL
reescrituras forzadas
optimización reactiva a cada actualización.

Todo eso genera desgaste. Ayuda a romper la continuidad cuando las cosas no funcionan y el único objetivo que se busca con esos cambios es agradar al algoritmo.

Entonces, quizá sea justo decir que Illinois Wildflowers no sobrevive porque sea viejo. Es viejo porque fue construido para no necesitar reescribirse cada cinco años.

Todo es cuestión del “nicho fácil”

“Botánica es un nicho educativo, sin competencia comercial real.”, puede argumentar un experto en posicionamiento web.

Es cierto que no compite por palabras clave millonarias. Pero eso no invalida el caso.

Illinois Wildflowers parece estar disponible desde al menos 2002, con capturas en Internet Archive que se remontan a enero de 2004. Esto implica que el sitio existía desde uno o dos años antes de que Google AdSense estuviera disponible como herramienta de monetización.

En ese contexto, resulta poco probable que el Dr. John Hilty haya creado el sitio con fines de monetización, aun cuando hoy el proyecto integre AdSense.

► ¿Cuántos sitios “optimizados” para SEO sobrevivirán veinte años?

Otra posible crítica a todo este argumento podría ser que “Al final, Google decide. Si cambia el algoritmo, el sitio cae.”

Sí, es verdad. Google controla la visibilidad dentro de su ecosistema, pero no controla el valor intrínseco de los sitios.

Digamos que de la noche a la mañana Illinois Wildflowers perdiera tráfico ¿qué pensas qué pasaría con el sitio? Te digo lo que creo: seguiría siendo útil, seguiría siendo citado y seguiría siendo archivado.

En la práctica, todo este discurso alrededor del algoritmo de Google termina tratando a la web como un simple canal de distribución y no como un archivo cultural.

Illinois Wildflowers hace exactamente lo contrario y, al hacerlo, demuestra que la narrativa según la cual los sitios sin SEO técnico, sin optimización constante y sin obediencia al algoritmo “no funcionan” es, como mínimo, incompleta.

¿Es el SEO totalmente innecesario? Probablemente no. Pero sí está claramente sobrevaluado.

¿Funciona mejor la web cuando se deja de intentar complacer a su supuesto dios? De eso no tengo dudas.

Misc

Publicado el 13 de enero 2026

John MacLeod y la continuidad del DIY en Internet.

Mon, 29 Dec 2025 00:00:00 +0000

¿Cuál es el punto de contacto entre un improbable superhéroe cuyo único poder es lavar los platos telequinéticamente y la web en ciernes de los 90? Bueno… ninguno, al menos de forma directa. Pero…

Dishman es, quizás, la creación más conocida del artista canadiense John MacLeod.

Dishman, cuyo título completo es The Mundane Adventures of Dishman, nació en 1985 como un minicómic autoeditado dentro del auge del small press comics de los años ochenta. La serie se publicó de manera independiente en formato de minicómic de ocho páginas, con diez números entre 1985 y 1990. Rápidamente se destacó dentro de ese circuito de creadores que producían, copiaban y distribuían sus propios cómics sin intermediarios.

► Dishman, publicado sin intermediarios y sostenido por una relación directa con sus lectores.

Este formato pequeño y artesanal contrastaba con la industria dominante de los cómics, donde las grandes editoriales controlaban todo el proceso —desde la producción hasta la distribución masiva en puestos de ventas—, priorizando historias de superhéroes comerciales. En cambio, Dishman mezclaba elementos de la cultura superheroica con una narrativa absurda, cotidiana, desde un lugar que no buscaba ajustarse a expectativas comerciales.

Del cómic independiente a la web hecha a mano

A finales de los años 90, la web era un territorio, podriamos decir, artesanal, en donde algunos creadores independientes encontraron en ella algo familiar, una continuidad de prácticas que ya conocían bien: la autoedición, la movida del hazlo tú mismo, la circulación directa.

Uno de los creadores que exploraron este nuevo medio de forma temprana, fue MacLeod, quién mantiene desde al menos 1998 un sitio web personal alojado en Sentex, bajo la dirección https://www.sentex.net/~sardine/.

► Un sitio sobrio, sin adornos, construido en HTML "puro", que hoy funciona como un registro de una web previa a las plataformas, los likes, los feeds y las métricas.

Cuando le pregunté por la motivación inicial para crear su página web, MacLeod reconoce que en su momento no lo pensó en términos teóricos, pero que con el tiempo el vínculo se volvió evidente:

«No estoy seguro de haberlo comprendido de forma consciente en ese momento, pero sí: era una extensión de la small press, de toda la mentalidad hazlo tú mismo.»

Una web experimental

Desde el punto de vista de un creador, la web de finales de los 90 tampoco era, digamos, un espacio plenamente dominado. MacLeod la recuerda como algo experimental:

«Supongo que se sentía más experimental, ya que en esas etapas tempranas no siempre me quedaba claro cómo podía hacer algo tan básico como subir una imagen.»

La web existía, sí, pero tenía una curva de aprendizaje que exigía paciencia y, en algunos casos, presupuesto ($$), del mismo modo que el small press había dependido históricamente de fotocopiadoras, grapas y redes informales de distribución:

«En ese momento, un escáner no era asequible para un usuario doméstico básico.»

Esa materialidad también se reflejaba en las herramientas. El sitio fue construido directamente en HTML, sin capas de abstracción, framworks, ni editores visuales:

«Empecé con MS Notepad; pronto pasé a NoteTab (básicamente, el Bloc de notas con esteroides) y, después de un par de años, descubrí Arachnophilia.»

► Editor HTML Arachnophilia, una de las herramientas populares de finales de los 90 para escribir HTML a mano, con atajos que facilitaban el marcado sin ocultar el código.

Y, como él mismo subraya:

«En todos los casos trabajaba directamente, con las manos en el código HTML en bruto.»

La web como zine permanente

En su antiguo sitio, MacLeod dedica una sección especifica al small press, y al preguntarle si veía la web como una extensión digital de esa filosofía, la conexión con el presente resulta inmediata:

«Sí, y creo que todavía lo es. Hoy, cualquiera que se tome el trabajo de publicar su propio blog, ya sea en WordPress o en la plataforma que sea, básicamente está publicando un fanzine.»

Webrings y comunidad distribuida

El sitio también formó parte del Cartoonists Ring, una de las estructuras comunitarias típicas de la web temprana. Sin idealizarla, MacLeod es honesto y reconoce que no fue especialmente constante en su participación:

«Mirándolo en retrospectiva, no mucho, en realidad. No creo que haya sido lo suficientemente diligente a la hora de participar o de tejer redes como para aprovechar realmente ese recurso.»

► Cartoonists Ring fue uno de los tantos web ring que existieron a finales de los 90. Una red de sitios enlazados entre sí, creada para facilitar el descubrimiento y la circulación entre páginas afines antes de los buscadores masivos y las redes sociales.

Que el sitio siga en línea hoy en día no es, en el caso de MacLeod, una estrategia consciente de preservación:

«Sigo teniendo el control porque Sentex sigue siendo mi proveedor de Internet.»

En los años 90, algunos ISPs incluían alojamiento web como parte del servicio:

«El alojamiento web básico venía incluido en su plan.»

La permanencia se sostiene en la estabilidad y la confianza:

«Soy el tipo de persona a la que le gusta quedarse con lo que ya conoce.»

Tampoco hubo una planificación explícita sobre la longevidad del sitio:

«Esperaba que estuviera disponible durante un tiempo, quizá algunos años, pero no me preocupaba demasiado por ese aspecto.»

Desde la mirada actual, su postura sobre la conservación es bastante clara:

«Siento que todo merece ser preservado. Supongo que es porque me interesa más la historia que a mucha otra gente. Cuando veo que alguien publica un libro recopilatorio de una tira o una serie de cómics antiguos, siempre me parece algo fantástico; incluso más cuando se trata de una obra que no es especialmente popular, porque le da más posibilidades de ser descubierta.»

Y todavía funciona…

Las preguntas a MacLeod las envié originalmente a la dirección de contacto que figura en su sitio actual: hello@jdmacleod.com. Ese correo rebotó. Sin demasiadas esperanzas de obtener una respuesta, opté por escribirle a la dirección que aparece en el index de su página “vieja”: sardine@sentex.net. Un correo que, muy probablemente, existe desde hace casi 30 años. Para mi sorpresa —y sin poder pedir un mejor cierre para esta historia—, funcionó.

Arqueología web

Publicado el 29 de diciembre 2025

Yutaka Saito y la búsqueda de una nueva gramática para la iteración

Wed, 05 Nov 2025 00:00:00 +0000

Como un calígrafo del código, Saito trazó en Gura una filosofía de la repetición y la simplicidad.

"El deseo de crear esas reglas a gusto propio crece y se convierte en la motivación para el desarrollo."

Esta frase de Yutaka Saito, creador del lenguaje Gura (http://www.gura-lang.org/), condensa la esencia de lo que muchos desarrolladores independientes sienten al crear un lenguaje propio. No se trata de competir con Python, Java o C++, sino de construir una herramienta que refleje su modo de pensar, su manera particular de procesar las operaciones mentales ¿Y no es acaso esa la definición de una herramienta? Una extensión hecha a medida, personalizada para realizar una determinada tarea.

En el caso de Gura, Saito buscaba principalmente una forma más natural de expresar la iteración, elemento central en las tareas de procesamiento de datos.

A través de Gura, vemos cómo una motivación profundamente personal —deseo de control, curiosidad técnica, y la búsqueda de la simplicidad en la expresión de procesos— puede dar lugar a un lenguaje capaz de conceptos avanzados como Implicit Mapping y Member Mapping.

► Yutaka Saito, creador de los lenguajes de programación Gura y su sucesor Gurax.

Iteración como eje central

No son pocas las ocasiones en que programando, necesitamos aplicar una operación o transformación a múltiples datos almacenados en listas, para luego generar otra lista con los resultados. En la mayoría de los lenguajes tradicionales, esto se hace con bucles explícitos (for, while, do-loop, etc.) o, si se trabaja en un lenguaje funcional, con funciones de orden superior que aplican la operación a cada elemento de la lista.

En Gura, este enfoque se simplifica gracias al Implicit Mapping. Cuando una función que normalmente toma un solo argumento y devuelve un resultado recibe una lista o un iterador como entrada, automáticamente devuelve una lista de resultados, sin necesidad de escribir bucles explícitos.

En el siguiente ejemplo, podemos ver cómo la lista se procesa automáticamente, sin necesidad de for ni map explícito. Esto funciona para números, strings, objetos y otros tipos de datos:

import(math)
numbers = [4, 9, 16, 25]
roots = math.sqrt(numbers)  
println(roots)  // Salida: [2, 3, 4, 5]

Gura vectoriza operaciones, aplicando funciones y operadores automáticamente a cada elemento de la lista sin necesidad de bucles explícitos.

import(math)
a = [1, 2, 3]
b = [4, 5, 6]
sum_list = a + b         
squares = math.sqrt(a)    
ceil_sum = math.ceil(a + b)
println(sum_list)   // [5, 7, 9]
println(squares)    // [1, 1.4142..., 1.732...]
println(ceil_sum)   // [5, 7, 9]

Alguien podría argumentar que este tipo de operaciones vectorizadas también pueden realizarse en otros lenguajes de programación, con o sin ayuda de librerías. Es cierto. Pero en Gura, el valor agregado radica en cómo incorpora la vectorización de forma nativa, universal y automática, sin necesidad de librerías externas ni sintaxis especial, y además la extiende a varios tipos de datos. Veamos algunos ejemplos.

Implicit Mapping integrado

En Gura, cualquier función o operador que tenga el atributo :map puede trabajar automáticamente con listas, iteradores o valores escalares sin cambiar nada en la sintaxis:

f(x:number):map = x*x
f([2,3,4])  // [4, 9, 16]

No hace falta declarar arrays especiales ni usar funciones externas. Funciona incluso con iteradores, evitando consumo de memoria innecesario.

Compatibilidad con múltiples tipos de datos

Implicit Mapping no está limitado a números; funciona con strings, booleanos, listas, objetos. Por ejemplo, puedes transformar todos los strings de una lista a mayúsculas con la misma sintaxis que un valor único:

strs = ['hello', 'world']
strs_upper = strs::upper()  // ['HELLO', 'WORLD']

Operaciones compuestas y vectorización de operadores

No solo funciones: los operadores aritméticos y lógicos también se vectorizan automáticamente. No se necesita llamar a una función de map explícita como en otros lenguajes.

[1, 2, 3] + 10  // [11, 12, 13]
[1, 2, 3] * [2, 3, 4]  // [2, 6, 12]

Member Mapping

Permite aplicar métodos de objetos sobre listas de manera directa con :: o :*:

['cat', 'lion']::len()  // [3, 4]

Esto combina la orientación a objetos con la vectorización, algo que pocos lenguajes logran sin librerías adicionales.

► Gura incluye un modo interactivo, un entorno REPL (Read–Eval–Print Loop) que permite escribir y ejecutar código en tiempo real. Este modo es ideal para probar expresiones, funciones y estructuras del lenguaje de manera inmediata.

Un lenguaje con ambición universal

Uno podría pensar que Gura, con su enfoque introspectivo y su sintaxis minimalista, sería un lenguaje de nicho. Pero Saito nunca lo concibió así. Desde sus primeras versiones, se propuso que fuera multipropósito, capaz de escribir desde pequeños scripts hasta herramientas gráficas o programas científicos.

Para lograrlo, desarrolló —en solitario— una biblioteca estándar sorprendentemente amplia, organizada en decenas de módulos. Cada uno amplía el alcance del lenguaje hacia áreas específicas: desde el manejo de archivos hasta el procesamiento de imágenes, redes, compresión, sqlite, entre otras utilidades.

Esa amplitud no es común en los lenguajes personales. Mientras muchos proyectos similares quedan en la etapa de “prueba de concepto”, Gura avanza hacia un terreno más pragmático; quiere ser usable, no sólo interesante.

► Diversas aplicaciones creadas con Gura, que van desde herramientas gráficas hasta utilidades científicas, reflejan la versatilidad y alcance práctico del lenguaje diseñado por Yutaka Saito.

El gran desconocido

A pesar de su madurez técnica y la amplitud de módulos disponibles, Gura sigue siendo un lenguaje poco conocido fuera de ciertos círculos experimentales. El propio Saito reconoce esta realidad con una mezcla de resignación y pragmatismo. Desarrollar un lenguaje de programación no garantiza su adopción. Podría mencionar cientos de ejemplos similares, donde la genialidad técnica no siempre va acompañada de visibilidad.

En parte, la baja adopción de Gura podría explicarse por factores estructurales, como ser la falta de una comunidad activa, lo que genera una notoria ausencia de proyectos desarrollados en ese lenguaje.

Saito intentó romper ese aislamiento a través de la creación de aplicaciones prácticas. Una de las más destacadas fue Gura Shot, un programa para manipular fotografías de identificación que llegó a tener cierta repercusión entre los usuarios japoneses por su utilidad.

► Gura Shot permite crear fácilmente fotografías de identificación del tamaño requerido a partir de imágenes de cámaras digitales.

Sin embargo, incluso con este tipo de esfuerzos, el lenguaje permaneció en una especie de periferia tecnológica, admirado por quienes lo descubren, pero, aún, invisible para la mayoría.

Pero quizás también hay un componente más humano y filosófico detrás la invisibilidad del lenguaje. Y es que Gura no fue diseñado con la clara intención de convertirse en un producto masivo, sino en una herramienta personal, una extensión del pensamiento de su creador. Y ese tipo de proyectos —por definición— no siempre buscan “conquistar el mundo”, sino expresar una visión particular de cómo debería ser la programación.

La entrevista

Luego de haber usado el lenguaje durante un tiempo, sentí la necesidad de entrevistar a su artífice, Yutaka Saito. Quería preguntarle por los aspectos que hacen de Gura un lenguaje tan singular: su marcado —casi obsesivo— enfoque en la iteración, y en qué escenarios cree que este paradigma puede resultar verdaderamente útil.

También me interesaba explorar la dimensión humana que implica desarrollar un lenguaje de programación desde cero: los desafíos, la motivación para continuar y el propósito final detrás del proyecto.

Saito fue muy amable y abierto al responder todas mis preguntas. Sus respuestas me permitieron comprender aspectos que no se pueden captar a través de los manuales técnicos.

Gracias, Saito, por tu tiempo.

¿Qué te motivó inicialmente a crear Gura-lang? ¿Estabas tratando de resolver un problema específico o explorando una nueva idea en el diseño de lenguajes?

La motivación inicial surgió de mi intento por crear una aplicación para graficar funciones. Estaba familiarizado con software bien conocido como gnuplot, pero quería una herramienta que pudiera realizar operaciones como la diferenciación directamente dentro del formato de una expresión matemática. Imaginaba un lenguaje de scripting simple, capaz de definir funciones y manejar variables. En ese momento, pensaba en algo como definir una ecuación y = sin(x) y graficarla.

El programa podría generar internamente valores numéricos para x dentro de un rango e intervalo adecuados, calcular y y luego graficar los resultados. Pero me di cuenta de que la versatilidad del lenguaje aumentaría enormemente si el argumento x pudiera aceptar múltiples valores (por ejemplo, un arreglo) y devolver también los resultados como un arreglo.

Ese concepto fue el punto de partida de lo que luego llamé Implicit Mapping.

Gura-lang se describe como un lenguaje orientado a la iteración. ¿Podrías explicar por qué consideras que la iteración es un concepto tan central?

Para procesar una colección de datos —ya sean números, cadenas o datos estructurados— muchos lenguajes abordan la tarea de forma algorítmica, utilizando construcciones como for o while.

Sin embargo, al representar una colección de datos como una estructura de tipo iterador, este procesamiento repetitivo puede expresarse de una manera mucho más simple. Creo que esa simplicidad resulta sumamente efectiva en enfoques modernos como el aprendizaje automático.

Cuando se alimentan grandes volúmenes de datos a una computadora en un formato adecuado para el objetivo de aprendizaje, usar iteradores permite una implementación mucho más eficiente y limpia de todo el proceso.

Cuando comenzaste a desarrollar Gura-lang, ¿eras consciente de que ideas similares habían aparecido en lenguajes como Icon o APL? ¿Cómo ves el lugar de Gura en ese linaje?

Cuando comencé a desarrollar Gura, sabía muy poco sobre lenguajes de programación más allá de los diez aproximadamente más conocidos. Fue cerca de un año después del inicio del desarrollo cuando me di cuenta de que existían enfoques similares —procesar colecciones de datos como listas y arreglos en bloque— en lenguajes como Icon o APL.

Por lo tanto, las ideas que en Gura denominamos “Implicit Mapping” y “Member Mapping” eran, en mi mente, completamente originales y no provenían de ninguna línea de herencia previa.

En cuanto a la sintaxis del lenguaje, tenía presente TypeScript, ya que su sintaxis es similar a la de C++, que utilizo a diario, y me resultaba muy familiar. También tomé inspiración de Python, especialmente en el diseño de las funciones integradas y las bibliotecas estándar.

En un principio, consideré implementar características como Implicit Mapping extendiendo lenguajes ya existentes, lo que me habría permitido aprovechar sus bibliotecas. Sin embargo, pronto comprendí que esta característica afecta al núcleo mismo de las llamadas a funciones, y que solo podía lograrse diseñando el lenguaje desde cero. Anticipaba el enorme esfuerzo que ello implicaba, pero el deseo de concretar mi idea única y el simple interés por crear un nuevo lenguaje me impulsaron a iniciar el desarrollo.

Gura-lang admite Implicit Mapping y Member Mapping. ¿Podrías explicar cómo estos mecanismos de mapeo (implícito y de miembro) afectan el rendimiento, el uso de memoria o la legibilidad en comparación con los bucles explícitos o las comprensiones en otros lenguajes?

El uso de estas características gestiona automáticamente el procesamiento repetitivo durante las llamadas normales a funciones y el uso de operadores, eliminando la necesidad de construcciones explícitas como los bucles for. Esto ofrece una ventaja significativa en términos de legibilidad y concisión.

Otro punto clave es que el procesamiento iterativo está encapsulado dentro de la estructura de datos del iterador. Con el procesamiento mediante bucles explícitos (usando for, etc.), a menudo resulta difícil determinar si el proceso introduce efectos secundarios externos o si está influido por factores externos. Sin embargo, al adoptar la forma de un iterador, la relación entre el procesamiento interno del iterador y el procesamiento externo se define con claridad. Si el procesamiento dentro del iterador está aislado (por ejemplo, genera resultados a partir de un flujo de datos fijo sin dependencias externas), se vuelve apto para el procesamiento en paralelo, lo que puede contribuir significativamente al rendimiento.

En cuanto a la eficiencia de memoria, no creo que esta característica, por sí sola, garantice necesariamente una mejora. Dependiendo del tipo de procesamiento, la necesidad de almacenar en memoria los datos generados por la iteración podría, de hecho, aumentar el consumo. Sin embargo, observando el entorno actual del hardware —donde las velocidades de CPU están alcanzando sus límites, mientras que la capacidad de memoria disponible aumenta drásticamente—, creo que el enfoque de aprovechar grandes cantidades de memoria para mejorar el rendimiento seguirá evolucionando y cobrará cada vez más relevancia.

Casi una década después, la computación paralela y concurrente se ha vuelto mucho más accesible, incluso en entornos de scripting. ¿Cómo ves esta evolución hoy en día, y crees que lenguajes como Gura-lang (o Gurax) siguen bien posicionados para aprovechar este paradigma?

Como mencionas, los intentos de mejorar el rendimiento mediante la paralelización —ya sea con GPU o con computación cuántica— están en pleno auge. Sin embargo, en la mayoría de los lenguajes, los programadores logran la programación paralela creando explícitamente múltiples hilos de ejecución. Ejecutar varios hilos requiere gestionar la competencia por los recursos, lo que vuelve el programa excesivamente complejo. Esto es, francamente, absurdo: la mayoría de los programadores no están interesados en ejecutar programas en paralelo per se, sino simplemente en aumentar el rendimiento de ejecución. El escenario ideal sería poder usar el mismo enfoque de programación de siempre, con la paralelización del proceso completamente oculta al programador.

Implicit Mapping podría ser una solución a este desafío. Al representar los datos como un iterador y aplicar Implicit Mapping, la operación parece ser una llamada de función o una operación aritmética normal, pero el script podría decidir automáticamente procesarla en segundo plano. Es decir, generar múltiples iteradores conduciría automáticamente al procesamiento en paralelo.

Sin embargo, personalmente tengo muy poco conocimiento sobre procesamiento paralelo. Además, su implementación sería increíblemente difícil, probablemente más allá de lo que una sola persona puede lograr. Por lo tanto, lo que he descrito hasta ahora sigue siendo un sueño. Aun así, a menudo me impulsa con fuerza el deseo de hacerlo realidad.

¿Has considerado extender Gura-lang (o Gurax) para interactuar con otros ecosistemas (por ejemplo, integrarlo como lenguaje de scripting dentro de otras aplicaciones, al estilo de Lua)?

Dado que inicialmente lo desarrollé como un lenguaje de scripting para una aplicación de dibujo de gráficos, siempre he tenido en mente la posibilidad de integrarlo en otras aplicaciones. Anteriormente trabajé en una empresa de diseño de hardware, donde creé una herramienta para representar formas de onda de señales digitales. Incrusté Gura en ese programa para automatizar el dibujo de patrones de pulsos mediante scripts, y funcionó muy bien. Ese proceso de desarrollo me dio confianza en la utilidad de Gura para ser embebido en aplicaciones.

También estoy considerando su aplicación en microcontroladores de placa única. Actualmente estoy desarrollando una plataforma llamada pico-jxgLABO, que conecta diversos componentes de hardware a una Raspberry Pi Pico. Con frecuencia se necesita un lenguaje de scripting que permita controlar fácilmente el hardware.

El analizador (parser) de Gura es muy simple, y como lo construí yo mismo, entiendo todos los detalles de su procesamiento. Si la parte de gestión de memoria pudiera adaptarse a un microcontrolador, sería posible crear una versión MicroGura, similar a MicroPython para microcontroladores.

Más adelante comenzaste a trabajar en Gurax. ¿Es un sucesor de Gura-lang o una reconstrucción completa? ¿Cuáles son las principales diferencias entre ambos?

Sí, Gurax es el sucesor de Gura.

Gura ejecuta los programas en forma de árbol de sintaxis. Aunque esto resulta fácil de implementar, es difícil lograr un alto rendimiento de ejecución. Otro problema era que el contexto de ejecución estaba ligado a C++. Por ejemplo, una llamada a función dentro de un programa escrito en Gura utilizaba internamente el mecanismo de llamadas a funciones de C++. Esto consumía rápidamente el área limitada de memoria de pila asignada por el compilador de C++, lo que provocaba desbordamientos de pila (stack overflow) durante llamadas recursivas.

Gurax resolvió este problema mediante la implementación de una máquina virtual (VM) dedicada que ejecuta códigos de instrucción personalizados. Preparé instrucciones para la gestión de datos, operaciones aritméticas, bifurcaciones y saltos de programa, y ahora los scripts se compilan en una secuencia de estas instrucciones. Esto mejoró el rendimiento aproximadamente al doble en comparación con Gura. Pero lo que más me alegró fue que las llamadas recursivas ya no provocan desbordamientos de pila. Dado que el mecanismo de llamadas a función se gestiona dentro de la VM, la administración de la pila también es independiente, y finalmente me sentí liberado de las limitaciones de C++.

Aunque Gurax es el sucesor de Gura, prácticamente fue reconstruido desde cero. El desarrollo de Gura implicaba agregar características sobre código existente, lo que derivó en muchas implementaciones ineficientes. Durante el rediseño, también cambié la convención de nombres de las API proporcionadas por el lenguaje, pasando de snake_case a camelCase. Gura estaba fuertemente influenciado por Python, y su estilo de nombres seguía ese patrón. El uso de snake_case se debía a esa influencia, pero como en mi trabajo diario utilizo camelCase, el cambio respondió simplemente a ser fiel a mi propia preferencia.

¿Has visto a otras personas o proyectos utilizar Gura-lang fuera de tus propias herramientas, como Gura Shot o Getter Photo?

No he oído hablar de nadie más que haya creado programas con Gura. Eso es bastante decepcionante.

¡Sí, Gura Shot! Me alegra mucho que lo menciones. Gura Shot fue una aplicación creada para demostrar que el lenguaje Gura podía utilizarse en proyectos prácticos, y también esperaba que sirviera para dar a conocer el lenguaje de programación Gura a más personas.

Gura Shot apareció en un importante sitio japonés de software libre y se convirtió en un éxito popular, utilizado por muchos usuarios. También fue mencionado en diversas revistas de software libre, y creo que el número de descargas fue bastante alto. No he comprobado las cifras exactas, por lo que no puedo dar números concretos.

Sin embargo, a pesar de la popularidad de la aplicación, nadie mostró interés en el lenguaje de scripting que la impulsaba. El programa de Gura Shot se distribuía como archivos de texto plano escritos en Gura, lo que significa que podía leerse completamente con un editor de texto. Pero, al tratarse de una aplicación, es natural que la mayoría de las personas simplemente la usaran por su funcionalidad, sin preocuparse por cómo estaba hecha.

Aunque no se logró el objetivo de dar visibilidad al lenguaje, el hecho de que la aplicación haya sido ampliamente aceptada demostró que el lenguaje Gura posee la versatilidad necesaria para sostener programas de ese tipo. Ese resultado, en sí mismo, fue suficientemente satisfactorio.

Desarrollar un lenguaje de programación en solitario es un proceso largo y complejo. ¿Qué te motiva a continuar por ese camino?

Cualquiera que programe como aficionado probablemente sienta interés en desarrollar un lenguaje de programación o un sistema operativo. Ambos son herramientas que facilitan enormemente la actividad de programar, pero, a cambio, el programador debe ajustarse a las reglas que estos imponen. Con el tiempo, surge el deseo de crear esas reglas a gusto propio, y ese deseo se convierte en la principal motivación para el desarrollo.

Sin embargo, aunque suelo ver artículos y blogs sobre lenguajes de programación creados por una sola persona, la mayoría permanecen en un estado experimental, realizando únicamente procesamiento muy básico. Una vez que se construyen las partes esenciales —como el parser, la generación de instrucciones y la gestión de datos—, la necesidad de “crear un lenguaje” suele quedar satisfecha, lo que hace que muchos proyectos no avancen más. Pero yo no quería que mi lenguaje fuera así.

Creo que un lenguaje de programación es un medio para resolver problemas, y que, a menos que alcance un nivel donde pueda resolver problemas del mundo real, no puede considerarse un verdadero lenguaje de programación.

Para lograrlo, debo desarrollar bibliotecas para el procesamiento en red (HTTP, Sockets), el procesamiento de datos de texto (expresiones regulares, YAML, XML, JSON), el procesamiento de imágenes (JPEG, PNG) y el procesamiento interactivo con el usuario (GUI). Es un proceso muy laborioso y que consume mucho tiempo.

Aun así, disfruto profundamente crear estos componentes. Me resulta estimulante ver cómo las capacidades de mi lenguaje crecen con cada avance. Creo que lo que me impulsa es precisamente el placer de saber que, usando mis propias manos y mi mente, puedo seguir aumentando mis propias creaciones.

Por último, ¿qué te gustaría que ocurriera con Gura-lang (o Gurax) en el futuro?

Como todo ha estado impulsado únicamente por mi interés personal, sinceramente no tengo una visión rígida para el futuro. El deseo de que otras personas lo utilicen ya no es tan fuerte como antes; llegué a pensar que estaría bien si solo yo pudiera usarlo de manera conveniente. Los lenguajes de scripting son muy útiles para el procesamiento rápido de datos, y utilizo Gurax, el sucesor de Gura, a diario en mi trabajo personal. Por lo tanto, si necesito alguna funcionalidad para mis tareas, simplemente mejoro el lenguaje según sea necesario... ¡Qué mentalidad tan modesta y autosuficiente!

Sin embargo, esa era mi postura hasta ayer. A través de esta entrevista, mi forma de pensar cambió. Aprendí que, incluso sin una promoción activa, hay personas como tú que muestran interés. Imaginar que podría haber otros que encuentren este proyecto interesante marca una gran diferencia en mi perspectiva. Aplicaciones como el cómputo paralelo, que serían difíciles de lograr solo con mis propios medios, podrían incluso hacerse realidad.

Por eso, me gustaría seguir desarrollando Gurax manteniéndome abierto a las contribuciones de otros. Si alguien estuviera interesado en participar en el desarrollo, me encantaría colaborar.

Entrevistas

Publicado el 5 de noviembre 2025

Entre madera, GIFs y un taller digital eterno

Sun, 02 Nov 2025 00:00:00 +0000

Mientras las olas de la modernidad arrasan con las modas tecnológicas, en un rincón de Azumino, Japón, vive un artista cuyo sitio web, como un bonsái cuidado con paciencia, crece de forma mínima, casi imperceptible, pero que se mantiene con vida.

Vivo en la ciudad. En una capital. Llena de todo eso que ya sabemos abunda en esos lugares. De vez en cuando me gusta visitar pueblos pequeños; en cierto modo, son rincones en donde aún hay espacio para detenerse a oler las flores a un lado del camino. En internet me pasa lo mismo.

Si buscamos en el lugar correcto, podemos encontrar pequeños talleres digitales escondidos entre los pliegues de la red.

En estos lugares no aplican las reglas del SEO, los embudos de venta ni los call to action. Son sitios que existen, como un cuaderno de bocetos o un atelier, para mostrar lo que una persona hace con sus manos.

Uno de esos lugares es Woodpecker Studio, el sitio del artista japonés Kazuhiko Kikuchi, en línea de forma ininterrumpida desde hace más de dos décadas: https://www.ne.jp/asahi/kitutuki/kobo/index.html

► Fotografía de Woodpecker Studio: una pequeña cabaña que oficia de galería y taller, enclavado en el bosque de Azumino, Japón, donde los visitantes pueden ver y adquirir tallados de animales en madera, papercraft y otras obras artesanales, e incluso probar a hacer ellos mismos marcadores de libros.

El artesano

Creado en el año 2000, el sitio nació con el propósito de compartir sus xilografías y tallados en madera. Nada más. Nada menos.

Kikuchi sube cada archivo manualmente, escribe todas las etiquetas HTML a mano, y mantiene el contenido con la misma paciencia con que trabaja la madera.

Su web no intenta escalar ni captar clics. No busca arrastrar a un “cliente” a un embudo; se mantiene como un taller abierto, donde el visitante puede entrar, mirar y salir sin ser perseguido.

“El diseño del sitio web se basa en mis preferencias personales, y traté de mantenerlo lo más simple posible. Al mismo tiempo, este diseño también se debe a las limitaciones técnicas de la época en que creé el sitio web, en 2000, y a mis propias limitaciones técnicas. En ese momento, apenas había comenzado a estudiar tecnología web y no conocía métodos avanzados de expresión”, me explica Kikuchi en su correo.

“El sitio web está básicamente creado con tecnología de hace unos 20 años. Creo que está bien dejarlo tal como está, como un artefacto histórico. Sin embargo, me gustaría incorporar técnicas de expresión adaptadas a las pequeñas pantallas de los smartphones y el uso de videos dentro de las nuevas tecnologías.”, me contó Kikuchi.

El código de su sitio revela cómo conserva la estética de la web de principios de los 2000: el uso de tablas para la maquetación, etiquetas HTML hoy en desuso pero aún soportadas por los navegadores por compatibilidad, y una estructura hecha a mano sin frameworks ni hojas de estilo externas.

El siguiente fragmento de código pertenece a una de sus páginas principales:

<TABLE border="0" cellpadding="2" cellspacing="4" bordercolorlight="#deb887" bordercolordark="#8b4513">

<TR valign="middle" align="right">
<TD bgcolor="#ffe599" width="320">
<A href="../1anm/e-1anm.html">
<FONT size="4"><B>GIF ANIMATION</B></FONT>
<IMG align="middle" width="32" height="32" alt="Weasel" src="../1anm/133ok/okojyo2-bay.gif" border="0" hspace="8" vspace="2"></A><BR>
<DIV align="center">Animals, Birds, Flowers</DIV></TD></TR>

<TR valign="middle" align="left">
<TD bgcolor="#ffebcd">
<A href="../11ysi/e-sakuhin10.html">
<IMG align="middle" width="32" height="32" alt="Waremokou" src="../11ysi/104g/simarisu2-r.gif" border="0" hspace="8" vspace="2">
<FONT size="4"><B>JAPANESE WILD ANIMALS</B></FONT></A><BR>
<DIV align="center">Japanese animal illustrated guide</DIV></TD></TR>

<TR valign="middle" align="right">
<TD bgcolor="#ffe599">
<A href="../13hn/e-hana.html">
<FONT size="4"><B>FLOWER ICON</B></FONT>
<IMG align="middle" width="32" height="32" alt="Kisuge" src="../13hn/12hr/kisuge.gif" border="0" hspace="8" vspace="2"></A><BR>
<DIV align="center">Flowers of a field</DIV></TD></TR>

<TR valign="middle" align="left">
<TD bgcolor="#ffebcd">
<A href="../12okk/e-okkake.html">
<IMG align="middle" width="32" height="32" alt="Seal" src="../12okk/ok/azarasi.gif" border="0" hspace="8" vspace="2">
<FONT size="4"><B>RUNNING ANIMAL</B></FONT>
</A><BR>
<DIV align="center">Please play with Mouse</DIV></TD></TR>

<TR valign="middle" align="right">
<TD bgcolor="#ffe599">
<A href="../2hng/e-sakuhin2.html">
<FONT size="4"><B>WOODCUT PRINT</B></FONT>
<IMG align="middle" width="48" height="38" alt="Long-tailed tit" src="tp/enaga.jpg" border="0" hspace="8" vspace="2"></A><BR>
<DIV align="center">Woodcut print and Paper-cutting</DIV></TD></TR>

<TR valign="middle" align="left
">
<TD bgcolor="#ffebcd">
<A href="../3kmk/e-sakuhin3.html">
<IMG align="middle" width="48" height="38" alt="bear" src="tp/kuma.jpg" border="0" hspace="8" vspace="2">
<FONT size="4"><B>WOOD CARVING</B></FONT></A><BR>
<DIV align="center">Animal pair and family</TD></TR>

<TR valign="middle" align="right">
<TD bgcolor="#ffe599">
<A href="../4ppk/e-sakuhin4.html">
<FONT size="4"><B>PAPERCRAFT</B></FONT>
<IMG align="middle" width="48" height="38" alt="cat card" src="tp/neko.jpg" border="0" hspace="8" vspace="2"></A><BR>
<DIV align="center">Animal pop up card</DIV></TD></TR>

<TR valign="middle" align="left">
<TD bgcolor="#ffebcd">
<A href="../5grc/e-sakuhin5.html">
<IMG align="middle" width="48" height="38" alt="pengin" src="tp/pengin.gif" border="0" hspace="8" vspace="2">
<FONT size="4"><B>ILLUSTRATION</B></FONT></A><BR>
<DIV align="center">Animal picture postcard</DIV></TD></TR>

</TABLE>

Los detalles

En el pie del sitio encontramos un simpático detalle: un pequeño GIF animado de un pájaro llevando un sobre en el pico marca el enlace a la dirección de correo de Kikuchi.

► El sitio está lleno de detalles como este; cada pequeño elemento refleja la atención y la paciencia que definen su oficio.

► Kikuchi nos muestra que la web, como la madera, se puede tallar. Se puede lijar, perfeccionar y dejar reposar.

Entre lo físico y lo digital

Durante la creación del sitio web, Kikuchi comenzó a experimentar con animaciones GIF. Inicialmente las imaginó como simples accesorios para presentar sus obras, pero el propio proceso lo cautivó. Ver cómo sus dibujos cobran vida resultó tan fascinante que terminó creando cientos de ellos: “Las animaciones se crearon de manera experimental mientras aprendía la tecnología de animación GIF durante el proceso de creación del sitio web. Al principio pensé en usarlas como accesorios para presentar mis obras, pero después de crearlas, me resultó tan interesante que terminé haciendo una gran cantidad de ellas. Es muy interesante ver cómo se mueven los dibujos que hice”.

Con el tiempo, sus experimentos se convirtieron en un pequeño mundo animado propio: pájaros carpinteros picoteando, hámsters girando, nutrias marinas flotando, pingüinos tambaleándose, flores meciéndose. Colecciones como Animal Family, Botanical Garden y Running Animal capturan la misma ternura y atención a la vida que se encuentra en sus tallados —solo que ahora, en píxeles.

► Kikuchi generó una especie de forma de arte híbrido, donde la línea tallada en madera encontraba eco en los píxeles animados.

Sus GIFs se hicieron populares en otros sitios web, usados libremente con su permiso. Pero con el tiempo, los agradecimientos que solía recibir por correo electrónico dejaron de llegar. La cultura de la web había cambiado…

“He anunciado que las animaciones GIF pueden usarse libremente con fines no comerciales. Creo que bastantes personas las están utilizando en sus sitios web.La forma en que se usan ha cambiado significativamente con el tiempo. Entre 2000 y 2015, muchas personas pedían permiso para usarlas por correo electrónico y luego agradecían tras utilizarlas. Sin embargo, desde alrededor de 2015, la gente las ha estado usando sin pedir permiso y sin informar que las han utilizado. Como he anunciado que se pueden usar libremente, eso está bien, pero creo que este cambio está relacionado con la mayor difusión de los teléfonos móviles y los smartphones. Recibir comentarios y retroalimentación de los visitantes era muy gratificante para el creador, y es triste que se hayan vuelto menos frecuentes”, reflexiona en su correo.

La fauna japonesa a través del lente de Kikuchi

Una de las secciones más notables del sitio web de Kikuchi es la lista completa de animales salvajes japoneses, una guía ilustrada meticulosa de la fauna nativa del país.

A través de dibujos y animaciones GIF, representa a cada animal con el cuidado de un naturalista y la sensibilidad de un artista. Cada categoría comienza con referencias a los libros y guías de campo que utilizó como fuentes, combinando documentación e imaginación en un archivo personal y único de la vida silvestre de Japón.

► Cada ilustración —algunas estáticas, otras animadas— refleja su dedicación a documentar la fauna de Japón mediante un trabajo digital artesanal y paciente.

Sobre esa sección, Kikuchi menciona lo siguiente: “intenté dibujar los animales salvajes que se encuentran en Japón de la manera más realista posible”. A lo largo de los años, esta colección ha crecido “poco a poco” y ahora incluye 173 especies, cuidadosamente divididas en nueve páginas.

Un rincón que resiste

Que un sitio personal se mantenga intacto durante 25 años es poco común. Lo habitual es ver páginas rediseñadas, migradas o desaparecidas; y eso en el mejor de los casos. Pero Woodpecker Studio resiste.

Quizás eso que nombramos como la “pequeña web” no sea un movimiento, sino una forma de mirar; de cuidar lo que uno hace, aunque nadie lo vea.

Arqueología web

Publicado el 2 de noviembre 2025

Volver a pensar Internet desde la libertad y la privacidad

Wed, 22 Oct 2025 00:00:00 +0000

Josh Long comparte su visión sobre privacidad, derechos digitales y la web independiente.

Conocí a Josh Long a través de Mojeek, un buscador independiente que uso con frecuencia y sobre el cual tengo pendiente escribir.

Josh tuvo la amabilidad de contactarme cuando integré ese buscador en Tecnolocuras. Desde entonces, siempre ha estado disponible para responder cualquier consulta. Y no solo conmigo: su dedicación es bien conocida entre los miembros de la comunidad de Mojeek, donde supo ofrecer asistencia y compartir su conocimiento durante mucho tiempo.

En lo personal, veo a Josh como un referente en materia de privacidad y defensa de los derechos que tenemos, de forma inherente, como ciudadanos digitales. No son pocos sus artículos en los que desarrolla con claridad temas que van desde la privacidad en línea y los riesgos de la concentración de poder en las grandes compañías tecnológicas, hasta explicaciones simples y precisas sobre aspectos técnicos complejos.

Luego de estar varios años involucrado con Mojeek, Josh pasó a formar parte del equipo de Proton. Ese cambio, sin duda, refleja su compromiso con la privacidad en línea y con las tecnologías afines. Proton es, de hecho, una empresa reconocida por su enfoque en proteger la privacidad de sus usuarios y por ofrecer alternativas plenamente funcionales a los servicios de las compañías dominantes.

Quise aprovechar el contacto que tengo con Josh para conocer más sobre su trabajo y, sobre todo, su visión sobre el presente y futuro de la privacidad y los derechos de los usuarios.

Si quieren conocer más sobre su trabajo, pueden visitar su perfil en LinkedIn, en Mastodon Josh(@privacydingus@mstdn.social) y escucharlo conversar sobre privacidad digital en el podcast de Jose Burgos.

Gracias, Josh, por tu tiempo.

¿Cómo te involucraste por primera vez en el mundo de la privacidad digital? ¿Hubo algún momento o experiencia específica que marcara ese camino?

Me metí de manera un tanto accidental en una carrera de marketing después de la universidad, lo que significaba que era inevitable que eventualmente tendría que usar al menos una de las gigantescas plataformas hambrientas de datos, siempre presentes cuando socializaba como estudiante, para tratar de llegar a la gente. En mi último trabajo que no estaba relacionado con la privacidad, trabajé en una empresa cuyo negocio completo estaba basado en los anuncios de Facebook. Esta empresa tenía un objetivo algo noble (al menos eso era lo que decíamos al público), pero la manera en que esos datos podían ser utilizados para manipular a las personas no me parecía correcta. Empecé a escuchar con devoción a Michael Bazzell, pagué por mi primer VPN y aprendí todo lo que pude. A partir de ahí, me resultó prácticamente imposible aceptar cualquier trabajo que no compartiera al menos una visión similar sobre el estado de las tecnologías digitales; si en algún momento en el futuro dejo la lucha por la privacidad, será para algo radicalmente diferente, he visto demasiado.

¿Qué te atrajo inicialmente de proyectos como Mojeek y ahora Proton?

Mojeek tenía, y todavía tiene, mucho del espíritu de las tecnologías de la web temprana, algo digno de admiración. Nos cuentan todas estas historias completamente inventadas sobre fundadores, de cómo dos jóvenes desaliñados comían pizza en un garaje y crearon el futuro, pero todo eso es propaganda del Valle. En la mayoría de los casos, al menos uno de esos chicos tenía acceso a una cantidad de dinero exorbitante y, por lo tanto, a una razón por la que no necesitaba trabajar. Mojeek es, verdaderamente, una versión real de esa actitud de ingenio y esfuerzo. Marc aprendió todo lo que sabe por cuenta propia, creciendo de una manera muy meditada y deliberada. Mi antiguo jefe, Colin, también es un tipo muy perspicaz cuando se trata de tecnología. Estos factores, combinados con el hecho de que podría, en cierto modo, escribir el guión de marketing para una startup tan necesaria, hicieron que la decisión fuera fácil para mí: gano dinero para poder sobrevivir, pero la misión es lo primordial. Difundir la privacidad a las masas.

En Proton vi, y sigo viendo, un lugar donde puedo aplicar las habilidades que adquirí durante esos casi cinco años —y antes, trabajando en tecnología orientada a la privacidad— a toda una gama de desafíos distintos y nuevos. Ningún día es igual a otro. Además de esto, mientras que Mojeek se centraba en un área específica de la pila tecnológica, Proton está construyendo un ecosistema. El hecho es que necesitamos ambos para avanzar, no solo en materia de privacidad, sino también para empujar a toda la industria hacia un lugar donde sirva más a las personas que al lucro, habilitando mejores sistemas en un sentido global y holístico. La tecnología está en todas partes; sostiene gran parte de la sociedad misma, y por eso los proyectos y las personas que la construyen necesitan estar alineados con lo que es bueno para la humanidad en su conjunto. Para mí, ambas empresas tienen una comprensión innata de esto, ya sea que lo expresen explícitamente o no.

¿Qué proyectos o iniciativas consideras esenciales hoy para quienes queremos una Internet más independiente y respetuosa de la privacidad?

Además de los dos proyectos mencionados en la pregunta anterior, creo que lo que Ladybird está haciendo con un navegador que utiliza su propio motor de renderizado es algo muy necesario, dado que nuestras únicas opciones reales —Gecko y Chromium— están financiadas por Google o, en gran medida, controladas por Google. Sé que Chromium es un proyecto de código abierto, pero cambios como Manifest V3 demuestran que el código sigue, básicamente, la dirección que ellos quieren. También incluiría aquí la variedad de diferentes distribuciones de Linux; personalmente he estado usando Pop!_OS desde hace bastante tiempo, aunque tengo aprecio por Debian, Ubuntu y muchas distribuciones derivadas de ellas (en particular Armbian y Raspbian).

Los sistemas operativos alternativos para teléfonos, como (aunque no limitados a) GrapheneOS —mi sistema de uso diario—, /e/OS de la Fundación e, y Calyx, también ofrecen una alternativa muy necesaria frente a las dos grandes opciones móviles. Y no nos engañemos: la computación para la mayoría de las personas se ha desplazado enormemente hacia los dispositivos de mano. También creo que los proyectos de hardware alternativo son una gran parte de mostrarle a la gente que las cosas pueden ser diferentes. Mi computadora portátil personal es una Framework, pero proyectos como el reproductor de música de código abierto Tangara son un gran recordatorio de que no necesitamos tener nuestras herramientas digitales completamente en manos de un pequeño grupo de empresas ultrapoderosas que trabajan en contra de nuestros intereses.

Las redes sociales federadas también ofrecen una forma muy diferente de comunicarse e interactuar con la información en línea. Ha quedado claramente demostrado, a medida que la web ha evolucionado, que entregar la “plaza pública” a multimillonarios que buscan lucrar con ella no produce resultados prosociales. Finalmente, no podría organizar mi vida sin RSS; enviar XML a través de un protocolo web es algo ingenioso y permite que tú, el usuario, decidas cuándo recibes la información, en lugar de entregar esa decisión a una empresa como Twitter o a un boletín de Mailchimp repleto de píxeles que solo genera más ruido en tu bandeja de entrada.

Según tu experiencia, ¿cuáles son los mayores obstáculos que impiden a las personas adoptar tecnologías que priorizan la privacidad?

El poder de las configuraciones predeterminadas. El hecho de que la tecnología esté en todas partes no significa que se comprenda en una medida proporcional a su alcance. Las personas tienen un tiempo limitado cada día —y en toda una vida—, y la tecnología no ocupa para ellas el mismo lugar que ocupa para mí. Otras personas disfrutan de la jardinería, el anime, las caminatas, o de criar hijos. No digo que ninguna de esas cosas me interese, pero la realidad es que la mayoría de la gente vive ocupada. Si algo es ubicuo pero no se entiende, entonces quienes sí lo entienden —y, lo que es más importante, quienes lo controlan— tienen un enorme poder sobre los demás.

Diría que esto es muy similar a lo que ocurre con el sistema financiero. En general, las personas no pueden sobrevivir sin dinero; el dinero está en todas partes, pero ¿realmente la mayoría lo entiende? Quienes controlan las formas en que fluye el dinero, quienes saben cómo manipular esos sistemas, y quienes nacen con un gran capital, son los que pueden moldear la sociedad a su voluntad.

Todo esto es una forma larga de decir que, para que la privacidad se vuelva algo común, debe convertirse en la opción predeterminada. Las tecnologías centradas en el usuario deben estar presentes desde el primer momento en que alguien configura un dispositivo —al menos junto a otras opciones—. Las herramientas que las personas usan son muy “adhesivas” una vez que están configuradas, y la mayoría no tiene los conocimientos necesarios ni siquiera para desear cambiar, mucho menos para realizar todos los pasos que implica hacerlo.

¿Qué rol deberían tener los gobiernos en la protección de la privacidad en línea, sin caer en autoritarismos ni ofrecer soluciones engañosas?

Necesitamos que los Estados respeten el derecho humano a la privacidad, tal como se establece en el Artículo 12 de la Declaración Universal de los Derechos Humanos. Esto implica construir sistemas gubernamentales que no creen organizaciones como la NSA, o eliminarlas si ya existen. Debemos contar con una buena gobernanza que no practique la vigilancia masiva de los ciudadanos.

Sin embargo, esto solo resuelve una parte del problema, ya que gran parte de los datos que recopilan los gobiernos son comprados o adquiridos a empresas privadas. Una medida adicional necesaria es promulgar leyes que limiten la capacidad de las compañías privadas para vulnerar la privacidad de las personas. En la Unión Europea comenzamos a avanzar en esa dirección con el Reglamento General de Protección de Datos (GDPR), pero su implementación fue un desastre: un despliegue deficiente y una aplicación demasiado laxa.

A mi entender, el mejor tipo de ley en este ámbito es aquella que hace que los flujos de datos sean radicalmente transparentes, garantizando que toda transmisión de información que pueda poner en riesgo la privacidad de una persona requiera un consentimiento explícito, después de que el proceso haya sido explicado de forma comprensible para cualquier ciudadano común.

Con los años que llevo trabajando en este campo, me ha quedado claro que muchas más personas de las que uno imagina están preocupadas por cómo se usan sus datos, pero simplemente no saben —o no entienden bien— lo que realmente está ocurriendo.

El auge de la IA generativa está concentrando aún más poder en pocas empresas. ¿Cómo ves este fenómeno desde la perspectiva de la privacidad y la descentralización?

La mayoría de las “inteligencias artificiales”, como las publicaciones tecnológicas y las grandes corporaciones han decidido llamar a esta nueva generación de tecnologías generativas basadas en aprendizaje automático, no pueden existir sin enormes cantidades de información extraída —a menudo sin permiso— de la web abierta. Esto significa que los abusos a la privacidad están incorporados desde la base misma de la creación de estas tecnologías. Pero no termina ahí. Si observamos los principales usos que las personas les dan a la IA, también implican divulgaciones de datos personales, tanto conscientes como inconscientes.

Muchos utilizan estas máquinas, al igual que ocurría con ELIZA de Weizenbaum, como sustituto de la terapia conversacional o la orientación personal. Para que esto funcione, es necesario ofrecer una gran cantidad de información sensible sobre uno mismo, la cual queda almacenada (aunque sea solo para que el modelo lingüístico pueda cumplir su tarea).

En las redes sociales, además, muchas personas usan la generación de imágenes para emular determinados estilos artísticos o para crear retratos junto a versiones más jóvenes de sí mismas. Estos experimentos pueden resultar entretenidos, pero también implican alimentar con más y más fragmentos de nuestra identidad los conjuntos de datos de entrenamiento.

¿Crees que es posible desarrollar IA que no dependa de la explotación masiva de datos personales y corporativos?

Creo que eso sería posible, pero probablemente sería incluso menos rentable que la situación actual, y mucho más difícil de llevar a cabo. Hasta ahora, las grandes tecnológicas han tendido a usar cualquier cosa que encuentren disponible de forma gratuita para crear canalizaciones de datos que les generen ingresos, normalmente a través de la publicidad.

Esto se puede ver con bastante claridad si observamos las redes sociales: las personas tenían la necesidad de conectarse en línea, y ese espacio digital fue provisto y luego mercantilizado. La mentalidad por defecto de las startups o de Silicon Valley no suele incluir el pensar antes de actuar; se trata, abrumadoramente, de hacer cosas, obtener inversión y luego monetizar.

Cuando el pensamiento llega, suele hacerlo en casos como el de Tristan Harris, quien tuvo un repentino mea culpa después de haber sido durante años una pieza clave dentro de la maquinaria (y, lo que es importante, después de haber ganado una cantidad muy cómoda de dinero).

¿A qué señales deberíamos prestar atención hoy para anticipar hacia dónde se dirige Internet en los próximos 5 a 10 años?

Como alguien que trabaja en marketing, tengo una señal muy clara que tendrá numerosos efectos secundarios y a la que la gente debería prestar mucha atención. Internet está empezando a ser invadida por bots. Los modelos de lenguaje (LLMs) han dado a lo que antes era un conjunto bastante increíble y poco fiable de bots en la web la capacidad de generar textos mucho más convincentes y parecidos a los humanos.

Esto significa que muchos espacios que originalmente estaban llenos de contenido de calidad o discusión están empezando a parecer centros comerciales vacíos; superficialmente se ven muy similares a cuando funcionaban correctamente, pero al rascar la superficie, se nota que ya no operan como antes.

Corremos el riesgo de que muchos de los espacios que han facilitado la conversación y el intercambio de conocimiento en línea sean invadidos por intrusos inorgánicos. Es posible que muchos digan que esto no es una gran pérdida, dado que las redes sociales han hecho mucho daño a la sociedad, pero aún existen periodistas, activistas, políticos y muchas otras personas que dependen de estos lugares para entender el mundo. Además, los motores de búsqueda parecen converger en ofrecer respuestas generadas por LLM; si espacios como Reddit —que, siendo francos, está sobrerrepresentado en la fuente de respuestas del Modo IA de Google— se llenan de respuestas de IA, ¿qué implica esto para nuestra capacidad de encontrar significado y verdad en línea?

Entrevistas

Publicado el 22 de octubre 2025

La web que se quedó en el tiempo

Sun, 19 Oct 2025 00:00:00 +0000

Una historia sobre la fragilidad técnica de la memoria digital y el valor de conservar los rastros personales de la vieja web, contada a través del sitio que un fan dedicó durante décadas a la serie My Favorite Martian.

Hay algo profundamente humano en dedicar años a construir un sitio web. Página a página, línea a línea, se levanta un pequeño refugio digital. Y no se trata solo de “subir información”, es más bien una especie de archivo emocional que crece y envejece junto a su creador. Pero llega un momento —a veces inesperado— en el que ese espacio puede quedar fuera de alcance. No porque haya desaparecido, sino porque, simplemente, ya no es posible entrar. Se pierde la llave.

Ese es el caso de JH, creador del sitio My Favorite Martian (https://members.tripod.com/~jhh_2/TVMFM.htm), probablemente el más completo archivo en línea sobre la icónica serie de televisión, emitida en los años sesenta, y protagonizada por Bill Bixby y Ray Walston.

Desde finales de los noventa, la web de JH ha reunido reseñas, imágenes y material histórico sobre la serie, convirtiéndose en una referencia para los fanáticos. Sin embargo, hace un tiempo que JH perdió el acceso a su sitio: no puede actualizarlo, corregirlo ni trasladarlo debidamente a otro lugar. Lo que fue su refugio digital, hoy sigue existiendo, pero congelado en el tiempo.

La historia de un sitio y su creador

El 3 de diciembre de 2017, le envié el siguiente correo a JH:


Hi, 
Just a note to say that yours "My Favorite Martian" website is great!

Thank you. Regards. Henry.

Simplemente quería agradecerle por el trabajo de recopilar y subir información sobre la serie que tanto supe disfrutar. JH respondió:


Hello Henry,
Many thanks for your kind words! Glad to know you enjoyed the site!

Best, JH

Ocho años después de haber enviado aquel correo, quise ponerme en contacto nuevamente con JH. Esta vez, mi interés no era solo agradecerle, sino conocer la historia detrás del desarrollo del sitio y su visión sobre el futuro del proyecto. Así comenzaba mi nuevo mensaje:


Hello JH,
I hope this message finds you well!
Back in 2017, I wrote to you simply to say how much I appreciated your My Favorite Martian website — and you kindly replied. All these years later, I’m still very fond of your site and the dedication behind it.
I’m now working on an article (and possibly an interview) for my website, tecnolocuras.com, which is published in Spanish, about classic fan sites and the people who keep them alive, as part of a project exploring the early web and its preservation. Your site is a perfect example: simple, personal, and full of valuable information for fans.
If you’re willing, I’d love to ask you a few brief questions:

Have you continued updating or adding content over the years?
Do you have plans to keep the site online in the future?
Technically speaking, how is the site built and maintained? (e.g., is it still all hand-coded HTML on Tripod?)
Looking back, what motivated you to create it, and what has kept you motivated to keep it online?

Of course, there’s no rush — and I completely understand if you’d rather not take part.
Thank you again for creating and maintaining such a wonderful tribute to My Favorite Martian.
Best regards,
Henry

JH tuvo la amabilidad de contarme en detalle cómo nació y creció aquel sitio, desde un viejo computador Compaq de 1998 y una conexión dial-up, hasta los días en que Tripod —uno de los servicios gratuitos más populares de la web de los noventa— era sinónimo de tener “tu propio lugar” en Internet.


"Very unfortunately, I can no longer access the website. I set it up on an old 1998 Compaq computer using a dial up connection and a web publishing wizard for HTML documents which it uploaded. ( The documents were created on Word, saved, and then saved again as HTML documents where photos were inserted.) As you might know, dial up service is discontinued. I am not sure whether this old computer is capable of using a high speed internet cable connection.
Needless to say, I got a new computer in 2012 that does, obviously, use high speed internet but it does not have the ability to produce HTML documents or have that web publishing app to connect with tripod.
I'm afraid I don't have the knowledge to figure out that problem.
The only idea I have considered, is trying to move the old computer to where the high speed cable is, and see what happens, but given its location, it's not practical.
It is disappointing because there are some things I'd love to update and remove on the site, but alas, it is what it is for now."

En los párrafos anteriores está condensado todo un momento de la web: la época en la que aprender a construir un sitio no requería cursos ni frameworks, sólo curiosidad, tiempo y paciencia. Algunas de las herramientas de publicación venían integradas en los programas de oficina. Los resultados podían lucir amateur, sí, pero personales, con una impronta que hoy escasea.

► JH publicó su sitio en Tripod, una de las muchas plataformas que ofrecían alojamiento gratuito a cambio de un banner publicitario. Era la era de Geocities, Angelfire y FortuneCity, unos territorios abiertos donde millones de usuarios ensayaban sus primeras páginas.

Durante años, JH mantuvo el sitio, agregando material nuevo cada tanto. Escaneos de revistas, artículos sobre los actores, capturas de VHS, enlaces a otros fans. Todo organizado en páginas simples, con estructura de tabla, un estilo minimalista y funcional a su objetivo. Pero el testimonio de JH también resulta valioso por otro motivo, el de registrar los procedimientos técnicos que se utilizaban para construir la web en una Internet todavía en ciernes.

En muchos sentidos, estudiar estas prácticas es análogo a cómo los arqueólogos y antropólogos examinan las herramientas de las civilizaciones primitivas; cada cuchillo, cada instrumento de piedra o madera, revelan detalles sobre la forma de vida, los conocimientos técnicos y las prioridades de quienes los fabricaban y usaban.


"Going back to 1997 as the internet was starting up I became aware of something called websites that fans of some TV shows were creating. I had no computer,  however, some of my friends did and they made me aware of email and sites for shows and music we liked.  The Sci-Fi TV cable network had a website with message boards so that  fans of certain shows could communicate. I still didn't have a computer so I used the ones in local libraries to use these message boards and during the next months I emailed a few fans of MFM and we discussed the show but nothing more.
Then finally one day, on a library computer, I saw that someone put up a website for "Martian". It mainly just had summaries of each episode, with some articles about toys of the series. The webmaster posted an invitation for fans to submit articles, which I did and he was kind enough to publish my work. We kept in touch and he offered me some hints about putting up a website of my own. I was glad to see the show getting recognition from him, but I knew I could offer more information, thanks to growing up with the series and saving articles about it, but I had no idea how one could create a "website".
Luckily, a local college offered a course in creating websites, and while it did offer techniques of coding, essentially, they taught the HTML method of creating webpages. I began using floppy A discs to save the test pages, and very fortunately, I knew of a friend of a friend who understood all about webpages and I was shown how to publish the pages.
So I finally bought my Compaq computer in October 1998 , which included a scanner for the photos.
I chose Tripod to host the site instead of Geocities and it was a good decision. So the first pages went up in December 1998.

I got a device called a Grabbit which hooked up to a VCR and could grab photos from video tapes of the show, which I enjoyed adding to the site."

Me dijo JH, reviviendo los días en que Internet era todavía un territorio nuevo.

La fragilidad técnica de lo que sobrevive

Cuando un sitio se vuelve inaccesible para su propio creador, la primera tentación es buscar una solución técnica. Y, en efecto, existen alternativas —todas parciales, todas con matices—. En el caso de JH, la propuesta más sencilla que le hice, era tratar de replicar su sitio en otro servidor gratuito, como Neocities.org, una plataforma que intenta recuperar el espíritu de la web personal de los años noventa.

Neocities ofrece alojamiento gratuito, editor en línea y la posibilidad de publicar directamente documentos HTML. La idea era bien simple: copiar el contenido del sitio original y volver a subirlo bajo un nuevo dominio, con la promesa de poder actualizarlo sin depender de software obsoleto. Sin embargo, el verdadero problema a resolver no es copiar los archivos a otro lugar, sino perder el vínculo con la dirección original.

El dominio https://members.tripod.com/~jhh_2/TVMFM.htm sigue en línea, visible para cualquier navegador, pero JH no tiene acceso a modificarlo ni a configurar un redireccionamiento hacia una nueva dirección. En la práctica, eso significa que los cientos de enlaces externos —foros, listas de fans, catálogos antiguos— que apuntan a esa URL nunca sabrán que el sitio se movió. El visitante casual seguirá llegando a una página detenida en el tiempo, sin saber que en otra parte existe una versión más reciente.

► El caso del sitio de JH es un ejemplo de lo que podríamos denominar “preservación sin control”, en donde el contenido sobrevive, pero su autor ya no puede intervenir en él. Como una casa cerrada que sigue en pie, pero cuyas llaves se perdieron hace tiempo, y no es posible derribar la puerta a patadas.

La memoria digital

El caso de JH y su sitio sobre My Favorite Martian no es único. Existen miles de páginas personales que, como la suya, fueron construidas con paciencia y dedicación durante años, pero que hoy enfrentan el riesgo de desaparecer o de quedar congeladas por cambios técnicos, cierres de servicios o pérdida de acceso a cuentas.

Estas webs son testigos de una época en la que Internet era un espacio artesanal, donde cada enlace, cada imagen escaneada y cada línea de texto tenía el cuidado y la intención del creador. Perderlas significa olvidar fragmentos de historia, testimonios y pequeñas obras del quehacer doméstico digital.

Las soluciones técnicas que hoy tenemos ayudan a salvar el contenido, pero no restauran el control. Los vínculos externos, el posicionamiento en buscadores, la familiaridad de los visitantes, todo eso puede perderse.

► Incluso una copia imperfecta es mejor que nada, y permite que generaciones futuras puedan navegar y explorar el material, aunque sea fuera del dominio original.

¿Para qué conservar?

Hace un tiempo hablé de preservación digital con un persona de mi entorno, y me hizo una pregunta para la cual no tuve respuesta en su momento, y creo que aún no la tengo del todo: ¿Y para qué conservar?, me dijo.

Suelo tener una mirada nihilista, y creo que podría aceptar, sin mucha resistencia, la desaparición como parte natural del tiempo. Pero sé que hay valor en el esfuerzo que implica conservar la memoria digital. Un sitio dedicado a una serie de televisión puede tener un significado profundo en la vida de quienes la amaron. Y si la muerte ya es olvido, ¿por qué no intentar salvar aquello que está a nuestro alcance? ¿no es precisamente eso un rasgo que nos distingue como especie? Intentarlo es quizá una de las pocas maneras de mantener vivo lo que consideramos valioso.

Arqueología web

Publicado el 19 de octubre 2025

Los gatos de Diane

Thu, 11 Sep 2025 00:00:00 +0000

Todo empezó como una pequeña peripecia. Quise escribirle a Diane —o mejor dicho, Diabella—, autora de un sitio extrañamente encantador que descubrí navegando por los pasillos menos iluminados de la red.

Compuse un correo breve. Me presenté como un desarrollador de software, interesado en conversar sobre su forma particular de crear sitios web alejados de las tendencias actuales. Pregunté qué pensaba de la evolución del desarrollo web, si alguna vez sintió la necesidad de actualizarse, y si creía posible ofrecer hoy un servicio comercial apegado a la lógica de la vieja web, donde primaban la información y la creatividad por encima de la optimización, el SEO y las técnicas de seguimiento.


Hi Diane,
My name is Henry, I’m a software developer. I write on my blog tecnolocuras.com, where I explore topics related to the history of the web.
I came across your site and I’d love to hear your thoughts on a few things:


How do you see today’s web development compared to when you first started?


Have you felt the need to incorporate new technologies, or do you prefer to stay true to your original style?


Do you think there’s still room to offer web development services that prioritize information and creativity over trends and optimization?


What tools and sources of inspiration do you use when creating your art?


Thank you very much for your time,
Henry.

El correo nunca llegó a destino. Rebotó. La casilla estaba deshabilitada, o al menos eso es lo que parece:


I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
Host mx-aol.mail.gm0.yahoodns.net[67.195.228.86] said: 55430 Sorry, your message to diabella@aol.com cannot be delivered. This mailbox is disabled (554.30). (in reply to end of DATA command).

Intenté conseguir otra dirección de correo a través del WHOIS de su dominio, pero lo único que encontré fue un email genérico de su proveedor y un formulario de contacto donde se promete reenviar el mensaje al dueño del dominio.

► ¿Mi intento de contacto terminó en un callejón sin salida?.

El hallazgo

Llegué a diabellalovescats.com gracias a Wiby, un buscador alternativo que se propone rescatar la otra web: aquella hecha por personas, sin algoritmos invasivos ni la lógica perversa del SEO y todo eso.

Una búsqueda aleatoria me llevó a su dominio, registrado en 2001 y todavía en pie más de veinte años después. Fue como tropezar con una cápsula del tiempo: páginas simples en HTML, fondos lisos, tipografías sencillas, y una colección de imágenes que parecían hechas con herramientas básicas, quizá con Paint o algo similar.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

Su página principal sigue el estándar HTML 3.2. Esa versión de HTML, publicada en 1997, es muy básica, con soporte limitado para CSS. Esto explica que todo el diseño dependa de tablas, atributos y colores de fondo directamente en etiquetas body o td.

<body bgcolor="#FFCCCC" link="#FF0000" vlink="#800040" alink="#0F7A0C" background="catbackpeach4.jpg">

► Las tablas son la principal herramienta de layout: anchura, color de fondo, bordes y padding se definen en cada table o td.

Diane también brinda servicio de diseño web y arte gráfico. Páginas hechas en HTML, personalizadas. Puro HTML. Incluso dejó como ejemplo un trabajo para Animal Lifeline Corp, que ya no está disponible pero sobrevive gracias a Wayback Machine.

► En tiempos donde todos los sitios parecen clones, la propuesta de Diane es casi subversiva. Este sitio estuvo en línea hasta el 2017.

Diabella Loves Cats es una rareza, y no solo por su código…

Los gatos

Escribe Diane en su página de presentación:

«Cuando era niña, mi sueño más preciado era tener un gato. Pero eso nunca iba a suceder. Una y otra vez recogía gatos callejeros y los llevaba a casa con historias increíbles: "Mira, mamá, encontré a este gato congelado en la nieve"... o, "mira, mamá, este gato estaba atrapado en un desagüe".
Nunca funcionó. Pasaban unos días y mamá le daba a papá esa orden tan familiar: "¡George, deshazte de este gato!"

¿Qué debía hacer? ¿Qué debía hacer el pobre padre? La palabra de mamá era ley.

Entonces, cuando finalmente llegó el día de dejar el nido, mi mayor emoción fue que finalmente haría realidad mi sueño.

Inmediatamente comencé a buscar por las calles y en pocos meses acogí a varios gatos. Todos estos gatos han pasado por el arcoíris hace mucho tiempo, pero recuerdo a cada uno con una sonrisa.»

Su pasión por los gatos se hace evidente en sus historias de rescate y cuidado. Uno de los primeros casos que comparte es el de Momma Cat, una gata blanca embarazada que fue encontrada buscando comida en la basura con lo que parecía ser su última fuerza. Excepto por su abultado vientre, era un saco de huesos.

Momma Cat fue fácil de atrapar. Diane preparó una caja con toallas en un rincón tranquilo, anticipando el nacimiento de los gatitos. A la mañana siguiente la caja estaba vacía… pero en el armario había cinco pequeños gatos blancos. Eventualmente, todos encontraron hogar, incluida Momma Cat.

El arte

El sitio está poblado de imágenes de gatos. Gatos por todos lados. Gatos y más gatos.

Algunas composiciones parecen collages digitales, con un aire vintage que no es casual: Diane también es restauradora, y en su biografía cuenta cómo una vieja máquina de escribir encontrada por azar la inició en el mundo de los objetos antiguos.

«Todo comenzó hace muchos años con un antojo de pastel cuando mi exmarido se aventuró valientemente a salir a la noche nevada en busca de una panadería abierta. Las panaderías estaban cerradas pero Jay no regresó con las manos vacías. En lugar de una caja de pasteles, cruzó la puerta con una vieja máquina de escribir cubierta de nieve con la que algún buen samaritano había contaminado la vereda. Acepté a medias dejarlo compartir nuestra casa en el suelo de un armario.

Algo inesperado ocurrió el día que lo saqué del armario. Al tocar ligeramente sus teclas experimenté una fuerte sensación de unidad con el pasado y me pregunté quién lo había poseído y qué impresiones habían dejado sus teclas a lo largo de los años. No encajaba exactamente con la decoración ni pude hacerla funcionar, pero con toda su historia esta máquina de escribir era demasiado noble para vivir en un armario. Así que la iluminé y la senté encima de una mesa de café. Durante las siguientes semanas desarrollé una afinidad con este viejo trozo de maquinaria.»

Las muñecas

Lo fascinante de Diane es que no se limita al arte digital. También confecciona muñecas que parecen ser una proyección estética de sus personajes digitales.

Esmerelda the Gypsy Cat o Witch-Hazel son ejemplos de cómo su quehacer artístico se expande en distintos soportes, generando un universo (¿un lore?) que tiene coherencia entre lo digital y lo tangible.

► «Creado con muchos materiales diferentes, mido 30 pulgadas de alto, estoy relleno de medias y vestido con joyas y ropa vintage. Incluso tengo un liguero de diamantes de imitación vintage. Cada parte de mí es realista... si sabes a qué me refiero.»

«Uno de mis pasatiempos favoritos siempre ha sido escribir historias de fantasía profusamente ilustradas cuyas páginas están contenidas en grandes álbumes de fotografías. Las "ilustraciones" siempre contenían una enorme variedad de hallazgos de tiendas de chatarra. Para Esmeralda era un antiguo guante con volantes rojos, una vieja gargantilla de diamantes de imitación, tapetes de encaje y más. Estos pequeños hallazgos fueron pegados en las páginas del álbum y guardados a salvo debajo de sus cubiertas de plástico.

Un verano un amigo muy especial entró en mi vida. Y así comencé a trabajar en un libro de cuentos titulado Esmeralda la gata gitana que le regalaría en Navidad.

Mientras estaba involucrado en la escritura de la historia, se me ocurrió tratar de darle vida. Fue mi primer intento de hacer muñecas. El proyecto duró muchos meses y fue emocionante. Esmerelda mide 30" de alto. Su cabeza es de papel maché. Un patrón para su cuerpo fue cortado de muselina teñida de gris. Está llena de medias viejas. La parte divertida llegó cuando estaba lista para vestirse. Era difícil hacer zapatos realistas, así que fue a una tienda de ropa infantil para que le pusieran un par. Nunca olvidaré el día que entré a esa tienda con Esmeralda escondida en una manta y la puse en el mostrador para que le pusieran zapatos.

Y así comenzaron tres años de fabricación de muñecas. Uno para regalar cada Navidad a este amigo especial, junto con un libro de cuentos ilustrado. Cada una de mis muñecas es anatómicamente correcta pero tendrás que confiar en mi palabra.»

Mientras exploraba esas páginas (que son unas cuantas), no pude evitar pensar en Henry Darger, el artista outsider estadounidense que durante décadas creó en secreto «La Historia de las Vivians, en lo que se conoce como Los Reinos de lo Irreal, sobre la Guerra-Tormenta Glandeco-Angeliniana causada por la Rebelión de los Niños Esclavos», un manuscrito monumental acompañado de cientos de ilustraciones.

► Una de las pocas fotos conocidas de Darger. Foto: David Berglund

Darger trabajaba en soledad, con papel que recogía en la calle, con recortes y acuarelas. Diane, en cambio, eligió la web como escenario.

► Fotografía tomada por Nathan Lerner durante la limpieza de la habitación de Darger en 1972.

La soledad creativa de Diane se despliega en páginas accesibles al mundo, pero con la misma lógica marginal, la de no buscar reconocimiento institucional ni ajustarse a tendencias, simplemente crea porque necesita hacerlo.

► Quizás sea una comparación injusta, pero creo que hay algo común en ambos: la convicción de construir un universo personal a contracorriente. Darger convirtió su habitación en un refugio creativo; Diane hizo lo mismo con su sitio web.

Lo que queda (es la poesía)

Sigo sin poder contactarme con Diane. Tengo una pista de su apellido, gracias al valor de un atributo registrado en el código, pero luego de ensayar varios dorks, no obtuve resultados significativos.

<meta name="author" content="Diane B">

► Encontré una cuenta de Pinterest, pero no estoy seguro de que la persona que publica sea la propia Diabella.

Me conformo con haber tenido la posibilidad de asomarme, aunque sea en puntitas de pie y con un ojo entreabierto, al universo íntimo de Diane. Al menos tengo la certeza de que internet todavía guarda algunos tesoros escondidos.

Arqueología web

Publicado el 11 de setiembre 2025