Jacobo Tarrío

Project Spite

Mon, 04 Jul 2022 00:00:00 +0000

I saw my first demo in 1993 or so. It was magical: I would run a program, and a display of shapes, effects, and music would appear on my computer, all rendered in real time. One day, after watching one of those demos, still humming its music, I started my editor to try and code a simple 3D cube, when my little brother said:

“Oh, so you think you’re going to be able to code that…”

He was 10 or 11 and probably just wanted me to get off the computer so he could play a game, but it hurt me a little at the time.

So, of course, nearly 30 years later I still remember it and I dedicate this project to that memory.

Last April I realized that, one year from now, it will be the 30th anniversary of Second Reality, and thought that:

It would be cool if someone would write an HTML5 remake for 2023.
Hey, I’m someone.

So I started working on it.

Now, about a month later I realized that I had never written a demo before, it was taking me a long time to get something going, that I have little to no idea what the names of the different effects in the demo are, much less how to code them, and that I don’t have enough artistic ability to redo the drawings for a 1080p or 4k resolution world.

Therefore, I decided to complete the intro, put a ribbon on it, release it along with the source code, and see if anyone would like to build upon it.

You can see the demo here.

You can exit the demo at any time pressing Enter or “Q”. It works at a 1080p resolution, fullscreen. It should work in a computer but also on a phone or tablet.

Many of the assets were reused or adapted from the original Second Reality demo, whose source code was published 10 year ago, for the 20th anniversary. I repainted the planet landscape so it doesn’t look all blocky and upscaled.

The music is played in real time from the original S3M, of course; I wrote the player myself, though it is pretty much an “only needs to be able to play one song” affair.

Let me know what you think!

No abuséis de los tipos de datos primitivos

Sun, 17 Jan 2021 00:00:00 +0000

Pedidle a un programador moderno que os diseñe un programa, y pronto os dará un diagrama con clases llamadas Cliente y Empleado, y Usuario y UsuarioDAO, y ConnectionProvider y ConnectionProviderFactory y AbstractConnectionProviderFactoryImpl.

Bueno, tal vez sólo los programadores Java se metan en tales fregados, pero está claro que, hoy en día, cualquier programador conoce y utiliza los conceptos básicos de orientación a objetos. Incluso en lenguajes no orientados a objetos, los programadores crean y usan structs, o records, o Types o cualesquiera mecanismos del lenguaje para crear nuevos tipos de datos.

Y, aún así, por muy sabios que nos consideremos los programadores en la actualidad, en nuestros programas todavía sobreviven vestigios de los viejos tiempos en los que Fortran y COBOL y BASIC sólo nos proporcionaban tipos de datos primitivos. Cada vez que queremos almacenar una clave primaria de un registro de la base de datos, la ponemos en una variable de tipo long o string. Si queremos pasarle un timestamp a una función, usamos un argumento de tipo int o long. ¿Una función que devuelve un UUID? Tipo string. ¿Una cadena de texto recibida del usuario? ¿Una cadena de texto lista para insertar en un documento HTML? Ambas, tipo string.

Utilizamos los mismos tipos de datos, una y otra vez, para cosas tan diferentes como claves primarias de distintas tablas y timestamps en segundos y milisegundos, o URIs y UUIDs. Ésta es una práctica extremadamente habitual que, también, es una causa de errores extremadamente habitual. ¿Quién no ha escrito nunca código que intenta buscar un registro en la tabla equivocada, o que compara segundos y microsegundos, o que inserta una cadena de texto sin escapar en un documento HTML?

En este artículo os describo tres estrategias para tratar con esos objetos, evitar confusiones como las que describo arriba, y evitar errores de programación.

Utilizad nuevos tipos para nuevas entidades

¿Conocéis el Internet Archive? Es una organización sin ánimo de lucro que quiere formar una “biblioteca de Internet” archivando todas las páginas web del mundo para conservarlas y para que podamos verlas en el futuro.

Podéis suponer que el código fuente del Internet Archive trabaja mucho con URIs. Cada página web tiene su propio URI y contiene otros URIs de todas las páginas web a las que enlaza. En el archivo, las páginas web están indexadas mediante sus URIs para que los usuarios puedan acceder a ellas. En definitiva, para el Internet Archive, los URIs son el pan nuestro de cada día.

Los programadores siempre estamos tentados de almacenar URIs en variables de tipo string. Vemos una cadena alfanumérica y nos decimos: “eso es fácil: es una cadena de texto, así que tipo string”. Sin embargo, los URIs no son sólo cadenas de texto. Los URIs tienen ciertas reglas que deben cumplir en todo momento: han de seguir un cierto formato, ciertos caracteres no son válidos, hay secuencias de escape, etc.

Cuando almacenamos un URI en una variable de tipo string, el sistema no sabe nada de esas reglas. La variable podría contener un URI mal formateado, o incluso algo que no es un URI en absoluto, y no habría ningún mensaje de error ni nada parecido hasta que intentásemos usarla y se rompiera algo. Por lo tanto, necesitamos escribir (y acordarnos de utilizar siempre) código que, cada vez que asignemos un nuevo valor a la variable, lo verifique y normalice. Si no lo hacemos, nos exponemos a una multitud de posibles errores de programación. Tal vez no seamos capaz de encontrar la página web que el usuario busca, tal vez tengamos un XSS en nuestra página, o algún otro problema entre medias.

Para solucionar el problema con más eficacia tenemos que reconocer que un URI no es una cadena de texto que podamos manipular usando sólo variables de tipo string, sino que tenemos que utilizar una clase específica que codifique todas las reglas y el formato de un URI. Esta clase URI ha de tener funciones para convertir una cadena de texto en un objeto de tipo URI, aplicando todas las reglas de validación y normalización, y también necesita tener funciones para extraer las distintas partes del URI y obtener una representación del URI en forma de cadena de texto.

La mayoría de los lenguajes modernos incluyen una clase URI en su biblioteca estándar, así que sólo tendremos que acordarnos de utilizarla en lugar del tipo string en cualquier lugar en el que tratemos con URIs.

