1. Forecastfox: En la planificación de las vacaciones es fundamental conocer el estado del tiempo en los días indicados. En este sentido nos ayuda esta extensión, que nos permite conocer la previsión meteorológica del lugar del mundo que queramos fácilmente. Ofrece muchas opciones de personalización y la información puede mostrarse tanto en la barra de herramientas como en la de estado.

2. Directions with Google Maps: Esta extensión nos facilita la localización en Google Maps de cualquier dirección que veamos en una página web. Basta con seleccionar el texto, pulsar con el botón derecho del ratón y elegir “Localizar en Google Maps” para que se abra una pestaña con la dirección señalizada en un mapa de Google. Ideal para encontrar fácilmente aquellos lugares que queramos visitar en nuestras vacaciones.

3. Hoteloogle.com: Se trata de un nuevo motor para la barra de búsquedas de Firefox que nos permite localizar y compara hoteles en un buen número de ciudades por todo el mundo. Una sencilla manera de encontrar alojamiento al mejor precio. Por cierto, Hoteloogle.com no me da comisión por mencionarlos

4. Fotofox: ¿Qué es lo que más hacemos en vacaciones? Sacar fotos, sin duda. Cámaras digitales, móviles, agendas, consolas portátiles… existen numerosos dispositivos que hacen que el tomar fotografías sea cada vez más sencillo y accesible para todos, lo que hace a su vez que tengamos ingentes cantidades de fotos que además estamos deseando compartir con nuestros conocidos. Para ello, nada mejor que un buen servicio Web 2.0 de gestión de fotos. Con esta extensión podremos compartir nuestras fotos con los demás en el servicio que queremos, a elegir de entre los más populares.

5. Foursquare: Para finalizar, no puedo resistirme a hacer referencia al máximo exponente de las redes sociales de la geolocalización. Gracias a Foursquare y a los comentarios y pistas de otros usuarios podremos localizar sitios interesantes y cómo sacarles el máximo provecho. La única pega es que hay que darse de alta en Foursquare para un óptimo rendimiento de la extensión, pero a estas alturas ¿qué más da una red social más o menos?

Estas son mis extensiones preferidas para las vacaciones de verano. ¿Cuales son las vuestras? ¿Alguna sugerencia?

Cuatro días después del anuncio de Debian, el proyecto KDE hizo pública la inmediata disponibilidad de la versión 4.5 de su entorno de escritorio, que se ha centrado en la resolución de errores y en la estabilización del software antes que en la adición de nuevas funcionalidades. Esto la convierte en una versión clave para todos los que utilizamos KDE SC como nuestro escritorio habitual.

Pues bien, debido a que Debian Squeeze se congeló sólo unos días antes, sus usuarios no podrán disfrutar de KDE SC 4.5. ¿Tan difícil era coordinarse con la gente de KDE para evitarlo? Teniendo en cuenta que una semana antes KDE había publicado la última versión candidata de la versión 4.5, ¿por qué se ha elegido en Debian esta fecha para congelar?

Entiendo que un proyecto del calibre de Debian no puede estar al tanto de los avatares de cada software incluido en la distribución y publicar según los demás lo van haciendo, ni siquiera por pesos pesados como Firefox u OpenOffice.org, pero sí hay ciertos componentes software cruciales a los que SIEMPRE habría que seguir de cerca, como el propio núcleo de Linux, el entorno gráfico X.org o los entornos KDE y GNOME.

Al final, los perjudicados por esta decisión son los usuarios de Debian y KDE, que no podrán contar con la mejor versión de este escritorio hasta la fecha, y el propio proyecto Debian, que vuelve a salir a la calle con una distribución estable sin el software más moderno disponible (desde la congelación hasta la publicación pueden pasar semanas, lo que agrava el problema).

El problema parecía provenir de una aparente incapacidad de Facebook de extraer del portal web del cliente la información necesaria para la publicación de la noticia a compartir, a pesar de haber utilizado el método estándar más sencillo para compartir una página web en Facebook. El siguiente paso fue seguir a rajatabla las instrucciones de Facebook, tanto para utilizar otros métodos para compartir información web como para facilitar la detección de dicha información, sin éxito.

