El venerable cowsay

Lo bien que me lo pasaba "tuneando" la shell con cowsay... Lo divertido es que se lo enseñas a gente joven y se queda alucinada ;-)

10 años de desarrollo web

Ante todo, debo felicitarme a mi mismo. Este blog cumple 10 años. No voy a hacer el propósito de actualizarlo más a menudo (sobre todo porque no lo puedo mantener), pero seguirá existiendo por ahora.

¿Cómo ha ido cambiando el desarrollo web en estos años?

En 2005 teníamos la versión 5 de PHP recién salida del horno, la gente empezó a dejar de usar el "register_globals" (lo que costó...). No obstante, durante mucho tiempo se siguió utilizando PHP 4 en muchos sitios.

Por entonces se empezó a extender la idea en el mundillo PHP de que separar la lógica de la presentación era bueno y se empezó a extender el uso de motores de plantillas como Smarty. Parece que no, pero empezar a ver código PHP limpio de echo y sprintf fue un alivio.

Perl seguía fuerte en desarrollo web (Movable Type,...). Python no tenía mucha relevancia en el desarrollo web y Ruby era prácticamente un desconocido por estos lares.

Afortunadamente, ya empezaba a calar la idea entre los responsables IT de que quizás hacer las webs con tecnología J2EE no era lo adecuado en todos los casos. El tiempo nos ha dado la razón a los que pensábamos que era viable realizar proyectos de envergadura mantenibles con lenguajes de scripting.

Un punto de inflexión en el desarrollo web fue la aparición y popularización de varias soluciones que simplificaban mucho el trabajo: los frameworks. En el lado del servidor, herramientas como Ruby On Rails, Symfony, Django, y similares demostraron que era posible hacer aplicaciones web sin tener que estar tirando consultas SQL a pelo y manteniendo el código de forma organizada y previsible. En el lado cliente, las librerías de Javascript Prototype y jQuery (entre otras) nos ayudaron a abstraernos en cierta forma de las peculiaridades de cada navegador.

En 2008 ocurrieron dos cosas muy interesantes: llegaron los primeros iPhone a España y se lanzó el navegador Chrome. Nada ha vuelto a ser igual. Desde ese momento, Internet Explorer empezó a perder cuota de mercado inexorablemente.





Recuerdo alguna anécdota de entonces: le pregunté a un responsable editorial...

"Si la cuota de usuarios de alguna de las versiones de Internet Explorer baja del 5%, ¿nos autorizas a dejar de darle soporte?"

Je, je, je. A día de hoy, ya no tenemos que dar soporte a los Explorer más antiguos. Los diseñadores y maquetadores respiran aliviados.

Por otra parte, el incremento de uso de los teléfonos móviles con navegador nos obligó a todos a empezar a hacer webs diferenciadas para estos dispositivos.

De esta época también data la locura de las "apps". Todo el mundo quería tener una app, sin saber ni siquiera diferenciar una app nativa de un acceso directo en el "escritorio" del móvil con el iconito a la versión web. El tiempo parece que también ha colocado las cosas en su sitio. No era normal que unos dispositivos con un navegador tan completo (el Safari de los iPhone o el stock browser de Android, ambos basados en Webkit, también estaba el Opera Mini) necesitasen una aplicación nativa para mostrar lo que el navegador podía hacer perfectamente.

En 2010 se empezó a comercializar el iPad y poco después todas las tabletas de otros fabricantes. Otro cachivache más al que dar soporte. La maquetación y diseño se han complicado bastante, así que se ha terminado haciendo un diseño único que se adapte al dispositivo en el que se ve la página. No era viable tener tres versiones diferentes de una misma web, una para "desktop", otra para tablet y otra para móvil.

JavaScript ha evolucionado mucho y parece que prácticamente está estandarizado. Librerías como jQuery, Motools,.. y multitud de frameworks y librerías han surgido para facilitarnos el trabajo. Ya no vemos cosas como document.getElementById().