El Internet Archive, en su página principal, tiene una caja de texto en la que un usuario puede escribir un URI y ver qué había en esa página en algún momento del pasado. El servidor web recibe la petición web que contiene ese URI en forma de cadena de caracteres; lo primero que hace el servidor es convertirlo en un objeto de tipo URI. A partir de ese momento, ese URI está validado y formateado, por lo que el servidor puede pasarlo al servicio de almacenamiento, que podrá recuperar el contenido de la página web.

A veces no podemos utilizar clases proporcionadas por nuestra biblioteca estándar y tenemos que escribirlas nosotros mismos. Por ejemplo, hace años trabajé en un proyecto que tenía una base de datos que almacenaba objetos indexados mediante un identificador que seguía el formato HHHHHHHH-V, donde H era un dígito hexadecimal y V era un número de versión de uno o más dígitos.

Los programadores originales del sistema no se habían puesto de acuerdo en cómo tratar estos identificadores. En algunas partes del programa, el identificador iba almacenado en una variable de tipo string. En otras partes, el identificador estaba dividido en dos variables: una de tipo string que contenía los dígitos hexadecimales y otra de tipo int que contenía el número de versión. Nuestro código muchas veces se parecía a esto:

public List<String> buscaIdsAsociados(String id)
        throws IllegalArgumentException, NotFoundException {
    if (!esValido(id)) {
        throw new IllegalArgumentException();
    }
    String hexa = extraeHexa(id);
    int version = extraeVersion(id);
    Registro registro = buscaRegistro(hexa, version);
    List<String> idsAsociados = new ArrayList<>();
    for (Registro asociado : registro.getRegistrosAsociados()) {
        idsAsociados.add(asociado.getHexa() + "-" + asociado.getVersion());
    }
    return idsAsociados;
}

public Registro buscaRegistro(String hexa, int version) {
    Query query = createQuery("SELECT * FROM Registros WHERE hexa=?, version=?",
                              hexa, version);
    return convertir(query.execute());
}

Como podéis ver, era un jaleo. Nos pasábamos el tiempo validando identificadores y dividiéndolos en dos partes y reensamblándolos y buscando errores causados por sitios donde nos habíamos olvidado de validar o donde habíamos pasado un identificador cuando necesitábamos la parte hexadecimal o viceversa.

La solución a este problema consistió en reconocer que un identificador es un nuevo tipo de entidad y no sólo una cadena de texto, y crear una clase dedicada a almacenar y manipular identificadores.

public class Identificador {
    private String hexa;
    private int version;

    private Identificador(String hexa, int version) {
        this.hexa = hexa;
        this.version = version;
    }

    public String getHexa() { return hexa; }
    public int getVersion() { return version; }
    public String toString() { return hexa + "-" + version; }

    public static Identificador crear(String id) throws IllegalArgumentException {
        // Validación y extracción de las partes del identificador
        ...
        String hexa = ...;
        int version = ...;
        return new Identificador(hexa, version);
    }
}

Y, con esto, pudimos simplificar nuestro código, evitando las constantes validaciones y tratando los identificadores de la misma manera en todo el programa, eliminando cientos de líneas de código y oportunidades para introducir errores.

public List<Identificador> buscaIdsAsociados(Identificador id)
        throws NotFoundException {
    Registro registro = buscaRegistro(id);
    List<Identificador> idsAsociados = new ArrayList<>();
    for (Registro asociado : registro.getRegistrosAsociados()) {
        idsAsociados.add(asociado.getIdentificador());
    }
    return idsAsociados;
}

public Registro buscaRegistro(Identificador id) {
    Query query = createQuery("SELECT * FROM Registros WHERE hexa=?, version=?",
                              identificador.getHexa(), identificador.getVersion());
    return convertir(query.execute());
}

Utilizad distintos tipos para distintas entidades

En el mundillo de las bases de datos hay dos escuelas: la escuela de los que utilizan INTs para las claves primarias y la escuela de los que utilizan UUIDs. Sea cual sea la escuela a la que pertenezca vuestro DBA, vuestro código va a acabar lleno de variables, todas del mismo tipo, que contienen claves primarias pertenecientes a distintas tablas.

long idArticulo = getLongParam("idArticulo");
long idComentario = getLongParam("idComentario");
Comentario comentario = cargaComentario(idArticulo, idComentario);
long idUsuario = comentario.idAutor();
Usuario usuario = cargaUsuario(idArticulo);
outputTemplate("comentario", usuario, comentario);

Este podría ser parte del código fuente de un CMS: una función que gestiona la respuesta a una operación HTTP GET para mostrar un comentario de un artículo. Esta función recibe un identificador de artículo y de comentario, carga el comentario y los datos del usuario que publicó el comentario, y los convierte a HTML para mostrarlos en el navegador.

La base de datos utiliza números enteros para las claves primarias, y el lenguaje las almacena en variables de tipo long. Tenemos una clave para el artículo, otra para el comentario y otra para el usuario. Y como todas estas claves van en variables del mismo tipo, es muy fácil confundirse y mezclarlas sin darse cuenta. De hecho, el código de arriba contiene un error. ¿Cuánto tiempo os lleva descubrirlo?

Aunque todas las claves primarias van en variables del mismo tipo, no son intercambiables. Si pasamos un identificador de usuario a una función que espera un identificador de artículo, esta función nos dará un resultado incorrecto. Lo malo es que no nos daremos cuenta de esta confusión hasta que probemos el programa y nos demos cuenta del error; o, peor todavía, hasta que un usuario lo vea y nos avise. O, lo peor de todo, nunca nos daremos cuenta y terminaremos corrompiendo datos.

Si estas claves no son intercambiables en la práctica, tampoco deberían ser intercambiables en el código. Podemos lograr esto muy fácilmente usando clases distintas para las claves primarias de cada tabla.

IdArticulo idArticulo = new IdArticulo(getLongParam("idArticulo"));
IdComentario idComentario = new IdComentario(getLongParam("idComentario"));
Comentario comentario = cargaComentario(idArticulo, idComentario);
IdUsuario idUsuario = comentario.idAutor();
Usuario usuario = cargaUsuario(idArticulo); // El compilador nos da un error aquí.
outputTemplate("comentario", usuario, comentario);

Crear estas clases es superfácil en la mayoría de los lenguajes modernos. Por ejemplo, en Java, podemos crear una clase base que incorpore toda la funcionalidad, y después añadir una línea de código para cada tipo.

