Mi espacio

Recientemente hemos entregado a un cliente una aplicación software dentro de un proyecto que está a punto de terminar. Sólo queda cerrar algunos flecos que no dependen directamente de nosotros, sino del propio cliente. El proyecto era pequeño:

• 5 meses en total
• 4 meses desarrollando la aplicación
• 1 Jefe de proyecto, 1 desarrollador del lado del cliente, 2 desarrolladores JEE y 1 asegurador de la calidad

Para la construcción hemos contado con:

• Marco tecnológico Java: Spring framework, Eclipse Birt, Hibernate
• ExtJS
• DEIN – Ecosistema Software (de esto ya os hablaré)

Me gustaría contar algunas lecciones que hemos aprendido:

1. Nos es conveniente homogeneizar los entornos de desarrollo local de todos los miembros del equipo. Aunque el cliente nos indique cuál es su entorno de producción y eso quede reflejado en los requisitos no funcionales del análisis, es altamente aconsejable la disparidad. Es una forma muy simple se disminuir riesgos y asegurar un mayor nivel de calidad. Concretamente en este proyecto hemos usado:
   1. Ubuntu, Eclipse, Jetty, JDK 1.5 (entorno de desarrollo local)
   2. Windows XP, Eclipse, Tomcat JDK 1.6 (entorno de desarrollo local)
   3. Debian, Tomcat, Apache, JDK 1.5 (entorno de despliegue virtualizado que DEIN proporciona)
2. Las tareas de análisis nunca terminan. Cuando el analista decide que hay una versión estable de los requisitos y se ponen en marcha las tareas de implementación, se activa un proceso iterativo entre el diseño-implementación y el análisis. El objetivo final para el cliente es que lo que le entreguemos satisfaga sus espectativas, sin embargo, nosotros compartimos ese mismo objetivo y además tenemos que asegurarnos de que lo construido y lo analizado está sincronizado y se corresponden. ¿Por qué? Porque aunque sean desarrollos a medida (llave en mano) es probable que surjan ampliaciones, revisiones, etc. y por eso mismo tenemos que ser consecuentes con lo que hacemos. No es la primera vez que me encuentro un documento de análisis perfectamente maquetado con una página inicial en la que se indica que lo validó tal persona hace un año y recientemente se ha publicado una versión.
3. Es importantísimo hacerle ver al cliente cuánto cuestan los cambios y todo lo que adicionalmente solicita. Entiendo que es una tarea complicada, pero ahí está la destreza de un buen jefe de proyecto. Lo que no podemos hacer es admitir cambios y mejoras durante la evolución del proyecto con el fin de mejorar la experiencia de los usuarios finales, y que luego, cuando el proyecto está terminando te inunden en procesos eternos llenos de burocracia.
4. En tu planificación prioriza al máximo el obtener una primera release que puedas mostrar a los usuarios finales. Haz todas las entregar parciales que puedas y la disponibilidad del cliente permita. En este proyecto concretamente, el cliente ha tenido la oportunidad de ver todos los avances de forma diaria. DEIN se encargaba se desplegar todas las noches un SNAPSHOT del proyecto en el entorno de despliegue, que por supuesto estaba disponible para el cliente.
5. Establece sesiones de trabajo (preferiblemente, semanalmente) con todos los miembros del equipo. Aprovecha esta sesiones de trabajo para hacer una puesta en común de perspectivas, dudas, aclaraciones, consideraciones, propuestas, etc…
6. Procura que todos tus proyectos tengan algo de I+D+I. Disponer de un departamento de verdad de I+D+I no es sencillo y requiere inversión, pero cuando no se tiene esa opción, algo debemos hacer. Cuidado con los experiementos en proyectos pequeños, es muy sencillo incumplir en la planificación si algo no sale todo lo bien que esperábamos.

Supongo que la lista podría continuar, pero son los que puedo contar y pueden ser útiles. En cuanto me autoricen, publicaré algunas capturas de pantalla (y con suerte un screencast) sobre el proyecto.

Aquellos que me soportan todos los días en el trabajo saben que soy un maniático de los detalles. Soy de las personas que sufre si los fuentes de un proyecto no están correctamente tabulados o si los terminadores de línea no son los correctos. Sí, sí, lo sé, Opina 1.x me hace sufrir, pero poco a poco lo voy organizando todo, especialmente en Opina 2.x.

