Mi rincón en Internet

A veces tengo que llamar a un servicio técnico que funciona de la siguiente forma: llamo, digo quién soy, qué problema tengo y a continuación me validan una contraseña que nos han asignado. Por seguridad (no es muy recomendable decir la contraseña en voz alta rodeado de gente), en vez de pedirme la contraseña completa, me piden sólo algunas letras o cifras de la misma: “por favor, dígame las posiciones 1, 6 y 7 de su contraseña”.

La primera vez que llamé no fui capaz de decirle las letras que me pedía hasta el tercer intento por lo menos. ¿Qué pasó?
Sencillo: estaba contando los caracteres como si estuviese programando, empezando por 0.

Normalmente, procederíamos así a la hora de contar (en la línea de arriba, la palabra, en la de abajo, la numeración o posiciones):

 C | o | n | t | r | a | s | e | ñ | a

 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

Sin embargo, un programador contará así:

 C | o | n | t | r | a | s | e | ñ | a

 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Casi todos los lenguajes de programación y sistemas siguen este esquema: empezar a contar desde cero. ¿Por qué se hace de esta forma tan poco intuitiva?
La razón que me parece más sencilla es la siguiente: el número 0 también contiene información.

Cuando utilizamos los números naturales para contar empezamos con el 1 porque el 0 no tiene significado: si no hay nada que contar, no contamos. Si hay algo que contar, empezamos por la unidad: “una manzana, dos manzanas, …”

Sin embargo en los ordenadores cuando contamos en realidad lo que estamos es enumerando direcciones o posiciones.
Vamos a ver un sencillo ejemplo:

Supongamos que tenemos una ínfima memoria RAM de 8 bytes. Esto quiere decir que sólo disponemos de 8 “huecos”, “casillas”, posiciones o direcciones de memoria.
Podemos pensar en la memoria RAM como en un montón de buzones de correo apilados.

Si queremos acceder a una de estas direcciones para recuperar el contenido o escribir algo necesitamos saber su dirección. Como sabemos, los ordenadores sólo utilizan ceros y unos para contar, así que con tres bits seremos capaces de direccionar toda la memoria:

000 - 001 - 010 - 011 - 100 - 101 - 110 - 111

Estas ternas de números binarios son en el sistema decimal:

0 - 1 - 2 - 3 - 4 - 5 - 6 - 7

Así que tendremos el buzón 0, el buzón 1, el buzón 2, … hasta el buzón 7. Total, 8 buzones.
Si nos hubiésemos empeñado en numerar los buzones desde el número 1 no nos hubiesen bastado 3 bits (*), puesto que el número 8 en binario es 1000 (**).

Los mayoría de los lenguajes de programación trata las cadenas de texto de la misma forma. Por ejemplo, el lenguaje PHP (con el cual están programados estos blogs) tiene una función o instrucción para extraer parte de una cadena de texto:
substr(‘Contraseña’, 1, 5) nos proporciona 5 caracteres de la palabra ‘Contraseña’ a partir de la posición 1, esto es, “ontra”.
Como ven, también cuentan desde 0.

(*) Existe una regla muy sencilla para saber cuántas posiciones podemos abarcar con n bits: 2^{^n}.

• Con 3 bits podemos contar 2^{^3} = 8 posiciones, esto es, del 0 al 7.
• Con 4 bits podemos contar hasta 2^{^4}=16 posiciones (del 0 al 15).

Un ordenador que funcione con 32 bits (los Pentium “clásicos”, por ejemplo) podrá direccionar 2^{^32} = 4.294.967.296 direcciones, es decir, 4 Gigas de memoria. No compre más memoria que esta cantidad para su viejo Pentium. No podrá utilizarla.

(**) A los informáticos también se nos dan muy bien las potencias del número 2. Pregúntenle a un programador “¿cuanto es 2^{^10}?”. Seguro que le contesta con bastante rapidez

Los lectores más madrugadores del día 1 de enero han podido comprobar que la página “Edición papel” no funcionó por la mañana durante un rato.

La culpa ha sido del que firma estas líneas: debido a un error de programación, la página trataba de mostrar todas las portadas hasta el año 2038. Obviamente, todavía no publicamos el periódico con tanta anticipación. Tras un breve repaso, descubrí mi error (un error trivial, todo hay que decirlo) y en unos minutos ya estaba todo arreglado.