public abstract class Id {
    private long id;
    public Id(long id) { this.id = id; }
    public long getId() { return id; }
    public String toString() { return getClass().getSimpleName() + "=" + id; }
}

public IdArticulo extends Id { public IdArticulo(long id) { super(id); } }

public IdComentario extends Id { public IdComentario(long id) { super(id); } }

public IdUsuario extends Id { public IdUsuario(long id) { super(id); } }

Esta técnica también os va a resultar útil en tareas de procesamiento de datos, en las que podríamos estar manejando datos pertenecientes a distintas etapas de procesamiento al mismo tiempo sin querer mezclarlos. Hoy en día, os la encontraréis más habitualmente a la hora de evitar XSS en aplicaciones web.

Muchas aplicaciones web necesitan recibir una cadena de texto del usuario, procesarla de alguna manera, y finalmente mostrarla en una página web. Si no tenéis cuidado y pegáis ese texto directamente en el HTML, os expondréis a un ataque XSS; como mínimo, tenéis que escapar esa cadena de texto antes de ponerla en el HTML. A veces, los programadores de las aplicaciones web se confunden y escapan una cadena dos veces, y después los usuarios ven cosas raras como “técnica” en lugar de “técnica”. O hacen mal el escape de cadenas para SQL y después los usuarios ven “O\'Connell” en lugar de “O'Connell”.

Para evitar estos problemas, muchos frameworks web modernos no nos permiten pegar strings directamente, sino que nos obligan a usar tipos especiales que contienen cadenas de texto ya escapadas. Podemos crear una instancia de uno de esos tipos a partir de una cadena sin escapar, y a partir de entonces ya no cabe confusión: dondequiera que utilicemos esa clase, es una cadena ya escapada y lista para insertar en código HTML.

Utilizad un solo tipo para una sola entidad

Es muy habitual utilizar ints y longs para representar intervalos de tiempo. La cuestión es: ¿en qué unidad? El sistema operativo Unix utiliza segundos pero los lenguajes Java y JavaScript utilizan milisegundos. Yo he trabajado con sistemas que utilizaban microsegundos y nanosegundos. Muchas veces es necesario utilizar distintas unidades en distintos lugares de un mismo programa, dependiendo de quién haya escrito el código o qué función reciba un determinado número.

El problema es que todos esos intervalos de tiempo se representan como un long, así sin más, sin marcar las unidades empleadas de ninguna manera, así que es muy fácil pasar a una función un número de milisegundos cuando espera segundos, o restar microsegundos de nanosegundos, u otras operaciones sin sentido que acabamos realizando sin querer.

Podríamos caer en la tentación de intentar solucionar este problema creando un nuevo tipo para cada unidad. Una clase Segundos almacenaría un intervalo medido en segundos, una clase Milisegundos almacenaría otro intervalo medido en milisegundos, y así sucesivamente. De esta manera ya no podríamos mezclar distintas unidades sin que el compilador se quejara.

El problema es que, muchas veces, necesitamos convertir entre unas unidades y otras; a veces tenemos una función que devuelve un intervalo medido en segundos que tenemos que pasar a otra función que espera milisegundos, así que necesitamos hacer una conversión. Otras veces, tenemos que combinar dos intervalos que pueden estar medidos en distintas unidades. Esto podríamos solucionando añadiendo funciones de conversión y de suma y de resta para cada par de unidades, pero con cuatro unidades, esto acabarían siendo cuarenta y cuatro funciones en total. Eso es un montón de funciones.

public class Segundos {
    public Milisegundos milisegundos() { return ... }
    public Microsegundos microsegundos() { return ... }
    public Nanosegundos nanosegundos() { return ... }
    public Segundos suma(Segundos otro) { return ... }
    public Segundos suma(Milisegundos otro) { return ... }
    public Segundos suma(Microsegundos otro) { return ... }
    public Segundos suma(Nanosegundos otro) { return ... }
    public Segundos resta(Segundos otro) { return ... }
    public Segundos resta(Milisegundos otro) { return ... }
    public Segundos resta(Microsegundos otro) { return ... }
    public Segundos resta(Nanosegundos otro) { return ... }
}
// Y otras tres veces igual para Milisegundos, Microsegundos y Nanosegundos

Francamente, esta opción no es sostenible. A poco que necesitemos añadir una o dos unidades u operaciones, tendremos que escribir una cantidad de código colosal y, para más inri, la mayor parte consistirá en operaciones de conversión.

La verdadera solución consiste en darse cuenta de que la entidad para la que estamos creando tipos de datos no es el número de segundos, milisegundos o microsegundos. La entidad es el intervalo de tiempo, y todas esas unidades no son más que maneras de medirlo. No necesitamos crear un tipo para cada unidad de tiempo; necesitamos crear un tipo para los intervalos de tiempo, que tenga las operaciones necesarias para poder expresar esos intervalos en las unidades adecuadas.

Por ejemplo, podríamos crear un tipo Intervalo que contenga una variable que expresa la longitud del intervalo en una unidad cómoda, y que también contenga funciones para expresar ese intervalo en segundos, milisegundos, microsegundos y nanosegundos, junto con funciones para hacer la conversión inversa.

public class Intervalo {
    private double valor;
    private Intervalo(double valor) { this.valor = valor; }
    // Constructores
    public static Intervalo deSegundos(long segundos) { return new Intervalo(segundos); }
    public static Intervalo deMilisegundos(long milisegundos) { return new Intervalo(milisegundos / 1e3); }
    public static Intervalo deMicrosegundos(long microsegundos) { return new Intervalo(microsegundos / 1e6); }
    public static Intervalo deNanosegundos(long nanosegundos) { return new Intervalo(nanosegundos / 1e9); }
    // Conversiones
    public long segundos() { return (long) valor; }
    public long milisegundos() { return (long) (valor * 1e3); }
    public long microsegundos() { return (long) (valor * 1e6); }
    public long nanosegundos() { return (long) (valor * 1e9); }
    // Combinaciones
    public Intervalo suma(Intervalo otro) { return new Intervalo(valor + otro.valor); }
    public Intervalo resta(Intervalo otro) { return new Intervalo(valor - otro.valor); }
}

Y esto es todo lo que necesitamos para poder representar intervalos de tiempo medidos en varias unidades, y cada vez que añadimos una nueva unidad, sólo necesitamos añadir dos funciones.