Algo que debe formar parte de todo buen ecosistema software que se precie es un conjunto de buenas prácticas que recomienden cómo debemos usar las herramientas que lo forman. En este caso hablaremos de subversion, el sistema de control de versiones que uso. Gracias a las propiedades de subversión podemos controlar:

1. Los terminadores de línea
2. Los tipos mime de los archivos
3. Los archivo que siempre ignoramos y que proyecto tras proyecto tenemos que ignorar. ¿El directorio /target tal conocido por aquellos que usan Maven? ¿El directorio /build?

Pues bien, para evitar que cada vez que se añada un archivo tengamos que configurar sus propiedades svn, que mejor forma que tener todas esas propiedades bien definidas en un archivo y que se usen en el ecosistema.

A continuación se muestra el archivo de configuración que estoy usando en Opina para las propiedades svn:

#
# Opina: gestor de encuestas
# Copyright (C) 2005-2008 Opina Development Team
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA
#
# $Id: opina-svn-properties 1842 2008-10-09 19:46:18Z recena $
#

[auto-props]
*.sh         = svn:executable;svn:eol-style=native;svn:keywords=Id
*.bat        = svn:mime-type=text/plain;svn:eol-style=CRLF
*.bmp        = svn:mime-type=image/bmp
*.class      = svn:mime-type=application/java
*.doc        = svn:mime-type=application/msword
*.exe        = svn:mime-type=application/octet-stream
*.gif        = svn:mime-type=image/gif
*.gz         = svn:mime-type=application/x-gzip
*.jar        = svn:mime-type=application/java-archive
*.jpg        = svn:mime-type=image/jpeg
*.jpeg       = svn:mime-type=image/jpeg
*.pdf        = svn:mime-type=application/pdf
*.png        = svn:mime-type=image/png
*.tgz        = svn:mime-type=application/octet-stream
*.tif        = svn:mime-type=image/tiff
*.tiff       = svn:mime-type=image/tiff
*.zip        = svn:mime-type=application/zip
*.txt        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.xml        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.xsd        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.xsl        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.wsdl       = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.htm        = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Id
*.html       = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Id
*.css        = svn:mime-type=text/css;svn:eol-style=native;svn:keywords=Id
*.js         = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.jsp        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.txt        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.java       = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.properties = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.sql        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id

Una vez que tenemos configuradas nuestras propiedades tenemos que hacer dos cosas:

1. Indicarle a nuestro cliente de subversion que estas propiedades existen y tienen esos valores
2. Indicarle a nuestro cliente de subversion que las tenga en cuenta.

En mi caso uso subversive como cliente de subversion, es un plugin para Eclipse. Para importar estas propiedades hacemos lo siguiente: Windows > Preferences > Team > SVN > Properties Configuration > Automation properties > import. Una imagen mejor, ¿no?

Ahora debemos localizar el archivo de configuración que el cliente usa:

~/.subversion/config (Linux)
%USERPROFILE%\Application Data\Subversion\config (Windows)

Ahora cambiados dos propiedades en ese archivo de configación

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store build dist target
enable-auto-props = yes

Espero que esto ayude un poco a aquellos desarrolladores que son un poco despistados y se olvidan de configurar convenientemente las propiedades svn. Ahora el siguiente paso es hacer hook (pre-commit) que se encargue de que las cosas están bien configuradas, y en caso contrario, envíe un correo al QA para repartir collejas.

Después de 8 años vinculado al desarrollo de software tengo que reconocer que cualquier instalación de una nueva versión de un software supone un reto y no está exento de sorpresas.

El diseño e implementación de tests son actividades muy importantes y necesarias en el ciclo de vida de un proyecto software. Estas actividades forman parte de una disciplina denominada aseguramiento de calidad del software. Recientemente he llegado a la conclusión de que son esos pequeños detalles, que normalmente se dejan pasar por alto, los que más tiempo nos hacen perder a la hora de realizar un paso a producción. Realizar un paso a producción tiene sus connotaciones, y una de ellas es que normalmente o se realizan en las instalaciones del cliente o las realiza el propio cliente. Podríamos considerar en lugar del cliente, al usuario final para así dejar a un lado la parte empresarial de la profesión.

