Mi espacio

La verdad es que la primera vez que tuve que renderizar unas gráficas fue para una pequeña aplicación programada en PHP que se encargaba de controlar la ocupación de unas aulas de informática. Por aquella época, JpGraph era una de las mejores librerías en PHP para el renderizado de gráficas. La verdad es que desde aquello ha llovido un poco y ahora hay otras opciones.

Hace unos días os comentaba que estábamos (en GMV) trabajando en un plugin para TRAC llamado STractistics para medir la actividad de los proyectos. Todavía está un poco verde, pero estamos trabajando para añadirle nuevas funcionalidades. Para este proyecto se barajaron varias opciones:

• Generar las gráficas en el servidor al estilo de JpGraph y devolverlas al cliente como una imagen.
• Generar las gráficas en el cliente: HTML + CSS o HTML + CSS +Javascript.
• Generar las gráficas en el cliente: Flash (SWF), OpenFlashChart
• Generar las gráficas en “Google” haciendo uso de Google Chart API

Se hicieron algunas pruebas con la segunda opción y los resultados no eran malos, todo lo contrario, sin embargo, los problemas de compatibilidad con los distintos navegadores web suponía un problema. Las búsquedas nos llevaron a Open Flash Char, desde mi punto de vista, un excelente trabajo que nos permite generar unas vistosas y configurables gráficas.

Ayer leía que el software usado en SOITU durante las elecciones para el renderizado de gráficas ha sido liberado con licencia GNU GPLv3. Mi más sincera enhorabuena por la iniciativa. Después de conocer cómo funciona OpenFlashChart y de leer como funciona Charts (SOITU), la forma en la que este último recoje los datos es más sencilla y cómoda, basta con generar un XML.

Por ahora STractistics se quedará así pero se estudiará la migración a Charts (SOITU).

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.

En un post anterior os publicaba un simple shell script que he preparado para las copias de seguridad de mis proyectos en trac. Partiendo de ese mismo script, lo he modificado para realizar las copias de seguridad de los repositorios de subversion.

Dejo el script por si a alguien le puede resultar útil.

He preparado un pequeño shell script para realizar las copias de seguridad de mis proyectos en trac. El script cuenta con tres parámetros de configuración:

• BACKUP_DIR: Directorio donde se van a almacenar los tar.gz correspondientes a cada proyecto.
• TRAC_PROJECTS_DIR: Directorio donde se encuentran los proyectos de trac.
• TRAC_INSTALL_DIR: Directorio donde se encuentra instalado trac. En mi caso hice la instalación con la opción –prefix=/usr/local/trac y por ese motivo tengo un diretorio base donde están instalados todos los archivos correspondientes a trac.

El script genera un archivo de la siguiente forma: PROJECTNAME_YYMMDD_HHMM.tar.gz. Una vez probado el script desde la línea de comandos, he programado una tarea en el cron que ejecuta el script todos los días a las 00:00h. Si tenéis algún problema con el script en el cron, comprobad que las variables de entorno necesarias de PYTHON están disponibles. En mi caso, antes de invocar a trac-admin con la opción hotcopy, he tenido que definir la variable PYTHONPATH.

Dejo el script por si a alguien le puede resultar útil.

Desde hace algunas semanas tengo pendiente escribir sobre profiling en PHP. Hace tiempo que no desarrollo ningún proyecto serio con PHP, sin embargo es un lenguaje de programación que siempre me traerá buenos recuerdos y del que procuro nos desvincularme demasiado. Aunque el marco tecnológico en el que me muevo ahora es otro, creo que es necesario no perder de vista otra opciones porque nos pueden aportar soluciones muy interesantes.

La intención de este post, y algún otro que le seguirá, es proporcionar algunas referencias para instalar y configurar un entorno de desarrollo con PHP en que tengamos la posibilidad de realizar debugging y profiling de forma más o menos seria. Las instrucciones están hechas sobre el sistema operativo Microsoft Windows, pero son fáciles de trasladar a otros sistemas operativos.  Antes de comenzar necesitamos conocer los requisitos para la instalación:

• WAMP Server: Es un paquete preparado para Microsoft Windows ( lo he probado en Windows 2000, Windows XP y Windows Vista) que a través de un instalador tendremos disponible un Apache Web Server, PHP5 y MySQL. Concretamente, WAMP 1.7.1 tiene Apache Web Server 2.2.4, PHP 5.2.2 y MySQL 5.0.37. Al igual que este paquete existen otros como por ejemplo XAMPP (disponible para Microft Windows, Linux, Solaris y Mac OSX) y MAMP (disponible para Mac OSX y con una versión PRO),
• Xdebug : Es la herramienta que nos proporcionará las trazas de los mensajes de error, información sobre la memoria consumida por los script, información sobre los tiempos de ejecución de script, funciones, etc… Esta herramienta se instalará y configurará como una extensión del intérprete de PHP. La versión que usaremos será la 2.0.0RC para Microsoft Windows y PHP 5.2.1 .
• WinCacheGrind: Esta herramienta está disponible para Microft Windows y es la que nos permitirá analizar los archivos que Xdebug genera con la información de profiling a partir de una interfaz gráfica. Esta herramienta no es necesaria porque Xdebug permite varios modos para monitorizar la información, sin embargo, el que personalmente me parece más interesante es el que genera unos archivos que posteriormente pueden ser analizados con WinCacheGrind.

Una vez que nos hemos descargado el instalador de WAMP Server, Xdebug (extensión para PHP) y WinCacheGrind, procedemos a su instalación:

1. De la instalación de WAMP Server poco hay que destacar porque precisamente una de las ventajas que tiene usar este tipo de paquetes en lugar de instalar las cosas de forma individual, es que proporciona un asistente que si mal no recuerdo lo único que pregunta es el directorio para la instalación, posibilidad de configurar los puertos con los que Apache Web Server y MySQL trabajarán y poco más. Tras la instalación y ejecutando wampserver tendremos una utilidad desde la que podremos lanzar los servicios y configurar Apache, MySQL y PHP. A continuación debemos lanzar los servicios, en nuestro caso con lanzar Apache Web Server es suficiente.
2. Para comprobar que la instalación se ha realizado correctamente, podemos acceder desde nuestro navegador web a http://localhost y ver una página con información sobre el paquete instalado.
3. Para instalar la extensión de PHP correspondiente a Xdebug:
   1. Copiamos la DLL en el directorio WAMP_INSTALL_DIR/php/ext/
   2. Habilitamos la extensión editando el archivo php.ini que se encuentra en WAMP_INSTALL_DIR/Apache2/bin
   3. Buscando la sección del archivo donde se encuentran el resto de extensiones añadimos la siguiente línea: zend_extension_ts=”WAMP_INSTALL_DIR/php/ext/LIBRARY_NAME”
4. Reiniciamos Apache Web Server y accedemos al phpinfo que nos proporciona la págna principal de WAMP Server. Para comprobar que la extensión se ha cargado correctamente debemos obtener:
   
5. Para descripción detallada sobre cada uno de los parámetros de configuración visitar la página de xdebug. A continuaciónun ejemplo de configuración básica (profiling):
   

Espero que estas notas ayuden a configurar un entorno de desarrollo con PHP con la posibilidad de realizar tareas de profiling. Intentaré añadir un screenscast con un ejemplo.