Se nos ocurrió entonces que si el analizador de Facebook no podía encontrar la información deseada puede que fuera porque el código del portal tuviese algún problema. Aunque estábamos seguros de antemano de que dicho código era estándar, por si acaso pasamos el portal por el validador del W3C, que nos confirmó que el código XHTML que producía el motor de Typo3 era válido. Esto es algo que cuidamos mucho en nuestros proyectos web, buscando asegurar la visibilidad en la mayoría de navegadores, plataformas y sistemas operativos. En el caso de Typo3, esto lo conseguimos tanto a través de extensiones especializadas (para el contenido y funcionalidades estándares) como de una composición de código muy cuidadosa (en el caso de las personalizaciones que tengamos que llevar a cabo). Para los interesados, les recomiendo extensiones como cron_accessiblemenus, accessible_tables y qcom_htmlcleaner.

Lo siguiente fue investigar (vía Google, dónde si no) si había más gente con este problema. Desgraciadamente, esta incidencia es más común de lo deseable y se produce independientemente de la forma de gestionar y producir el código del portal, ya sea a mano o con un gestor de contenidos (Typo3, Drupal, Joomla, etc.). A pesar de que nadie encontraba una solución, al menos una que sirviese para todo el mundo, sí nos dimos cuenta de que había algo en común en todas las quejas: los responsables de dichos sitios web también tenían mucho cuidado con la validez y estandarización del código que producían. Eso nos llevó a pensar que quizás el problema estuviese ahí, algo en el código que impedía que el analizador de Facebook hiciese su trabajo. A estas alturas era evidente que la culpa era de Facebook y no de los centenares de desarrolladores web con el mismo problema en todo el mundo, pero eso no quitaba para buscar una solución para nuestro cliente.

En nuestro caso, analizando minuciosamente el código XHTML del portal, encontramos pronto un primer candidato a “culpable”. Todos nuestros portales Typo3 empiezan de la misma manera, con una línea como ésta:

<?xml version="1.0" encoding="utf-8"?>

A día de hoy, pocos navegadores, dispositivos y otros elementos de acceso a la web echan cuenta de la información contenida en esa línea, por muy estándar que sea, así que probamos a eliminarla y, ¡voilá!, problema resuelto. El analizador de Facebook era repentinamente capaz de capturar la información de las noticias que nuestro cliente quería compartir. En el caso de Typo3, basta con añadir la siguiente línea en la configuración de la plantilla:

config.xmlprologue = none

A pesar de producir código válido y estándar en el portal web y de haber seguido las instrucciones del propio Facebook al pie de la letra, su analizador era incapaz de realizar correctamente el trabajo para el que supuestamente está preparado, lo que no habla muy bien de la popular red social. Si para que funcione bien, encima hay que “disminuir” el nivel de estandarización de una web, apaga y vámonos. Este es precisamente el peligro de no respetar los estándares en la web: problemas, costes extra, usuarios excluidos y, en el caso de una empresa, clientes insatisfechos.

Para ello, lo que voy a hacer es adaptar los pasos y tareas detallados en el otro artículo a Scrum, mi metodología favorita y la que utilizamos preferentemente en Activa Sistemas. El proyecto empieza definiendo el conjunto inicial de requerimientos y funcionalidades del nuevo entorno web y recogiendolo en el product backlog, que nos servirá de guía a lo largo del proyecto. A continuación pactamos con el cliente los objetivos de la primera iteración, con lo que estaremos en disposición de acometer las tareas que en el artículo anterior estaban dentro de la fase de Codificación de una metodología en cascada.

En la primera iteración se instala necesariamente el motor de Typo3 sobre el que desarrollaremos el proyecto y una plantilla estándar que nos permita visualizar desde el primer momento el resultado del trabajo. De este modo se cumple con una de las premisas fundamentales del desarrollo ágil: tener siempre disponible un producto publicable y en funcionamiento que el cliente puede revisar cuando quiera.

