Mi espacio

Supongo que con este título no estoy diciendo nada nuevo, sin embargo, el día a día nos dice otra cosa. Tan importante es desarrollar un software de calidad como su mantenimiento o explotación, de hecho, la experiencia nos dice que cuanto mejor hagamos el trabajo al principio más fácil y cómodamente abordaremos las etapas futuras.

Hablamos siempre de lo importante que es documentar, definir pruebas, refinar nuestras metodologías, definir buenas prácticas, especialización de los recursos y otras miles de cosas, pero todas ellas afectan -en gran medida- el equipo de desarrollo. ¿Y qué pasa con el resto de perfiles que interviene el ciclo de vida del software? ¿Qué pasa con los administradores de bases de datos y/o administradores de sistemas? ¿Cómo es nuestra relación con ellos? ¿Qué herramientas y procedimientos compartimos con ellos? Dentro del equipo de desarrollo hay “cosas” que comienzan a madurar y síntoma de ello es que a veces nos preguntamos, ¿Qué haríamos sin…?

En este post os hablaré concrétamente de Maven e Hibernate. En mi entorno profesional, estas dos herramientas son muy frecuentes y ambas tienen mucho que decir sobre la relación del equipo de desarrollo y el resto de perfiles que normalmente pertenecen al departamento de sistemas.

Desde hace tiempo la elaboración de libros blancos de buenas prácticas se ha convertido en una moda. En un próximo post daré mi opinión al respecto (”La parte oscura de los libros blancos”), pero por ahora sólo hago referencia porque son precisamente estos libros blancos los que indican/recomiendan/exigen el uso de herramientas como Maven e Hibernate. De qué vale que el equipo de desarrollo haga uso de este tipo de herramientas si luego nos encontramos con situaciones como estas:

• El despliegue del software lo lleva a cabo el propio departamento de sistemas y allí reina su propio libro blanco de buenas prácticas. Si nuestro proyecto está modelado con Maven, y contamos con un ecosistema software mínimamente definido, ¿Por qué tenemos que entregar un WAR con la aplicación que posteriormente descomprimen para configurar (base de datos, LDAP, SMTP, etc)? ¿Por qué los administradores de sistemas no usan Maven? Se podrían beneficiar de muchas cosas como por ejemplo los perfiles para los distintos entornos de despliegue, ejecución de pruebas que no pueden faltar y un largo etcetera. Creo que sería genial que tanto el equipo de desarrollo como el departamento de sistemas compartiesen el uso de Maven. Evidentemente, cada uno desde su perspectiva.
• ¿Por qué debemos entregar al DBA los script de creación de esquemas cuando de eso se encarga automáticamente hibernate? Recientemente preparamos para un proyecto un módulo con una interfaz de línea de comandos con varias finalidades, crear el esquema de base de datos, creación de sinónimos y carga inicial de información (tablas maestras). Con un módulo de estas características, el proceso de instalación como podéis imaginar queda resumido en ejecutar un par de sentencias desde la línea de comandos. Pues parece que esto no entraba dentro del libro blanco del departamento de sistemas.

Estos son sólo dos ejemplos que ponen de manifiesto que el equipo de desarrollo y el departamento de sistemas deben tener un único libro blanco de buenas prácticas y que existe una brecha que debe estrecharse cuanto antes.

En varias ocasiones he tenido oportunidad de charlar con responsables de departamentos de sistemas y una de sus preocupaciones es que los equipos de desarrollo les entregan software que una vez puesto en producción comienza a dar problemas. ¿Qué pasa en esta situación? Al igual que existen pruebas unitarias y funcionales, el departamento de sistemas puede disponer de pruebas de integración y sistemas que proporcionen unos indicadores para garantizar unos mínimos. No sería la primera vez que se pone en producción una aplicación con la configuración por defecto del pool C3P0 muy usado con Hibernate. Luego vienen las sorpresas. ¿Cómo comprueban los DBAs que las tablas de un sistema de información comienzan con un determinado prefijo? ¿Mirando los scripts? ¿No sería más fácil con un plugin de Maven?

Una vez más, la comunicación entre los distintos perfiles es fundamental para que el ciclo de vida de un software funcione.

Soy de las personas que tiene la gran suerte de disfrutar en su trabajo y de su trabajo. Con anterioridad compartí ese sentimiento y sigo pensado exactamente igual, sin embargo, está claro que algo debo estar haciendo mal cuando ayer, a las 19:20 (después de haber llegado al trabajo a las 8:30 y almorzado en una hora) me despedía de mis compañeros que aun seguían en la oficina y tenía un gran sentimiento de culpa. Tenía la sensación de que los estaba “dejando colgados”. Lo peor de todo es que el motivo por el que ayer salí algo antes es porque los ratones bailaban en mi nevara. Era imposible seguir retrasando el paso por el supermercado.

Reconozco que estamos viviendo una situación dura, y en cierta medida, me siento responsable de esta situación. Sólo espero que el sacrifio tenga su recompensa y que pronto comencemos a disfrutar de ella.