Con intención de recoger esos tests que nos adviertan de esos pequeños detalles, he preparado el siguiente listado de tests que incluiré por regla general en mi plan de tests para proyectos Java:

1. Comprobar que la JVM que hay configurada en el sistema operativo es válida según el catálogo de requisitos no funcionales. Eso no evitará que si nuestra aplicación se despliega sobre un contenedor o servidor de aplicaciones, éste esté configurado con una JVM distinta a la del S.O., pero esta situación es menos frecuente.
2. Si nuestra aplicación necesita una base de datos, comprobar que la configuración es correcta y que la versión y base de datos están recogidas en el catálogo de requisitos no funcionales.
3. Realizar una comprobación como la anterior para servicios como directorio activo, correo electrónico, etc. De esta forma, podremos descartar problemas de integración con sistemas externos a nuestro software.
4. Si nuestro software necesita escribir en el sistema de ficheros, comprobar que disponemos de los permisos correspondientes.
5. Si nuestro software necesita acceder a internet o fuera de una red de área local, realizar la correspondiente comprobación.

Estos tests son muy simples pero nos ayudarán a detectar posibles problemas de integración con el entorno donde nuestro software se tiene que instalar. ¿Alguna sugerencia para añadir a estas pruebas de carácter muy básico?

Hace algunas semanas conocí el blog de John Ferguson Smart. Llegué a él de casualidad, como otras muchas veces mientras navegamos por la red en busca de información. Me sorprendió gratamente al ver que era el autor del libro Java Power Tools. Cuando vi el índice del libro me gustó mucho porque en él se habla de todas esas herramientas, buenas prácticas, metodologías y procesos que forman parte de mi trabajo.

John tiene una empresa llamada Wakaleo Consulting en la que ofrece servicios profesionales sobre:

• Software Development Environment
• Enterprise Java Kickstart
• Training, Mentoring and Coaching

Hace algún tiempo comentaba algo sobre aquellas empresas que ofrecen servicios muy especializados sobre procesos de construcción de software, metodologías, buenas prácticas, herramientas como Maven, PMD, etc. Pues Wakaleo parece ser otra de ellas. Me sigo preguntando si estas empresas tienen cabida en el mercado español…

John ha publicado las transparencias que ha usado en una de sus últimas ponencias en las que habla sobre JUnit.

La verdad es que en la nueva versión de Opina comenzamos a usar JUnit 4 pero ahora estamos evaluando TestNG y el cambio me ha gustado mucho. Personalmente no fui el promotor del cambio, sino mi compañero José María. Todo vino a raíz de necesitar hacer una provisión de datos en la que hemos usando XStream y poder configurar el orden en el  que se ejecutan las pruebas. Con independencia de que también hemos organizado las pruebas en grupos para darle forma a las operaciones CRUD que usamos en nuestras pruebas unitarias.

Antes de comenzar me gustaría comentar que la palabra distribuible está entre comillas porque la RAE parece que no la reconoce, sin embargo, creo que mucha gente la usamos. Este pequeño post lo he clasificado dentro de las categorías Herramientas y Software QA que tengo definidas en mi blog. Lo que justifica este hecho es que hablaré de Apache Maven y sobre cómo mejorar ciertos procesos típicos en la vida de un proyecto software. Para ello hablaré de los “distribuibles”, empaquetados, ensamblados o como se quieran llamar a esas estructuras (comprimidas o no) de directorios y archivos que se usan dentro del marco tecnológico JAVA como son los JAR, WAR, AAR, EAR, etc.

En esas estructuras de directorios normalmente encontramos ficheros compilados (p.e, .class), archivos de propiedades (p.e, .properties), archivos de configuración (p.e, .xml), recursos gráficos (p.e, .png), metainformación (p.e, manifest.mf) y algunos otros más. Personalmente me gustaría destacar todos aquellos archivos que formen parte de la configuración de una aplicación. Las configuraciones más comunes son las referentes a la conexión de base de datos, sistema de correo, sistemas LDAP, etc.

Una muy buena aproximación para mejorar la facilidad de mantenimiento, automatización y personalización de estos “distribuibles” es usar Maven y sacarle partido a los distintos plugins que existen (packaging types / tools) y la gestión de perfiles. Con esto podremos conseguir generar el WAR de nuestra aplicación web configurado para el entorno de producción de nuestro cliente. Bastará con realizar un proceso como el siguiente:

1. Realizar un export del sistema de control de versiones correspondiente a la versión que se desee, que entiendo que estará etiquetada en directorio tags de nuestro repositorio.
2. Dar de alta un perfil con la configuración del entorno que nuestro cliente nos ha facilitado.
3. Ejecutar algo similar a: mvn package -P oracle -Denv=client-dev
4. Desplegar, manual o automáticamente, nuestro WAR (artefacto) donde corresponda.

Doy por supuesto que los miembros del equipo de desarrollo estarán muy familiarizados con la generación de estos distribuibles, sin embargo, son otros perfiles los que, durante el desarrollo del proyecto y/o tras su finalización, tendrán que continuar con su soporte, mantenimiento y evolución. Un ejemplo con el que muchos se pueden sentir identificados es el típico proyecto de llave en mano para un cliente que nos encarga algo a medida. En ese contexto, si el cliente nos demanda que le enviemos un SNAPSHOT para que su personal vaya haciendo pruebas, ¿Qué “distribuible” preparamos?

Es muy frecuente que si se trata de un proyecto software, haya sido un departamento, área o división de desarrollo quien nos haya realizado el encargo. Con esto quiero decir, que el perfil que va a recibir nuestro “distribuible” es probable que con unas simples instrucciones sea capaz de generar el “distribuible” apropiado a partir de un export del repositorio. Ahora bien, no basta con hacer un export, comprimirlo y enviarlo al cliente con las instrucciones, entre otras porque en el repositorio es muy probable que haya información sobre nuestros entornos de desarrollo, múltiples perfiles configurados o simplemente, información que no es útil para el cliente y que únicamente provoca ruido. Con lo cual, parece razonable pensar que vamos a necesitar un “distribuible” con las fuentes de nuestro proyecto que, acompañadas de una guía de instalación y configuración, permitan que el propio cliente pueda ir asumiendo estas tareas que tarde o temprano serán de su plena responsabilidad.

La opción planteada me parece lógica. El cliente nos demanda las fuentes del proyecto, nosotros se las entregamos con los archivos justos y precisos que necesitan para la configuración, pruebas unitarias/integración y la posterior generación del WAR, JAR, AAR o el que corresponda, que se desplegará en el entorno correspondiente.

Con la intención de dar un pasito más y pensando en los perfiles del departamento, área o división de infraestructuras, creo que agradecerán si les ahoramos hacer un export, tener instalado maven, tener instalado el JDK correspondiente y otros pequeños detalles que pueden hacer que algo fácil y mecánico, se retrase durante días. En prácticamente todas empresas e instituciones que conozco es el personal de sistemas o infraestructuras quien verdaderamente realizara los despliegues en los entorno de producción, por lo tanto, nos interesa facilitar al máximo las cosas.

Entiendo que para un administrador de sistemas le resultará más cómodo descomprimir un archivo comprimido (zip, tar.gz, etc.), editar el archivo de configuración que estará documentado en la correspondiente guía de la que antes hablaba y colocar la estructura de directorios y archivos en el lugar correspondiente para su despliegue. Este nuevo caso nos encontramos con que necesitamos preparar un “distribuible” con los binarios de nuestro proyecto.

Son muchas las circunstancias que puede hacer que el administrador del servidor de aplicaciones del cliente necesite volver a desplegar una aplicación determinada, como por ejemplo, cambios en la configuración de red, DNS, modificaciones en las credenciales (usuarios/contraseñas), migraciones, etc, ¿En todas esas situaciones es necesario que haya un desarrollador presente? Si las cosas se hacen bien, podemos ahorrarnos mucho trabajo. Tengo que reconocer que la realidad es otra, pero lo bueno es saber que existen otras formas de hacer las cosas.

Para concluir me gustaría añadir que aparte de lo que podamos generar en nuestra fase de empaquetado (package) y que además lo tenemos automáticamente con Maven, es muy recomendable preparar al menos otros dos “distribuibles” adicionales, uno con los fuentes y otro con los binarios. Para ello es de gran utilidad el plugin de Maven Assembly. Como me he extendido demasiado, aprovecharé otro post para poner algún ejemplo con este plugin. En Opina lo usamos para generar opina-bin-1.0.8.zip, que es el binario de la versión 1.0.8 de Opina que está listo para ser descargado, descomprimido, configurado y desplegado.