A partir de aquí podremos ir diseñando e integrando la plantilla visual, introduciendo el contenido estático, instalando las extensiones y codificando las personalizaciones en paralelo en las sucesivas iteraciones, en las que podremos implicar sin problemas al cliente y a los futuros usuarios.

Además, gracias a ciertas caracteristicas de Typo3, podremos incorporar al desarrollo del proyecto herramientas de otras metodologías ágiles como XP o TDD. Por ejemplo, incluye su propio sistema de control de versiones, lo que facilita la introducción controlada de pequeños cambios y posibilita la propiedad colectiva del código. Así mismo, la construcción de pruebas unitarias es relativamente sencilla, gracias tanto al propio framework PHP de Typo3 como a ciertas extensiones especializadas (PHPUnit, Cool).

Con esto espero haber dejado claro que es perfectamente posible gestionar de forma ágil un proyecto web en general y con Typo3 en particular. Sólo se trata de tener las ganas de hacerlo y las herramientas adecuadas para ello.

La situación era la siguiente: teníamos que migrar varias máquinas virtuales Xen que contenían sendos portales web desde un servidor físico a otro. Aquí se nos presentaba la primera dificultad. A pesar de que las arquitecturas hardware de los servidores eran prácticamente idénticas, no era así en el caso de los sistemas operativos, ya que el origen tenía instalado Debian 4.0 y el destino Debian 5.0. Habrá quien piense que soy un exagerado y que eso no es tanta diferencia. Nada más lejos de la realidad, ya que las versiones de núcleo Linux y del software de virtualización Xen son diferentes, lo que de algún modo impedía el correcto funcionamiento de la herramienta “xm migrate”, que fallaba inmediata e indefectiblemente con un error críptico cada vez que era invocada desde la línea de comandos del servidor de origen. A pesar de preparar concienzudamente ambos servidores para permitir la migración al vuelo, la herramienta propia de Xen no hacía su trabajo.

La solución fue relativamente sencilla. Todo consistió en hacer lo mismo que se suponía debía hacer “xm migrate” pero a mano y paso a paso. Lo primero era parar la máquina virtual con “xm shutdown”, para proceder a continuación a su copia al servidor destino. Aunque nosotros lo hicimos por SSH, las posibilidades aquí son amplias (FTP, NFS, SMB, USB, etc.). La copia de cada máquina virtual comprendía el fichero imagen del disco principal, el fichero imagen de la memoria de intercambio o swap y el fichero de configuración correspondiente.

Una vez copiados los ficheros al servidor destino, el siguiente paso es arrancar las máquinas virtuales una a una con “xm create”. Sin embargo, no iba a ser tan sencillo, ya que Xen se quejó de que le faltaban el núcleo Linux y el initrd de las máquinas virtuales, que procedimos a copiar desde el servidor origen, con lo que el arranque se produjo después sin más problemas.

Para finalizar, quedaban por ajustar algunas cosas, como la configuración de red de Xen (en el servidor origen se usaba el modo bridge mientras que en el destino estaba activo por defecto el modo NAT), la actualización de los DNS de los portales web con la IP del servidor destino y la configuración del proxy inverso residente en los servidores físicos que gestiona las peticiones realizadas a cada máquina virtual.

De esta historia puede obtenerse una valiosa lección. Aunque cualquier sistema de virtualización, incluyendo Xen, hacen su trabajo a un buen nivel, podemos encontrarnos en cualquier momento una serie de problemas que impidan su adecuada gestión y mantenimiento, más teniendo en cuenta lo delicados y exigentes que son. En este sentido, es fundamental tener unos profundos conocimientos y experiencia en administración de sistemas en general y en el sistema de virtualización de nuestra elección en particular para evitarnos males mayores y salir airosos de cualquier situación.

