Hoy arrancamos una nueva iniciativa en Agrobits. Una sección de entrevistas para ilustrar la relevancia de los sistemas de información y el desarrollo de software en la investigación agraria y alimentaria. Para esta primera edición, y aprovechando que estamos a punto de celebrar por segunda vez el Global Sprint de Mozilla Science Lab, hemos invitado a nuestro compañero, y sin embargo amigo, Eduardo López Senespleda a que nos cuente su experiencia.

Agrobits - Buenos días Eduardo, bienvenido a Agrobits. ¿Podrías contarle a nuestros lectores quien eres y a qué te dedicas?

Eduardo - Hola, buenos días Antonio. Pues soy un ingeniero de montes, doctor, pero ante todo una persona muy familiar (y padre orgulloso) además de friki. Trabajo en el CIFOR, como tecnólogo, principalmente en labores de apoyo a la investigación. Estoy especializado en ecología y suelos forestales. Y entre otras cosas, también trato de dar rienda suelta a mi afición por la tecnología aplicándolo, siempre que me resulta posible, a mi trabajo. Por ejemplo, con el desarrollo de “artilugios” usando software y hardware libre (concretamente Arduino). Últimamente estaba tratando de elaborar y calibrar unas sondas de humedad edáfica, entre otras cosas que tengo en mente.  

A - ¿Cuánto tiempo llevas trabajando en el INIA?

E - Entré en esta casa allá por el año 2003, de la mano de mi mentor, recientemente jubilado, Gregorio Montero. Gracias a él conocí esta profesión antes de iniciar mis estudios universitarios, profesión que me enamoró y que, todavía a día de hoy, me fascina. Luego tuve la inmensa suerte de conocer y trabajar con Otilio Sánchez Palomares, también ya jubilado hace tiempo. Él me encaminó hacia la ecología forestal y los suelos forestales. Aunque fue profesor mío en la carrera, no fue hasta llegar aquí que descubrí la enorme faceta personal y profesional que escondía, siendo posteriormente uno de mis directores de tesis. He de decir, que me considero tutelado en mi camino por el INIA por dos de los mayores profesionales, cada uno en su campo, que creo que ha habido. Dos de los “grandes” forestales.

A - ¿Cómo describirías tu relación profesional con los sistemas de información y/o con el desarrollo de software?

E - Mis padres tuvieron el acierto de hacer el esfuerzo y comprar un ordenador cuando yo era pequeño, uno de los primeros Amstrad CPC 464, donde hacía mis pinitos en BASIC. Posteriormente me regalaron un PC de la casa Bull, con procesador 8086 y doble disquetera de 5 ¼ y sin disco duro, en el que había que cargar el MSDos en memoria al arrancar. También eché horas delante de este aparato. Mi padre, radioaficionado e ingeniero frustrado pero con una enorme afición por la electrónica, decidió montar una vez un PC que fuimos comprando por componentes, comprados mes a mes. Así tuvimos nuestro primer PC con procesador Intel 486 … a partir de ahí, siempre me han acompañado los ordenadores… Profesionalmente, casi toda mi actividad está ligada a los datos y el software para procesarlos y exprimirlos. Considero que tengo facilidad para aprender y utilizar lenguajes de programación, pero la mayor parte de las ocasiones son para usos muy puntuales.

Pantalla de presentación del programa PINARES original

Hace ya casi diez años que mi amigo Rafael Alonso y yo hablábamos en nuestras tertulias compartiendo ubicación en “la cueva”, aquí en el INIA, sobre el desarrollo de un programa que nos facilitara todos los cálculos que hacíamos con frecuencia. Una especie de programa “Pinares” como el antiguo desarrollado por Gandullo y Sánchez Palomares, para asistir a los gestores forestales en la toma de decisiones. Y en nuestros delirios imaginábamos cada vez más funcionalidades a dicho programa…. Hasta ahora. El equipo de personas que participaron y participan en su desarrollo está formado por ingenieros de montes e informáticos. Los primeros (Rafael Alonso, Gregorio Montero y yo mismo) damos las pautas, explicamos los algoritmos, traducimos “nuestro” lenguaje. Los segundos, Álvaro Calleja en una fase inicial, pero  sobre todo Fernando Cavero son los encargados de darle forma.

Pantalla de presentación del actual ModERFoRest

Ahora mismo estamos envueltos en la ardua tarea de terminar tal programa: ModERFoRest (Modeling Environmental Requirements for Forest Restoration). A ver, yo no soy programador, pero puedo comunicarme y entenderme con Fernando, y así vamos tratando de resolver, en conjunto, las vicisitudes por las que va pasando ModERFoRest.

La ortografía de ModERFoRest se ganó este meme durante las jornadas

A - El año pasado, participaste en la edición madrileña del Global Sprint de Mozilla Science Lab con este proyecto. Cuéntanos en qué consiste, y qué te llevo a participar.

E- ModERFoRest es un programa que inicialmente está pensado para asistir a los gestores forestales en la toma de decisiones sobre la consideración de especies forestales en planes de repoblación, de restauración, de gestión adaptativa, etc. El software implementa dos algoritmos, con propiedades distintas, para la estimación del nicho y de las correspondientes áreas potenciales de expansión, en función de las condiciones climáticas y edáficas. Incluye las principales variables predictoras para 18 especies forestales arbóreas, frondosas y coníferas. El lenguaje de programación es C++, y el entorno de desarrollo es Qt. ModERFoRest incluye librerías de código abierto como Armadillo para el cálculo de álgebra matricial, y posee licencia GPL3.

ModERFoRest estaba inicialmente pensado para ser descargado e instalado en el ordenador del usuario, aprovechando la capacidad de cálculo que tuviera su ordenador. Pero las dificultades que aparecían una y otra vez en la compilación para su uso en plataformas Windows hizo que Fernando y yo acudiéramos al Global Sprint del año pasado, a la edición de Madrid que organizaste. Íbamos, sobre todo, con la intención de darlo a conocer y tratar de “enganchar” a alguien en el proyecto, alguien que pudiera darnos una pista o echar una mano con dicho problema.

A - ¿Y consideras que se cumplió ese objetivo?

Sí, en gran medida. Por desgracia llegamos tarde a la presentación por video conferencia, y no pudimos darle la difusión global deseada. Pero sin duda fue satisfactorio, dando un nuevo soplo al proyecto.

