Mi espacio

El trabajo que están haciendo en Drupal 7 es realmente bueno. De todas las mejoras que traerá tengo especial interés en la nueva capa de abstracción de base de datos y el diseño de interacción. Para saber más sobre el diseño de interacción en Drupal 7 recomiendo este blog que no tiene desperdicio.

Viendo la siguiente galería de imágenes nos podemos hacer a la idea de las sorpresas que nos encontraremos. Hoy precisamente he mantenido una interesante conversión con algunos de mis compañeros de trabajo sobre el valor de trabajar con prototipos (storyboards, wireframes) y modelos conceptuales, y lo que están aportando en nuestros proyectos. Aun nos queda mucho por aprender, pero creo que lo importante es tener convinción sobre lo que uno está haciendo. Incluso, aunque los resultados no sean todo lo satisfactorios que deseemos.

En el próximo proyecto en el que tengamos la oportunidad, voy en poner en práctica ciertos cambios que no implican un cambio en la metodología de desarrollo pero sí en la ejecución y enfoque de ciertas tareas. Algunas notas previas:

1. En el roadmap del proyecto no aparecerán milestones con palabras como análisis, diseño, codificación o verificación
2. El desarrollador de interfaces de usuario trabajará desde el primer momento con el analista, no esperaremos a que los objetivos y funcionalidades estén algo avanzadas.
3. Ni hablar de domino o modelo de datos hasta que las historias de usuario estén maduras. Con eso me conformo. Conseguir la validación es -casi- una utopía y dar la sensación de que se están cerrando las puertas al cambio.
4. Los ingredientes: una wiki, un buen móvil para sacarle fotos a los bocetos y la pizarra, rotuladores de colores y un buen taco de A4 y A3 (reciclables por favor).
5. No sé por qué pero casi todos los diagramas sobre arquitecturas lógicas que he visto representan la persistencia de los datos en la parte inferior y ascienden hasta el lado del cliente pasando por la capa de acceso a datos, modelo, lógica de negocio y controlador. Pues bien, nosotros queremos empezar por arriba. Comenzando por codificar los interfaces de usuario a partir de los prototipos y descender. Habrá un momento en el que habrá gente trabajando en paralelo en las distintas capas. Eso será buena señal.
6. Vamos a definir un glosario de términos que NO podemos usar delante de los usuarios que nos ayudarán (o no) a conocer lo que necesitan. También hay situaciones en las que los usuarios sólo tienen claros objetivos de muy alto nivel y necesitan que tú les guíes.

Si un arquitecto es capaz de transmitir una idea creativa mediante la proyección, nosotros tenemos que ser capaces de diseñar la interacción entre los usuarios y la información que necesitan gestionar. En más de una ocasión me he encontrado en reuniones para presentar los trabajos realizados (total o parcialmente) y tras presentarlos el cliente te dice claramente que eso no es lo que el tenía en mente o lo que él necesita. Qué le pasaría a un arquitecto si tras construir una vivienda el cliente le dice que eso no es lo que quiere.

En los últimos años he trabajado con distintas soluciones de gestión de contenidos basadas en fuente abierta. Concretamente en los dos últimos años he participado en 4 proyectos, uno de ellos desarrollado sobre Plone, otros dos sobre Drupal y otro bastante grande con OpenCMS. Dentro del Departamento de Software que dirijo nos propusimos fijar un periodo en el que evaluar distintas soluciones. Básicamente para hablar con conocimiento de causa y basándonos en nuestra propia experiencia. Nuestra apuesta por Drupal es clara desde hace tiempo y en ese camino nos encontramos. No hace demasiado tiempo publicábamos nuestro primer módulo de integración entre Drupal y Alfresco. Ahora nos encontramos en un proceso de definición de lo que podría ser una distribución para uno de nuestros principales clientes. El viernes pasado hicimos una presentación del proyecto y parece que fue bien recibida.

Una distribución es un concepto en Drupal no demasiado explotado pero que tiene -desde mi punto de vista- unas posibilidades enormes. Durante la presentación del otro día lo definimos como:

Una distribución de Drupal es una instalación personalizada a nivel de módulos (incluyendo temas) y configuración.

