Mi espacio

A través de la lista de correo de iris-libre he sabido que han publicado un video con la mesa redonda sobre software libre y universidad celebrada con motivo de e-Verano 2007. Los componentes de la mesa son:

• Claudio Arjona, C.I.C.A
• Miguel Rueda, SOLFA
• Rafael Pastor, UNED
• Rafael Rodrigue, OSLUCA

Enhorabuena por el trabajo que se está haciendo desde SOLFA. Me fastida mucho no tener tiempo para seguir colaborando con ellos.

Desde la polémica aparición del sitio web del Congreso de los Diputados, y a raíz de una entrada de Javier Cañada en su blog donde daba su opinión sobre por qué este tipo de proyectos de la administración pública fracasaban estrepitosamente, tenía pendiente una propuesta.

En teoría, cuando estos proyectos se hacen públicos, la administración correspondiente publica el pliego con sus clausulas administrativas y técnicas. En dicho documento se establece una ponderación sobre distintos aspectos (solución técnica, económica, referencias en proyectos similares, etc.). Tras la presentación de ofertas por parte de las empresas, una mesa de adjudicación, estudia las ofertas y resuelve el concurso adjudicando el concurso a una oferta (pueden ser varias empresas, UTE).

Si se constituye una mesa de adjudicación para estudiar y evaluar las ofertas, ¿Por qué no se constituye una mesa para estudiar y evaluar el trabajo realizado por la empresa adjudicataria?

El objetivo de esta “segunda mesa” sería, en primer lugar, evaluar el cumplimiento de la oferta (plazos, documentación, recursos, tareas, etc.) y en segundo lugar, obtener un informe de calidad que pudiera servir de referencia para futuras contrataciones de características similares. Este trabajo podría (y debería) ser compartido entre administraciones públicas.

No debemos olvidar que la administración pública trabaja para el ciudadano, y cuando proyectos de estas características fracasan de la forma en la que lo hacen, la administración pública no está haciendo correctamente su trabajo.

Esta mañana me enteraba a través de un correo electrónico que el sitio web del Ministerio de Vivienda había sufrido un pequeño percance.

El objetivo de esta entrada es presentar lo que entiendo por integración continua y cómo enjaca esta nueva pieza dentro del ecosistema que constituye un entorno de desarrollo y las metodologías que se aplican. Según la R.A.E.:

ecosistema: Comunidad de los seres vivos cuyos procesos vitales se relacionan entre sí y se desarrollan en función de los factores físicos de un mismo ambiente.

En nuestro caso los seres vivos son los distintos miembros del equipo con su correspondiente rol, los procesos vitales podrían ser las tareas que deben realizar para “sobrevivir” y que se desarrollan a partir de unas pautas, normas y procedimientos que las metodologías arbitran.

“La integración continua es una práctica en el desarrollo de software que consiste en poner en común todas las tareas que se han realizado en un intervalo de tiempo y, mediante la automatización de ciertos procesos, comprobar cuáles han sido los efectos de dichas tareas“.

Que este post sirva como presentación para un nuevo tema dentro de este blog.

Esta semana ha surgido en Opina la necesidad de definir un entorno de desarrollo en el que en lugar de Apache Tomcat se necesitaba trabajar con Jetty 6.x. Nunca había trabajo con Jetty, sin embargo, mis compañeros de trabajo todos lo usaban y las primeras impresiones son muy buenas.

El objetivo del presente post es, teniendo nuestro proyecto J2EE descrito con Maven y configurado en Eclipse, trabajar con Jetty. En este caso el proyecto será Opina e intentaremos usar Jetty en lugar de Apache Tomcat durante el desarrollo.

En primer lugar tendremos que configurar el plugin de maven correspondiente. Para ello, en la sección correspondiente a build (dentro de pom.xml):

<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.5</version>
<configuration>
<scanIntervalSeconds>5</scanIntervalSeconds>
<scanTargets>
<scanTarget>
${basedir}/src/main/webapp/WEB-INF
</scanTarget>
</scanTargets>
<classesDirectory>
${basedir}/src/main/webapp/WEB-INF
</classesDirectory>
<contextPath>${project.artifactId}</contextPath>
<webAppSourceDirectory>
${basedir}/src/main/webapp
</webAppSourceDirectory>
<webXml>
${basedir}/src/main/webapp/WEB-INF/web.xml
</webXml>
</configuration>
</plugin>

Esta configuración está condicionada a que en Opina usarmos ${basedir}/src/main/webapp para montar la aplicación mientras estamos desarrollando. Prueba de ello es que normalmente usamos: mvn compile war:inplace