Pero, ¿por qué trataba de mostrar las portadas hasta el 2038 y no otra fecha? La razón es la forma en que la mayoría de los sistemas informáticos manejan las fechas: miden el tiempo basándose en una fecha “cero” o inicial y contando los segundos desde esta fecha. La fecha de referencia más habitual es el 1 de enero de 1970 a las 00:00:00 horas.

El número de segundos desde esta fecha de referencia se denomina “timestamp” (marca de tiempo) y, como decíamos, es uno de los métodos más habituales de manejar las fechas/hora en informática.

En el momento en que estoy escribiendo esto, mi sistema me dice que el “timestamp” es 1199227361, esto es, han pasado ese número de segundos desde el 1 de enero de 1970.

La mayor parte de las máquinas actuales utilizan 32 bits para representar el tiempo, esto quiere decir que pueden manejar valores entre -2147483648 y 2147483647. En el momento que alcancemos el segundo 2147483648, los sistemas fallarán y seguirán contando en el segundo -2147483648, una cifra sin mucho sentido. Por ejemplo, mi equipo “piensa” que el segundo 2147483648 corresponde al 13 de diciembre de 1901.

El segundo 2147483647 realmente lo alcanzaremos el día 19 de enero de 2038. Si para entonces no se han modificado los sistemas actuales, tendremos un problema, el llamado “Problema del año 2038“. Se espera que en ese momento la mayoría de equipos utilizarán 64 bits para manejar las fechas y horas, pero ¿qué pasará con los sistemas que todavía utilicen 32 bits? Todavía no hay una solución definitiva, pero no hay mucha prisa, tenemos 30 años por delante para arreglarlo. Esperemos que no nos “pille el toro”.

El otro día nos llamó un lector del periódico para preguntarnos porqué le había desaparecido un comentario que había escrito en una noticia.

Le preguntamos qué noticia era y, tras localizarla, observamos que su comentario estaba visible.
Preguntamos entonces al lector qué navegador estaba usando (era Internet Explorer) y le sugerimos entonces la combinación “mágica” de teclas: Ctrl+F5

¡Ya veo el comentario! nos respondió el paciente lector, ¿por qué pasaba esto?, nos preguntó. Mi respuesta fue algo críptica: “el navegador le estaba mostrando la página no actualizada que tenía guardada en la caché”.

Intentaré en esta entrada enmendarme y explicar un poco mejor qué es eso de la caché.
Podríamos definir caché como una técnica ampliamente utilizada en los ordenadores que consiste en guardar la información más utilizada en una localización más cercana (más accesible y rápida) al elemento que necesita esta información en vez de en su ubicación original.

No queda muy claro ¿verdad?

A ver si con un ejemplo se entiende mejor:
Volvamos al lector de las noticias y su programa navegador. Generalmente los navegadores van guardando una copia en el ordenador del usuario de las páginas y otros elementos (imágenes, archivos auxiliares, etc) que el usuario va visitando.
Con esto lo que se consigue es que cuando visitamos una página en la que ya hemos estado anteriormente el navegador nos muestra la copia que guardó en la anterior visita, en vez de recuperar los contenidos de la página de internet.
Obviamente, la página se carga en el navegador instantáneamente ya que está guardada en el mismo ordenador del usuario. La desventaja de esto es que si la página “verdadera” ha cambiado mientras, no nos enteramos.
La ubicación donde el navegador guarda estas páginas temporales es la llamada caché del navegador.

No sólo “cachean” (disculpen el barbarismo) los navegadores. Como decíamos, esta técnica se utiliza mucho, y a todos los niveles: desde los microprocesadores (CPU) hasta los programas que utilizamos los usuarios finales.

Esta misma página que Ud. está leyendo ha sido cacheada varias veces por distintos dispositivos y programas.
La mayoría de las páginas web hoy en día no son estáticas, sino dinámicas, esto es, se generan “al vuelo”, cuando alguien (el lector) las solicita a un servidor web.

Este texto que estoy escribiendo, el título, la fecha y demás datos se guardan en una base de datos. Cuando alguien solicita esta página, el servidor web a su vez pide los datos a la base de datos (que puede estar en la misma máquina o en otra). Una vez obtenidos los datos necesarios, “compone” la página dinámicamente, poniendo el título en un sitio, el texto en otro, añadiendo el encabezado de la página y el pie. Una vez montada la página, la devuelve al cliente (la persona que desde su navegador solicitó la página).

