Mi espacio

El pasado viernes 17 de octubre se celebró la segunda edición de la desconferencia del grupo Ecosistemas Software. Tal y como se adelantaba en la lista, la asistencia sería muy reducida, finalmente asistimos 5 personas (Paco, Viki, Darío, Felipe y el que escribe). Pero tuvo su lado positivo, esta desconferencia estuvo más acotada y dirigida que la anterior, y nos permitió participar mucho más.

A continuación cito algunos de los temas que se trataron (18:20h – 21:15h aprox.):

1. Dado que teníamos una nueva incorporación, Felipe se presentó, nos contó donde trabajaba, a qué se dedicaba, cuál era su marco tecnológico, cómo era su ecosistema, etc…
2. Estuvimos hablando sobre las distintas formas de distribuir nuestros aplicativos Java (war, jar, ear, aar, zip, con instaladores, etc)  y yo estuve hablando sobre las ventaja de usar el plugin de maven assembly y como lo estoy usando en Opina y otros proyectos.
3. Y por último sobre metodologías de trabajo y especialización en los equipos.

El segundo punto sí estaba previsto que lo tratásemos y así lo hicimos, sin embargo, y esto es lo bueno que tienen estas reuniones, salen temas realmente interesantes donde uno aprende mucho justificando sus ideas y escuchando a los demás.

Algunas cuestiones/ideas interesantes que me gustaría destacar:

1. Felipe planteó que las aplicaciones web se podían distribuir en formato WAR y que los parámetros de configuración fueran proporcionados por el contenidor o servidor de aplicaciones a través de un recurso JNDI. Desde luego es una forma de que WAR sea válido en cualquier entorno de despliegue siempre y cuando se conozca el nombre del recurso que el administrador de sistemas asigne.
2. El plugin Assembly es muy útil para diseñar los distribuibles clásicos: binario, fuentes, etc.
3. Debemos organizar una desconferencia para hablar única y exclusivamente de metodologías y su vinculación con los ecosistemas software.
4. Las desconferencias debemos guiarlas y centrar los temas que se van a tratar.
5. Deberíamos elegir otras opciones que no sean los viernes.

Una foto (Darío, Viki, Paco, Felipe, Dani) en las oficinas de BitRock. Aprovecho para darles las gracias por su hospitalidad.

En lo que resta del mes de octubre asistiré a dos eventos. El primero de ellos será el próximo lunes 20, día en el que comienza la conferencia internacional de software libre y se prolonga durante los días 20, 21 y 22. Limitaré mi asistencia al día 21, especialmente porque uno de mis compañeros de trabajo impartirá un charla. Tengo que reconocer que el evento, hoy por hoy, no me gusta como está enfocado.

Por otro lado, y este sí que me gusta mucho, asistiré con mi compañero Antonio Manuel Muñiz al JSWEB que se celebrará en Sevilla durante los días 29 y 30.

Tras el parón veraniego, el grupo de ecosistemas-software organiza “Desconferencia 02″. Como ya sucediera en su primera edición, esta nueva edición se volverá a celebrar en las instalaciones de BitRock.

La desconferencia se celebrará el próximo viernes 17 a las 18:00h:

BitRock S.L.
C/ Salado 11 – Local 15
41010 Sevilla
Spain

Para esta segunda edición voy a preparar algunas cositas sobre distribuibles en Java. Supongo que luego saldrán otros muchos temas. Se ruega a todos los que tengan pensado asistir confirmen su asistencia en la lista de correo. El espacio es limitado y además tengo que saber la gente que asistirá para comprar unos refrescos y algo para picar.

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.

Es una lástima leer noticias como esta: Los ingenieros informáticos crean un colegio para defenderse del intrusismo. Como si el intrusismo fuera el problema.

¿Por qué? Porque detrás de Octality hay gente con iniciativa y mucho trabajo de calidad. Mi más sincera enhorabuena.

Se acaba de publicar una nueva revisión de Opina 1.x, concretamente la revisión 10. Esta nueva revisión soluciona un problema importante en la gestión de grupos y preguntas.

Instalar Opina 1.0.10