El lenguaje se ha rehabilitado a los ojos de los desarrolladores. JS ya no es el lenguaje que se usa para hacer monerías en una página web. Es un estándar, con muchas implementaciones y ya no está restringido a ejecutarse en el navegador. Node.js es la implementación más conocida de JS fuera del navegador, pudiendo correr en el "backend".

La sintaxis de objetos de JS (JSON) se ha convertido en muchos casos en el formato estándar "de facto" para intercambiar información estructurada, desplazando al voluminoso XML.

AJAX... Asynchronous Javascript And Xml... las siglas se han quedado, pero nadie utiliza ya XML para intercambiar datos, mejor JSON, que es más compacto y se parsea más rápido.

HTML5, casi más una buzzword que otra cosa. Pero está muy  bien tener un <video>, <audio> y <canvas> nativos y estructurar un poco mejor el HTML (<header>, <section>, <footer>,...), pero parece que no nos terminamos de quitar de encima al COBOL de la web: Flash.

Volviendo a JavaScript, en los últimos años ha habido una "explosión" de utilidades, implementaciones, frameworks y librerías. Los que nos hemos quedado un poco en la parte del desarrollo del backend estamos un poco desconcertados (yo al menos).

La última tecnología que se ha popularizado y ha pasado a ser "mainstream" en los últimos años son las bases de datos no relacionales (NoSQL). Otro campo en el que profundizar, sobre todo los que hemos seguido en el paradigma relacional.

Pese a todos estos cambios, hay una constante que permanece: hacer webs se lleva mucho tiempo. Tenemos mejores herramientas y entornos, pero los requisitos ahora son mucho más exigentes.

Nos hacemos mayores

De repente, uno se da cuenta de que esto de la web ya lleva unos cuantos años entre nosotros. Consultando la documentación de PHP me he encontrado con esto:



Una anotación de un desarrollador fechada ¡11 años atrás!

Me pongo en modo "abuelo Cebolleta" y recuerdo cuando se desactivó el "register_globals" hace unos doce años el revuelo que se montó.

El desarrollo de una página web

Me ha dado mucha envidia José Pujol con sus "posts" en los que explica el día a día de su trabajo, así que en esta entrada voy a hacer lo mismo.

En la web de Público tenemos dos partes muy diferenciadas: el gestor de contenidos y las páginas que genera (básicamente, la portada, las subportadas y las páginas con noticias) y el resto (blogs, video, sección de cine, archivos estáticos, etc).

Hoy voy a tratar de contar cómo hemos construido la página web del concurso Foto Libre.

Lo primero que hicimos fue reunirnos con la gente del periódico que organizaba el concurso (departamentos de fotografía, "marketing" y sistemas). En esta reunión se estableció la mecánica del concurso desde un punto de vista genérico, sin entrar en detalles técnicos.
Esta fase se suele denominar "toma de requisitos" y es fundamental para que un proyecto salga adelante. Tienen que quedar perfectamente especificadas todas las características deseables.

Con esta información, desde la parte de diseño y programación web (nosotros) se hicieron unos bocetos o esquemas de las páginas. Por ejemplo: "pantalla de inicio, desde ahí el usuario puede ir al formulario de registro o a la galería de fotos", o "pantalla de registro, el usuario introduce sus datos para participar y se le envía un correo de confirmación", etc.
Existe un término llamado "casos de uso" que sirve para documentar las posibles interacciones y flujo de trabajo de una aplicación.
En este punto, todavía no se ha escrito nada de código, pero son pasos necesarios para que todo salga bien. Si no está claro qué se quiere obtener, difícilmente el proyecto será del gusto del peticionario.

Cuando todos los implicados han dado el visto bueno a estos bocetos, empieza el trabajo de los diseñadores (Matteo y Daniel) y programadores (Rodrigo y el autor de estas líneas).

El separar funciones es bueno y productivo y permite avanzar en paralelo. Mientras los diseñadores van esbozando las distintas pantallas, los programadores vamos haciendo el trabajo "de trastienda": diseño de la base de datos (si es necesaria, claro), elección de la tecnología que se utilizará en el desarrollo (lenguajes de programación, "frameworks", etc), diseño funcional de la aplicación (separación de las distintas funcionalidades de la aplicación), etc.

En este punto, los diseñadores nos proveen con algunos archivos HTML y CSS estáticos. Los programadores los "desmenuzamos" y asignamos a cada parte de la aplicación una labor, algunas de estas unidades funcionales son las que se encargan de generar el HTML de forma dinámica (obteniendo los datos de las fotos de una base de datos, validando los datos que introducen los usuarios cuando se registran o suben fotos, etc).
Es la llamada "capa de presentación".

Hoy en día muchas webs se diseñan siguiendo un patrón o modelo muy conocido: MVC (Modelo, Vista, Controlador).
La capa M (modelo) abstrae, representa y ofrece mecanismos de acceso a los datos "crudos" de la aplicación, la capa C (controlador) se ocupa de gestionar las peticiones de las distintas páginas y solicitar los datos para generar estas páginas.
Por último, la capa V (vista o presentación) "pinta" o representa los datos en un formato determinado (en nuestra aplicación de Foto Libre, en HTML).

Para muchas páginas web sencillas o informales esta separación está casi más en la mente de las persona que escribe el código, pero en desarrollos de mayor entidad conviene separar físicamente estas funcionalidades.

Espero no haberles aburrido mucho. Es difícil condensar en unas pocas líneas tanta información. Otro día les contaremos más cosas sobre el trabajo que hacemos.

Los servicios de Internet menos conocidos

¿Alguno de ustedes se acuerda y/o utilizó Gopher? ¿Qué fue de Archie? ¿Está perdiendo popularidad el IRC frente a otros sistemas de mensajería instantánea?

Internet no se reduce a navegar, leer el correo y "mensajear". Hay muchas aplicaciones, servicios y protocolos que son desconocidos para el público en general.

Sólo voy a comentar algunas de estas aplicaciones/protocolos menos conocidos pero muy utilizados hoy en día:

[Todos los enlaces apuntan a la Wikipedia en inglés]

• NTP: Network Time Protocol. Sirve para ajustar la hora de un equipo desde un servidor que ofrezca este servicio. No se si Windows utiliza este protocolo. En sistemas Unix (Mac OSX, Linux, *BSD, ...) se utiliza con frecuencia.


• SSH: Secure Shell. Permite trabajar en una "shell" o "línea de comandos" de un equipo remoto de forma segura (utilizando datos cifrados). Ha sustituido en muchos entornos al veterano Telnet y es una herramienta indispensable hoy en día para la administración de servidores.


• DHCP: Dinamic Host Configuration Protocol. Mediante este protocolo la mayoría de los ordenadores conectados a un red consiguen una dirección IP y algunos datos más para poder trabajar.
  Al arrancar el sistema, el ordenador emite por su tarjeta de red una "petición" (algo como '¿hay algún servidor DHCP en esta red que me de los datos de configuración?'). El servidor DHCP le asigna entonces una dirección IP, las direcciones de los servidores de nombres y algunos datos más.


• DNS: Domain Name System. Sin este servicio no podríamos usar Internet como lo hacemos hoy en día. A grandes rasgos, este servicio se encarga de traducir los nombres comunes de los ordenadores (p. ej., blogs.publico.es) a las direcciones IP que tienen asignadas.
  Es uno de los servicios básicos de Internet. Una caída de un servidor DNS suele ser bastante catastrófica, puede dejar sin servicio a muchos (cientos, miles o más) usuarios, dependiendo de la importancia del servidor.

El maldito botón “Limpiar formulario”

Me contaban el otro día una anécdota nada divertida. Cierta persona tenía que rellenar un formulario con un montón de campos para una administración pública, había que especificar hasta 80 centros de trabajo, más los datos comunes, etc. En total, unos 100 campos.

