Artefacto

No hemos dado señales de vida últimamente, pero estos meses están siendo de lo más productivos. De momento, toca dar la bienvenida a la familia Artefacto al Restaurante del Casino de Burgos, para quienes hemos desarrollado un proyecto que abarca desde el diseño de interiores y decoración del local hasta el diseño de su sitio web.

La web, programada en Flash, se apoya en nuestro sistema de gestión de contenidos, Artefacto Server, para permitir una configuración sencilla de algunas de sus secciones.

¡Bienvenidos a bordo!

Llevamos ya bastante tiempo trabajando en la nueva web de Artefacto, que sustituirá a nuestros venerables vagones de metro, y que estará lista, si todo marcha según lo previsto, a lo largo de estos últimos días del año.

Más adelante revelaremos más detalles sobre la web, por el momento sólo quiero escribir un pequeño apunte técnico relacionado con la navegación. Hemos decidido hacer un pequeño menú desplegable utilizando Javascript, para lo cual una opción muy interesante resultó ser Redux (ver ejemplo), un menú de tipo acordeón escrito en apenas 40 líneas de código gracias a JQuery. Es sencillo de configurar y además proporciona persistencia mediante cookies.

Sólo tiene –tenía– un pero. Y es que si se utiliza en páginas con enlaces semánticos, el script guarda una cookie distinta para cada ruta visitada, al interpretar la dirección como un camino de directorios. Al final, esto hace que cada página del sitio tenga una memoria del menú distinta. En fin, para volverse loco –puedo dar fe de ello–. Sin embargo, la solución –no tanto el diagnóstico– es bastante sencillo. Basta sustituir la línea:

$.cookie(parent, this.className);


Por esta otra:

$.cookie(parent, this.className, {path: '/'});


Que inserta la cookie asociada al directorio raíz del sitio. Lo cual de paso nos sirve como excusa para admirar dos cosas: la increíble potencia de JQuery y lo increíblemente práctico que es el plugin para la gestión de cookies de que dispone. Poesía pura :-)

Justo cuando parecía que Apple empezaba a olvidarse del Mac Mini y muchos empezábamos a temernos su retirada, la compañía de la manzana nos sorprendió hace unos días con una actualización del hardware (acompañada de una rebaja en el precio) y con una novedad muy interesante: un Mac Mini especialmente diseñado para funcionar como servidor.

Este nuevo Mac Mini monta un Core 2 Duo a 2.53 GHz, 4 GB de memoria principal y dos discos duros de 500 GB (es decir, 1 TB en total), uno de los cuales va montado en lugar de la unidad de DVD. También incluye una copia de Mac OS X Server (Snow Leopard), todo por 929 €. Una opción verdaderamente interesante tanto para usuarios domésticos como para pequeñas empresas. Y teniendo en cuenta que la licencia de Snow Leopard Server cuesta 479 €, creo que realmente vale la pena tenerlo en cuenta.

Los sistemas operativos para servidores de Apple siempre han destacado por sus excelentes prestaciones y por su facilidad de uso. Además de las funciones típicas en un servidor, Snow Leopard Server permite compartir calendarios, agenda, wikis y dispone de un acceso telefónico que me parece realmente tentador :-)

Hace un tiempo escribí un artículo sobre la biblioteca para Javascript SWFObject, dirigida a facilitar la integración y la accesibilidad del Flash incluido en las páginas web, que venimos utilizando desde hace bastante tiempo con resultados muy satisfactorios.

El hecho es que utilizar la biblioteca en cuestión requiere, evidentemente, de cierto código adicional, y cada vez que tenía que utilizar un archivo de Flash distinto y unas dimensiones diferentes me veía obligado a hacer más cambios de los que me parecían razonables. Así pues, decidí ponerme al lío y programar una pequeña clase en PHP que he llamado FlashLoader y que soluciona el problema.

Para utilizarla, hay que instanciar la clase FlashLoader indicando la ruta del archivo de Flash, la de la biblioteca SWFObject, el ancho, el alto y la versión. Luego, simplemente hay que ir llamando a métodos que devuelven las cabeceras para incluir el archivo de la biblioteca, la inicialización de la misma y el código del objeto Flash.

He preparado un ejemplo que consta de la clase (class.flashloader.php), un archivo de ejemplo con el Flash (flash.swf), la versión 2.1 de la biblioteca SWFObject (swfobject.js) y el archivo principal (index.php). Casi no hay comentarios porque creo que se entiende muy fácilmente.

Descargar FlashLoader 1.1 (ejemplo)

La clase puede distribuirse con arreglo a los términos de la licencia GPL. Las aportaciones, preguntas y demás serán bienvenidas :-)

