En la entrada anterior de esta serie veíamos cómo desarrollar un widget en opensocial y probarlo. El único problema es que el proceso era engorroso y que teníamos que seguir varios pasos desde que se nos ocurría un cambio y lo veíamos ejecutar (lo que no predispone mucho a la experimentación). Pero los chicos de OpenSocial han pensado en eso y han desarrollado un widget que realmente es un pequeño entorno de desarrollo en OpenSocial al estilo de lo que widgetcreator es para iGoogle.
El aspecto de la aplicación es más o menos unas pestañas, una pequeña explicación y luego unos campos de texto con un código de ejemplo, con un botón de ejecución que al pulsarlo ejecuta el campo de texto y presenta la salida en la misma página en negro. Guapo, ¿no?
Las pestañas simplemente separan los distintos conceptos que maneja OpenSocial:
People – Obtención de informacion de personas y amigos.
Data – Almacenamiento e información sobre el usuario de la aplicación.
Activities – Para añadir y obtener actividades al usuario de la aplicación (del tipo Raul le ha metido el dedo en el ojo a Javier).
Editor – Simplemente un sitio donde escribir y ejecutar sin mucha molestia código OpenSocial en Orkut.
Bueno, pues nada más por hoy. Instaladla y jugad con ella porque es realmente facil, y si hacéis algo interesante no olvidéis que podéis enviárnoslo.
Ya hemos hablado de la importancia de la latencia en el tiempo de descarga de las páginas web. Reducir el número de "three-way handshakes" activando KeepAlives, el número de ficheros a descargar, paralelizarlos sobre un máximo de 4 dominios, etc., son consejos importantes para reducir el impacto de la latencia, pero hay algo que sobrepasa a cualquier otra técnica para reducir el tiempo de espera cuando queremos usar un recurso (imagen, hoja de estilo, javascript, etc.), y es no mandarle nada al navegador, siempre que éste tenga en caché una copia del recurso en cuestión.
El navegador divide los recursos que tiene en su caché en dos tipos, los "frescos" y los "dudosos". Los recursos frescos pueden usarse sin preguntarle nada al servidor. Los recursos dudosos se pueden usar, pero antes hay que preguntarle al servidor que nos lo envió si sigue siendo válido, o si hay que tirarlo a la basura y usar una nueva versión que el servidor le mandará al navegador.
¿Cómo controlar si un recurso entra en la caché, y si lo hace, el tiempo que permanece fresco? Con las cabeceras Cache-Control o Expires. La cabecera Expires contiene una fecha a partir de la cual el recurso debe ser considerado como dudoso. Si la fecha está en el pasado, o si no es una fecha (como "0"), se considerará inmediatamente al recurso como dudoso. La cabecera Cache-Control ofrece muchas más opciones, permitiendo por ejemplo especificar si un proxy que se encuentre entre el usuario y el servidor puede guardar el recurso en caché o si sólo el navegador puede hacerlo. Podéis leer la especificación para ver todas las subopciones de Cache-Control, siendo una de las más importantes max-age, que especifica durante cuántos segundos se tiene que considerar el recurso como fresco. Si se usa Cache-Control, toma prioridad sobre Expires. Recordemos que si un recurso es fresco, el navegador lo usa directamente sin decirle nada al servidor. Más rápido imposible.
Si el recurso es dudoso, ¿cómo puede el navegador comprobar si ha cambiado en el servidor o no? La pregunta, en prácticamente todos los casos, es completamente irrelevante. Es mejor que vuestros recursos siempre se mantengan frescos, poniendo un Expires o un Cache-Control max-age de muchos años. O están en la caché y pueden usarse directamente, o no están y hay que pedírselos al servidor.
¿Por qué muchas páginas los dejan pasar al estado "dudoso" (poniendo pequeños tiempos de expiración)? Porque quieren que si cambian el recurso, el navegador se baje la nueva versión. Esto es extremadamente problemático, porque en la práctica es imposible predecir cuándo se va a cambiar un recurso, así que no le podemos decir al navegador hasta cuándo lo puede mantener fresco, o nos arriesgamos a que el navegador use una versión antigua de algunas de nuestras imágenes, páginas de estilo, javascript, etc.
Tenemos tres alternativas para atacar este problema:
La última opción es obviamente la ideal, y la que más trabajo necesita por parte del desarrollador, ergo es la opción menos usada. En realidad no es tan difícil de implementar. En lugar de poner en el HTML enlaces como "imagen.png", pondremos un enlace llamado "imagen.png?v=1". El servidor evidentemente ignorará el "?v=1", pero el navegador eso no lo sabe. Cuando actualicemos "imagen.png", cambiamos el número de versión, y en el HTML ponemos "imagen.png?v=2". Así pues, en el mismo instante en que tengamos una versión nueva de "imagen.png" el navegador tendrá que pedírsela al servidor (él no tiene en su caché nada sobre "imagen.png?v=2"). Si queremos aumentar la legibilidad, o evitar que algún proxy no cachée nuestra imagen por usar un ? en la URL, podemos escribir imagen.v2.png, y eliminar el .v2 con mod_rewrite en Apache. Con un poco de esfuerzo, todo el proceso puede automatizarse. En Panoramio por ejemplo tenemos una tabla con el MD5 de todos los recursos estáticos qué usamos, y su número de versión (excepto para las imágenes que suben los usuarios). Cuando subimos una nueva versión de Panoramio, un script comprueba el MD5 de todos los recursos, y si este cambia, aumentamos su número de versión. Todas las URLs a nuestros recursos las generamos a través de una función que le añade a la URL el número de versión que hemos calculado anteriormente. Todo esto se basa en que nuestro HTML no debe de estar cacheado, o los clientes puede recibir una versión antigua del HTML con una versión nueva de algunos recursos.
Si teneis algún recurso para el que este tipo de solución no es práctica, entonces tendréis que dejar que vuestros recursos pasen al estado dudoso (o no cachearlo en absoluto). Para comprobar si un recurso sigue siendo válido, el navegador le pregunta al servidor si ese recurso ha cambiado desde que se metió en la caché, usando la cabecera If-Modified-Since. Si no ha cambiado, el servidor responde con HTTP/304 Not Modified, y si ha cambiado responde enviando el nuevo contenido.
Si nuestro recurso no tiene una fecha de modificación clara (por ejemplo, si se ha generado dinámicamente), este método de verificación no nos servirá. Si ese es nuestro caso, al enviar el recurso la primera vez tendremos que añadir la cabecera ETag, que contendrá un identificador único que deberá cambiar cuando cambie el recurso. Los ETag que tanto Apache como IIS generan no dependen exclusivamente del contenido del fichero, si no que también dependen de datos específicos del servidor (por ejemplo, el inode donde se encuentra el fichero). Si usamos varios servidores, este ETag será inutilizable. En la práctica hay muy pocas razones para usar un ETag, siendo la validación por fecha suficiente en la mayoría de los casos.
En el anterior artículo de esta serie preguntasteis por herramientas para poder medir el tiempo de descarga de páginas web. Una formidable es Fiddler, aunque sólo disponible para Windows. Específicamente para Firefox tenemos firebug, sin duda el plugin de desarrollo más útil que existe para Firefox, y que incluye un panel donde podemos ver el tiempo que tarda cada petición al servidor, pero ¡cuidado al interpretar los resultados!, firebug muestra cuando las peticiones entran en la cola de peticiones de Firefox, no cuando se despacha la petición realmente al servidor. El autor de Fiddler tiene un artículo donde habla también sobre el rendimiento de páginas web, y donde explica con algo más de detalle las diferentes cabeceras involucradas en todo el proceso de cacheo.
Queda bastante que hablar de este tema, sobre la compresión de los recursos en el servidor, y sobre todo de los distintos bugs en servidores y clientes que le ponen un poco de pimienta a la vida, pero ya es tarde. ¡Hasta la próxima!
Google Moon y Google Mars son buenos ejemplos de lo que se puede hacer con el API de Google Maps. Sin embargo, cuando lanzamos estos productos, con las ganas de ponerlos a disposición del público cuanto antes, no tuvimos ocasión de ir más allá y ofrecer el uso de las imágenes de Google Moon y Google Mars a través del API de Maps. ¡Pero eso era antes!
El API de Maps v2.95 llega recién salida del horno con soporte explícito para mapas de la Luna y de Marte. ¿Quieres preparar tu próximo aterrizaje en la luna, mantener una base de datos de colonias alienígenas, o simplemente llevar un registro de lo que hemos perdido en Marte? Ahora, crear todo esto y más, es tan sencillo como crear cualquier otro mashup de Maps. ¡Ya no hay límites al cielo!
Y hablando del cielo... cuando estábamos trabajando con Mars y Moon, no nos quedamos ahí. En esta versión del API también hemos incluido soporte de las imágenes de Sky. Sí, ahora puedes utilizar el API de Maps para crear versiones web del cosmos utilizando nuestra galería de imágenes telescópicas. Eso sí, como todavía no dominamos el geoposicionamiento intergaláctico ni la búsqueda de rutas espaciales, tendréis que seguir utilizando los mapas de la Tierra para buscar pizzerías o encontrar la mejor forma de llegar a vuestro destino. Al menos, por ahora.
Michael Kosowsky, de HeyWhatsThat.com ha creado una aplicación que consitutye un gran ejemplo de este nuevo tipo de mapas. En su página Visibilidad Cósmica se pueden ver y entender las fases de la Luna o de Marte. Incluso se puede ver dónde están los planetas o el horizonte, y todo personalizado para diferentes ubicaciones y horas. Esperamos que este ejemplo sea solo uno de los primeros y que haya muchos por venir.
Todo esto ha sido posible gracias a las siguientes constantes predefindas GMapType,que hemos añadido al API de Maps v2.95:
