Enriqueciendo los datos

Hola a todos:

Como habréis comprobado hace tiempo que no subo ninguna transfromación o job de pentaho. Esto no quiere decir que haya abandonado el proyecto.

Los metadatos que Assembla nos proporciona no son suficientes para dar respuesta a todos los puntos de la rúbrica que debemos cumplimentar de manera automática. Por ello vamos a hacer uso de herramientas adicionales:

StatSVN: Conocida herramienta que nos da información del reparto de trabajo de un determinado repositorio SVN. Basta con hacer un checkout de cada proyecto, generar un xml de cada uno mediante «svn log -v –xml» y posteriormente pasarle este fichero a statsvn. Con ello obtendremos una web en html de cada proyecto. En ella veremos información como el número de líneas que ha escrito/modificado cada usuario, la evolución en tamaño del proyecto, la distribución de commits a lo largo del tiempo, etc. Para no aburriros os dejo un ejemplo del proyecto que desarrolla el lenguaje Ruby:

http://statsvn.org/demo/ruby/

CVSAnaly: Herramienta de libresoft. Va en la línea de StatSVN pero es mucho más potente. CVSAnaly no se queda en generar HTML, sino que almacena información de cada repositorio en una base de datos. Esto nos facilita la labor posterior de análisis. Además es compatible con SVN, GIT y CVS. Antiguamente la instalación de esta herramienta daba quebraderos de cabeza. Ahora viene empaquetada en un .deb y extremadamente sencillo. Incluso se configura automáticamente la conexión con la base de datos, en nuestro caso MySQL. Os dejo un enlace al modelo de datos. Aun no hemos analizado a fondo qué nos proporciona ni cómo los vamos a adaptar al modelo que tenemos actualmente, que aun no está en su versión final. http://melquiades.flossmetrics.org/wiki/lib/exe/detail.php?id=scm&media=scm_singledb_schema_1.0.png

Sonar: Otra herramienta libre que  obtener información del código fuente. Esta información es el número de líneas de código, el número de lineas de comentarios, cobertura de las pruebas unitarias e incluso calidad del código (nombre de las variables, tabulación, etc). Soporta una gran variedad de lenguajes de programación y su diseño es totalmente modular, lo que nos permite añadir plugins facilmente. Os dejo también una URL con una demo pública de Sonar http://nemo.sonarsource.org/

Las herramientas ya están instaladas en un servidor, falta desarrollar las tareas de pentaho y estudiar qué información debemos extraer de cada una de ellas.

Encuentro BetaBeers

Hola a todos!!

Quería avisaros de que me he apuntado al evento BetaBeers que tendrá lugar próximamente en Cádiz para explicar Abreforjas. Os mantendré informados en todo momento acerca de la fecha y el lugar concreto.

Por el momento podéis apuntaros tanto para ir como oyente o ponente en esta dirección: BetaBeers

 

Saludos y nos vemos pronto!!!

Un informe con más chicha

Tras haber trasteado más con Pentaho BI-Server y añadiendo el plugin Saiku hemos conseguido un informe más complejo. Dicho informe nos muestra todos los proyectos que hemos obtenido de Assembla, los usuarios que han participado en ese proyecto y la cantidad de tickets de cada milestone que han resuelto.

Esperamos conseguir informes más completos cuando trabajemos con forjas más ricas en datos (lenguaje de programación, tipo de software, base de datos que utiliza, etc)

 

Informe

Primer informe

Al tener los datos ya almacenados me he puesto a investigar qué podía sacar de ellos con la herramienta pentaho reporting. Os dejo una muestra en la que se observan características de los tickets agrupados por milestones y proyectos: Informe

Sé que es demasiado simple aun pero tengo que investigar algo más para hacer uno más complejo.

Saludos

Assembla terminado!!!

Tras estos días de trabajo con la API de Assembla he conseguido descargar y almacenar los metadatos de la lista de proyectos que me facilitaron.

Estos proyectos son resultado de prácticas de dos asignaturas que se imparten en la titulación de Ingeniería Informática en la Universidad de Cádiz. Los datos que hemos extraído (descargas, tickets, y milestones), en combinación con los datos que resulten del análisis del código que se aloja en el repositorio, servirán para postevaluar los proyectos siguiendo una determinada rúbrica. Con lo que en este proyecto se ha extraído se podrá conocer, entre otras cosas, los tickets que ha resuelto cada usuario del grupo, comprobando que el reparto ha sido equitativo, quién ha creado más tickets, si la distribución de éstos en el tiempo ha sido constante (sin picos muy altos de trabajo), los tickets asociados a cada milestone, etc.