Ahora podemos utilizar esta clase para sustituir en nuestro código todos esos longs expresados en unidades indeterminadas, y así evitar todas las confusiones y oportunidades para errores que mencioné más arriba.

// Viejuno.
// ¿En qué unidad está el _timeout_? ¿Segundos? ¿Milisegundos? ¿Semanas?
Registro buscaRegistro(Identificador id, long timeout) { ... }

// La última moda.
Registro buscaRegistro(Identificador id, Intervalo timeout) { ... }

Muchos lenguajes de programación modernos incluyen una clase parecida a Intervalo en su biblioteca estándar. Por ejemplo, Java tiene el paquete java.time, que proporciona la clase Duration (junto con otra clase, llamada Instant, que representa un particular punto en el tiempo). El lenguaje C++, por su parte, proporciona el namespace std::chrono, con sus clases duration y time_point. En otros lenguajes hay bibliotecas de terceros que la proporcionan. Utilizadlas siempre que podáis; nunca uséis longs para representar el tiempo.

Conclusiones

A veces, utilizar un tipo primitivo del sistema es lo más sencillo pero puede acabar dándonos muchos quebraderos de cabeza. Tenemos que pensar en si el número que almacenamos en ese long es realmente un número o si lo que hay en ese string es una cadena de texto sin más, y crear y utilizar nuevos tipos de datos cuando éstos tengan algún tipo de complicación o restricción o invariante.

Los humanos sabemos que no podemos sumar dos cerezas a tres naranjas, pero los ordenadores, si sólo ven dos longs o dos doubles, los sumarán y dividirán sin pensárselo dos veces. Nosotros, los humanos que sabemos que las entidades distintas pertenecen a tipos distintos, tenemos que comunicarle esta distinción al ordenador, en forma de nuevos tipos de datos.

Y finalmente, nosotros sabemos que 60 segundos es lo mismo que un minuto, o que 5000 metros equivalen a 5 kilómetros; sin embargo, el ordenador sólo ve una variable que dice “60” y otra que dice “1”, o un valor “5000” y otro “5”. Depende de nosotros decirle al ordenador que ambas cosas son la misma.

La próxima vez que penséis en que estaría bien si pudiéseis “anotar” o “marcar” un número o una cadena de texto para tratarla especialmente, probad a crear y utilizar un nuevo tipo de datos. Al hacerlo, estoy seguro de que vuestros programas serán mucho más fiables y fáciles de leer y modificar.

The bandwidth of a Morse Code signal

Wed, 13 May 2020 00:00:00 +0000

In most countries, you need to pass an examination to get an amateur radio license. In the US, the question pool is public, so a big part of studying for the license consists of going through the whole question pool and making sure you know the answers to every question. One of them tripped me for a bit:

T8A11
What is the approximate maximum bandwidth required to transmit a CW signal?
    A. 2.4 kHz
    B. 150 Hz
    C. 1000 Hz
    D. 15 kHz

(To normal people, a CW signal is a “beeping Morse code signal”.)

Now, a CW signal is pretty much a sinusoidal wave, and I knew that a pure sinusoidal wave takes a tiny, tiny bandwidth, so I could eliminate answers “A”, “C”, and “D” straight away. That left “B”, but I didn’t know why it would be the right answer, so I had to think about it for a while.

It is true that a sinusoidal signal takes very little bandwidth. If a CW signal consisted just of a steady sinusoidal carrier that never turned off and on, it would indeed have an extremely low bandwidth, only limited by the transmitting oscillator’s stability.

However, a CW signal is not a steady sinusoidal; it is modulated. In particular, it is modulated by turning it off and on according to a message that’s encoded using Morse code. This modulation causes the CW signal to have a bigger bandwidth than a steady carrier.

As an extreme, we can imagine that we want to transmit a series of Morse dots at 30 words per minute. That would be equivalent to switching the carrier on and off 25 times every second. That’s a 12.5-Hz signal that, when modulated, requires a 25-Hz bandwidth at the very minimum (12.5 Hz on each sideband). In practice, the required bandwidth would be higher, depending on how abruptly the carrier was switched on and off.

To demonstrate it, I wrote a widget to simulate a CW signal being received by a CW radio with a filter centered at 600 Hz. It can play the received signal on your speakers and show its frequency spectrum on your screen. The top half displays an instantaneous chart (with horizontal lines every 40 dB), while the bottom displays a waterfall plot. The vertical lines indicate the frequency of the received signal, with dashed lines every 500 Hz and continuous lines every 1000 Hz.

Let’s first look at (and listen to) a transmitter that produces a signal with very abrupt off/on and on/off transitions. Go ahead and press “Play”:

As you can see, when the carrier is steady on, the signal does not use much bandwidth; it is when the signal switches on or off that it uses a lot of bandwidth. This bandwidth usage depends on how sudden the on/off transitions are. Above, the switches were instantaneous, so the signal uses a lot of bandwidth, which is not good.

To avoid using so much bandwidth, many radio transmitters ramp the signal up and down over 5 milliseconds instead of cutting it on and off. This lowers the bandwidth usage without really affecting the sound. You can check it out by pressing “Play” on the widget below:

That’s not the whole story, however. The widgets above simulate a radio with a receive filter, so they don’t show the whole bandwidth that’s used by the signals. The widgets below had their filters removed, so they can show how much bandwidth is really used in each case. The one on the left is the original signal that switches on and off suddenly, while the one on the right is the modified signal with 5-millisecond transitions:

The difference is undeniable. On the left, the on/off transitions appear as broadband energy spikes that are almost as powerful as the signal itself across the whole band. On the right, the spikes still produce quite a bit of power, but it occupies a smaller bandwidth and their power goes down faster as they get further from the central frequency.

The huge amount of power produced by sudden on/off switches causes an annoying effect, called “key clicks”. Press “Play” on the widget below to hear it:

In this widget, there is a signal being transmitted 2800 Hz above where we are listening, so it’s outside of what the filter will let through and we can’t hear it. However, the filter lets through some of the energy that comes from the carrier being switched on and off, and it can be heard as clicks.

These “key clicks” are very annoying since they could even drown out real signals and they can often be heard quite far away from the signal’s frequency, so if your transmitter produces clicks, other amateur radio operators will be quick to find you to tell you what they think of your radio transmitter.