Al pie del formulario había dos botones: "Validar y enviar" y "Limpiar". La persona que me contó este caso, no muy ducha en cuestiones informáticas, interpretó que "Limpiar" se refería a una especie de corrector ortográfico o algo así, así que lo pulsó.

Mágicamente, el formulario se borró por completo, tirando a la basura más de una hora de trabajo de esta persona. Para echarse a llorar.

Y yo añado: y para matar al diseñador o programador de ese formulario.

1. Los botones de un formulario pueden rotularse. ¿No estaría más clara la función de ese botón si estuviese rotulado como "Borrar todo" o algo así?


2. Regla de oro cuando se diseña un interfaz de usuario: si una acción es potencialmente destructiva, pide al usuario confirmación antes de proceder a ejecutarla.


3. Opinión más personal: ¿para qué se necesita un botón de "limpiar" en un formulario? Sinceramente, no le veo ninguna utilidad.

RetroMadrid 2008

Una entrada breve:

Me han enviado información sobre una feria de informática clásica, RetroMadrid 2008, que se va a celebrar próximamente.

Para los que nos gustan los equipos antiguos y la "arqueología informática" es una exposición digna de verse.



Los datos del evento son:

• Fecha: Sábado 8 de marzo de 2008.


• Horario: 10:30 a 18:30.


• Lugar: Centro Cultural El Greco (Calle el Greco s/n. 28011 Madrid).


• Entrada: Gratuita.


• Teléfonos: 91 479 32 61 - 31 50

Direcciones IP, usuarios únicos y pucherazos

Hace unos días una de las encuestas que poníamos en la web de Público proporcionó unos resultados un tanto sorprendentes. Como mi compañero Electoblogger comentaba en su entrada, teníamos la sospecha de que la encuesta estaba falseada.

Obviamente partimos del supuesto de que este tipo de "encuestas web" sólo tienen un valor estimativo y que no son representativas ni válidas desde un punto de vista estadístico.
Personalmente, no fue el resultado de la encuesta lo que me resultó más sospechoso, sino el número de votos: teníamos casi el doble de votos que en otras encuestas, y eso que se publicó en fin de semana, que siempre hay menos lectores.

Como este "blog" está dedicado a cosas técnicas, dejaremos el análisis sociológico y político de estos presuntamente resultados falseados y nos meteremos en lo que nos gusta: la informática.

Cuando se hacen encuestas en una página web se trata de limitar las votaciones repetidas siempre de alguna forma, cumpliéndose la siguiente proporcionalidad en la mayor parte de los casos: a mayor fiabilidad del método de control, mayor incomodidad para el usuario.
En nuestras encuestas lo que más hemos primado ha sido la comodidad para participar, con lo que el control era relativamente fácil de ser eludido.

Direcciones IP

¿Cómo averiguamos que nos estaban haciendo una votación masiva?
Cuando un dispositivo (no sólo un ordenador) se conecta a Internet se le asigna un identificador único (ahora mismo matizo esto) o dirección IP (del inglés Internet Protocol).

Estas direcciones consisten en un número hexadecimal (en base 16) de 32 cifras bits, que se suele representar en notación decimal (base 10) de la forma aaa.bbb.ccc.ddd, donde los distintos números toman un valor de 0 a 254.

Hay algunos conjuntos de direcciones de red que se han establecido para uso interno, esto es, para redes que utilizan el protocolo de Internet pero que no están conectadas a Internet. No debería encontrarse nunca en Internet un equipo con la dirección, por ejemplo, 192.168.1.2 (dirección típica de red interna).

No voy a entrar en más detalles de cómo se asignan estas direcciones ni cómo se reparten, sólo quiero destacar un hecho: las direcciones IP disponibles son limitadas y se están acabando. Para solucionar este problema o al menos mitigarlo se han inventado varias técnicas:

• Direcciones IP dinámicas:
  Si usted se conecta desde su casa, cada vez que establece una conexión su proveedor de Internet le asigna una dirección IP. Cuando termina la conexión, la dirección IP vuelve a estar libre y puede ser asignada a otro usuario.
  Con este sistema un proveedor de acceso puede reservar, por decir un número, 10.000 direcciones y dar servicio a, por ejemplo, 50.000 usuarios (siempre y cuando no se conecten más de 10.000 usuarios simultáneamente).
  Si usted quiere una dirección IP fija, tiene que encontrar un proveedor que se la "venda" y pagarla, por supuesto.


• Servidores "proxy":
  Supongamos una oficina en la que todos los equipos están interconectados en una red interna. Si se quiere proporcionar acceso a Internet (páginas web, generalmente) a los equipos de esta red interna se puede añadir un equipo adicional (servidor proxy) que por un lado está conectado a Internet (con una dirección IP) y por el otro está conectado a la red interna (con una dirección IP de las "privadas"). Además tiene instalado un programa que le permite recuperar páginas web y servirlas a otros equipos.
  El resto de equipos solicitarán las páginas web al "proxy" y éste será el que las recupere de Internet.
  Desde Internet, todos los equipos de esta oficina están "saliendo" con la misma dirección IP, la del proxy.


• NAT (del inglés Network Address Translation o Traducción de Direcciones de Red):
  Es una técnica bastante diferente a la del proxy desde el punto de vista técnico, pero con un resultado "desde el exterior" similar: varios equipos "salen" a Internet con la misma dirección IP.

La consecuencia de todo esto es la siguiente (generalizando mucho): los usuarios finales en Internet tenemos dos perfiles. O somos usuarios "domésticos" con direcciones IP variables (hoy "salgo" con una, mañana con otra) o somos usuarios "corporativos" que compartimos la misma dirección con el resto de equipos de la oficina.

Registro de direcciones

Los servidores web guardan en un registro mucha información, la más típica es qué página nos piden, a qué hora y qué día, el resultado de la petición y la dirección IP que nos solicitó esa página o recurso.
En el caso de nuestra encuesta presuntamente falseada teníamos una dirección IP desde la que se había votado miles de veces lo mismo.
O era la dirección IP de una oficina, empresa, institución o similar con muchísimos usuarios que nos visitaban y votaban lo mismo o era la dirección de un particular que estaba "jugueteando" un rato con nuestra encuesta.

¿Cómo saberlo? Existen herramientas para saber a qué entidad u organización pertenece una determinada dirección IP. En el caso de nuestro "sospechoso" la dirección pertenecía al proveedor de acceso mayoritario en España (Telefónica), y el nombre del equipo era el típico que utilizan los proveedores de Internet para sus clientes "domésticos" con direcciones IP dinámicas.

Por supuesto, esta dirección en otro momento puede pertenecer a cualquier otro cliente, pero los proveedores de acceso están obligados por ley a guardar un registro de qué dirección asignan a cada abonado y en qué intervalo de tiempo el abonado tiene esta dirección. Esta información es confidencial y sólo puede ser accedida por orden judicial.

No es el caso, nuestro "supervotante" no ha cometido delito alguno, sólo ha utilizado muchas veces (miles de veces) un servicio que ofrecíamos saltándose algunas restricciones.

El caso es que a la poca fiabilidad que pueda tener una encuesta de este tipo se le ha unido la incertidumbre de que algún usuario ha votado masivamente. Estamos pensando qué hacer para aumentar la fiabilidad de nuestras encuestas sin complicar mucho el sistema para que siga siendo fácil participar. A ver qué se nos ocurre ...

Conclusión

¿Cree usted que utilizar Internet es un acto anónimo? Ni de lejos.

Los informáticos contamos empezando por 0

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.


Notas

(*) 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 ;-)

Comenzamos mal el año

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".

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.

Al cabo de un año, el perro se parece al amo

¿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".

Pesetas	Euros
	Redondeo “monetario”	Redondeo “matemático”
10,105	10,11	10,10
10,115	10,12	10,12
10,125	10,13	10,12
10,135	10,14	10,14

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.