En este sencillo proceso se cachea casi todo por razones de eficiencia. Si a la base de datos le va a llegar muchas veces la solicitud “dame el título, texto y fecha del artículo X”, el programa que la gestiona guardará en memoria los resultados de esta consulta, para que la siguiente vez que se lo pidan pueda devolver estos datos con mayor rapidez.

El servidor web, una vez que tiene los datos, como decíamos, “monta” la página final y la guarda también, para que la siguiente vez que le sea solicitada no tenga que repetir la consulta a la base de datos ni el proceso de montaje.

Finalmente, el navegador de la persona que solicitó la página con toda probabilidad también cacheará la página, o algunos de sus elementos, para que en una posterior visita no tenga que solicitarla de nuevo al servidor web.

La duda que nos puede surgir es ¿cuánto tiempo permanecen los datos en las cachés? En algún momento tendrán que renovarse, si no, veríamos siempre todo igual.

La respuesta es compleja, y depende mucho de la tipología del sitio web, del número de visitas y muchos más factores. Por ejemplo, este blog actualiza su caché cada 5 minutos aproximadamente. Otras páginas web, en las que la información varía más en el tiempo (por ejemplo, la página web del diario Público) se actualizan con mayor frecuencia. A menudo se busca un compromiso entre la conveniencia de cachear páginas (se sirven con mayor rapidez) y la necesidad de que éstas estén actualizadas.

¿Recuerdan el refrán? A los informáticos nos pasa lo mismo. De tanto trabajar con ordenadores, acabamos pensando como tales.
Los ordenadores son sólo máquinas, para hacer su trabajo necesitan unas instrucciones precisas, no entienden ambigüedades ni sutilezas. Las personas que nos dedicamos a la informática, en numerosas ocasiones, también.

Con su permiso, voy a contarles una batallita.
Hace unos años estaba encargado del mantenimiento de un programa de contabilidad y gestión de almacén. Según se iba acercando la implantación del euro, hubo que hacer modificaciones en el programa para que mostrase todos los importes en pesetas y euros.

Tras una breve reunión con los usuarios, se decidió añadir un campo adicional en los formularios y una columna más en los listados con el importe convertido en euros. Era un trabajo sencillo, y al cabo de una semana el cliente ya tenía la modificación hecha.

Al cerrar el mes, recibí una llamada del cliente, me contaba que los totales en euros que daba el programa y los que recibía de los proveedores no coincidían, eran errores pequeños, del orden de céntimos de euro, uno o dos euros a lo sumo, pero estaban ahí.

Lo primero que pensé fue que el factor de conversión (1 € = 166,386 pta) lo había puesto mal, revisé donde aparecía y estaba bien. Lo siguiente fue revisar el proceso de conversión a euros: multiplicaba el importe en pesetas por el factor de conversión y el resultado lo redondeaba a dos decimales. Todo parecía correcto.

Al final, hablando con personas que trabajaban en contabilidad me enteré que para pasar a euros el redondeo no es el mismo que el redondeo “matemático”: pasando de pesetas a euros se redondea siempre “hacia arriba”. De los diversos criterios “matemáticos” para redondear, uno de los más utilizados es el “redondeo al par más próximo”.

Pues bien, mi programa utilizaba una función que redondeaba “matemáticamente”. Se cambió la función para que redondease “hacia arriba” y todo arreglado en unos minutos.

¿Por qué surgió este problema? Fue un doble error, del cliente y mío. Del cliente por presuponer que yo sabía cómo se redondea “monetariamente”, y mío por no preguntarlo (pienso que la forma de redondear “matemática” es más precisa y promedia los errores de redondeo mejor que el método “monetario”: tengo la mente un tanto cuadriculada, y así trabajo).

Conclusión: los informáticos, en muchas ocasiones, pensamos diferente que nuestros usuarios.

La próxima vez que llame al informático de su oficina no le diga “no puedo imprimir”.
Dígale “al tratar de imprimir en la impresora X, me salta un cuadro de error que dice ‘La junta de la trócola se ha descogorciado. Aceptar/Cancelar’“.
Verá cómo su informático tarda menos en arreglar el problema y lo hace con una sonrisa en el rostro.

Si está encargando al programador un listado de clientes no le diga “quiero un listado de los clientes“. Mejor será “quiero un listado de clientes, ordenados por su CIF ascendentemente, con 50 líneas como máximo por pantalla y la posibilidad de reordenar el listado por apellidos, fecha de alta en el sistema o número de teléfono“.

No tema agobiar a un informático nunca con un exceso de información (relevante, eso sí). Nos gusta y lo agradecemos.