Aunque todavía está a falta de que nuestros clientes completen el contenido, ya está disponible la nueva web de Iberdatos, a la que hemos añadido una sección separada que permite a los visitantes contratar servicios legales con apenas dos clics (el de aceptar las condiciones y el de enviar el formulario :-P).

Esta nueva iniciativa permite tanto la contratación de servicios legales o proyectos de adecuación en materia de protección de datos como la realización de consultas sobre derecho de las nuevas tecnologías, todo de manera rápida, sencilla y eficaz.

Smashing Magazine recogía el otro día una curiosa recopilación de páginas de error de recurso no encontrado (el error 404 del protocolo HTTP). Las hay verdaderamente elaboradas y curiosas, aunque si tuviera que quedarme con una, sin ninguna duda elegiría la siguiente:

Recientemente hemos añadido una página de error en la web de Artefacto Server, y próximamente extenderemos esta característica a los nuevos sitios que estamos desarrollando. Aunque el diseño es importante, una página de error de este tipo debería estar centrada en aportar información al usuario y ofrecerle alguna alternativa. Nosotros nos hemos inclinado por ofrecer un pequeño formulario de contacto que permita a los visitantes preguntarnos por la información que estaban buscando:

Hay otras opciones que pueden ser interesantes, como mostrar el mapa del sitio o utilizar la dirección escrita por el visitante para realizar una búsqueda en el sitio. Probablemente añadamos alguna de estas características tarde o temprano, en función de los datos que obtengamos a través de las estadísticas.

Leo en el blog de Reven que la revista .net ha lanzado una campaña encaminada a pedir la desaparición del Internet Explorer 6. Este navegador fue lanzado en un momento en que Microsoft imponía sus propias normas utilizando su posición en el mercado, ignorando sistemáticamente las recomendaciones de la organización W3C, organismo encargado de la estandarización de las tecnologías web.

La consecuencia es que los desarrolladores web nos vemos obligados generalmente a hacer verdaderas locuras para lograr que nuestros sitios cumplan los estándares y a la vez funcionen correctamente en IE 6. La solución acaba pasando muchas veces por ignorar los propios estándares y lograr una solución que más o menos funcione en todos los navegadores. Otras veces no hay más remedio que definir una hoja de estilos específica para Internet Explorer o añadir código Javascript, siempre después de unas cuantas horas de sufrimiento y búsquedas…

Hace ya tiempo que Microsoft lanzó el Internet Explorer 7, que soluciona la mayor parte de los problemas de su predecesor (aunque crea otros, claro está). Sin embargo, muy pocas personas han instalado la nueva versión, y de hecho la mayoría de nuestros clientes siguen utilizando la versión 6.0. Eso nos obliga, al final, a tener que seguir desarrollando con este navegador en mente.

Según los datos que manejo, más o menos el 10% de las horas que necesitamos para desarrollar una plantilla XHTML desde cero son invertidas en asegurar su funcionamiento en IE 6. Conozco directamente al menos dos empresas de desarrollo donde ya desglosan estos costes a los clientes para concienciarles de los costes que les supone este navegador, y en Artefacto ya hemos considerado en alguna ocasión empezar a hacerlo.

Últimamente, muchas voces del mundo del desarrollo se inclinan por intentar superar de una vez para siempre la era IE 6. Esta campaña es un paso más, pero hay otras iniciativas algo más radicales como la que plantean en anieto2k, consistente en eliminar los estilos de las páginas siempre que sean cargadas con Internet Explorer 6 a partir del 18 de octubre de este año. Una idea atrevida pero sin duda eficaz.

Veremos en qué acaba todo esto. Personalmente opino que todos saldríamos ganando: los desarrolladores seríamos más felices y nuestros clientes navegarían más seguros, y por eso he decido escribir este artículo apoyando la causa.

Aquellos que todavía usen Internet Explorer 6 pueden actualizar su navegador, o pasarse a otra de las fantásticas opciones que existen, como Firefox, Opera o Safari, mucho más respetuosas con los estándares, más seguras y con muchas más opciones interesantes.

También se hacen eco de la iniciativa en menéame.

Llevo todo el fin de semana arreglando el código de Artefacto Server, mejorando su legibilidad y tratando de mejorar su eficiencia todo lo que sea posible. El problema de las aplicaciones web es que en cuanto empiezan a crecer se multiplican las consultas a la base de datos, la inclusión de ficheros de PHP, la descarga de archivos de estilos o de Javascript… y al final pueden llegar a ser realmente pesadas.