Dicha personalización se basa en perfiles. Las opciones que brindan estos perfiles son muy amplías. Podemos desde inicializar un sitio web con un conjunto de taxonomías base o bien crear ciertos contenidos por defecto. Si nos encontramos en un entorno corporativo los beneficios de diseñar e implementar nuestra propia distribución son muchos. Sólo tenéis que pensar la cantidad de sitios web que tiene una administración pública autonómica, una multinacional y el conjunto de universidades españolas, y que gran parte de ellos, tienen que dar solución una y otra vez a los mismos requisitos (autenticación, gestión de identidades, flujos de trabajo, búsquedas, integraciones, etc.). Digamos que el concepto de distribución en estos tres ejemplos puede ayudarnos a conseguir:

• Fiabilidad: se garantiza su robustez, seguridad, rendimiento
• Mantenibilidad: centralizada en un equipo
• Reutilización: la necesidades comunes se satisfacen inicialmente
• Rentabilidad: las necesidades comunes sólo se harían una vez
• Solución horizontal
• Afianzar módulos básicos
• Facilidad en las actualizaciones
• Centralización de los repositorios

Desde luego antes de comenzar lo primero que habría que estudiar cuáles son esos módulos básicos, esos requisitos comunes que constantemente se repiten, necesidades de integración, etc. Pero no sólo debemos pensar en los módulos funcionales, también debemos pensar en los temas. En proporcionar un conjunto de temas base sobre los que construir tu diseño visual tanto para navegadores convencionales como para PDAs o dispositivos móviles.

Al final de todo hay un objetivo mucho más ambicioso, proporcionar una solución de gestión de contenidos adaptada a las necesidades de un entorno y que permita a los responsables de sitio centrarse en lo verdaderamente importante, en sus usuarios y la información.

Lo realmente bueno de Drupal en este sentido es que puedes -si haces las cosas bien- garantizar la compatibilidad con futuras versiones si partes de su núcleo, lo que se conoce como Drupal Core.

¿Qué tienen en común Apache Software Foundation, Codehaus y Drupal? Aunque a niveles muy distintos, conforman tres grandes comunidades dentro del mundo del software libre y fuente abierta en las que hemos realizado aportaciones durante el primer trimestre (Q1/2009) del año:

• José Morales ha recibido la invitación para ser committer en Apache Continuum. Una de las piezas clave de DEIN – Ecosistema Software.
• Antonio Manuel Muñiz ha publicado hoy su primera versión de Sonar PDF Plugin.
• Sergio Martín continúa dando soporte al módulo de Drupal que permite la integración con Alfresco y que publicó recientemente.

Como responsable del departamento de software del que formamos parte, sólo tengo buenas palabras hacia el trabajo de mis compañeros. Los retos fueron planteados y poco tiempo después, vinieron los resultados.

Son muchos los motivos por los que participamos en estas iniciativas, pero lo más importante es aprender y compartir. Todo esto revierte directamente en la calidad de nuestros compromisos profesionales.

Me siento realmente orgulloso de trabajar con la gente con la que trabajo.

A mediados de enero, escribía una entrada con el título “Drupal y Alfresco se conocen libremente“. Prueba de esa libertad es que ayer, volvíamos a publicar una nueva versión de este módulo de Drupal que permite su integración con Alfresco. Esta nueva versión incluye mejoras considerables en usabilidad, rendimiento y eliminación de código fuente prescindible. A continuación una captura de pantalla del sub-módulo alfresco_browser:

Este submódulo es una de los principales atractivos de esta nueva versión:

1. Visualización de documentos y sus metadatos
2. Navegación por los distintos espacios
3. Búsquedas
4. Creación de contenidos en Drupal a partir de los propios documentos.

Sólo me queda dar la enhorabuena a mi compañero Sergio Martín por su excelente trabajo. Desde luego esta, y otras cosas, son las que me hacen disfrutar día a día de mi trabajo.

En los últimos meses he tenido que codificar varios temas en Drupal para unos proyectos que hemos desarrollado. Para aquellos que estáis comenzando os recomiendo encarecideamente que no comencéis un tema desde cero. En Drupal, existe el concepto de módulo y submódulo, esto se extendiende también para los temas.

Haz un sub-tema partiendo de Zen Extend And Design. Es un tema considerado base sobre el extender el tuyo. ¿Qué te proporciona?

• Plantillas de las vistas principales (node, page, comment, etc)
• Las plantillas tienen una semántica muy bien definida y usan correctamente los estándares web.
• Un punto de partida para aprender a desarrollar temas en Drupal
• Buena documentación

Una lectura que no puede faltal para todo aquel que vaya a desarrollar un tema es lo que se conoce como la anatomía de un tema. A mi me ha venido muy bien organizar las hojas de estilo según dicha anatomía:

En unos días liberaré el último en el que estoy trabajando.