Para llevar a cabo esto he tenido que estudiar la API de assembla, cuyos patrones de URIs han sido incluidos como inserciones en la base de datos en el fichero forges.sql. En la página de la API de Assembla http://www.assembla.com/spaces/breakoutdocs/wiki/Assembla_REST_API tenéis información acerca de qué datos proporciona cada documento. Como podéis comprobar la información que proporciona es más pobre que la que da SourceForge y, al querer mantener el mismo modelo de la base de datos hay muchos campos que quedarán vacíos. Aquí tenéis todo el mapeado, tanto de Assembla como lo que se realizó en su día para SourceForge https://docs.google.com/spreadsheet/ccc?key=0AnNbYBJtxBVAdEM3ck9XNk84d0FGeVVVTExqVEJTN1E

También he facilitado la prueba del programa en vuestros equipos. Para ello os he puesto en svn:/trunk/Repository un archivo llamado repo.xml, que contiene el repositorio con el que yo trabajo. Para instalarlo en vuestro ordenador personal sólo tenéis que crear un repositorio en vuestro PC desde el menú del propio Pentaho Tools/Repository/Connect y pincháis en el símbolo verde con un «+». En ese momento deberéis decidir si queréis guardar el repositorio con ayuda de un SGBD, yo en mi caso utilizo mysql, o en ficheros (nunca lo he utilizado).  Aquí os dejo una referencia donde dan información más detallada http://www.xperimentos.com/2007/05/21/repositorio-de-objetos-en-kettle/. Una vez creado el repositorio sólo tenéis que cliclar en Tools/Repository/Import y seleccionar el archivo repo.xml.

Para que Abreforjas funcione, os recuerdo que debéis tener una base de datos mysql con el modelo de datos que os incluyo en los ficheros creates3.sql y forges.sql y una conexión entre Pentaho y dicha base de datos configurada. http://wiki.pentaho.com/display/EAI/.03+Database+Connections

Los jobs que tenéis que ejecutar son, por este orden, CUSL/Assembla Discoverer, CUSL/Generic Wrapper/Generic Wrapper y CUSL/Integration Process/Integration Assembla Process. Como siempre deberéis estar atentos a las rutas de los ficheros que son consultados, ya que, con toda seguridad, no coincidirán en vuestro equipo y en el mío.

Un saludo a todos!!!

Giro en Abreforjas

Tras dejar el proyecto un poco parado debido a la carga de exámenes vuelvo con muchas fuerzas y ganas de seguir con el proyecto.

Como sabéis, la línea que estaba siguiendo consistía en obtener toda la información posible de los proyectos de SourceForge. Se había conseguido obtener los nombres de los proyectos, su información más general en formato RDF, los tickets y las descargas. Sin embargo únicamente habíamos mapeado la información general en la base de datos.