A - Y tanto un nuevo soplo. Un nuevo soploEl impacto de esa jornada va a afectar incluso a la arquitectura y modo de distribución de la aplicación, ¿no es cierto?

E - Efectivamente, de la interacción con los asistentes surgieron ideas que fraguaron en la cabeza de Fernando y han transformado el concepto del programa. En su concepción inicial tenía una arquitectura en la que era un archivo descargable y que debía instalarse en el ordenador. Actualmente se ha derivado hacia el concepto de servicio web. En este caso, el usuario, una vez registrado (de forma gratuita), puede cargar sus datos y definir las opciones de cálculo y las salidas que desea. El servicio es diferido, es decir, no tiene que permanecer conectado hasta que obtenga los resultados. Cuando todo esté preparado, recibirá un correo electrónico en el que se le avisa de que ya están disponibles los resultados para su descarga y análisis. Creo que eso, unido a otras cuestiones va a dotar de una gran flexibilidad al proyecto. 



A - ¿Volveríais a participar?

E - Sí, sin duda. Por mi parte no veo inconveniente alguno. Y seguro que Fernando comparte mi opinión.

A - Pues falta muy poco para activar la nueva convocatoria, ¡reservad el 1 y el 2 de junio!. ¿Quieres añadir algo? ¿Qué te deberíamos haber preguntado?

E - Poco más, sólo añadir un último comentario sobre el desarrollo de soluciones en investigación con Arduino. Creo que este tipo de plataformas pueden ser de gran utilidad en organismos como éste. Es más, creo en la necesidad de tener un laboratorio “tecnológico” en el CIFOR, del tipo que alguna vez me ha comentado Jorge García, compañero nuestro y sobre todo tuyo, que dirigía en el Instituto Carlos III. Un laboratorio que permita obtener soluciones a problemas concretos de la investigación en campo que desarrollamos. Creo que tenemos gente motivada y cualificada para ese desempeño, sólo hay que darles la oportunidad de ponerlo en práctica.

¿CIFORlab?, ¿INIAlab?, ... eso se merece otro meme

A - Y por último, no lo haremos público para no poner a nadie en un compromiso pero, ¿a quién deberíamos entrevistar en la próxima entrega?

E - ...

A - Tendréis que esperar a nuevas edidciones de estas entrevistas para conocer su interesante respuesta 2x1. Muchas gracias Eduardo, hasta la próxima.

E - Muchas gracias a ti por la oportunidad. Seguimos en contacto para ir a la nueva edición de este año del Mozilla Science Lab.

Agrobits - Y eso ha sido todo por esta edición, espero que os haya resultado interesante. Y por supuesto si queréis participar con vuestros proyectos software, o queréis recomendarnos a alguien para entrevistarlo, ¡no dejéis de poneros en contacto! Hasta el próximo agrobits.

cifor-inia

El pasado día 8 de febrero tuvo lugar en el aula de informática del INIA un taller de introducción para los usuarios del INIA que comenzarán a utilizar el supercomputador Finis Terrae II del Centro de Supercomputación de Galicia (CESGA), en base al acuerdo/contrato entre nuestras organizaciones.

Pablo Rey y Aurelio Rodríguez del CESGA viajaron desde Santiago de Compostela, y en un programa apretadísimo nos explicaron la arquitectura del supercomputador, los modos en que pueden acceder los usuarios, el funcionamiento del sistema de colas para los trabajos de cálculo y algunos conceptos de computación paralela para el uso de las aplicaciones en sistemas con múltiples núcleos (cores).

La recepción fue muy buena por parte de los investigadores y técnicos del INIA. Tuvimos un lleno completo de la sala de informática, incluso algunas personas se quedaron sin poder asistir. Los participantes vinieron del Departamento de Mejora Genética Animal y del CIFOR, en su mayor parte, y también del Departamento de Biotecnología.

Se resolvieron dudas generales, estrategias para la optimización de las tareas lanzadas y también dudas particulares para la instalación de aplicaciones específicas en el sistema.

Lamentablemente, olvidamos tomar una foto de los asistentes para ilustrar esta entrada.