On a transmitter with a 5-millisecond ramp time there isn’t so much power outside of the signal, so the filter doesn’t let so much energy through and there are no clicks. Press “Play” on the widget below to hear the result:

This is the part where you can do your own experiments with key clicks. Here are two widgets you can try: the left one is clicky, while the right one is not clicky. Both have a slider you can use to modify the signal’s frequency and see where the clicks are present, or where the signal is louder than the clicks.

Found anything interesting? Let me know what you think!

Mi bug más memorable

Sat, 02 May 2020 00:00:00 +0000

Este mes se cumplen diez años de aquella vez en que mi equipo y yo pensamos por un rato que nos íbamos a ver envueltos en un incidente diplomático internacional.

Era mayo de 2010, y hacía unos meses que me había incorporado al equipo del servidor de gadgets de Google en Mountain View (California), procedente de la oficina de Google en Dublín (Irlanda).

Si os acordáis de iGoogle, seguro que también recordaréis los gadgets. iGoogle era el portal personalizable de Google y tenía unas ventanitas, llamadas “gadgets”, que los usuarios podían seleccionar y poner en su página de iGoogle según su antojo. Había gadgets para ver el email, las noticias o el pronóstico del tiempo, e incluso había uno que hacía conversiones de unidades de medida (de metros a pies, de pintas a litros, etc.). Nuestro equipo se encargaba del sistema que mostraba los gadgets a los usuarios.

Un día nos llegó un aviso que decía que, en Taiwán, el gadget de conversión de unidades no aparecía en caracteres chinos tradicionales, que son los que se utilizan en Taiwán, sino en caracteres chinos simplificados, que son los que se utilizan en la China continental.

En aquellas fechas, Google y China no estaban atravesando el mejor momento de su relación: unos meses antes, Google había descubierto una serie de ataques por parte de hackers procedentes de China y anunció que cerraba el buscador especial para China que censuraba ciertos resultados. A partir de entonces, los usuarios chinos usarían el buscador normal sin censura. A China no le gustó esta reacción, ni a Google le había gustado la acción original.

Con tanta tensión entre Google y China, la noticia de que los usuarios en Taiwán veían un gadget como si estuviesen en China tampoco fue del agrado del equipo del servidor de gadgets. ¿Tal vez había alguien en China interceptando el tráfico de Google para Taiwán? Deseábamos de todo corazón que no fuera cierto, y aunque no pensábamos de verdad verdadera que eso era lo que estaba pasando, necesitábamos llegar al fondo del asunto.

El primer paso cuando se recibe un aviso de error es intentar reproducirlo: no es posible investigar un error que no se puede ver. Sin embargo, por más que lo intentaba, yo no era capaz de reproducir el error. Enviaba peticiones para ver el gadget como si fuera un usuario de Taiwán, pero siempre lo veía en chino tradicional, como si no hubiera ningún error. Lo intenté de una y otra manera, pero sin ningún resultado.

Después se me ocurrió enviar la misma petición a todos los servidores al mismo tiempo y ver si había diferencias entre ellos. Nuestro servicio recibía peticiones de todo el mundo, así que también teníamos servidores repartidos por todo el planeta y las peticiones llegaban automáticamente al servidor más cercano. Cuando yo hacía mis pruebas, mis peticiones iban a un servidor situado en los EEUU, pero las peticiones procedentes de Taiwán iban a un servidor ubicado en Asia. En teoría, todos los servidores eran idénticos, pero ¿y si no lo fueran?

Preparé una página web que enviaba peticiones directamente a todos los servidores, la cargué en mi navegador, y entonces vi que algunos servidores daban respuestas diferentes. La mayoría de los servidores en Europa y América respondían con el gadget en chino tradicional, que era el resultado correcto; sin embargo, la mayoría de los servidores en Asia respondían en chino simplificado.

Para hacerlo más misterioso, no todos los servidores en cada lugar me daban el mismo resultado: algunos daban la respuesta correcta y otros la respuesta incorrecta, pero la proporción entre uno y otro era distinta dependiendo de la ubicación.

Después de hacer muchas pruebas, me di cuenta de que había una especie de efecto memoria. Durante varios minutos después de enviar una petición para ver el gadget en chino simplificado, los servidores respondían en chino simplificado a todas las peticiones en chino tradicional. También ocurría al contrario: tras una petición en chino tradicional, los servidores respondían en chino tradicional a las peticiones en chino simplificado.

Esto explicaba por qué la mayor parte de los servidores en Asia respondían en chino simplificado: la mayoría de los usuarios hablantes de chino viven en China, por lo que usan caracteres simplificados. La mayoría de las peticiones procedentes de China iba a servidores en Asia, por lo que éstos recibían peticiones en chino simplificado. Entonces estos servidores se quedaban “atascados” en chino simplificado y, cuando recibían una petición en chino tradicional, daban una respuesta en chino simplificado.

Sentí un gran alivio cuando di con esta explicación, ya que significaba que el problema no había sido causado por una acción de interceptación de tráfico al nivel de una nación-estado, sino que era un error de programación normal y corriente. No obstante, todavía necesitábamos arreglarlo, y los síntomas sugerían que estaba causado por un problema con una caché.

Los gadgets estaban definidos en un fichero XML. Los gadgets también podían estar traducidos a varios idiomas, así que el texto del gadget en cada idioma estaba guardado en otro fichero XML, y el fichero de definición del gadget contenía una lista que indicaba qué idioma aparecía en qué fichero de traducción.

Cada vez que alguien quería ver un gadget, el servidor tenía que descargar el fichero XML de definición, interpretarlo, determinar qué fichero de traducción tenía que usar, descargar el fichero XML de traducción e interpretarlo también. Algunos gadgets tenían millones de usuarios, por lo que el servidor tendría que descargar e interpretar los mismos ficheros una y otra vez. Para evitarlo, el servidor de gadgets tenía una “caché”.

Una caché es una estructura de datos que almacena el resultado de una operación para evitar tener que realizar esa operación repetidamente. En el servidor de gadgets, la caché almacenaba ficheros XML que había descargado e interpretado anteriormente. Cuando el servidor necesitaba un fichero, primero miraba si ya estaba en la caché; si lo estaba, podía utilizarlo directamente sin necesidad de descargarlo e interpretarlo. Si no, el servidor descargaba el fichero, lo interpretaba y almacenaba el resultado en la caché para poder utilizarlo en el futuro.