El cambio en la línea de abreforjas viene dado por el descubrimiento de FlossMole (http://flossmole.org/), una web que ofrece información actualizada de un conjunto de forjas, entre ellas SourceForge. Es por esto que debemos estudiar qué datos nos ofrece FlossMole para no «reinventar la rueda». No tendría sentido realizar el mismo trabajo de nuevo si podemos aprovechar los datos que en esta web se nos ofrecen.

Debido a esto y a una petición de profesores con los que colaboro me he dispuesto a tratar de realizar el mismo proceso en Assembla. Ésta tiene ciertas peculiaridades (no todos los proyectos son visibles, no se ofrece la lista de proyectos) y ofrece menos metadatos a través de su API. Por esto vamos a trabajar con una lista de proyectos definida y vamos a descargar toda la información que Assembla nos provee a través de su API para realizar un posterior mapeo en el mismo esquema, quizás con algunas modificaciones, de la base de datos.

En estos momentos, aunque aún no lo he subido a la forja, he conseguido bajarme toda la información (tickets, milestones, documents, etc) de la lista de los proyectos que me proporcionaron. Esta información se encuentra en ficheros XML y mi trabajo actual se concentra en mapear los datos qué estos ficheros contienen en el esquema de la base de datos que sí tenéis liberado.

Pronto tendréis más noticias. Saludos!!!

Tenemos logo!!!!

Como os habréis fijado ahora tenemos logo en el blog. Además del que podéis ver también disponemos de éste:

 

Los logos son fruto de la colaboración en el Hackathon UCA 2011. Donde además de trabajar, tuvimos conversaciones muy interesantes tanto de los proyectos como de la programación en general.

Saludos a todos 😉

Generic Wrapper y problemas surgidos

Hola a todos:

Tras unas semanas de trabajo he podido subir una primera versión del módulo GenericWrapper. La finalidad de este módulo es la de bajarse todos los archivos que la forja disponga de los proyectos. Actualmente sólo trabaja con SourceForge y se descarga el fichero DOAP del proyecto y los ficheros asociados a los tickets y a las downloads. Como no sabemos cuantos ficheros de estos últimos tendrá cada proyecto he añadido un contador para que no se pisen. De esta manera, los ficheros se almacenan con un nombre que sigue la plantilla FORJA-Nombreproyecto-TIPO-NUM. Un ejemplo Sourceforge-firefoxtakeout-GENERAL-0. El campo tipo está limitado a GENERAL, TICKETS o DOWNLOADS.

Al descargar los tickets he tenido problemas ya que SourceForge no sigue siempre el mismo XML-Schema. Cuando no puede acceder, o no tiene, la información de un determinado ticket, devuelve un fichero XML que sigue el esquema sf:error. Pentaho trataba de leerlo como si fuera un fichero normal y el XPath fallaba. Para resolverlo he comprobado antes de extraer la información que el fichero cumple el Schema propio de un fichero RDF. Dicho Schema lo he subido en un fichero llamado rdf.xsd.

La codificación de los ficheros también me ha dado problemas. Según la cabecera de éstos, los ficheros siguen la codificación UTF-8. Sin embargo en su interior hay palabras con acentos y otros caracteres especiales. Pentaho fallaba en este paso independientemente de si lo ejecutaba en Windows o en Linux. Para solventarlo añadí una tarea que modifcaba la cabecera de los ficheros antes de guardarlos y les asignaba la codificación ISO-8859-1.

Como último problema tenemos el consumo de memoria. Tanto el Wrapper como el Discoverer consumen toda la memoria que le asigno a la máquina virtual de Java y empiezan a ralentizarse en su labor, llegando alguno a lanzar la excepción Java Heap Space. He aumentado la memoria de la máquina virtual hasta 2GB ya un así sigue fallando, aunque tarda más en llegar dicho fallo ¿Alguien tiene alguna idea?

Saludos.

 

Source Forge Discoverer

 

Ya he añadido los ficheros correspondientes al job SourceForge Discoverer con sus correspondientes transformaciones. Este trabajo se encarga de obtener, mediante peticiones rss, los nombres de todos los proyectos alojados en SourceForge y almacenarlos en la base de datos.

También se ha añadido el fichero uri.txt, que sirve para almacenar cual fue la última URI de la que se obtuvieron los nombres de los proyectos. De esta manera, si el proceso se para, voluntaria o inesperedamente, podremos continuar la descarga por donde íbamos y evitar así empezar de nuevo.

Si queréis probarlo deberéis configurar algunas cosas en Pentaho:

• Configurar la conexión a la base de datos [1]
• Pentaho no permite el uso de rutas relativas, por lo que en la configuración actual el tratará de leer el fichero uri.txt de un directorio local a mi ordenador. Para arreglarlo existen dos opciones. La primera consiste en cambiar el parámetro DATA_PATH_1 de todas las transformaciones/trabajos en Edit/Settings/Parameters y poniendo en el valor por defecto la ruta en la que vosotros tenéis alojado el fichero uri.txt. La segunda solución se basa en modificar las tareas ‘Source Forge Parameters Generator’/’Text File Input’ y ‘Source Forge URI Holder’/’Text File Output’  especificando la ruta correcta del fichero uri.txt
•  Para disminuir los tiempos de carga de la base de datos he anulado algunas restricciones y es posible que al ejecutarlo os de algún fallo de clave foránea. De nuevo existen dos opciones: Quitar la restricción de claves foráneas de la tabla projects o esperar a que, en unos días suba un script que rellenará dicha tabla.

El siguiente paso es algo más duro. Debemos descargar los ficheros RDF asociados a los proyectos de los cuales acabamos de obtener los nombres. Estos RDF son: un DOAP con la información general del proyecto, ficheros que contienen información de los Tickets y ficheros que contienen información de las descargas.

 

Veamos cómo se me da la cosa. Saludos.

 

PD: Este viernes, seguramente, me pase por OpenData Sevilla para aprender un poco más de este mundillo. Os animo a todos a asistir.

 

[1] http://wiki.pentaho.com/display/ServerDoc1x/01.+Setting+Up+Your+Database+Connections

Primeros pasos

Tras la declaración de intenciones tocaba ponerse manos a la obra. En este fin de semana he conseguido establecer una primera versión de lo que será la base de datos. El ER está subido en la forja en formato PNG pero os lo adjunto aquí para que podáis verlo sin problemas.

En un futuro añadiré que añadir más campos, algunos específicos de una determinada forja, si considero que son de interés para los posteriores análisis.

El siguiente paso es obtener los nombres de los proyectos alojados en SourceForge, visibles a través de publicaciones RSS. Una vez estos nombres se almacenen en la base de datos, podremos acceder a más información de estos a través de la API de SourceForge.

Sin más, me despido hasta que tenga nuevas novedades. Un saludo a todos aquellos que me están dando ánimos por las redes sociales por iniciar este proyecto.