Sólo me queda aprovechar este espacio para agradecer a mis compañeros toda su dedicación y derroche de buena actitud.

GRACIAS.

Leyendo la introducción de la presentación que Brett Porter llevará a cabo en el ApacheCon US 2008, me han venido a la mente algunas situaciones que he vivido durante estos años con Apache Maven.

Si mis recuerdos no me fallan, comencé usando Maven 1 a finales del 2004 cuando decidimos usarlo en Opina. Su uso en el proyecto Opina me permitió verdaderamente conocer las bondades de esta herramienta. Por aquella época lo que más se le parecía era Apache Ant. En mi entorno profesional de entonces, lo que más predominaba era usar los IDEs para todo (definir el proyecto, compilación, empaquetado, etc.) y en contadas ocasiones, me encontraba proyectos en los que se usaba Ant. Tiempo después, y cuando mi experiencia con Maven había aumentado, impartí algunas charlas sobre esta herramienta y su beneficios en distintos escenarios.

No debemos perder de vista que los desarrolladores hacían su trabajo correctamente sin Maven ni Ant, y que por tanto, para que éstos decidieran incorporar una nueva herramienta a su día a día, algún beneficio tendrían que recibir a cambio.

Fue trabajando para el Servicio de Informática de la Consejería de Obras Públicas y Transportes (Junta de Andalucía) donde tuve la oportunidad de observar la bienvenida que los desarrolladores le hacía a Maven. He de reconocer que fue aquí donde vi por primera vez usar Maven en la Administración Pública Andaluza. Ahora las cosas han cambiado mucho, hasta tal punto, que los pliegos técnicos de los concursos públicos requieren que sus desarrollos Java usen Maven.

A continuación algunas de las situaciones con las que me he encontrado y que según en qué entornos, han podido suponer una barrera:

• La calidad y ritmo de documentación (oficial) disminuyó tras la aparición de Maven 2.x.
• La necesidad de que los ordenadores de los desarrolladores tuvieran que acceder a Internet para trabajar con los repositorios oficiales supuso un inconveniente, especialmente, en los entornos corporativos donde el acceso a Internet está controlado.
• En relación con el punto anterior, el consumo de ancho de banda. Hoy existen varias alternativas para gestionar repositorios de Maven, y como todos sabéis, uno de sus objetivos es disponer de una caché (y/o mirror) de los repositorios que más empleamos y con esto, ahorrar en ancho de banda. Por aquella época eran muy pocas las opciones en este sentido y además implicaban un nuevo frente de guerra, el responsable de sistemas (o infraestructuras) tenía que dar el visto bueno para instalar un software de este tipo.
• La mala gestión de los repositorios oficiales. ¿Cuántas veces nos hemos encontrado un artefacto en un repositorio sin su correspondiente POM? Esto se traducía en que ejecutar ciertas tareas tardaban más de lo que la paciencia de un desarrollador es capaz de aguantar estando acostumbrado a pulsar un botón y listo. Cierto, cierto, existe la opción “-O” para trabajar en modo offline. ¿Cuánto tiempo tardaste en darte cuenta de la utilidad de esta opción?
• Aunque parezca extraño, hay gente que sigue sin ver a Maven más allá de una herramienta de construcción para proyectos Java. Maven también es un framework con el podemos dar solución a necesidades específicas. Evidentemente hay gran cantidad de plugins que constituyen un valor añadido para Maven, pero es importante no perder de vista que podemos extender Maven.
• Dependencias transitivas. ¿Quién no se ha peleado con las dependencias transitivas? Hoy por hoy la situación está más controlada porque existen herramientas que nos ayudan a analizar las dependencias de nuestro proyecto. Sin embargo, todavía seguimos dependiendo de que ciertos POMs en los repositorios no estén todo lo bien que debieran y que nuestros proyectos si nos descuidamos pasen a pesar 15Mb o más.

Como en casi todo en esta profesión, siempre hay muchas maneras de hacer las cosas, pero siempre hay una que es elegante, inteligente y eficaz. Por eso os recomiendo leer estas dos referencias:

1. Maven: the definite guide
2. Better build with Maven

Supongo que me dejo cosas en el tintero, ¿Alguna aportación?

En un equipo de trabajo dedicado a la ingeniería del software, la existencia de perfiles asociados a recursos concretos denota un alto nivel de especialización. Es normal encontrarse equipos de trabajo donde los recursos que los forman hacen de todo o casi de todo. Donde trabajo, eso no sucede. Desde hace algún tiempo, como parte de un cambio en la cultura de empresa, se comenzó a forjar un alto grado de especialización. Entre los distintos perfiles que se definieron, está el analista.

No quiero añadirle el completo “funcional”, prefiero referirme a él, como analista. Según la RAE, un analista es el que hace análisis, y un análisis es:

1. Distinción y separación de las partes de un todo hasta llegar a conocer sus principios o elementos.
2. Examen que se hace de una obra, de un escrito o de cualquier realidad susceptible de estudio intelectual.
3. Estudio, mediante técnicas informáticas, de los límites, características y posibles soluciones de un problema al que se aplica un tratamiento por ordenador.