Mi teoría inicial era que, de alguna manera, la caché podría estar confundiendo los ficheros de traducción al chino simplificado y chino tradicional. Me pasé varios días inspeccionando el código y el contenido de la caché, pero no pude ver ningún problema. Hasta donde yo podía ver, la caché de ficheros XML estaba implementada correctamente y funcionaba perfectamente. Si no fuera porque podía verlo con mis propios ojos, habría jurado que era imposible que el gadget mostrara el idioma incorrecto.

Durante el tiempo que invertí en inspeccionar el código, también estuve intentando reproducir el problema en mi ordenador. Los servidores de producción se quedaban “atascados” durante unos minutos en chino simplificado o chino tradicional, pero esto no sucedía nunca cuando ejecutaba el servidor en mi ordenador: si enviaba peticiones mezcladas, también recibía respuestas mezcladas. Por lo tanto, una vez más, no podía reproducir el problema de forma controlada.

Por este motivo tomé una decisión drástica: iba a conectar un depurador a un servidor en la red de producción y reproducir el error allí.

A buen seguro, no iba a hacer eso con un servidor de producción. En aquel momento teníamos varios tipos de servidores: no sólo servidores de producción, que recibían las peticiones procedentes de usuarios normales; también teníamos servidores “sandbox”, que no tenían usuarios externos, sino que los usábamos para que iGoogle y otros servicios que usaban gadgets pudiesen hacer pruebas sin afectar a los usuarios. Yo no iba, ni de lejos, a conectar un depurador a un servidor de producción y arriesgarme a afectar a usuarios externos; lo haría todo en un servidor “sandbox”.

Así pues, elegí uno de los servidores “sandbox”, lo preparé, le conecté un depurador, reproduje el error, lo investigué y, finalmente, dejé todo como estaba antes. Tras mi investigación confirmé que, como yo pensaba, era un problema de caché, pero no el problema de caché que yo me esperaba.

Según mi teoría, el programa acudiría a la caché para obtener el fichero con la traducción al chino tradicional pero la caché respondería con el fichero incorrecto. Mi intención era interrumpir el programa justo antes de que solicitara el fichero XML y ver qué ocurría. Para mi sorpresa, la caché funcionó correctamente: el programa solicitó el fichero con la traducción al chino tradicional y la caché proporcionó la traducción al chino tradicional, tal como debía ser. Obviamente, el problema tenía que estar en otro sitio.

Después de obtener la traducción, el programa la aplicó al gadget. En los gadgets con traducciones, el fichero de definición no incluía ningún texto en ningún idioma; en su lugar, incluía unas marcas que el servidor sustituía por el texto que aparecía en el fichero de traducción. Y, en efecto, eso es lo que hizo el servidor: tomó el fichero XML de definición del gadget, buscó las marcas y, dondequiera que hubiese una marca, la sustituyó por el correspondiente texto en chino tradicional.

El siguiente paso era interpretar el fichero XML resultante.

Había muchísima gente que utilizaba el gadget de conversión de unidades traducido a caracteres chinos tradicionales. Esto significa que, después de sustituir las marcas por texto en chino, el servidor tendría que interpretar el mismo código XML resultante una y otra vez. Ya que el servidor tenía que interpretar el mismo código varias veces al día, éste utilizaba una caché para ahorrarse todo ese trabajo redundante, y hasta ese momento yo no tenía ni idea de que esa caché existía.

Ésta era la caché que daba el resultado incorrecto: la caché recibía el fichero XML con textos en chino tradicional y devolvía el resultado de interpretar el mismo fichero XML con textos en chino simplificado.

Lo que necesitaba determinar era por qué sucedía eso.

Las cachés funcionan asociando una clave a un valor. Por ejemplo, la primera caché de la que hablé en este artículo, que evitaba tener que descargar e interpretar ficheros XML repetidamente, usaba el URL del fichero como clave y el fichero interpretado como valor.

La nueva caché, que se utilizaba para evitar tener que interpretar repetidamente ficheros de definición con una traducción aplicada, usaba de clave el fichero XML representado como un array de bytes. Para obtener la clave, el servidor llamaba a la función String.getBytes(), que convierte una cadena a un array de bytes utilizando la codificación predeterminada.

En mi ordenador, la codificación predeterminada era UTF-8. Esta codificación representa cada carácter chino en dos o tres bytes. Por ejemplo, UTF-8 representa el texto “你好” como los bytes {0xe4, 0xbd, 0xa0, 0xe5, 0xa5, 0xbd}.

En los servidores, sin embargo, la codificación predeterminada era US-ASCII. Esta codificación es muy antigua (1963) y sólo contempla el alfabeto latino utilizado en el idioma inglés, por lo que no puede codificar los caracteres chinos. Cuando getBytes() encuentra un carácter que no puede codificar, lo sustituye por un signo de interrogación. Por lo tanto, el texto “你好” queda convertido en “??”.

Y aquí estaba el problema: cuando el servidor, que utilizaba US-ASCII, generaba una clave, ésta consistía en un fichero XML con cada carácter chino sustituido por un signo de interrogación. Como las traducciones al chino simplificado y chino tradicional usaban el mismo número de caracteres, aunque éstos fuesen distintos, las claves resultaban ser idénticas, por lo que el servidor respondía con el valor que había en la caché aunque fuese en la variante de chino incorrecta.

En cambio, este problema no era reproducible en mi ordenador, ya que usaba UTF-8, que sí contempla los caracteres chinos. Por lo tanto, las claves eran diferentes y la caché respondía con el valor correcto.

Después de varias semanas probando esto y aquello, inspeccionando el código, batiéndome en vano con la caché y, finalmente, tomando medidas desesperadas, la solución a este error consistió en sustituir todas las llamadas a getBytes() para usar la codificación UTF-8 de forma explícita.

Esta historia comenzó como una intriga de espionaje a nivel internacional y terminó cambiando una función para especificar la codificación. Supongo que es un final un poco anticlimático, pero al menos todos los miembros del equipo estábamos contentos de no tener que acudir a testificar al Congreso de los EEUU ni nada parecido.