Una vez que hemos actualizado el archivo pom.xml, vamos a configurar Eclipse para que podamos invocar a Maven con los argumentos que necesitamos:

1. Run > External Tools > Open External Tools Dialog
2. Sobre Program, pulsamos el botón derecho y  New
3. Definimos un nombre para esta tarea (junto a Name)
4. Estando sobre la pestaña Main:
   1. Location: Indicamos donde se encuentra el ejecutable de Maven
   2. Working directory: Navegamos por Working Directory y seleccionamos nuestro proyecto
   3. Arguments: Indicamos los argumentos que nos interesen, por ejemplo: compile war:inplace jetty:run. Con estos argumentos conseguimos que nuestro proyecto pase por todas las fases del ciclo de vida definido en Maven hasta llegar a la fase de compilación. Esto nos garantizará que se han generado todos nuestros recursos (web.xml, struts-config.xml, etc), se ha aplicado nuestro perfil correspondiente (profiles.xml), se ha compilado nuestras clases, se han obtenido nuestras dependencias y que nuestra aplicación se ha construido en ${basedir}/src/main/webapp.
5. Aplicar
6. Cerrar

Si todo ha ido bien, estaremos dispuestos a ejecutar la tarea. Para ello:

He preparado un screencast de la consola de Eclipse simplemente para que vea como se ejecutan las distintas tareas que se le indican a Maven y como posteriormente se lanza Jetty con nuestra aplicación.

Y ahora lo más importante para poder desarrollar con estos ingredientes, la depuración. ¿Qué tenemos que hacer para poder depurar? El siguiente objetivo es claro. Ahora necesitamos seguir usando la perspectiva de depuración de Eclipse de igual forma que la usamos en otros proyectos o la usamos cuando usamos Apache Tomcat.

Tenemos que modificar la tarea que hemos creado. Para ello, editamos la tarea, y sobre la pestaña Environment, añadimos la variable MAVEN_OPTS con el valor: -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=y

Una vez modificada la tarea:

1. Run > Open Debug Dialog
2. Sobre Remote Java Application, pulsamos con el botón derecho y New
3. Definimos un nombre (junto a Name)
4. Y sobre la pestaña Connetion:
   1. Project: Selecionamos nuestro proyecto
   2. Connection Properties:
      1. Host: localhost
      2. Port: 4000 (el que hemos indicando en MAVEN_OPTS).
5. Aplicar
6. Cerrar (aun no debemos depurar nada)

Teniendo la tarea definida y la configuración para la depuración, estamos en disposición de comprobar si todo ha ido bien. Para ello, he preparado un segundo screencast.

Algunas referencias donde viene todo esto explicado:

1. Debugging with the Maven Jetty Plugin inside Eclipse
2. Maven Jetty Plugin

Un problema con el que me he encontrado, y parece que más gente, es que cuando se desea terminar la tarea que acabados de ejecutar el proceso no se detiene y Jetty continua en ejecución. Si las tareas que hemos definido las ejecutamos desde la línea de comandos todo funciona perfectamente. Al pulsar CTRL+C, la tarea de Maven termina y Jetty de apaga correctamente. Parece que hay un parche que nos ayuda a terminar la tarea que aun no he probado.

Es probable que la integración mejore considerablemente cuando hagan compatible con la versión 6 de Jetty el plugin de Eclipse Jetty Launcher.

Existen otras formas de integración con los mismos ingredientes. Sin embargo esta es la que interesante me ha parecido, entre otras cosas porque no nos hemos tenido que preocupar ni de descargar Jetty.

He preparado un screencast con el ejemplo de uso que exponía en el anterior post sobre Apache JMeter. La verdad es que el screencast no está demasiado trabajado, pero la experiencia preparando el screencast ha sido un poco frustante. Después de tener preparada la secuencia, a la hora de renderizarla, se me ha quedado colgado el equipo en varias ocasiones y he tenido que repetir todo el proceso (con lo que ello implica). Quiero recordar que Wink, la herramienta que he usado para crear el screencast, funcionaba mejor en Microsoft Windows XP. Mi experiencia con Microsoft Vista no está siendo muy satisfactoria.

Hacía ya tiempo que quería escribir algo sobre Apache JMeter, y aprovecharé que anoche estuve haciendo algunas pruebas con Opina para explicar cómo realizar un prueba de rendimiento. Como según se indica en la página de la herramienta, es una aplicación de escritorio desarrollada en java para realizar pruebas de rendimiento. Diseñada originalmente para trabajar con aplicaciones web pero en sus últimas versiones se ha ido ampliando el catálogo de funcionalidades y se puede usar para trabajar con otro tipo de aplicaciones.