El primer obstáculo es la propia Administración Pública. A día de hoy es muy raro encontrar una licitación en la que no se pida utilizar METRICA v3 o una metodología clásica similar. De hecho, en una licitación a la que nos presentamos hace un par de años y que no conseguimos, se me llegó a argumentar que nos quedamos fuera por no proponer una metodología adecuada, cuando lo que planteamos fue precisamente una metodología basada en entrevistas, iteraciones, escenarios y maquetas. Solución: introducir de forma sutil (por no decir oculta) en las propuestas mecanismos ágiles en la relación con el cliente y utilizar herramientas ágiles en los procesos internos de desarrollo del proyecto, como la programación en parejas típica de XP o las mencionadas iteraciones de Scrum (dejando de lado al cliente).

El segundo obstáculo nace de las propias dimensiones de Andalucía. La distancia entre Ayamonte al oeste y Pulpí al este es de más de 600 kilómetros. Cuando uno tiene su sede en Sevilla y trabaja mucho en Almería, como nos pasa en Activa Sistemas, se producen inevitablemente unos costes extras de desplazamiento, manutención y estancia que no son precisamente despreciables. A pesar de que Internet ha recortado las distancias considerablemente, es indiscutible que sigue haciendo falta el contacto directo con el cliente, ya sea porque éste lo exige para creerse que “se está haciendo algo” o bien porque existen tareas en todo proyecto de desarrollo que necesitan de una actuación de campo. Si a esto le añadimos las iteraciones de un proyecto ágil, los costes logísticos se convierten en un gran obstáculo para ser competitivo frente a otras ofertas. Solución: minimizar los viajes, aprovecharlos para realizar varias tareas en paralelo, maximizar el contacto por Internet (utilizando desde el correo electrónico hasta la videoconferencia, pasando por la mensajería instantánea) y, a pesar de todo, calcular un presupuesto holgado para poder costear varios viajes.

El tercer y último obstáculo es uno que se menciona en un artículo en Agile Spain (¿ves Jose como os sigo?): los presupuestos cerrados. En dicho artículo, en la sección de “Estimaciones”, se dice que hay que intentar huir de proyectos a precio cerrado. Pues bien, a día de hoy estoy aún por ver un proyecto en el que el cliente me dé un cheque en blanco. Lo más parecido que me he encontrado es una bolsa de horas que se va gastando y cuyo consumo controla el cliente en todo momento. No sé en otros lugares de España, pero en Andalucía lo que se estila es el presupuesto cerrado, tanto en coste como en tiempo, lo que no evita que el cliente intente tomarse “barra libre”, como comenta el mencionado artículo, lo cual va a ocurrir independientemente de la metodología utilizada. Solución: presupuestos holgados (a la vez que competitivos) para tener margen de maniobra y poder satisfacer al cliente en los eventuales cambios que se produzcan en el desarrollo del proyecto (que seguro se van a dar).

Aplicando las soluciones comentadas hemos conseguido sortear estos duros obstáculos en diversos proyectos, los cuales han resultado ser los más satisfactorios tanto para el cliente como para nosotros mismos. Esperemos que la situación siga cambiando y que las metodologías ágiles vayan calando cada vez más en la sociedad andaluza.

En este sentido, impedir que en Europa se pueda patentar el software es fundamental para conseguir dichos objetivos. Si no fuera así, según Eurolinux, las pymes europeas no tendrían un mercado accesible, las administraciones públicas no podrían utilizar estándares realmente abiertos, no se podría promover la creación de puestos de trabajo mediante inversión pública sostenible en el desarrollo del software libre y Europa no tendría independencia digital.

A mí se me ocurren algunas razones más, como el ahogamiento de la innovación o la pérdida de la libre competencia, no tanto a manos de las grandes empresas tecnológicas (que prefieren comprarte para quitarte de en medio) como de los conocidos como trolls de patentes, empresas con una amplia cartera de patentes, las cuales probablemente no habrán investigado y desarrollado ellos mismos sino que las habrán comprado a un tercero, y cuya única línea de negocio es demandar a todo aquél que utilice comercialmente tecnologías cubiertas por algunas de sus patentes sin haber pagado previamente unos suculentos royalties. Es fácil imaginar muchos más peligros que encierran estas prácticas para la economía de Europa.

