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.

Declaración de intenciones

Hola a todos:

Mi nombre es Nacho Traverso y soy alumno de Ingeniería Informática en la Universidad de Cádiz. Este año me presento al CUSL (Concurso Universitario de Software Libre) con mi proyecto Abreforjas.

Cualquier persona que haya desarrollado software libre seguramente haya utilizado una forja alguna vez en su vida. Como sabéis, en las forjas no sólo se almacena el código, sino que nos proporcionan una serie de herramientas y funcionalidades para mejorar el desarrollo, darle visibilidad al proyecto, clasificarlo, etcétera. Pues bien, Abreforjas se va a encargar de extraer la máxima información posible de todos los proyectos alojados en una serie de forjas. Empezaremos con Sourceforge, aunque el objetivo es abarcar también Google Code, Git Hub y Assembla. ¿Qué datos queremos extraer? Pues todos aquellos que puedan resultar interesantes para un posterior análisis: lenguaje, sistema de base de datos, desarrolladores, sistema de control de versiones, bugs, tickets, etc. Sólo con los datos anteriormente indicados ya tenemos multitud de preguntas que responder:

-¿Qué lenguaje es el más utilizado en general?¿Y en una determinada forja?

-¿Qué usuario de la forja resuelve más bugs?¿Y más tickets?

-¿Qué desarrollador es el más activo?¿Cuál participa en más proyectos?

Y así podríamos seguir formulando todas las que se nos ocurrieran. Actualmente estas preguntas no se responden facilmente porque no se puede acceder a los datos facilmente. Abreforjas extraerá los datos de dichas forjas y los almacenará en una base de datos para su posterior análisis.

Ahora bien, hablamos de extracción de datos pero ¿Cómo se va a realizar dicha extracción? Pues mediante las APIs que las distintas forjas nos ofrecen. A partir de ellas extraeremos ficheros RDF que contendrán la información de un proyecto concreto en formato XML y que, posteriormente, serán analizados. Cada forja ofrece unos determinados recursos en sus APIs y utiliza unas determinadas magnitudes que no tienen por qué coincidir. Es el deber de Abreforjas integrar toda esta información de manera consistente, limpiando o normalizando los datos previamente a su almacén.

Bueno, y todo esto ¿Cómo lo vamos a hacer? Pues nos vamos a ayudar del entorno libre Pentaho BI Suite Community Edition [1] y su herramienta Kettle, diseñada especialmente para facilitar la integración de datos. Como sistema de gestión de base de datos hemos escogido MySQL, también libre como ya sabéis.

Estos datos se presentarán mediante un dashboard por internet y se permitirá realizar una serie de consultas para responder a posibles preguntas que tenga el usuario.

El proyecto se encuentra alojado en RedIris [2] y os invito a colaborar en este proyecto. Caminemos hacia una web más abierta y accesible para todos, incluso nuestros PCs =)

[1]  http://community.pentaho.com/

[2] https://forja.rediris.es/projects/cusl6-abreforja/

Saludos a todos.