He tomado de la RAE las acepciones más cercanas al tema que nos atañe. Pues bien, comenzaré con que no estoy de acuerdo con la parte de la tercera acepción en la que dice “...y posibles soluciones de un problema al que se le aplica un tratamiento por ordenador“. Dar soluciones a un problema considero que forma parte del diseño, y para eso ya tenemos a otros perfiles. Cuando nos encontramos ante un problema, lo primero que hacemos es obtener toda la información (datos, relaciones, semejanzas, contradicciones, etc) que es objetiva del problema. En este punto, dejamos a un lado cosas como “habrá querido decir…”, “supondrá esto que…”, es decir, las cuestiones subjetivas a un lado. Una vez que tenemos bien estructurada la información, entonces es cuando comenzamos a usar nuestro conocimiento en la materia del problema y podemos hacer uso incluso de suposiciones para encontrar una solución. Mi profesor de matemáticas nos decía que los problemas es fácil que se puedan resolver de múltiples formas, especialmente en las matemáticas. ¿Y no es cierto que un mismo proyecto software puede ser diseñado de múltiples formas? Sin embargo, los datos objetivos del problema son únicos, es decir, una persona puede ver un problema y obtener cierta información objetiva y, sin embargo, otra persona, puede ver esa misma información objetiva o incluso otra que la contenga.

A continuación expongo las principales funciones que deben recaer sobre el perfil de analista:

• Localización de las fuentes de información: Una vez que el analista toma contacto con el reto (sustituye al problema antes mencionado) debe detectar sus fuentes de información. En una gran parte de las ocasiones su fuente de información vendrá de usuarios expertos que le proporcionarán la información. En otros casos, tendrá que recurrir a biografía, internet, etc.
• Formalizar el reto: Evidentemente no puede retener toda esa información, necesitará organizarla, estructurarla, revisarla, etc. Por lo tanto, necesita seguir ciertas convenciones o prácticas para que él mismo pueda gestionar esa información.
• Interlocutor entre quien plantea el reto y quienes darán solución al reto: Según esto el punto anterior toda aun más fuerza porque el resultado de formalizar el reto no sólo le servirá a él, sino a otras personas (recursos).
• Velar porque la información objetiva que refleja el formalizar el reto siga íntegra: Tiene que ser capaz de analizar no sólo el reto sino también la solución, pero en este caso con el objetivo de asegurarse de que la información considerada en la solución es correcta.
• Proteger la solución: Siempre pueden aparecer datos que inicialmente estaban ocultos y, evidentemente, no podemos obviarlos, pero tampoco podemos permitir que el desarrollo de la solución deje de ser válido.

Evidentemente, no es fácil. De hecho considero que es un trabajo complicado y que requiere de ciertas habilidades/capacidades como por ejemplo:

• Capacidad de síntesis
• Capacidad comunicativa
• Buena oratoria
• Disciplina
• Orden
• Ser muy meticuloso con todo, incluso con los pequeños detalles.
• Capacidad de abstracción
• Capacidad de conceptualizar

Es probable que me haya dejado atrás tanto funcionalidades como habilidades/capacidades, supongo que cada uno tiene sus propias listas, pero creo estas resumen lo que busco en un buen analista. Personalmente creo que se comete un error cuando se dice que:

• Un analista primero tiene que haber sido desarrollador.
• Cuando se piensa que la evolución de un desarrollador es ser analista.
• Cuando se cree que para analizar hay que conocer las herramientas de usan los diseñadores

Procuraré escribir sobre la relación entre el perfil de analista y el resto de perfiles. Como curiosidad os recomiendo que busquéis en los portales de trabajo ofertas relacionadas con los analistas (informáticos). Al hilo de esta entrada os recomiendo leer “El arquitecto de software en versión española”.

Recientemente he tenido que configurar un entorno de desarrollo para trabajar con Drupal en Linux, concretamente Madriva. Quizás a alguien le puedan venir bien estas notas:

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.):

La verdad es que la gente de BitNami no para de sorprenderme. Hace unos minutos he entrado en BitNami para descargar unas cosas y me he encontrado con esto:

Dibujo de las stacks de Bitnami

El dibujo me gusta muchísimo. Opina detrás de Ruby y delante de Drupal, jejejeje, ojalá!

Estos detalles animan mucho para seguir trabajando.

Hace unos instantes me han escrito desde la empresa Hotelbeds Accommodation & Destination Services para comunicarme que han puesto en producción Opina con el objetivo de realizar encuestas a sus trabajadores.

Al parecer, inicialmente hicieron pruebas con Oracle y Resin y todo funcionaba correctamente, pero finalmente, por cuestiones ajenas a Opina han decidido instalarlo en el siguiente entorno:

• Linux
• Java jdk1.5.0_06
• MySql
• Tomcat 6.0

Si alguien está interesado en instalar Opina con Oracle, y se encuentra con problemas, que lo comunique a la lista de correo. Hay que realizar un pequeño cambio (BLOB, VARCHAR2) en el esquema que se genera para que todo funcione correctamente.