Precisamente por este mal uso que se le puede dar a las patentes de software y que tan generalizado está a día de hoy en EEUU, Eurolinux apoya StopSoftwarePatents.eu. Gracias al tratado de Lisboa, los ciudadanos europeos pueden organizar peticiones que, cuando alcanzan una masa crítica de apoyos, obligan a la Comisión de la Unión Europea a proponer un proceso legislativo. Lo que persigue Eurolinux es “reconstruir una plataforma para iniciar un proceso legislativo que invalide de una vez por todas las patentes de software en Europa”. Por eso, desde estas líneas, animo a todo el mundo a hacer todo lo que esté en su mano (empezando por firmar esta nueva petición) para asegurar que el futuro tecnológico de Europa esté en manos de sus ciudadanos.

Comparativa de tiempos de arranque (fuente: www.openoffice.org)

Entre todas las novedades de esta versión 3.2, sin duda la más destacable es la reducción del tiempo de arranque. Si en la versión 1.0 podíamos llegar a esperar más de 20 segundos en iniciar cualquiera de las aplicaciones ofimáticas, ahora es cuestión de muy pocos segundos el tener en pantalla el familiar interfaz de OpenOffice.org. Esto que puede parecer una trivilidad sin importancia, puede llegar a producir verdadero hastío en el usuario, repercutiendo de forma importante en su productividad frente al ordenador.

En segundo lugar de importancia se halla la mejora del soporte de los formatos ODF, MS Office y otros propietarios, lo cual supone un nuevo paso adelante hacia una mayor interoperatibilidad entre sistemas heterogéneos y una gran ayuda a la hora de introducir OpenOffice.org en una empresa u otro tipo de organización.

La lista de novedades continúa con una serie de mejoras generales, como el soporte de fuentes OpenType basadas en Postscript o la introducción de nuevos idiomas para la configuración regional, y con un buen número de mejoras en todas las aplicaciones que forman OpenOffice.org, siendo en esta ocasión Calc quien ha sufrido más cambios. Todas estas mejoras son muy interesantes y no hacen más que elevar el ya de por si elevado nivel de calidad de la suite ofimática.

Y ahora la pregunta del millón: ¿actualizar o no actualizar? La respuesta definitivamente es afirmativa. Salvo en muy contadas ocasiones (como cuando sacan dos versiones muy seguidas o cuando la nueva versión añade realmente poco a la actual), siempre que ha salido una nueva versión de OpenOffice.org no he dudado mucho en instalármela. El equipo de desarrollo suele introducir suficientes novedades y mejoras como para que merezca la pena la actualización, a pesar de que no se trata de una descarga ligera precisamente.

Ahora bien, si somos responsables de una red informatica con varias decenas de puestos de trabajo, actualizar OpenOffice.org puede convertirse en una ardua tarea si no contamos con un buen sistema local de distribución automatizada de software. En este caso, mi respuesta debe ser más moderada y sólo recomendar la instalación de una nueva versión si la misma es lo suficientemente importante como para justificar el esfuerzo, como sí ocurrió con la versión 3.0, la cual a estas alturas ya debería estar instalada en los ordenadores de todos los usuarios de OpenOffice.org.

Siguiendo las tendencias actuales, KDE SC 4.4 ofrece una mayor integración con las redes sociales y herramientas que facilitan la colaboración online. Para ello se ha mejorado el widget (elemento gráfico) Comunitario (que antes se llamaba Escritorio Social) para que los usuarios puedan enviar mensajes y encontrar a sus amigos desde el propio widget. Así mismo, se han creado dos nuevos widgets, Noticias Sociales (que permite al usuario seguir en tiempo real lo que ocurre en su red social favorita) y Base de Conocimiento (que posibilita la búsqueda de preguntas y respuestas en varios proveedores). Finalmente, gracias a las mejoras en el soporte online, los usuarios pueden ahora colaborar masivamente, compartiendo y recibiendo contenidos desde las propias aplicaciones, por ejemplo descargando nuevos niveles en los juegos, instalando nuevas funcionalidades en los programas, comentando y puntuando los contenidos, convirtiéndose en fan de un producto concreto y enviando su propio contenido directamente sin tener que empaquetarlo y subirlo a mano a un sitio web.