Nota: los interesados en el curso pueden encontrar información sobre una versión semejante en la web del CESGA (https://www.cesga.es/es/actuais/ver_curso/id_curso/2311), y grabaciones en Youtube de un curso semejante al impartido en el INIA.

Primera parte:

Segunda parte:

INIA - Instituto Nacional de Investigación y Tecnología Agraria y Alimentaria, Madrid, España

Recientemente he publicado en mi blog un artículo con las ideas que me he traído tras asistir en Barcelona al 5th Workshop de LEARN-RDM, un proyecto europeo para la mejora de las prácticas de gestión de datos de investigación.

http://hoos.spadial.com/dmp/phd/rdm/2017/02/02/learn-rdm-5th-BCN-workshop.html

TL;DR; Para los que os de pereza leer todo, o el inglés no sea lo vuestro; aquí va el resumen de las ideas:

  • Domain Data Protocols. Se trata de un conjunto de prácticas recomendadas de gestión de datos recopiladas para una determinada disciplina. Permitirían mejorar el diseño y el reuso de los planes de gestión de datos.
  • Machine actionable DMPs. ¿Y si un programa de ordenador pudiera conocer el grado de cumplimiento de un plan de gestión de datos, y ayudarnos a su cumplimiento?
  • Institutional Data Policy vs Institutional Template for DMPs. Una política institucional de datos es un documento más abstracto y flexible, el que se encuadran los planes de gestión de la institución, incluyendo una hipotética plantilla o plan por defecto.

Os dejo con la mini entrevista realizada para la documentación del workshop:

 

Universitat de Barcelona - Edifici Històric

Hoy 10 de noviembre de 2016, hemos realizado un mini taller de desarrollo con Javascript para crear sitios de divulgación científica, tomando como base un ejemplo de nuestro compañero @jmadrigalolmo.

Este tutorial fue publicado originalmente en:

https://github.com/inia-es/semanaCiencia16_iiff

Un ejemplo de la herramienta final se encuentra en:

https://github.com/inia-es/semanaCiencia16_iiff_src

Explicaciones explorables

Explicaciones explorables es un término acuñado por el ingeniero y diseñador Bret Victor para referirse a un documento interactivo, de carácter científico-técnico, que explica determinado concepto dando la oportunidad al lector de explorar los cambios que ocurren en el sistema o proceso cuando se modifican algunas de las variables que lo controlan.

Las páginas web y las aplicaciones para móvil o para tablet son el lugar ideal para estas Explicaciones Explorables, pero no significa que sea el único medio en el que se pueden construir. Una alternativa podrían ser los libros interactivos, con mecanismos simples de papel.

En este taller vamos a ver como podemos construir una sencilla web que nos ayude a explicar la relación que hay en un incendio forestal entre el material inflamado, la velocidad de propagación del fuego, el tamaño de la llama, y los medios de extinción más adecuados en cada caso.

Para ello construiremos progresivamente una página web interactiva con Javascript.

Estructura básica de una página web

Como algunos sabréis las páginas web están escritas en lenguaje HTML. La estructura más básica que podemos construir es:

Antes de seguir creemos un fichero llamado en una carpeta adecuada de nuestro ordenador, y copiemos o mejor, escribamos en él, el código de ejemplo. Después podemos abrir dicho fichero con nuestro navegador, y podremos ver el resultado de la página web.

HTML es un lenguaje de etiquetas. Cada sección del documento está comprendida entre una etiqueta de apertura y su correspondiente etiqueta de cierre .

Las etiquetas y limitan el princpio y el final del documento. También podemos ver que el documento se divide en dos secciones principales, una limitada por la etiqueta donde se indican aspectos de configuración de la página web; y otra limitada por la etiqueta donde está el contenido de la página propiamente dicho.

En este taller pasaremos de puntillas sobre muchos aspectos de HTML. Los interesados en profundizar en esta materia pueden seguir la documentación de MDN (Mozilla Developer Network): https://developer.mozilla.org/es/docs/Learn/HTML

Introducción a Javascript

Desde que el navegador Netscape incluyera por primera vez la posibilidad de ejecutar código Javascript en 1995, este lenguaje se han convertido en el estándar para desarrollo en el lado del cliente de la web.

Javascript tiene una sintáxis de la familia de C, similar a la de muchos lenguajes populares como C, C++, Java o PHP. Para incluir código Javascript en nuestra página web hacemos uso de la etiqueta .

La etiqueta puede ser incluida tanto en la sección como en la sección . Puesto que los ficheros HTML se ejecutan conforme son leídos, colocar el bloque al final de la sección , da ciertas garantías que el contenido completo de la página web ha sido cargado antes de ejecutar el código.

Este ejemplo ejecuta la función que indica al navegador que queremos mostrar un aviso, que requiere la aprobación ('Aceptar') del usuario antes de continuar.

Busquemos un aliado: Firebug

Firebug es un plugin de Firefox que facilita el desarrollo de páginas web y aplicaciones. Se instala fácilmente desde el gestor de complementos de Firefox. Una vez instalado, Firebug aparece con el icono de un pequeño insecto en la barra de herramientas del navegador.

La suite de Firebug tiene distintas herramientas que nos facilitan el trabajo de desarrollo: Consola, HTML, CSS, Script, DOM, Red y Cookies.

La herramienta Console nos mostrará los mensajes de error que genere nuestro código Javascript, pero también podemos acceder a ella haciendo uso del comando .

También es posible escribir código Javascript directamente en la consola, lo que la hace una manera ideal de realizar pruebas y aprender interactivamente.

Un viaje rápido por Javascript

Este taller, por su brevedad, solo pretende mostrar algunas características generales de Javascript, y unos pocos de los detalles que lo diferencian de otros lenguajes de programación.

Podemos hacer el siguiente recorrido directamente en la consola que abrimos en la sección anterior:

Javascript tiene detalles bastante avanzados. Si os habéis fijado, las funciones son objetos que tienen algunas funciones incluídas por defecto, como . Por ejemplo, podéis hacer también . Estas características hacen que sea un lenguaje realmente muy flexible.

Una Explicación Explorable

Vamos a crear una sencilla página web, que muestre la fórmula de Byram y permita explorar su evolución con algunos valores para la velocidad de propagación y los materiales del incendio.

En primer lugar creamos una sencilla web con las fórmulas, los datos y un ejemplo de la parte explorable.

Hemos introducido un par de etiquetas nuevas, como

para construir la tabla de datos, o para dar enfásis. Además hemos creado añadido las ecuaciones en forma de gráficos GIF (usando la herramienta online https://www.codecogs.com/latex/eqneditor.php).

 

Para añadir las imágenes podéis descargarlas del sitio web (https://github.com/inia-es/semanaCiencia16_iiff_src/tree/gh-pages/img). Este sitio web tiene todo el código de este ejemplo, pero si lo descargáis ahora arruinareis parte de la diversión.

Haciendo un sitio interactivo

Para esta parte del tutorial vamos a hacer uso de la librería Tangle. Podemos descargar los ficheros en http://worrydream.com/Tangle/download.html, y ponerlo en una carpeta de nuestro proyecto.

Ahora lo añadimos a nuestra web añadiendo:

a la sección de nuestra página web.

Ahora vamos a identificar la velocidad de propagación como un parámetro de entrada. Para ello vamos a modificar el texto por el siguiente código.

Y en la sección incializamos dicha variable:

# Generando valores de salida

Ahora vamos a hacer que el valor de longitud de la llama varie con la velocidad. Primero, identificamos la longitud de la llama como una variable del modelo, sustituimos por algo como:

Añadimos una función que calcule el valor de la llama. Vamos a usar una función de prueba, que nos permite probar el sistema interactivo. En el siguiente bloque usaremos la fórmula de Byram correctamente.

Y usamos esa función para actualizar el valor de en el modelo de Tangle:

Matemáticas en Javascript

Vamos a crear una función en Javascript para la fórmula de Byram. Es más fácil de lo que parece:

Ahora usaremos esta fórmula en nuestra función

Mejora estética

Vamos a mejorar un poco el aspecto de nuestro proyecto. En primer vamos a mejorar el aspecto de nuestra interfaz. Añadiremos parámetros a nuestro modelo para que admita decimales en la entrada y podamos darle un rango mínimo y máximo de valores, lo haremos con las etiquetas , y :

En segundo lugar vamos a dar formato a la salida, para poder ignorar los decimales que no necesitemos. Lo haremos con la etiqueta . Esta etiqueta formatea la salida haciendo uso de la descripción de formatos de la librería estándar de C (, , ...). Ver http://www.manpages.info/linux/sprintf.3.html

También vamos a mejorar el aspecto del sitio con Bootsrap (getbootstrap.com). Bootstrap es un framework CSS muy sencillo de utilizar para aquellos que no sabemos mucho de CSS, o no tenemos buena coordinación estética.

Guardamos los ficheros en la carpeta y luego los añadimos a la sección de nuestro HTML:

Para que Bootstrap dé una mejor estructura a nuestro contenido debemos poner todo el contenido entre las etiquetas:

Algunas etiquetas para mejorar el aspecto de nuestra tabla de datos:

Y un retoque (, , ) para mejorar el aspecto de nuestros resultados:

Para terminar la mejora añadimos la clase a las imágenes con las fórmulas:

Pocos dan tanto con tan poco esfuero.

Sofisticando el modelo

Hasta ahora hemos trabajado siempre con el mismo tipo de incendio, uno de pasto. Vamos a introducir ahora los otros tipos de incencios: matorral bajo y matorral alto.

Modificaremos para que sea una variable de entrada:

funciona como un selector horizontal como el que usamos para la velocidad. muestra solo uno de los valores contenidos según el valor que adopte la variable .

Ahora añadiremos la información de biomasa a Javascript, para poder usarla en la fórmula. Para ello usaremos un array:

Ahora solo nos queda introducirlo en la fórmula de Byram:

¡¡Enhorabuena!!, habéis construido vuestra primera Explicación Explorable.

Explicaciones visuales

Ahora vamos a añadir un elemento visual para mejorar la explicación.

Creamos una estructura haciendo uso de la capacidad de Bootstrap, para crear columnas. En cada uno vamos a insertar una imagen que explique el tamaño del incendio:

Cambiaremos el tamaño del incendio en función de la longitud calculada de la llama.

Vamos a añadir un identificador a la imagen que queremos modificar:

Para poder modificar su tamaño, creamos una referencia a este elemento en el código Javascript.

Calcularemos el tamaño del gráfico de la llama de manera proporcional al valor de longitud de la llama.

La longitud máxima de la llama en nuestro ejemplo es 24.07m. Como en cada navegador el tamaño del gráfico va a ser distinto, necesitamos averiguarlo en el código.

Ahora solo nos queda modificar la altura del fuego en la función update:

Hemos conseguido un tamaño de la llama interactivo, pero no es muy satisfactorio. Para hacer que las llamas crezcan hacia arriba, vamos a introducir un margen variable:

Para modificar la imagen de la recomendación, usaremos una estrategia parecida a la que hemos usado para modificar la llama, pero en lugar de modificar la propiedad mdificaremos la propiedad :

Y en Javascript creamos una función que seleccione la imagen para los distintos valores de longitud de la llama, y la aplicamos en nuestro update:

Buenas prácticas

Una vez que hemos llegado hasta aquí tenemos una aplicación interactiva que hemos intentado hacer atractiva para el público en general. Terminamos el tutorial con una pequeña mejora que no tiene repercusión funcional ni estética, pero mejora el diseño de la aplicación.

Vamos a evitar replicar los valores de biomasa en el código y en el HTML. Para ello tomaremos los valores de la tabla como origen de datos, y los utilizaremos en Javascript.

En primer lugar anotaremos los valores de la tabla con microdatos. Los microdatos describen más precisamente la información de una web, y permiten que sea explorada por buscadores con más información o utilizada por aplicaciones de terceros.

Usar microdatos es muy sencillo:

Para acceder a los valores usaremos la función que nos devuelve un elemento HTML. Para acceder a su contenido usamos su propiedad . Por último creamos una función que elimina la unidad de kg y nos devuelve un valor numérico.

La convocatoria de Reservistas Voluntarios 2016 busca 4 candidatos a oficiales del Ejército de Tierra con experiencia como analistas de incendios forestales, que tendrán destino en el Cuartel General de la UME en Torrejón de Ardoz.

La página web de ARES, la Asociación de Reservistas Españoles, describe la figura del reservista voluntario en los siguientes términos:

Los Reservistas Voluntarios somos españoles, mayores de edad, que ofrecemos nuestra disponibilidad a las Fuerzas Armadas de España para el caso en el que nuestros servicios fuesen necesarios a la Nación. Vestimos el mismo uniforme que los militares profesionales, con un distintivo específico de Reservistas Voluntarios, pero sólo nos  incorporamos por los períodos de tiempo que los ejércitos determinan en los planes anuales, que suelen ser cortos.


Ser Reservista Voluntario no es una profesión a tiempo completo, ni tampoco es una vía de acceso permanente a las Fuerzas Armadas. La mayoría de los Reservistas Voluntarios tienen una profesión civil a tiempo completo que compaginan sin problemas con su servicio en las Fuerzas Armadas.

Entre las 150 plazas convocadas el pasado 3 de octubre destacan las siguientes en el ámbito de nuestro portal Agripa:

  • 4 plazas de oficiales del Ejército de Tierra, con destino en el Cuartel General de la UME, formación como ingenieros de montes o equivalentes y se valorará la experiencia y estudios en incendios forestales y su análisis. Códigos: 50018, 50019, 50020 y 50021
  • 1 plaza de suboficial de la Armada, con destino en la Estación Naval La Algameca en Cartagena, con estudios de Técnico Superior en Medio Ambiente y Gestión Forestal. Se requiere el carné de conducir C. Código: 60014
  • 2 plazas de oficial en el Ejército del Aire, para Ingenieros de Montes, Agrónomos o Licenciados en Ciencias Ambientales, con experiencia en Gestión Medioambiental. Códigos: 70007 y 70008
  • 1 plaza de oficial de Cuerpos Comunes, para un Licenciado en Veterinaria, sin niguna especialidad particular. Código: 40015


Se trata de una oportunidad de reforzar la cooperación cívico militar, y de adquirir una nueva experiencia. Además de estas se convocan un total de 150 plazas, en diferentes especialidades y destinos.

En esta entrevista a Librado Carrasco, catedrático de la Facultad de Veterinaria de la Universidad de Córdoba, podéis echar un vistazo al interés que las especialidades agrarias, forestales o alimentarias pueden aportar a las operaciones de defensa. Creo que es un testimonio muy interesante y motivador.

Podéis conseguir más información en el BOE de la convocatoria (http://www.boe.es/boe/dias/2016/10/03/pdfs/BOE-A-2016-9032.pdf), y en la Subdelegaciones de Defensa de vuestra provincia.

TL;DR: Madrid joined Global Sprint of Mozilla Science last 2nd and 3rd june. We gathered a strong team of 6 people, and we helped two projects (ModERFoRest and Birding; both tools for environmental research) to set the ground to create future open source communities.

Como anunciaba hace unos días en estas mismas páginas los pasados 2 y 3 de junio se celebró el Global Sprint de Mozilla Science, un evento que une a investigadores, desarrolladores, bibliotecarios y otras personas interesadas en la ciencia abierta y el software libre para darle un impulso a proyectos de herramientas de software, de ciencia ciudadana, de contenidos de formación o de datos abiertos.

En el evento de este año han intervenido más de 320 participantes en más de 35 sedes; gracias a la colaboración de Medialab Prado, que nos cedió una sala de sus fantásticas instalaciones, en un tiempo record pudimos contar con una sede del evento en Madrid. Además también hubo sedes en La Orotava y Almería, siendo la primera vez que se participaba desde España. Podéis echar un vistazo al informe de resultados que han publicado los organizadores del evento.

Una vez conseguida la sede, mi segundo objetivo fue que la ciencia española, especialmente el INIA, participara con alguno de sus proyectos. Lo conseguimos con la colaboración de Eduardo López de CIFOR y Fernando Cavero, el programador del proyecto, con lo que ModERFoRest fue uno de los proyectos participantes en el evento global.

Con esto hubiera considerado un éxito nuestra participación, pero además conseguimos despertar el interés por el evento de gente fuera de nuestro ámbito. Como Mª Isabel Muñoz, que compartía con Eduardo el interés por el empleo de dispositivos Arduino de bajo coste como sensores de campo en actividades agroforestales. A su conversación se unió Jorge García, de nuestro área de informática, que aportó los conocimientos de electrónica y de diseño y desarrollo de dispositivos que trae de su larga experiencia en el Instituto de Salud Carlos III.

Aunque no tuvo tiempo de participar, se acercó a Medialab Juanjo Bazán que nos presentó la plataforma Alpha Research Base que pretende ser un punto de encuentro entre desarrolladores e investigadores para el desarrollo de software científico. Además resultó ser colega de uno de nuestros investigadores del INIA, con quien ha desarrollado el paquete Nimbus, que implementa el algoritmo Random Forest de selección genómica, también licenciado como software libre.

El viernes se sumó un segundo proyecto. Birding de Abel Serrano, un proyecto en su etapa inicial de desarrollo para el análisis de datos de sensores remotos en aves.

El trabajo sobre ambos proyectos fue similar, ampliar la documentación de los mismos para facilitar la incorporación de usuarios y desarrolladores al proyecto, es decir, preparar la tierra para cultivar una comunidad en torno al proyecto, gracias a las licencias de software libre. Ambos proyectos todavía necesitan más trabajo en este aspecto, pero estoy seguro que más pronto que tarde tendrán su fruto: que nuevos usuarios sean capaces de acceder a las herramientas, y que nuevos desarrolladores incorporen código, con nuevas características o detectando y corrigiendo los inevitables bugs.

Organizar el evento ha sido una experiencia muy satisfactoria, y estoy seguro de que servirá de germen a nuevas oportunidades para los proyectos participantes, y a otros que se quieran unir a nosotros en próximas convocatorias.

MediaLab-Prado, Calle de la Alameda 15, Madrid Spain

El Global Sprint de Mozilla Science Lab es un evento a nivel mundial que se celebra anualmente. En él, investigadores, programadores, bibliotecarios y el público en general se reunen para hackear (en el buen sentido del término) participando en el desarrollo de proyectos de ciencia abierta y datos abiertos.

El año pasado participé a título personal colaborando con algunos de los proyectos, cualquier apoyo supone un paso adelante para los mismos. Este año, gracias a nuestros amigos de Medialab Prado, contaremos con un espacio en Madrid donde reunirnos y poder compartir impresiones y apoyarnos mutuamente en nuestros proyectos.

¿Qué se hará?

El programa oficial del evento es sencillo. Basta registrarse en la página web, y puedes echar un vistazo a los proyectos que han solicitado participar en el evento. Puedes apuntarte para colaborar en cualquiera, pero también puedes traer tu propio proyecto; trabajar en su mejora y/o divulgación, buscar colaboradores y mejorar su publicación como software libre, datos abiertos, etc.

Este año hay cuatro ramas de proyectos: herramientas, ciencia ciudadana, formación y datos abiertos. Hay algunos muy interesantes: Ecodata Retriever o Content Mine , pero yo estoy deseando ver los vuestros.

Después nos reuniremos en Medialab Prado, no olvides traer tu portátil, y trabajaremos juntos en el desarrollo del proyecto de nuestro interés. Si los asistentes tienen interés puedo improvisar un taller de git, para el control de versiones del código fuente, de github como plataforma de colaboración en proyectos de software libre, o en general sobre el proceso de liberación de proyectos de software y desarrollo de las comunidades.

Cómo llegar a Medialab

Anímate

Apúntate ya en la web, las plazas son muy limitadas.

Si además estás interesado en traer tu proyecto es importante que lo comuniques cuánto antes, así podrá colocarse en la página web y atraer la atención de potenciales colaboradores. Si tienes dudas al respecto ponte en contacto con la organización (o conmigo).

Medialab-Prado, Calle de la Alameda, Madrid, España

Instalación de un proyecto open source con git

git nos va a facilitar la obtención del código fuente de nuestro proyecto con el comando

git clone https://github.com/pkp/ojs.git ojs

Debemos seguir encargándanos de aspectos como la conexión con una base de datos, o la configuración del servidor web.

Customización

A menudo necesitamos hacer modificaciones en el proyecto para ajustarlo a nuestras necesidades, en algunos casos es posible escribir un módulo o plugin que mantienen nuestro código a parte del núcleo del sistema, pero en otras ocasiones esto no es posible y debemos de modificar el código fuente del sistema que hemos descargado.

Al haberlo descargado con git clone lo tenemos bajo un sistema de control de versiones, podemos realizar las rectificaciones en una rama (git branch) para cada cambio que realicemos, y dentro de cada una de estas realizaremos los commit necesarios hasta que este disponible.

Una vez la característica funciona correctamente podremos volcar los cambios de esta rama en la rama principal de nuestro proyecto (master).

Actualización a una nueva versión

Antes o después, dependiendo del ritmo de actualización del proyecto aparecerá una nueva versión que incluirá tanto nuevas características que nos harán la vida más fácil, como corregirán algunos bugs y fallos de seguridad que nos conviene tener instalados en nuestro sistema.

Para incorporar el código a nuestro sistema solo tenemos que ejecutar el comando:

git pull origin master

Con lo que se descararán todos los cambios realizados desde la última vez, y se integrarán con los cambios que nosotros hayamos realizados.

Si nuestros cambios no afectan las zonas modificadas en la nueva versión git es muy capaz de mezclar ambos cambios. Sin embargo si los desarrolladores del proyecto han introducido cambios en las mismas líneas que nosotros git no sabrá tomar una decisión sobre cual es la versión adecuada, por lo que marcará el bloque (hunk) como un conflicto y nos dará una alerta.

All terminar el proceso de pull revisaremos los conflictos, y decidiremos qué versión del código es la más adecuada, la que nosotros escribimos o la que han introducido los desarrolladores de la rama principal del proyecto. En ocasiones, tendremos que reescribir el código de forma que incorpore ambos cambios a nuestro proyecto; pero en la mayor parte de los casos se tratará de unas pocas líneas.

Contribuciones de código fuente

Supongamos que hemos hecho una modificación del código fuente que puede ser útil a todos los usuarios del mismo, cómo la correción de un bug. Con git podemos contribuir la reparación de vuelta al código fuente, y nuestro cambio quedará siempre acreditado, lo que puede ser útil para un curriculum como programador.

 

 

Instituto Nacional De Investigaciones Agrarias, Avenida Padre Huidobro, Madrid, España

Uno de los aspectos a estudiar durante el análisis de la gestión de datos de investigación en el INIA son las reticencias, problemas o desventajas que encuentran los investigadores a la hora de compartir sus datos. La mayoría son los esperados, y comunes a la mayoría de las áreas de investigación:

  • Pérdida de competitividad (al permitir el acceso a investigadores "rivales").
  • Falta de reconocimiento al tiempo dedicado a su publicación.

Un problema que no esperabamos es el del anonimato. En algunos campos de investigación, los científicos pueden acceder a información o realizar experimentos o medidas con la condición que los datos no se hagan públicos. Pensemos en el caso de estudios médicos en el que los pacientes no quieren ser identificados, pero el problema es extensible a estudios financieros, comerciales, de seguridad informática, de producción animal, ... Los colaboradores (enfermos, empresas, criadores) desean que se realicen estudios que les permitan un mejor conocimiento de su sector, y la solución a alguno de sus problemas; pero no desean que sus datos sean públicos. Si están dispuestos a que los datos sean públicos de manera agregada como parte de los resultados de la investigación.

Por otro lado, los investigadores de estos sectores podrían avanzar en su investigación si pudieran acceder a los datos que otros colegas hubieran publicado con anterioridad; pero que no han hecho por la limitación impuesta por sus colaboradores.

Esto me ha llevado a pensar durante un tiempo en estrategias para anonimizar los datos científicos. Mi idea general es la de un sistema que mantiene la información individualizada, pero que usa una colección de claves públicas y privadas por dataset de manera que aún accediendo a los datos no se pueden relacionar con los de otras tablas. Por otro lado, el sistema es capaz de devolver datos agregados conforme a unas restricciones (temporales, espaciales, de volumen de la información utilizada) de forma que los usuarios pueden realizar consultas agregadas sin acceder a la totalidad de la información. Un sistema de este tipo, si bien está descrito a muy alto nivel, garantiza:

  • el anonimato, al no poder identificar los registros de los dataset con los individuos del estudio
  • la reusabilidad, al almacenar la información particular de los individuos, y ofrecer un sistema de consultas agregadas con tablas de otros datasets.

Por el momento, no he encontrado un sistema con estas características, aunque he descubierto el trabajo de DNAdigest, una organización británica sin ánimo de lucro dedicada a promover que los investigadores publiquen y compartan los datos genéticos de sus estudios, mientras se mantiene la privacidad de los individuos participantes.

La aproximación que hacen al problema viene descrita en el workshop que impartieron en septiembre de 2013 es similar a la que había pensado, aunque más génerica si cabe, ya que plantea una API, una interfaz común que permitiría el acceso a diferentes repositorios de información (genética en este caso) manteniendo la confidencialidad de los participantes.

Supongo que es el momento de averiguar cuál es el estado de desarrollo de este sistema y cómo podemos implementar dicha API en la estrategia de gestión de datos de investigación del INIA, de forma que nuestros investigadores puedan sacar el mayor partido de compartir los datos de investigación manteniendo la confidencialidad y el anonimato de los socios participantes.

Y los lectores de este blog, ¿pensáis que os podéis beneficiar de un sistema de este tipo, accediendo a la información pertinente de otros estudios sin necesidad de un acceso a los datasets completos? ¿habéis sufrido casos en los que sabéis que existen estudios que podrían ayudar a confirmar los vuestros, pero no es posible acceder a sus datos experimentales por estos motivos? ¿cómo lo habéis resuelto? ¿cómo compartis vuestra información cuando se os requiere en uno de estos casos? ¿en que casos lo hacéis? Dejad vuestras experiencias e ideas en los comentarios de la página.

Instituto Nacional De Investigaciones Agrarias, Avenida Padre Huidobro, Madrid, España

El martes 28 de julio me acerqué a las instalaciones del Campus Madrid de Google para dar una charla sobre git a los amigos de H4ckademy. H4ckademy es un programa de formación de desarrolladores a través de un proyecto que les ayuda simultáneamente a crear un portfolio y a ponerse al día con herramientas y buenas prácticas en el desarrollo de software moderno.

La charla fue de un nivel muy introductorio, pero se estableció al final un turno de preguntas bastante interesante.

Aquí tenéis un acceso a las transparencias que utilicé:

http://slides.com/ajspadial/git-a-life

Y los comentarios y fotografías que han compartido en las redes sociales:

Para el desarrollo de la charla he usado material del manual de git, y de la introducción a git de Software Carpentry. Creo que la charla tiene potencial para transformarse en un curso/taller introductorio de git. La charla estaba orientada a gente que quiere dejar de sentirse como en:

"Piled Higher and Deeper" by Jorge Cham
www.phdcomics.com

Y vosotros, ¿os habéis sentido alguna vez como el estudiante del cómic? ¿Creéis que un taller de este tipo os puede ser de utilidad en vuestro trabajo con código u otras fuentes? Deja un comentario y cuéntanos cómo te pueden ayudar estas herramientas.

Calle Moreno Nieto, 2, Madrid, España
git
7/23/2015 10:06:06 AM

El grupo de investigación EC3, de la Universidad de Granada, ha publicado el informe de impacto de las revistas científicas españolas según el índide h correspondiente al periodo 2010-2014, y la revista SJAR encabeza la sección de revistas agrarias.

Instituto Nacional De Investigaciones Agrarias, Avenida Padre Huidobro, Madrid, España

Crosscheck es un servicio que ayuda a detectar plagios en artículos científicos. Funciona como una gran base de datos con artículos de un gran número de revistas científicas, de forma que al chequear un artículo puede buscar patrones o similitudes con otros artículos existentes.

Cuando te registras en Crosscheck lo primero que realiza es la carga en su base de datos de todos los artículos de nuestras revistas, en el caso del INIA Forest Systems y Spanish Journal of Agriculture Research, que gestionamos usando Open Journal System, una plataforma de gestión de revistas científicas desarrollada por Public Knowledge Project.

Para que Crosscheck pueda realizar la indexación es necesario que añadamos metadatos a nuestros artículos de forma que Crosscheck sepa donde encontrar el fulltext de los artículos.

Para añadir estos metadatos seguimos los siguientes pasos descritos en el foro de OJS.

Por otro lado debemos enviarles una tabla CSV (comma separated values) con los DOIs de todos los artículos de nuestra revista en una columna, y los enlaces a la versión fulltext de los artículos en otra, bien sean estos HTML o PDF.

Para obtener este listado debemos realizar la siguiente consulta en la base de datos de nuestra revista:

```sql

SELECT

    setting_value AS doi,

    CONCAT('/index.php/nombre_revista/article/', IF(ag.label = 'html', 'view/', 'download/'), a.article_id, '/', galley_id) AS url

FROM articles a

LEFT JOIN article_galleys ag

    ON a.article_id = ag.article_id

LEFT JOIN article_settings `as`

    ON a.article_id = `as`.article_id

WHERE `as`.setting_name='pub-id::doi'

    AND ag.label='pdf'

INTO OUTFILE 'crosscheck_revistas_inia.csv'

    FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';

```

Con esto tendríamos todos los artículos de nuestras revistas indexados en Crosscheck, y estaríamos preparados para la detección de plagios. Esperemos que no sea necesario todo esto, pero nunca se sabe.

¿Y vosotros lectores? ¿Cuál es vuestra experiencia con el plagio? ¿Habéis sido plagiados? ¿Qué ocurrió? O tal vez uno de estos sistemas automáticos de detección de plagio os acusó injustamente y retrasó vuestra publicación. Dejad vuestras experiencias en los comentarios. Hasta la próxima entrada.

 

Instituto Nacional De Investigaciones Agrarias, Avenida Padre Huidobro, Madrid, España

Como ya os conté acabamos de publicar la aplicación AlcornoqueWeb; y como en todo lanzamiento hemos ido descubriendo algunos detalles que era necesario pulir.

Mientras @mariolasg se encargaba de mejorar algunas de las visualizaciones, yo me encargaba de algunos detalles técnicos, como la conexión con la base de datos, el servidor de correo, o añadir un pequeño desplegable con la descripción del proyecto.

Configuración inicial

Así que lo primero que hice fue copiar el código en mi ordenador, y crear un repositorio git.

git init

Ahora añado todos los ficheros de la carpeta al repositorio, y declaro el estado inicial del sistema.

git add .

git commit -m 'First commit.'

Y empiezo a trabajar, haciendo mis commits para cada cambio que realizo en la aplicación. Al cabo de unas horas éste es el aspecto que tiene mi historial de trabajo.

Conflicto

Como en un buen western después de una situación inicial idílica, aparece el conflicto. Al día siguiente, recibo un fichero .rar con la nueva versión de AlcornoqueWeb que ha hecho su autora. 

En un escenario normal, yo debería ir echar un vistazo a todos los ficheros comprobando en cuáles ha realizado cambios Mariola, en cuáles he realizado cambios yo, e ir discriminando con cuáles quedarme, y después analizar cuidadosamente aquellos ficheros en los que hayamos hecho cambios los dos para incorporar sus cambios sin perder ninguno de los que yo he hecho.

Pero ¿por qué voy a hacer yo el trabajo sucio cuando tengo un sistema de control de versiones como git? Sin miramientos copio los ficheros que me han mandado en el repositorio, machacando los existentes, que como con los cátaros ya se encargará git de discriminar entre justos y pecadores.

Así que abro el explorador de git, para ver qué ha ocurrido en el proyecto.

A la izquierda tengo el listado de los ficheros en que la versión que me ha enviado difiere de la mía. Para cada fichero, en la parte derecha me muestra en color roja las líneas que ella ha eliminado con respecto a la versión anterior del fichero (la mía), y en verde las que ella ha añadido.

No tengo que revisar los ficheros enteros, porque git ya se encarga de seleccionar y resaltar las secciones en las que ambas versiones divergen.

Puedo ver que en algunos casos mi compañera me ha enviado la versión anterior de los ficheros, previa a mis cambios. En esos ficheros usaré el comando git checkout -- para volver a mi versión.

A continuación hecho un vistazo a los ficheros en los que ha trabajado Mariola. En unos casos, son ficheros en los que yo no hice ningún cambio, así que no tengo más que aceptarlos. Al fin y al cambo hay que confiar en los compañeros. git add <nombre_del_fichero lo marca como listo para añadirlo al siguiente commit.

En otros casos se trata de ficheros donde los dos hemos hechos cambios. En esos casos quiero añadir la versión de mi compañera sólo en las secciones (hunk) donde ha trabajado ella, y permanecer con mi versión en las partes con mis cambios. Para estas selecciones detalladas hago uso de la opción Stage Hunk for Commit de la herramienta visual de git.

Ya casi hemos terminado, me faltan unos ficheros en los que git sabe qué ha habido cambios pero no sabe en qué consisten. El motivo por el que git no ve los cambios es que se trata de ficheros binarios de imágenes, y git sólo es capaz de analizar ficheros de texto. Sin embargo, como son unos ficheros que yo no he tocado sé que es la nueva versión la que debe ser incorporada. Unas llamadas más a git add <nombre_del_fichero y la revisión ha sido completada.

Desenlace

El último paso es incorporar los cambios con git commit -m 'Simulation update (by @mariolasg). Fijaros que al incluir un mensaje en cada commit más adelante podremos saber qué cambios se hicieron en ese paso, sin necesidad a priori de tener que entrar en el código.

El proceso ha sido muy sencillo, pero hubiera sido totalmente automático si mi compañera utilizara también git, ya que el sistema sabría identificar en qué puntos hemos hecho cambios desde una versión ancestro común. Además en ese caso no sería necesario decir el autor en el texto del  commit ya que el propio git se encarga de incorporar esa información tan útil.

Llegamos al final de esta historia y al contrario que en las películas del Oeste este repositorio no era demasiado pequeño para los dos. ¿Qué os ha parecido? ¿Creéis que git podría ser útil para vuestros proyectos de software? ¿O para otro tipo de trabajo colaborativo? ¿Tenéis alguna duda sobre el mismo? Dejad un comentario y podemos discutir como podéis sacar provecho de este tipo de herramientas.

Instituto Nacional De Investigaciones Agrarias, Avenida Padre Huidobro, Madrid, España

Es duro cuando los chicos se van de casa. Has pasado los últimos 35 años ocupándote de ellos, así que el día que deciden abandonar el nido no puedes dejar de pensar si serán capaces de arreglarselas por sí mismos, no se meterán en líos, y recordarán los sabios consejos que les has ido dando con el paso de los años, ¿porque lo has hecho, verdad?

Con el software ocurre algo parecido. Hablo en este caso de los proyectos pequeños. Esos programas que uno escribe para sí mismo, probablemente como herramienta para una tarea más sofisticada. Tal vez lo compartes con uno o dos colegas, o permites que la gente lo use a través de una web, o incluso lo descargue y lo instale en sus ordenadores. Sin embargo, controlamos el código fuente de los mismos, y normalmente no necesitamos compartirlo.

Sin embargo, a poco que el proyecto madure (y no le pasé como al bueno de Chris Elliot en Búscate la Vida) llegará un día en que compartirás el código con otros programadores. Bien porque quieres que te ayuden con algún aspecto oscuro de una librería, bien porque alguien se ha ofrecido a darle un aspecto moderno a la página web, o simplemente porque el asunto ha crecido demasiado y uno solo no tiene tiempo suficiente para el mantenimiento.

Lo más habitual es que los nuevos desarrolladores trabajen en el proyecto simultáneamente. Y ahí empieza la pesadilla del padre (bueno, y de todos los participantes), cuando tratan de adivinar sobre qué versión tienen que realizar los cambios al sistema de gestión de usuarios, o tienen que esperar días a que alguien termine sus cambios en el algoritmo de visión por computador para añadir la correción de un bug, que un usuario nos ha reportado desde otro centro de investigación.

Por momentos parece que estamos perdiendo el control. El control de las versiones de nuestro software. Pero afortunadamente hay una solución para esto, los sistemas de control de versiones. Y git destaca entre ellos por su potencia, transparecia y facilidad de uso. Lo digo en serio.

¿Qué es git?

git es un sistema de control de versiones escrito en el año 2005 por un chico muy listo:

Este tío tan sexy es Linus Torvalds, y además de ser el pionero del desarrollo del núcleo del sistema operativo GNU/Linux (que lleva su nombre), fue el creador de este sistema de control de versiones, que es probablemente el más popular en su categoría.

Hasta que se desarrolló git, un sistema de control de versiones era una herramienta profesional que requería de conocimientos técnicos para su instalación y de unos protocolos cuidadosos para su uso diario. Estos protocolos hacían que todos los participantes en el sistema tuvieran que usar un repositorio centralizado, y tuvieran que advertir a sus compañeros de las acciones que iban a realizar sobre el mismo para evitar conflictos.

Linus creo un sistema distribuido, y bastante fácil de usar. Y no es que lo diga yo. Es que a día de hoy es utilizado incluso fuera del ámbito del desarrollo de software para cualquier tipo de trabajo colaborativo. No evita todo los conflictos, algo imposible en cualquier trabajo en equipo, pero git hace casi todo el trabajo sucio

Un vistazo a git

En el próximo artículo del blog contaré como he usado git recientemente para sincronizar un código en el que estabamos trabajando dos personas simultáneamente.

Customización de proyectos libres con git

Igualmente, dedicaré a esto un artículo específico, pero imaginad que git me servirá para hacer modificaciones particulares en un proyecto de software libre sin miedo a perder la posibilidad de mantenerme al día con las actualizaciones que se hagan por los desarrolladores oficiales del mismo, como parches de seguridad, etc.

Conclusiones

¿Y vosotros lectores, cómo controláis las versiones del código qe escribís? ¿Usáis un sistema de control versiones? ¿Mantenéis una miriada de carpetas con nombres como program_01, program_02, program_02_(mayo), etc.? (yo lo he hecho en ocasiones :( ) ¿Os habéis enfrentado al reto de sincronizar estas versiones con otros desarrolladores, y sentido que dedicabáis más tiempo a saber en qué estado estaba el código fuente antes de realizar un cambio, que al desarrollo del propio cambio? Dejad vuestras experiencias, opiniones y dudas en los comentarios.

Instituto Nacional De Investigaciones Agrarias, Avenida Padre Huidobro, Madrid, España