La prueba que he preparado consiste en coger un cuestionario que tenía previamente preparado y simular que “alguien” lo está cumplimentando múltiples veces. Para simular este proceso, lo primero que necesitamos conocer son las peticiones HTTP que se tienen que realizar sobre Opina. En esta ocasión esto hubiera resultado muy sencillo porque el cuestionario carece de autenticación y proceso de registro, simplemente:

1. Solicitar el cuestionario
2. Nos redirige a una pantalla con la bienvenida y descripción del cuestionario
3. Nos muestra la única página con la que cuenta este cuestionario. Cumplimentarlo.
4. Y confirmar que hemos terminado para que nuestros datos se almacenen.

En lugar analizar la comunicación entre el cliente web y la aplicación, JMeter hará el trabajo por nosotros. La herramienta se encargará de grabar las peticiones que corresponden con la secuencia antes descrita. Los pasos a seguir son:

1. Ejecutamos JMeter.
   
2. Sobre el plan de pruebas añadimos un grupo de hilos
3. Sobre el banco de pruebas añadimos un elemento NoDePrueba, concretamente Servidor Proxy HTTP que debemos configurar:
   1. Nombre: indicaremos un nombre para el proxy
   2. Puerto: puerto en el que estará disponible el servicio de proxy
   3. Luego encontraremos varias opciones (capturar cabeceras http, establecer Keep-alive, etc) esto dependerá de lo que se pretenda realizar. En esta ocasión he seleccionado las dos primeras.
   4. Controlador objetivo: Plan de pruebas -> Grupo de hilos
   5. Patrones a incluir: .* (lo incluiremos todo)
      
4. Sobre el grupo de hilos añadimos un elemento de configuración: Valores por defecto para petición HTTP
   1. Nombre: un nombre de referencia para esta configuración
   2. Nombre del servidor o IP: servidor sobre el que realizaremos las peticiones, en mi prueba: www.ebabel.info
   3. Puerto: puerto sobre el que se realizarán las peticiones (por defecto es el 80), en mi prueba: 80
   4. Protocolo: HTTP o HTTPS, en mi prueba: HTTP. Si las peticiones tuvieran que realizar sobre HTTPS, algunas de las opciones de monitorización (cabeceras HTTP, etc) se perderían.
   5. Path: camino a partir del cual se realizarán las peticiones.
5. Ahora debemos configurar nuestro navegador para que use el servidor proxy HTTP que hemos configurado.
6. Arrancamos el servidor proxy HTTP desde la herramienta y con nuestro navegador reproducimos el proceso que deseamos simular. Todas las peticiones irán quedando registradas en nuestro grupo de hilos que previamente hemos creado.
   
7. Esto depende un poco del tipo de prueba, pero si las pruebas se están realizando sobre una aplicación en la que haya control de sesiones, recomiendo configurar un gestor de cookies HTTP. Para esta prueba lo he configurado haciendo que se limpien las cookies por cada iteración.
8. El número de iteraciones podemos configurarlo en el grupo de hilos.

En breve publicaré un screencast con la prueba. Para cualquier duda, un correo o un comentario.

Este blog cumple un año. Justamente el 6 de agosto de 2006 escribí mi primer post en la blogosfera. Son muchas las cosas que me gustaría ir escribiendo, algunas simplemente de opinión y otras quizás algo más técnicas, pero no logro sacar tiempo para escribir. Por ahora me conformo con escribir a este ritmo.

Un saludo a todos los que lo leen. 

Esta mañana he recibido un correo de un compañero de trabajo en el que me comunicaba que tenemos confirmada nuestra asistencia a las jornadas. El año pasado no pude ir pero parece que este año las posibilidades aumentan.

El programa tiene muy buena pinta, a ver si el próximo año desde GMV-SGI podemos presentar algo interesante. Este año hubo intención pero no tiempo.

Tan sólo hace unas horas que ha terminado la compo “combined demo” en la Assembly 2007 y ya están disponibles algunas de las producciones. Nunca he podido asistir a esta party. Año tras año surge algo y no puedo ir. Este año hubo expedición de españoles, espero que cuando vuelvan compartan algunas fotos y comentarios de una de las parties más míticas. Sólo un dato, la primera edición de esta party fue en el 1992. ¿Increible verdad?

Una vez más, los chicos de ASD se han lucido y nos han deleitado con esta maravilla, Lifeforce.