El escritorio en sí también ha recibido importantes mejoras. Por un lado, se ha creado un interfaz específico para netbooks, de forma que se aprovecha mejor el reducido espacio de sus pantallas y se facilita el uso de dispositivos táctiles. Por otro, ahora es posible agrupar varias ventanas en una sola mediante el uso de las populares pestañas.

Otras mejoras de la plataforma incluyen la integración de las búsquedas de escritorio dentro del explorador de ficheros Dolphin mediante el uso de la tecnología Nepomuk para ayudar al usuario a localizar y organizar sus datos, el primer uso del nuevo sistema de almacenamiento de datos propia de KDE (conocida como Akonadi) a través de la agenda de contactos KAddressbook, una nueva infraestructura de autentificación llamada KAuth que permite una gestión completa de privilegios, políticas de autorización y contraseñas, mejoras en diversas aplicaciones como KGet o Gwenview y la introducción de nuevas herramientas como Palapeli (un juego de puzzles), Cantor (un interfaz a software científico y estadístico) y Blogilo (una aplicación de blogging).

Por útlimo, la tecnología en la que se basa KDE SC 4.4 también presenta importantes novedades. Al basarse en la versión 4.6 del toolkit Qt, KDE SC tiene ahora soporte para la plataforma Symbian, una nueva infraestructura de animaciones, multitouch y mejor rendimiento.

Un último apunte. Dado que ASLinux Desktop 4.0 se publicará en Abril tras la congelación de Debian Squeeze, por fechas KDE SC 4.4 será indudablemente la versión del escritorio de la distribución de Activa Sistemas, aunque ya sólo por la calidad del producto se merece estar en los puestos de trabajo de cualquier usuario.

Firefox 3.6 supone un gran avance con respecto a las versiones anteriores, sobre todo en cuestiones de estabilidad (gracias a mecanismos como el control de plugins antiguos o la prohibición de mezclar código de las extensiones con el del propio Firefox) y rapidez (gracias al rendimiento mejorado del motor JavaScript, entre otras cosas). Llevo trabajando con él desde que se publicó y aún no se me ha quedado colgado ni una vez, siempre me ha respondido de forma casi inmediata y carga las páginas a gran velocidad. Y eso que soy un usuario que suele tener abiertas una media de 20 pestañas simultáneas, con contenido multimedia o con plugins en muchas de ellas, y con un elevado número de extensiones instaladas.

Además, Firefox 3.6 incluye de serie el soporte de nuevas tecnologías web que enriquecen la navegación, como los nuevos atributos CSS (como degradados, tamaño de fondos y eventos de puntero), las tipografías en formato Web Open Font y las nuevas especificaciones HTML5 (que permiten la reproducción nativa de vídeos, incluso a pantalla completa).

Si a todo esto le añadimos la filosofía del equipo de desarrollo de Firefox, que toma incluso decisiones impopulares por el bien del navegador y sus usuarios (por ejemplo, sólo publica nuevas características y funcionalidades cuando están realmente listas para los usuarios y no duda en retrasar la disponibilidad de nuevas versiones del navegador mientras no se cumplan unos mínimos de calidad, llegando incluso a saltarse versiones anunciadas), puedo asegurar que la versión 3.6 ha pasado la prueba con nota alta (ha conseguido que vuelva a disfrutar de la Web) y que el navegador del zorro rojo no sólo va a mantener sino que va a aumentar su cuota de mercado en los próximos meses. Ya puede la competencia ponerse las pilas si quiere seguir el ritmo de Firefox.