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.

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.

• 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.

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.

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.

En esta ocasión ha sido mi compañero y amigo Sergio Martín quien aceptó el reto y los resultados no se han hecho esperar. Desde hace unas horas está disponible para la comunidad de Drupal un módulo que nos permite su integración con Alfreso.

Para conocer las posibilidades de este módulo sólo hay que acceder a su página oficinal. Las posibilidades del módulo son múltiples.

• ¿Por qué preocuparse de que Drupal gestione los archivos que necesitamos publicar en un sitio web si para eso ya están los gestores documentales? Dejemos que Drupal y Alfresco se encarguen de lo que verdaderamente saben.
• La integración entre ambas soluciones se realiza usando HTTP-SOAP. Una prueba más de que la orientación a servicios flexibiliza muchísimo la interoperabilidad entre distintas soluciones.
• ¿Rendimiento? Aun estamos pendientes de obtener algunos datos objetivos.
• ¿Configuración? Muy sencilla, URL donde Alfresco tiene publicado su API HTTP-SOAP, usuario/contraseña, metadatos con los que deseamos trabajar y poco más.
• ¿Podemos referenciar los documentos desde otros tipos de contenido? Sí, gracias al submódulo alfresco_attach.module dado que el módulo principal proporciona un nuevo tipo de contenido (Alfresco item) perfectamente referenciable.
• Para mejorar la usabilidad existe el submódulo alfresco_import.module que nos permite importar de forma sencilla documentos a partir de un espacio de trabajo de Alfresco.

La versión que se ha publicado es un beta (6.x-1.0-beta) y nuestra intención es mantener y evolucionar el módulo. Evidentemente habrá incidencias que se tendrán que solucionar pero también tenemos nuevas funcionalides que no tardarán en llegar.

Te lo he dicho muchas veces, Sergio eres un crack. Lo mejor de todo es que estoy rodeado de otros tantos crack como él y entre todos creo que formamos un buen equipo. Gracias a todos.

1. Instalar y configurar Eclipse IDE con soporte para PHP (PDT Project). Ya comenté hace tiempo que uso Pulse para gestionar y mantener distintas instancias de Eclipse IDE.
2. Instalamos Apache Web Server con soporte para PHP (preferiblemente PHP5). Para esto tenemos varias opciones:
   1. LAMPStack de BitNami
   2. Seguir estas instrucciones.
   3. Instalar Apache Web Server con soporte para PHP y MySQL desde paquetes
   4. Instalar Apache Web Server con soporte para PHP y MySQL desde los fuentes
3. Descargamos y descomprimimos Drupal dentro de nuestro workspace de Eclipse:

   [recena@localhost Eclipse 3.3 PDT]$ wget http://ftp.drupal.org/files/projects/drupal-6.4.tar.gz
   [recena@localhost Eclipse 3.3 PDT]$ tar -xvzf drupal-6.4.tar.gz
   [recena@localhost Eclipse 3.3 PDT]$ rm drupal-6.4.tar.gz

4. Ahora configuramos un alias (p.e. qabox) para poder acceder a nuestra instalación de Drupal de una forma similar a http://localhost/qabox. Para ello añadimos a httpd.conf:

   Alias /qabox "/home/recena/Workspaces/Eclipse 3.3 PDT/drupal-6.4"
   <Directory "/home/recena/Workspaces/Eclipse 3.3 PDT/drupal-6.4">
           AllowOverride All
           Options MultiViews Indexes Includes FollowSymLinks
           Order allow,deny
           Allow from all
   </Directory>

5. A partir de este momento, accedemos a http://localhost/qabox, y lo que resta es seguir las instrucciones de la propia instalación de Drupal. Que no se os olvide colocar el correspondiente archivo .htaccess en el directorio raíz donde se encuentre instalado Drupal. En la documentación viene todo perfectamente comentado.

Una vez que tenemos lo básico para ejecutar Drupal nuestro trabajo se centrará -probablemente- en el desarrollo de módulos y/o temas. Pues bien, la idea es tener un proyecto para cada uno de los módulos y/o temas que desarrollemos. De esta forma tendremos nuestra instalación de Drupal por un lado, y nuestros desarrollos (modelados como proyectos de Eclipse) por otro. Ahora lo único que tenemos que hacer es decirle a Drupal que use estos módulos y/o temas. Así iremos viendo los resultados. Para hacer esto basta con hacer simples enlaces simbólicos donde corresponde y hacía donde se encuentran nuestros proyectos.

En la captura de pantalla que se muestra a continuación, veréis un tema que estoy desarrollando que se llama QABox y el enlace simbólico que he creado para que Drupal sepa que dispone de ese tema como se estuviera almacenado en $DRUPAL_HOME/sites/default/themes (p.e.):