La liga española de fútbol se fundó en 1929. El Real Madrid es el equipo que más veces la ha ganado, con 31 campeonatos, seguido del FC Barcelona con 20 y sólo en 28 ocasiones otro equipo se ha llevado el gato al agua- es decir, menos de un 40%.

Desde la temporada de 1929 hasta la temporada 1952-53, el FC Barcelona llevaba una ligera ventaja al Real Madrid, 6-2; aunque la liga estaba bastante más disputada; el Athletic de Bilbao se la llevó en 5 ocasiones, el Atlético de Madrid/Atlético de Aviación 4 y el Valencia 3- un 60% de las ligas se las llevaba alguien que no era ni Barça ni Madrid.

A partir de 1953-54, se da un cambio de tendencia. Hasta la temporada 87-88, el Madrid ganaría 21 ligas de 35 (el 60%), mientras que el Barça sólo ganó 4, empatado con el Atlético de Madrid y seguido del Athletic de Bilbao con 3.

En 1988, sin embargo, hubo un hecho que cambió otra vez la tendencia. Un holandés llamado Johann Cruyff fichó como entrenador del FC Barcelona. No ganó la liga el primer año que estuvo, ni el segundo (las ganó el Madrid), pero ganó cuatro ligas seguidas desde la temporada 1990-91 a la 1993-94. Hasta que se marchó al final de la temporada 1995-96, con esas 4 ligas se impuso estrechamente a las 3 conseguidas por el Real Madrid- más la primera Copa de Europa conseguida por el FC Barcelona.

A partir de entonces,  se han disputado 14 ligas más, en las que el FC Barcelona sigue ligeramente por delante del Real Madrid con 6 títulos ligueros contra 5 del Real Madrid.

Está claro que desde los años 50 hay dos grandes periodos, separados por la llegada de Cruyff al Barcelona; tomando como punto de referencia la primera liga de Cruyff, los números cantan: 23-4 para el Real Madrid primero y 10-6 para el FC Barcelona luego. De un dominio aplastante del Real Madrid (mayoría absoluta [60%] de victorias) a una ligera superioridad culé (sólo si este año gana la liga llegará al 50%).

Mientras tanto, en Europa… ¿qué pasó?

Pues algo parecido, hasta la primera liga de Cruyff, el Real Madrid había ganado la Copa de Europa en 6 ocasiones; las 5 primeras ediciones de la competición más una más en el 65. El FC Barcelona, ninguna.

A partir del 92, año donde Cruyff ganó su segunda liga, el Barça se ha llevado 3 copas de Europa, 1991-92 con Cruyff, 2005-06 con Rijkaard y 2008-09 con Guardiola. En el mismo periodo, el Real Madrid iguala esto con las 3 del 1997-98 (entrenados por Heynckes y gol en la final de Mijatovic), 1999-2000 y 2001-02 (las dos con del Bosque en el banquillo, la 2001-02 con Zidane y los galácticos).

¿Existen ciclos de dominación?

Yo creo que sólo existe uno, la hegemonía del Real Madrid hasta la segunda liga de Cruyff en el 91; 6 copas de Europa y el 60% de las ligas.

Tras llegar Cruyff, tras sus 4 ligas, realmente hay una igualdad a 6 ligas y 3 copas de Europa. Si consideramos que de las 4 ligas de Cruyff, la mitad se ganaron en la última jornada por cataclismos merengues en Tenerife… tenemos más argumentos en favor de esta igualdad.

A parte de esto, cabe apuntar que a partir del 91, el Madrid sólo ha conseguido dos ligas seguidas una vez; 2006-07 y 2007-08- curiosamente la primera con Capello, que fue cesado tras ganar para que llegase Bernd Schuster, yo no las consideraría una racha; eran dos equipos bastante diferentes. Si acaso la racha serían las dos copas de Europa seguidas mencionadas anteriormente conseguidas por Del Bosque.