De momento me estoy centrando en limitar las comprobaciones en la inclusión de archivos PHP, sustituyendo los require_once() por llamadas a require() convencionales (que resultan algo más rápidas al no tener que comprobar si el archivo ya ha sido incluido), en la corrección general del código, en la optimización de las consultas a la base de datos (verdadero cuello de botella de las aplicaciones web) y en la reducción del tamaño de las páginas.

Sobre esto último, algunas secciones del panel de control de Artefacto Server tenían código CSS o Javascript escrito directamente en el archivo PHP. Esto es un problema porque incrementa el tamaño de la página que se descarga al navegador, con lo cual el tiempo de carga es mayor. Ya solucionamos esto en gran medida en Artefacto Server 3.1, pero todavía quedaban algunos módulos con ciertas particularidades sin actualizar.

La ventaja de este enfoque es que el navegador guarda en la caché los archivos y eso siempre acelera la carga. No obstante, todavía se puede dar una vuelta de tuerca más, que consiste en comprimir el código Javascript o CSS, eliminando saltos de línea, espacios, etc. Adicionalmente, se puede cambiar el nombre de las funciones y variables y reducir el código todavía más. Para no tener que hacer este trabajo a mano hay algunas opciones interesantes, y la más popular parece ser JSMin, que además es libre. Hay una implementación en PHP, jsmin-php, con la que he estado trabajando estos días. He hecho la prueba con uno de los ficheros de funciones comunes y ha pasado de 3060 a 2476 bytes, lo cual nos arroja una tasa de compresión del 20%, que no está nada mal. Otro fichero Javascript del panel de control ha pasado de 3247 a 1754, lo cual supone una reducción de casi el 50%.

Hay que decir que todo esto no va a solucionarnos ningún problema por si solo, sino que tenemos que tomarlo como una acción más de un conjunto de medidas encaminadas a mejorar la rapidez general de la aplicación.

Vía | aNieto2k

Como paso previo a la creación de nuestro propio tema de Wordpress decidimos que lo mejor era traducir uno existente y después adaptarlo. Fruto de esa decisión, queremos publicar aquí la traducción que realizamos por si a alguien le sirve.

Hemos creado una sección de descargas donde iremos colgando poco a poco todo lo que podamos ir aportando a la comunidad. De momento ya se puede descargar el tema Journalist 1.9 traducido al español.

En Artefacto intentamos aportar un enfoque de calidad en todos nuestros proyectos, lo cual pasa ineludiblemente por utilizar estándares de codificación y por tener en cuenta la accesibilidad. Tradicionalmente, el uso de objetos Flash ha sido un inconveniente en este sentido, pero afortunadamente existen soluciones, la mayoría de ellas escritas en JavaScript, dirigidas a mejorar la integración de Flash en documentos XHTML.

Hasta hace unos meses, habíamos utilizado en nuestros proyectos el módulo Unobtrusive Flash Objects, que daba muy buenos resultados y que iba ya por su versión 3.22. Sin embargo, hace unos meses que apareció una revisión de este módulo, llamada SWFObject, que ya va por su versión 2.0, y que mejora en gran medida el uso de objetos Flash no obstructivo. En Google Code hay un wiki con mucha documentación sobre las opciones que permite este novedoso módulo.

En mi opinión resulta algo menos sencillo de usar que su predecesor, aunque los responsables del proyecto están en todo y han puesto a disposición de la comunidad un generador automático de código que simplifica en gran medida el trabajo.

La ventaja de todo esto es que se puede crear un contenido alternativo al Flash en la página, de manera que se mantenga la accesibilidad del sitio y de paso no perjudiquemos al posicionamiento. En nuestro último proyecto, una web realizada para la Sociedad de Montañeros Burgaleses (y que podéis ver en nuestro servidor de pruebas de momento) hemos seguido este enfoque. Así, en condiciones normales, el usuario vería el menú Flash:

Y si el navegador no soporta Flash o bien el usuario lo tiene desactivado, el contenido que se muestra es el siguiente:

Que aunque no es tan bonito como el Flash, sí que queda razonablemente bien para estar hecho sólo con texto y CSS, y además es totalmente accesible. La ventaja de este enfoque en el menú, es que por debajo del Flash sigue estando una lista XHTML con los enlaces, por lo que los buscadores los seguirán sin notar la diferencia. También hemos utilizado la misma estregia con la cabecera: en ausencia de Flash se carga una imagen que guarda la estética de la página.

Como digo, todo en una línea de compromiso con la accesibildad y las buenas prácticas de programación que esperamos ir extendiendo poco a poco a lo largo de toda nuestra estrategia de desarrollo web. Es un camino complicado pero vale la pena intentarlo.