Cacheando, que es gerundio

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.

Patrones de diseño para torpes - 2ª parte

Seguimos la serie de artículos sobre patrones de diseño. Vamos a ver otro de los patrones más típicos.

El patrón "Observer"

Usted es el/la encargado/a de la hemeroteca de un laboratorio. Periódicamente se reciben revistas sobre diferentes temas y con una periodicidad variable: unas son semanales, otras quincenales y otras mensuales.

Una de sus funciones es hacer llegar las revistas a diferentes personas de diferentes departamentos. Por ejemplo, la revista "Genómica de las hormigas" debe llegar al laboratorio de genética, la revista "Cristalografía de minerales venusianos" va al departamento de cristalografía, etc.

Imagínese ahora que cada persona de cada departamento estuviese cada dos por tres llamándole para preguntarle si ha llegado su revista, o, peor aún, entrara en su despacho y revolviese su mesa y el archivo buscando su preciada revista.

Obviamente, las personas no trabajamos así, en este ejemplo, lo más lógico, cómodo y organizado es que Ud. mantenga una lista de las personas o departamentos y notifique a estos la llegada de las revistas. Cada departamento decide entonces qué hacer con la revista (fotocopiarla, escanearla, ..., incluso leerla)

Cuando desarrollamos programas hay distintos módulos o unidades funcionales que deben interaccionar entre ellos, pero esta interacción no siempre es tan limpia o aséptica como sería deseable. En ocasiones un módulo, clase, función (o lo que sea) llega a "meterse en el despacho" de otra unidad funcional.

Pongamos un ejemplo más "software". En el libro "Desing Patterns" que mencionábamos en el anterior artículo proponen dos ejemplos muy ilustrativos:

• Una hoja de cálculo puede tener varias vistas (formas de presentar los datos) activas en un momento dado: un gráfico de barras, una rejilla de datos, un gráfico por sectores, ...
  Si los datos cambian, todas las vistas deben actualizarse. La forma más cómoda es tener un objeto "Datos" que informa a todos los objetos "Presentación" de los cambios que se producen. Estos objetos "Presentación" ya se ocuparán ellos de actualizarse.
  Lo bueno de este patrón es que los objetos "Presentación" no deben "meterse en el despacho" del objeto "Datos" para consultar si estos datos han cambiado o no.


• El otro ejemplo que se propone es un reloj. Tenemos un objeto "Temporizador" que cada segundo notifica a todos los objetos que le observan (un "RelojDigital", un "RelojAnalógico", ...) de que algo ha cambiado.

Distinguimos entonces el objeto observado y los objetos observadores. El objeto observado debe mantener una relación de los objetos que le observan y una forma de notificarles. Por su parte, los objetos observadores, sean del tipo que sean, deben implementar alguna funcionalidad para actualizarse en función del nuevo estado del objeto observado.

En el artículo "Five common PHP design patterns" nos proponen algunos ejemplos en PHP muy interesantes. Vamos a adaptar un poco el ejemplo correspondiente al patrón observer y "traducirlo".

<?php

interface IntfzObservador {
   function hayCambios($observado, $datos);
}

class NotificadorUsuarios implements IntfzObservador {
    public function hayCambios($sender, $args) {
        // Código para notificar: mensaje en consola,
        // registro en un fichero 'log', etc.
        echo("Se ha añadido '$args' a la lista de usuarios.n");
    }
}

class GrabadorBBDDUsuarios implements IntfzObservador {
   public function hayCambios($sender, $args) {
       // Código para grabar en BBDD.
       echo("Se ha grabado el usuario '$args' en la base de datos.n");
   }
}

class AltaSistemaUsuarios implements IntfzObservador {
   public function hayCambios($sender, $args) {
       // Código para crear la cuenta de usuario.
       echo("Se ha creado una cuenta para el usuario '$args'.n");
   }
}

class ListaUsuarios {
    private $observadores = array();
    public function anadirUsuario($nombre)  {
       foreach($this->observadores as $obs)
           $obs->hayCambios($this, $nombre);
    }
    public function anadirObservador($observador)  {
	    $this->observadores[]= $observador;
   }
}

/** Código de pruebas **/
$nu = new NotificadorUsuarios();
$gbu = new GrabadorBBDDUsuarios();
$asu = new AltaSistemaUsuarios();
$lu = new ListaUsuarios();
$lu->anadirObservador($nu);
$lu->anadirObservador($gbu);
$lu->anadirObservador($asu);
$lu->anadirUsuario("Juana");
$lu->anadirUsuario("Pedro");

?>

Las clases observadoras, independientemente de su naturaleza, deben tener un método común para ser notificadas por el observado. Esto puede garantizarse definiendo una interfaz (IntfzObservador en el ejemplo) y forzando a que estas clases observadoras implementen la interfaz.

El código es autoexplicativo. Tenemos dos observadores que "reaccionan" de diferente forma a los cambios en el observado. Uno de ellos de dedica a notificar los usuarios nuevos, otro los graba en una base de datos, otro los da de alta en el sistema, ...

Cada vez que se añade el objeto ListaUsuarios añade un usuario, notifica a sus observadores y éstos hacen sus tareas, sin interferir con este objeto observado.

Veamos la salida de este programa:

~ $ php test.php
Se ha añadido 'Juana' a la lista de usuarios.
Se ha grabado el usuario 'Juana' en la base de datos.
Se ha creado una cuenta para el usuario 'Juana'.
Se ha añadido 'Pedro' a la lista de usuarios.
Se ha grabado el usuario 'Pedro' en la base de datos.
Se ha creado una cuenta para el usuario 'Pedro'.
~ $

Tira nº 58: Matrix

Continuará ... no es una despedida ;-)

Colores

En el colegio nos enseñaban que los colores primarios eran amarillo, rojo y azul, que mezclando azul y amarillo salía color verde ...
Luego empezamos a trabajar con pantallas y nos encontramos con que los colores "primarios" son los del sistema RGB (rojo, verde y azul) y que rojo y verde da amarillo.
Cualquiera que sepa algo de diseño sabe que son dos sistemas de color diferentes, el aditivo y el sustractivo, y que los colores primarios de cada sistema no son los mismos, aunque coloquialmente se les llame igual.
Pero claro, a un pobre programador como yo, al que si le sacas de lo suyo está totalmente perdido, estas cosas se le escapan ;-)
El problema es que el "rojo" del sistema RGB (#FF0000) en realidad es "rojo anaranjado", el "azul" RGB (#0000FF) es "azul violáceo".
En esta figura se ve la "equivalencia" entre los dos sistemas. Las mezclas funcionan entre dos colores alternos. Por ejemplo, rojo + verde = amarillo, verde + azul = cian, ...

Para saber más, este "post" en malaciencia.info

Tira nº 57: corte y confección

Ahora en serio: en mi blog estoy haciendo una serie "divulgativa" sobre patrones de diseño.
El primero que trato de explicar es el patron "factory".