En el Barcelona, algo similar. Consiguió dos ligas seguidas en 1997-98 y 1998-99, la primera con Robson y la segunda con Van Gaal; 2004-05 y 2005-06; estas sí que ambas con Rijkaard y 2008-09/2009-10 con Guardiola.

Es decir, que no ha habido prácticamente continuidad.

Todo esto me lleva a pensar que sí, Cruyff entrenador cambió sustancialmente la dinámica de la liga Española. De la hegemonía del Madrid hemos pasado a una hegemonía de Barça y Real Madrid, con una ligera, ligerísima ventaja para el FC Barcelona conseguida en la mejor época cruyffista.

Hasta que no pasen unos cuantos años más, creo que no podremos decir mucho más.

Desde el principio de los tiempos, los humanos han deseado en ocasiones mantener la privacidad de sus comunicaciones. En tiempos de los romanos ya se utilizaban técnicas de criptografía como el cifrado César para las comunicaciones militares.

El cifrado César consiste en la sustitución simple de unas letras por otras, por ejemplo, sustituir la “a” por “c”, “b” por “d”, “c” por “e”, etc. Con lo que por ejemplo, “cifrado cesar” se convertiría en “ekhtcfq eguct”. Este sistema (y muchos otros) se basa en el secreto del sistema- sólo el emisor y receptor del mensaje conocen el método de cifrado y la manera en la que se realiza- en este caso, que cada letra se sustituye por la letra que existe a dos posiciones en el orden alfabético; lo que se conoce como clave secreta.

A pesar de que el cifrado César no ofrece prácticamente ninguna seguridad (una persona que intercepte un mensaje puede fácilmente deducir el sistema usado y desencriptarlo), sí que existen mecanismos de encriptación muy potentes basados en el secreto de la clave (básicamente, un sistema de clave secreta fuerte es aquel en el que podemos hacer que los mensajes sean más difícilmente desencriptables escogiendo claves más complejas).

Sin embargo, en muchas situaciones, los sistemas de claves secretas no son muy útiles. Para hacerlos funcionar, el emisor y el receptor deben poder compartir la clave de una manera segura antes de poder utilizarla.

Pongamos por ejemplo el caso de que queramos realizar transacciones seguras por internet, por ejemplo compras online. Como internet no es un canal de comunicación seguro (es razonablemente sencillo espiar, interceptar y alterar comunicaciones), antes de realizar cualquier compra a un vendedor online, deberíamos poder quedar con el vendedor y acordar una clave secreta por un canal seguro- por ejemplo, quedando presencialmente e intercambiando la clave, algo que no parece nada práctico.

Un investigador de una agencia de inteligencia británica dio en 1973 con un sistema tremendamente sencillo para resolver este problema. Lamentablemente, no lo pudo implementar ni publicar- ya que en ese momento no disponían de los sistemas informáticos suficientemente potentes como para hacerlo funcionar, y al formar parte de una agencia de inteligencia, se consideró un secreto de estado. En 1978, un trío de matemáticos- Rivest, Shamir y Adleman redescubrieron independientemente este sistema y lo publicaron con un nombre tomado de sus iniciales: RSA.

El sistema se basa en un concepto sencillo. En los esquemas de clave secreta, se utiliza una única clave y dos funciones matemáticas de codificación y decodificación. Formalmente, sea un mensaje m, una clave k, y dos funciones E(m,k) y D(m,k), se cumple que D(E(m,k),k)=m; es decir, que las codificar y decodificar un mensaje con la misma clave, se obtiene de nuevo el mensaje original.

El nuevo esquema RSA se basa en que las claves de codificación y decodificación son diferentes, y a pesar de que están íntimamente relacionadas, conocer una no implica conocer la otra. Con esto, yo puedo crear un par de claves; a una la llamaré clave pública y a la otra privada- siguiendo sus nombres, difundiré mi clave pública pero conservaré en secreto mi clave privada.