Aún así, este episodio grabó a fuego en mi mente la importancia de especificar siempre todos los parámetros de los que depende el programa y no dejar nada implícito o dependiente del entorno. Nuestro servidor falló porque dependía de un parámetro de configuración que era diferente en nuestros ordenadores y en producción; si hubiésemos especificado la codificación UTF-8 de forma explícita desde el principio, esto nunca nos habría pasado.

Y yo no tendría una historia tan chula para contar.

No se puede tener todo.

Una antena casera de onda corta para radioaficionados

Wed, 29 Apr 2020 00:00:00 +0000

Un día, en el verano de 2002, estaba navegando por Internet y caí en una página web en la que un radioaficionado describía sus experimentos haciendo rebotar ondas de radio en la Luna. Esa página me tuvo cautivo durante varias horas viendo fotos de sus gigantescas antenas, vídeos en los que enviaban código Morse y recibían el eco dos segundos y medio después, e informes sobre cómo dos radioaficionados en extremos opuestos del mundo se comunicaban usando la Luna como reflector.

Como soy un pedazo de friki, durante los siguientes días pensé en lo interesante que sería sacarme la licencia de radioaficionado e instalar una pequeña estación de radio en casa (no tan potente como para hacer rebotar señales en la Luna, pero sí para comunicarme con otros países). Sin embargo, aquél no era el mejor momento para esas ideas: estaba intentando terminar la carrera y tenía varias asignaturas pendientes para setiembre, por lo que mis padres no verían con buenos ojos esa nueva distracción. Además, entonces era necesario aprender código Morse para obtener la licencia. Por no hablar de la antena; seguro que necesitaría una antena muy grande. Quita, quita…

Una torre de antenas de radioaficionado construida sobre una casa en Palo Alto (California). En lo más alto tiene una antena omnidireccional para VHF y UHF; debajo, un dipolo, posiblemente para 20 metros; debajo del dipolo, una antena direccional tipo Yagi, probablemente para 10 metros. El dipolo y la antena Yagi se pueden girar con un motor para orientarlas hacia otras antenas distantes.

Varios años después, en 2013 y 2014, se popularizó el uso de descodificadores de TDT como receptores de radio definidos por software (SDR). Estos descodificadores tienen un modo especial en el que pueden recibir ondas de radio, digitalizarlas y pasarlas al ordenador para que éste las procese. Con este sistema es muy fácil experimentar con radio y, en muy poco tiempo, mucha gente hizo programas para escuchar la radio, recibir transmisiones ADS-B procedentes de aviones, recibir fotos meteorológicas directamente del satélite, etc.

Pronto cayó en mis manos uno de estos descodificadores e hice una app de Chrome para escuchar la radio. No tardé mucho tiempo en añadirle la capacidad de escuchar transmisiones de radioaficionados y, poco tiempo después, se me ocurrió otra vez la idea de sacarme la licencia. Me compré los libros, estudié (ya no era necesario aprender Morse) y en 2015 obtuve licencias en los EEUU y en España. Ahora realizo contactos por onda corta con un montón de radioaficionados, y, para mi alivio, no he tenido que instalar una antena gigantesca.

La mayoría de los radioaficionados no nos podemos permitir tener una torre como la de la foto de arriba (¡ojalá!). Muchos vivimos en pisos de alquiler, o los códigos urbanísticos no permiten este tipo de estructuras, o no tenemos espacio, o… miles de razones. Por este motivo, la historia de la radioafición es también la historia de la búsqueda de antenas compactas que se puedan utilizar en espacios limitados.

Durante estos años he probado a construir y utilizar varias antenas. Cuando vivía en California vivía en un bajo con un balcón cubierto, así que construí una antena de bucle magnético. Estas antenas son muy compactas pero también son engorrosas; tienen muy poco ancho de banda, así que es necesario reajustarlas cada vez que uno cambia de frecuencia.

Después de mudarme a Nueva York tuve un patio de 6 por 6 metros con un árbol, así que me construí una antena vertical hecha con cables eléctricos. Esta antena es multibanda, portátil y fácil de utilizar, y es la que os voy a describir en este artículo.

Descripción de la antena

Mi antena vertical consta de varios elementos: un radiador, seis radiales, un acoplador, un unun y, por supuesto, un cable coaxial que la conecta al transmisor de radio.

El radiador es el componente que asciende verticalmente y da el nombre de “vertical” a la antena. Está formado por un cable eléctrico de unos 15 metros de largo. Cualquier cable eléctrico sirve, pero es conveniente elegir uno que sea ligero y resistente, ya que va a estar colgado de un árbol y va a sufrir la acción del viento y del sol.

Los radiales son seis cables eléctricos de cinco metros de largo que forman el “plano de tierra” de la antena. Todos ellos reposan directamente en el suelo, están conectados en un solo punto y luego salen en línea recta en todas las direcciones, como los radios de una rueda de bicicleta. Igual que para el radiador, cualquier cable sirve.

El acoplador hace ajustes para que la diferencia de impedancia entre la antena y la línea de transmisión no afecte negativamente a la radio. El acoplador es opcional, pero entonces tendréis que cortar el radiador a una longitud específica para que funcione en una banda. El acoplador os permite utilizar la antena en las bandas de 20, 40 y 60 metros, entre otras.

Finalmente, el unun se encarga de eliminar interferencias de la línea de transmisión. Al transmitir, la antena induce corrientes en el cable coaxial que viene de la radio y el acoplador detecta esas corrientes, piensa que son debidas a un desajuste en la antena, e intenta arreglarlo, con lo que se desajusta por completo. El unun elimina esas corrientes antes de que lleguen al acoplador, por lo que éste funciona correctamente.

Primera foto: el cable que utilizo para el radiador. Es un cable trenzado de acero revestido de cobre diseñado específicamente para antenas portátiles, pero sirve cualquier tipo de cable que sea lo suficientemente ligero y resistente.
Segunda foto: detalle de la conexión del radiador y los radiales al acoplador. Utilizo un adaptador de bornes para conectar la antena; el radiador está conectado al borne rojo y los radiales al borne negro. El adaptador de bornes es opcional: podría haber enchufado el radiador directamente al centro del conector “Ant” y los radiales al tornillo “Gnd”.
Tercera foto: el acoplador (LDG Z11 Pro II, caja negra con botones grises) y el unun (LDG RU-1:1, caja azul) después de haber hecho todas las conexiones. Los radiales están extendidos en todas las direcciones. La caja negra con la etiqueta blanca contiene 8 pilas tipo AA para proporcionar 12 voltios al acoplador.

