• AJAX: acceso a las etags, soporte nativo para interpretar JSON.
• Importantes mejoras en las funciones .css y .attr.
• Mejoras en los efectos visuales (p.ej. easing personalizable para cada propiedad en la función effects).
• Nuevos eventos: focusin y focusout
• Aumento de hasta el triple en la velocidad de la función .html().
• Soporte para la creación de nuevos elementos al estilo del dojo.create:
  jQuery("<div />", {
id: "miid",
css: {
height: "70px",
width: "70px",
color: "blue",
backgroundColor: "#eee"
},
click: function() {
$(this).css("backgroundColor", "green");
}
}).appendTo("body");

Alguna desventaja: pasa a pesar unos 70KB comprimida.

Podeis encontrar más información en la web del lanzamiento.

Últimamente y a medida que mis sitios web están ganando en visitas, estoy muy interesado en el tema de la optimización de los proyectos web y poco a poco, voy incorporando varias técnicas que incorporo en la fase final del desarrollo.Una de ellas es la de añadir ETag para los proyectos web que generan contenido dinámico.

La mayoría de los sitios web con contenido dinámico no están continuamente cambiando el contenido, sino que éste es modificado en momentos muy puntuales. Todo el tiempo entre un cambio y otro, el contenido es el mismo y sin embargo, hacemos que el servidor vuelva a generarlo y a enviarlo al servidor como si fuera completamente nuevo.

Las ETags son unos identificadores que se envían al navegador para identificar el “estado” de una página dinámica o de un archivo estático. Son fácilmente configurables en Apache para los archivos estáticos, pero pocas veces son usadas cuando el contenido es generado a partir de fuentes dinámicas.

Imaginemos el caso de este blog. Cada página es modificada únicamente cuando yo hago algún cambio desde el panel de control o cuando alguien deja/modifica un comentario. El resto del tiempo, el contenido de las páginas no varía.Podríamos por tanto identificar a cada página por su URL (p.ej.  ”/2008/10/03/en-espana-se-vende-menos-que-se-compra/” ) y por la fecha en que fué actualizada. Si unimos ambas cosas, podríamos obtener un identificador único. Por ejemplo:

$etag = md5 ($_SERVER['REQUEST_URI'] . $last_modification_time);

Esa sería por lo tanto su Etag.  Y podríamos enviarla al navegador de la siguiente forma:

header("Etag: $etag");

El navegador, cada vez que pida esa página, enviará un header especial “If-None-Match” preguntando si es la misma página que ya le fué enviada la última vez. Con lo que antes de generar la página, podríamos comprobar:


if (trim($_SERVER['HTTP_IF_NONE_MATCH']) == $etag) {
header("HTTP/1.1 304 Not Modified");
exit;
}

De esta forma, informaríamos al navegador de que la página no ha cambiado y por lo tanto no tendríamos necesidad de volver a generarla ni de enviarla por la red. Así ahorraríamos tiempo de proceso en el servidor (carga) y ancho de banda, además de ofrecer una mejor experiencia al usuario.

Por supuesto esta no es una solución válida para cualquier proyecto o situación ( en algunas puede ser incluso contraproducente ), pero si que supone una mejora en una gran parte de los desarrollos. Al menos así ha sido para mí ;)

En el Zend Framework también tenemos ya una propuesta para usarlas.

La gente de 37signals, tras pelearse con varios editores wysiwyg (TinyMCE, Yahoo! YUI Editor, etc.) y no encontrar uno lo suficientemente personalizable, se han puesto manos a la obra para crear el suyo propio y le han llamado WysiHat.

Siempre me parece una buena idea innovar e intentar hacer las cosas mejor, así que desde aquí les doy mi apoyo.

Sin embargo, cuando estás limitado por el tiempo y la necesidad de acabar proyectos para cobrarlos, es bastante dificil innovar. En general creo que los editores existentes  son bastante buenos (mejorables, eso sí) y cumplen muy bien sus objetivos. Yo casi siempre he optado por tinyMCE, porque adaptarlo a cualquier proyecto es realmente fácil y su rendimiento es más que aceptable.

Si te interesa participar en el desarrollo de WysiHat o simplemente probarlo, pásate por su repositorio en github.

¿Qué editor Wysiwyg usas tú para tus proyectos?

Temas de seguridad, programación, CSS, rendimiento, etc. Todo lo que puede necesitar un desarrollador web y además bajo licencia Creative Commons Attribution. Por ahora, prácticamente todo está en inglés, esperemos que pronto haga acto de presencia la lengua de Cervantes.

En las imágenes podeis ver el top 10 de herramientas junto al porcentaje de uso.

Como veis, el tema está bastante movidito y la rivalidad entre las distintas herramientas las está haciendo mejorar hasta alcanzar cotas de calidad muy elevadas. Impresionante el incremento de  uso de JQuery  y  de Ext JS.

Toda la información y resultados de la encuesta podeis encontrarlos aquí.

Y aquí teneis una captura de lo que podemos esperar de ella:

Me alegra ver la sana competición que se está dando entre los diferentes frameworks Javascript, que está consiguiendo niveles de calidad sorprendentes. ¿Alguien duda ya de los beneficios del open source?

Programadores web

• Manuel Cebrián (Málaga)
• Oscar Reales (Málaga)
• Rafa Chacón (Sevilla)
• Luis Molina (Málaga -> Granada)

Diseñadores web

• Juan Pablo Olmo (Málaga)
• Daniel Mota (Cádiz)

Espero los vuestros en los comentarios.

Hemos visto muchas otras soluciones de esto mismo, usando Ajax, pero si hay que elegir, sin duda me quedo con la implementación de Flash. Aún no funciona en algunas plataformas, por ejemplo si estás en Linux, te mostrará el antiguo sistema de subida. Aunque si tienes alguna versión “debug” y muy nueva del plugin, puedes probarlo usando la url http://www.flickr.com/photos/upload/?nocheck para que no haga la comprobación.

Para todos aquellos que tengais dudas de cómo almacenar imagenes en MySQL, hace bastante tiempo escribí un artículo que os puede resultar interesante.

En general, mi experiencia sobre el tema me lleva a recomendar que se use el sistema de ficheros del servidor antes que guardar la imagen directamente dentro de la base de datos.

Algunos de los inconvenientes que me he encontrado:

• lentitud en las consultas a la tabla que contiene las imágenes.
• dificultad a la hora de recuperar las imágenes.
• dificultad a la hora de exportar la información de la base de datos e importarla en otro servidor / base de datos.
• sobrecarga del servidor (más pasos e instrucciones para conseguir algo que puede ser muy simple).
• etc.

Además, el tener disponibles las imágenes en carpetas del servidor os permitirá usar de forma sencilla herramientas de redimensionado y retoque como la biblioteca GD o las de imagemagick.

Por lo tanto,  mi recomendación es – siempre que sea posible – evitar guardar las imágenes directamente en la base de datos.

Veo también en las estadísticas que el tema de buscar un codigo postal es un problema muy común, por eso he escrito una pequeña utilidad para encontrar cualquier codigo postal de España.

Aún está un poco verde, por lo que puede tener fallos. Espero que la probeis y que si no os ayuda a encontrar el código postal que buscais, me lo comenteis para ir mejorándola.

Es muy sencilla, simplemente eliges la provincia y la localidad y escribes la calle y el número. En caso de que haya varias coincidencias para una calle determinada, el sistema mostrará la lista completa.