Así, cualquiera que quiera enviarme un mensaje, podrá coger mi clave pública y codificar el mensaje con ella. Sólo yo, con mi clave privada, podré descifrarlo.

Es decir, si pub es mi clave pública y prv mi clave privada, C la función de codificación y D la de decodificación, D(C(m,pub), prv)=m

Una propiedad interesante de este sistema es que si las funciones se escogen de manera que este proceso funciona a la inversa (puedo “decodificar” con la clave privada primero y al “recodificar” con la clave pública recupero el mensaje original también), yo puedo coger un mensaje y codificarlo con mi clave privada. Si publico el mensaje y la versión codificada, cualquiera que conozca mi clave pública podrá decodificar el mensaje que he codificado y verificar que coincide con el mensaje original. Poder codificar el mensaje de esta manera para que la gente lo pueda verificar sólo lo puede hacer el conocedor de la clave privada- así pues esta operación permite demostrar que el mensaje proviene del propietario de la clave privada. A esta operación se la denomina firma digital y tiene todas las utilidades de una firma en papel tradicional (con la ventaja que es más difícil de falsificar).

¿Cómo funciona este sistema? Pues tanto el investigador inglés como los señores RSA, tuvieron la brillante idea de realizar este esquema al ver el pequeño teorema de Fermat y/o el teorema de Euler. Estos teoremas sobre exponenciación, números primos y cocientes nos permiten encontrar una función de codificación y decodificación (exponenciación y cociente) usando como exponentes y cocientes unos números concretos basados en números primos que permiten que funcione todo esto. Las operaciones de codificación y decodificación son opuestas, y a pesar de que los números (claves) privados y públicos están profundamente relacionados, su relación no es fácilmente descubrible- para descubrirla hemos de factorizar en primos los números que lo componen, lo cuál es un problema complejo.

Lo mejor de todo es que obtener claves muy muy grandes (que hacen que la descomposición sea lenta), es muy sencillo. Podemos generar números primos gigantescos con relativa facilidad, y al componerlos, obtener un número enorme cuya descomposición es infinitamente más costosa.

El sistema RSA lo tiene todo: es muy, muy sencillo, podemos hacerlo tan difícilmente de romper como queramos (buscando primos mayores)… lo único que falla es que es relativamente lento; las operaciones de codificación son lentas. La solución aquí es sencilla- los esquemas de clave privada tienen a ser extremadamente veloces, así que normalmente lo que haremos es usar el sistema de criptografía asimétrica para intercambiar una clave para una codificación de clave privada; así el sistema de clave pública nos resuelve el problema de compartir la clave privada por un canal seguro: usamos la criptografía de clave pública para hacerlo, y a partir de entonces usamos los veloces algoritmos de clave privada para realizar el resto de comunicaciones.

Este sistema es usado hoy en día en la mayoría de aplicaciones de seguridad informática. El criptosistema RSA basado en números primos sigue siendo la implementación más popular- existe un sistema alternativo basado en “curvas elípticas” que se considera más seguro, pero es mucho más complejo y, sobre todo, que algunas de estas curvas elípticas están patentadas y no está claro si se pueden realizar implementaciones de este sistema sin pagar a sus inventores (mientras que el sistema RSA es “libre”).

Los primeros ordenadores se destinaron a la introducción y proceso de datos- no en vano los orígenes de IBM se remontan a la gestión del censo de habitantes de los Estados Unidos. Naturalmente, hasta el más primitivo de los sistemas de programación provee de primitivas de almacenamiento de datos, mecanismos sencillos para almacenar, organizar y acceder a datos en la memoria volátil del sistema (es decir, que estos datos se pierden al finalizar la ejecución del programa).

Rápidamente, los programadores se ocuparon de implementar funcionalidades que almacenaban estos datos en algún soporte persistente, de manera que los datos se conserven entre ejecución y ejecución del programa, y diseñaron maneras de organizar los datos de manera que las operaciones que se quieren realizar con ellos se hagan de una manera eficiente.

E. F. Codd, allá por 1969, planteó un sistema generalizado de almacenamiento y proceso de datos basado en unos principios muy sencillos.

Codd se dio cuenta que la información que típicamente se quería procesar se podía particionar en hechos simples, del siguiente estilo:

• La factura #1 es a nombre de Javier Sánchez, a fecha 3/12/2007
• La factura #2 es a nombre de Lucía Martínez, a fecha 5/12/2007
• …
• La línea 1 de la factura #32 es para “Mano de obra”, precio 300€
• La línea 2 de la factura #32 es para “Materiales”, precio 450€

Podemos escribir estos hechos de una manera compacta empleando dos tablas:

Cuando usemos el modelo relacional, definiremos las “tablas” (relaciones) que usaremos en nuestra aplicación, especificando qué “columnas” (atributos) tendrán y qué tipo de valores podrán ponerse en cada columna (en el ejemplo anterior, números de factura, números de línea, nombres, conceptos, fechas y cantidades).

Los sistemas de bases de datos relacionales nos permiten definir con precisión estas tablas, insertar valores, actualizarlos y realizar consultas sobre ellos (e.g. ¿cuál es la fecha del último pedido de Miguel Hernández?), sin preocuparnos de la implementación real de esta estructura de datos, su almacenamiento persistente ni los algoritmos de búsqueda para las consultas.

El trabajo con las bases de datos relacionales se realiza a través de un lenguaje específico adaptado a ellas; el lenguaje más común se conoce como SQL (Structured Query Language) mediante el cuál podemos expresar cosas como:

create table facturas (
  numero_factura          numero,
  nombre                  texto,
  fecha_factura           fecha
);

Que define la tabla facturas con las columnas que hemos visto anteriormente, o:

insert into facturas(numero_factura, nombre, fecha_factura) values (1, 'Javier Sánchez', 3/12/2007);

, que nos permite insertar uno de los hechos que hemos tabulado antes y consultas como:

select max(fecha) from facturas where nombre = 'Miguel Hernández';

a la que nos referíamos anteriormente.

Fijémonos que estas consultas son “declarativas”, es decir que no hablan de cómo se deben almacenar estos datos ni realizarse estas operaciones, sino que sólo dicen “qué se quiere hacer”.

Un siguiente paso interesante en el trabajo con estas relaciones es darnos cuenta que podemos trabajar con varias tablas simultáneamente que comparten información. Por ejemplo, podríamos preguntarnos cuánto se ha gastado Ana Jiménez en concepto de mano de obra entre todos sus pedidos; la tabla de pedidos nos dice qué facturas corresponden a Ana Jiménez y la tabla de líneas de facturas nos dice qué líneas de factura son de mano de obra y por qué cantidad- podemos asociar las dos tablas mediante la columna número de factura presente en ambas. Mediante una sencilla abstracción matemática, podemos realizar consultas y operaciones sobre varias tablas utilizando las posibles asociaciones que haya entre ellas.

Como el modelo relacional es tremendamente abstracto, es apropiado para una gran cantidad de aplicaciones. Así pues, se han desarrollado implementaciones de bases de datos que utilizan el modelo relacional que podemos usar en nuestros programas en vez de tener que “reinventar la rueda” del almacenamiento de datos constantemente. Además, resulta que toda “mejora” que se introduzca en una de estas implementaciones se aprovecha inmediatamente por todas las aplicaciones que usen la implementación.  Por ejemplo, las operaciones entre varias tablas se pueden beneficiar de técnicas de optimización que hacen que las bases de datos sean muchísimo más rápidas que las implementaciones simples de estas operaciones.

Adicionalmente, las aplicaciones se benefician de otras características de los sistemas de gestión de base de datos, como son:

• Restricciones de integridad. Podemos definir en la base de datos restricciones que deben cumplir los datos para considerarse correctos. Por ejemplo, una factura para ser correcta debe incluir un número correcto, un nombre y una fecha válida, evitando que se puedan introducir datos inválidos. Más allá, podemos decir cosas más interesantes como que el número de factura de una línea de factura debe corresponder a un número de factura en la tabla de facturas.
• Transacciones. Muchas veces una serie de operaciones sobre una base de datos deben realizarse en conjunto o no realizarse. Por ejemplo, una transferencia bancaria debe incluir un cargo en la cuenta origen y un ingreso en la cuenta destino; claramente si una de las dos operaciones falla, la otra no puede realizarse.

Estas y otras facilidades que ofrecen las bases de datos no son triviales de implementar, y el hecho de poder aprovechar la implementación de la base de datos nos permite desarrollar nuestra aplicación más rápidamente sin tenernos que preocupar de estos complicados detalles.

Hoy en día, tras más de 40 de años desde su invención, el modelo relacional es el estándar de facto para almacenamiento de datos en aplicaciones donde la integridad de los datos es vital- y es también inmensamente popular en aplicaciones menos críticas por su conveniencia, sencillez y velocidad.

En los inicios, había muy poquitos ordenadores- grandes como habitaciones e increíblemente caros. Muchos de estos ordenadores tenían múltiples pantallas y teclados para que los pudiesen utilizar simultáneamente muchas personas y que se rentabilizasen mejor. Cada ordenador era un mundo en sí mismo. Algunos de estos ordenadores permitían la comunicación entre personas sentadas en diferentes terminales.

Pronto, comenzaron a aparecer más y más ordenadores en el mundo. Algunos entes privilegiados podían disponer de varios ordenadores, y pronto surgió la necesidad de comunicarlos ente ellos; la capacidad de una máquina siempre nos es insuficiente y queremos realizar operaciones que aprovechen la capacidad de varios ordenadores.

Éste es un problema de fácil solución; los ordenadores trabajan con impulsos eléctricos y con compartir un medio conductor (léase, un hilo de cobre conectado a dos ordenadores), estos pueden enviarse datos codificándolos como descargas eléctricas de una manera muy similar a como funciona un solo ordenador internamente.

Este sistema ha funcionado perfectamente hasta el día de hoy- con no tantas evoluciones, existen hoy infinidad de redes con cientos de ordenadores comunicados a grandes velocidades entre sí mediante lo que es en esencia un hilo de cobre que pasa por todos ellos.

El análogo humano es una habitación llena de personas hablando a viva voz. Todo el mundo puede oír a todo el mundo y se pueden realizar todo tipo de conversaciones- un profesor puede dar clase a cientos de alumnos que le escuchan; un montón de parejas pueden estar en una sala de baile hablando entre ellas y grupos de conversación pueden formarse y deshacerse fácilmente.

Este esquema sencillo, lamentablemente, no funciona bien a gran escala. Intuitivamente vemos que compartir un solo cable de cobre entre una gran cantidad de ordenadores puede ser problemático. Nuestra sala con gente hablando deja de funcionar cuando las distancias son suficientes como para no oir- y si hay demasiada gente hablando, nace la confusión.

Los genios de ARPANET no se aturullaron delante de estos problemas y encontraron una solución simple y efectiva para este problema. Las redes locales de unos cuantos ordenadores funcionan maravillosamente bien, dijeron; no hace falta abandonar ni complicar este modelo. Sencillamente, interconectemos las redes entre sí.

Las comunicaciones locales pueden funcionar como hasta ahora. Lo único que tenemos que hacer es introducir unos dispositivos que tengan un pie en una red, y otro pie en otra. Cuando un ordenador en una red quiera comunicarse con otro ordenador en otra red, se dirigirá al dispositivo de su red que se comunica con otras redes y le entregará la información que quiere transmitir. Si el destinatario está en la otra red, el dispositivo no tiene más que entregárselo. Si no, lo único que tiene que buscar es otro dispositivo de este tipo que esté conectado con otra red que esté más cerca del destinatario y entregarle la información- así la información irá saltando de red en red hasta llegar a su destino.