Cómo utilizar la antena

Para usar esta antena es necesario colgar el radiador de un árbol, un poste o una estructura similar. Preferiblemente, esa estructura debería estar hecha de un material no conductor. Por ejemplo, una caña de pescar hecha de fibra de vidrio serviría, pero no una caña de pescar hecha de fibra de carbono.

Para colgar la antena yo utilizo un sedal y un peso de plomo. Primero ato el plomo al sedal, lo voleo como si fuera una honda y lo arrojo por encima de la copa del árbol. Con un poco de suerte, el plomo irá suficientemente alto, no chocará con ninguna rama y aterrizará al otro lado del árbol.

Hay algo de peligro de que el sedal se enrede en las ramas del árbol. En mi experiencia, esto ocurre principalmente si interfiero con el vuelo del plomo. Si lo lanzo y luego no toco el sedal hasta que el plomo llegue al suelo, casi siempre irá todo bien. Si lo lanzo y luego agarro el sedal para intentar controlar el vuelo del plomo, hay mucho peligro de que el plomo haga un extraño alrededor de una rama y se quede atascado.

Después de haber arrojado el sedal por encima del árbol puedo ir al plomo, desatarlo del sedal, atar la punta del radiador al sedal y luego izar el radiador. Después de esto sólo queda conectar el radiador y los radiales al acoplador, éste al unun y finalmente conectarlo al transmisor con un cable coaxial.

Los dibujos de debajo muestran distintas posibles configuraciones de la antena que podéis usar dependiendo de cuánto espacio tengáis, dónde estén vuestros árboles, etc. Fijaos en que un extremo del sedal está atado al radiador pero el otro extremo no está atado a ningún punto fijo, sino a un peso que lo mantiene tenso pero lo permite oscilar. Esto es importante porque el árbol y el radiador van a sufrir los embates del viento y se menearán en todas direcciones. Si atáis el sedal, es posible que, al moverse, tire del radiador demasiado fuerte y lo rompa. Al usar un peso que oscila libremente, no hay peligro de que esto ocurra.

Si vuestro radiador es más pesado que el mío, es muy probable que un sedal no sea lo suficientemente fuerte para izarlo. En ese caso deberíais usar un cordel más resistente; por ejemplo, una línea de arborista con su correspondiente peso.

En condiciones ideales, con un árbol suficientemente alto y suficientemente cerca, el radiador colgará verticalmente o casi verticalmente (primera figura). No siempre tenemos condiciones ideales, así que a veces hay que hacer adaptaciones. Por ejemplo, si el árbol está un poco lejos, podemos inclinar el radiador (segunda figura). Si el árbol no es lo bastante alto, tal vez tengamos que pasar parte del radiador por encima de la rama y dejarlo colgando de ésta (tercera figura). En ciertos casos, tal vez tengamos que dejar que el radiador zigzaguee por todo el sitio (cuarta figura).

Los radiales deberían salir de debajo del radiador y extenderse en línea recta y en todas direcciones. Si no tenéis espacio, tal vez necesitéis apañároslas de una u otra manera. Al final, lo más importante es que el plano de tierra sea lo más tupido, simétrico y uniforme posible, añadiendo radiales y alargándolos donde podáis o acortándolos donde no os quede más remedio.

Lo ideal sería distribuir los radiales de una forma simétrica y uniforme (primera figura). Si el espacio es limitado, siempre podéis doblar y plegar los radiales un poco para adaptarlos al sitio, aunque es conveniente que vayan lo más rectos posible (segunda figura). Ante la duda, lo mejor es poner muchos radiales para llenar el espacio disponible (tercera figura).

Dependiendo de la configuración del radiador y de los radiales, el patrón de radiación de la antena tendrá una u otra forma, así que sería inútil tratar de caracterizarlo en esta página web, pero en general, la máxima ganancia tiende a ser perpendicular al radiador y, si los radiales no son simétricos, habrá menos ganancia en la dirección en la que haya menos radiales o éstos sean menos densos.

Por lo tanto, si queréis una antena omnidireccional con buen DX, tratad de colgar el radiador más vertical que podáis y colocad los radiales lo más simétricos que podáis.

Conclusiones

He estado utilizando y mejorando poco a poco esta antena desde que me mudé a Nueva York. Como está hecha con cables eléctricos, es muy portátil, así que he podido utilizarla en mi patio en Brooklyn (6 por 6 metros con un árbol de unos 8 metros) y también en la casa de mis suegros en Connecticut (muchísimo espacio y un árbol de unos 12 metros). Gracias al acoplador, puedo utilizarla en las bandas de 20, 40 y 60 metros, así como otras bandas a las que no presto mucha atención.

En Nueva York casi siempre hago un zig-zag con el radiador y tengo que doblar los radiales un poco. Hay edificios justo al norte de la antena, así que no puedo recibir en esa dirección. Además, siendo Nueva York, hay un montón de ruido eléctrico. Aún así, he podido comunicarme con Brasil y con Polonia usando 50 vatios.

En Connecticut el radiador va completamente extendido pero inclinado hacia el norte, y el suelo también hace una ligera pendiente ascendente hacia el noroeste, por lo que también me es difícil hacer contactos en esas direcciones. Sin embargo, consigo muchos contactos con las islas del Caribe y con Europa. Mis contactos más lejanos son Serbia y Argentina, también con 50 vatios, aunque he podido, en ocasiones, oir estaciones australianas.

Contactos realizados con mi antena vertical. Los puntos azules son contactos realizados desde Brooklyn; los puntos marrones son contactos realizados desde Connecticut. También podéis ver el mapa actualizado con los últimos datos. (Mapa proporcionado por Google).

En el futuro cercano tengo pensado duplicar el número de radiales, de seis a doce. Esto debería mejorar el rendimiento de mi antena en 1 o 2 decibelios. También tengo interés en probar un poste extensible de fibra de vidrio (una “caña de pescar”) que me permita extender el radiador verticalmente sin necesidad de un árbol.

¡No dudéis en poneros en contacto conmigo si tenéis preguntas o sugerencias, o si queréis planear un contacto por radio!