Esto, en esencia, es internet. El “inter” es de interconexión de redes. El modelo se completa con un sistema de direcciones universales, las famosas IP con las que se identifica a cada dispositivo que vive en Internet- y el sistema de puertos, que identifica en cada dispositivo varios puntos de envío y recepción de datos (un puerto para el correo electrónico, un puerto para el tráfico web, etc.). Encima de esto, el sistema DNS que hace que los humanos podamos usar nombres en vez de IPs numéricas para referirnos a los dispositivos que viven en Internet y los diferentes protocolos que rigen los diferentes servicios que funcionan sobre internet.

Pese a que internet y su ecosistema asociado es infinitamente complejo, la gran virtud es que se basa en un modelo sencillo y elegante- simples redes locales interconectadas.

Próximas entregas:

• Hazañas informáticas II: el modelo de datos relacional
• Hazañas informáticas III: La criptografía asimétrica
• Hazañas informáticas IV: Las funciones hash
• Hazañas informáticas V: Las máquinas de Turing y Von Neumann
• Hazañas informáticas VI: el sistema UNIX

Me hallo en la enésima reorganización de mi preciado correo electrónico. Nada, abrirme un Google Apps Standard bajo un dominio propio mío, para poder gozar de algunas de las cosas de Google Apps (¿cuáles? No estoy seguro). Por supuesto, estoy aprovechando para reclasificar y agrupar correo, de manera que todos los preciosos mensajes estén almacenados centralizadamente (y duplicados).

Para ello, estoy recogiendo el correo de todas mis cuentas de correo activas- que sin incluir una o dos direcciones que desaparecieron en el olvido, son:

• La cuenta de correo de mi universidad, de la cuál no soy alumno desde hace más de 5 años, pero ahí sigue abierta
• Mi cuenta personal, alex-arroba-corcoles-punto-net, en un alojamiento familiar compartido
• Mi cuenta “secundaria” en fastmail.fm, que recién fueron comprados por Opera y siguen siendo uno de los pocos proveedores que dan cuentas IMAP gratuitas- si no podéis usar GMail por algún motivo o queréis una cuenta IMAP menos especial, los recomiendo
• Mi cuenta en mi compañía de móvil- la cuál prometía push al móvil, pero que nunca he conseguido hacer funcionar
• Mi cuenta de GMail, que utilizo para muchos servicios de Google, pero curiosamente uso relativamente poco para correo (en realidad, tenía mi cuenta de correo personal redirigida a GMail como archivo y para usar GMail de webmail donde no tengo Thunderbird)
• Una cuenta alternativa de GMail

Es interesante comprobar cosas como que apostar por IMAP desde el principio fue complicado, pero me ha permitido conservar correo casi sin esfuerzo- he recuperado correo hasta del 99, unos 11.000 mensajes de correo totalizando 685 megas (63kb por email). Lamentablemente, he podido cuantificar bastante correo enviado perdido- sólo conservo 2400 correos escritos por mi mismo. Los números están aquí, pequeña gráfica:

Puede apreciarse que, tras conseguir mi cuenta de Gmail (el 15/4/2004)… conservo bastante más correo y recibo más correo, in crescendo hasta hoy donde estoy de media en 6 emails diarios. En cambio desde 2004, parece ser que escribo menos; de 1,2 al día en 2004 hasta 0,8 en 2010.

Me pasan este acojonante reproductor de grandes premios. No sólo es un gran ejemplo de visualización de datos (curioso, me pedí el Tufte ayer), ni tampoco un gran ejemplo de lo que se puede hacer con eso de los estándares web, sino además un excelente recurso para enterarse a posteriori de lo que ha pasado en un GP.

Nota mental:

• Si queremos copiar grandes cantidades de correo de un servidor IMAP a otro, Larch es la respuesta
• Si disponemos de aún el más cutre servidor compartido donde lo podamos instalar, este tendrá más ancho de banda que nuestra ADSL doméstica y Larch irá más rápido