OpenSource

Proyectos Open Source en TFGs

Cada año en la escuela de ingeniería de Bilbao, los alumnos de 4º de Ingeniería Informática deben desarrollar su TFG. Muchas veces el proyecto consiste en implementar algún tipo de aplicación, normalmente desde 0. Algo que no cuadra con lo que se encontrarán ahí fuera…

Suele haber trabajos muy buenos pero la gran mayoría termina en los cajones de la biblioteca (repositorio online ADDI) https://labur.eus/MsIOT. Este curso 2019/2020 decidí cambiar ese destino.

La idea era convencer a tres alumno/as brillantes para que su TFG estuviera dirigido a mejorar una aplicación de código abierto usada a nivel internacional: https://github.com/bardsoftware/ganttproject…@GanttProject

Tres alumnos/as (Oihane, Anaitz y Urtzi) dieron el paso y han estado trabajando duro para corregir errores de la lista de bugs:

https://github.com/bardsoftware/ganttproject/issues

Este mes Oihane ha presentado su TFG con los resultados (9.8! 💪). Trabajar para mejorar una aplicación de software libre nos ha traído múltiples beneficios, tanto a los alumnos como al profesor. Y también el propio proyecto se ha visto beneficiado. Por múltiples razones:

Lo primero que han aprendido es a trabajar con el flujo de trabajo GitHub Flow https://guides.github.com/introduction/flow/… En concreto, cómo crear un fork, cómo mantenerlo actualizado con upstream, cómo crear ramas, generar Pull Requests al proyecto…

También aprenden a crear issues (documentar bugs o nuevas funcionalidades) y a discutirlos, a crear PRs y a hacer frente a los code-review 🙂

Deben persistir en el empeño durante días… Es fácil que un PR pueda llevar mucho más de lo esperado. Se acabó eso de “compila y funciona, ¡ya está!” No, ahora hay que pasar un control de calidad.

De hecho, aparte del code review, el código de los alumnos debe pasar los tests automáticos ejecutados por el sistema de integración continua de GanttProject.

Otro de los objetivos era crear documentación que realmente sirva en el futuro. En concreto, que sirva para que otros desarrolladores puedan empezar a contribuir con una curva de aprendizaje más suave que estos tres pioneros/as.

Me gustan los esquemas de diagramas de clase que han desarrollado de forma colaborativa

Y sobre todo, un tipo de diagrama al que no le sabemos poner nombre, pero que considero de los más importantes. Son pantallazos de la aplicación etiquetados con el nombre de las clases principales que implementan alguno de los componentes. Un ejemplo:

Esto, que puede parecer una tontería, es vital en un proyecto que contiene casi 800 clases Java y 95000 líneas de código.

Finalmente, el propio proyecto open source GanttProject también se ha visto beneficiado. Estos son los commits en la rama master de cada uno de los alumnos (que a su vez sirven para dar lustre a sus curriculum con posibilidad de verificación pública):

El curso que viene intentaré continuar con la idea. Y tal vez, extenderla hacia una asignatura (aunque me da vértigo, por el tiempo que requiere) en lugar de centrar los trabajos sobre OSS sólo en TFGs. ¿Alguien se anima a colaborar? 🙂

CENATIC: Software Libre y Administración

CENATIC nos recuerda, aprovechando el desarrollo de Tecnimap 2010, 10 razones por las que la Administración debería de liberar software:

1. Permite mayor eficiencia presupuestaria al ahorrar costes en el mantenimiento y en la evolución del software.
2. Cumple las recomendaciones de la Ley 11/2007, del Real Decreto de Interoperabilidad, y de las directivas europeas de la ISA.
3. Favorece la transparencia, la interoperabilidad, la independencia y la sostenibilidad de las aplicaciones de las Administraciones Públicas.
4. Desarrolla el ecosistema del sector TIC, garantizando la independencia de proveedores y su disponibilidad futura.
5. Pone conocimiento y activos a disposición de las empresas.
6. Contribuye a la reducción del déficit público, y fomenta el desarrollo de una economía basada en el conocimiento y la innovación.
7. Mejora la competitividad al fomentar la cooperación entre administraciones, universidades, centros de I+D+i y empresas, extendiendo buenas prácticas de compartición de conocimiento y fortaleciendo la innovación abierta.
8. Facilita la adaptación a las necesidades concretas de las administraciones, en materia lingüística, legislativa, de accesibilidad e imagen.
9. Garantiza la privacidad y la seguridad en el tratamiento de la información.
10. Permite Compartir, Reutilizar y Colaborar.

En definitiva: al liberar software, la Administración Pública reduce su déficit, aporta valor al sector privado, especialmente a las empresas TIC locales, favorece la competitividad y contribuye al desarrollo de una economía sostenible basada en el conocimiento y la innovación abiertos.

Free Technology Academy publica dos de sus libros en abierto

La Free Technology Academy es un campus virtual con módulos-curso que pueden ser cursados totalmente online.

Los materiales de estudio son recursos denominados «Open Educational Resources», se publican bajo licencias abiertas y pueden ser descargados gratuitamente. Los alumnos oficiales del curso, no obstante, tendrán a su disposición varios profesores, profesionales del área, de las distintas universidades que forman parte de la FTA:

* Free Knowledge Institute (FKI) – The Netherlands
* Open Universiteit Nederland (OUNL) – The Netherlands
* Universitat Oberta de Catalunya (UOC) – Spain
* University of Agder (UiA) – Norway

La FTA está financiada por el programa de Aprendizaje Permanente (Life Long Learning Programme – LLP -), y surge como una colaboración entre el FKI y las 3 universidades europeas citadas.

Hoy son noticia porque han publicado dos libros bajo licencias FDL y CC-by-sa.

El primero de ellos, «Introduction to Free Software«, ya lo conocíamos, dado que es una traducción al inglés del libro original en castellano «Introducción al Software Libre«, porJesús M. González-Barahona, Joaquín Seoane Pascual y Gregorio Robles como autores y Jordi Mas Hernández y David Megías Jiménez como coordinadores.

El segundo, «GNU/Linux Advanced Administration«,de Remo Suppi Boldrito como autor y Josep Jorba Esteve como coordinador, tampoco es nuevo, dado que es una adaptación y revisión del mismo curso publicado por la UOC en su momento.

Parece que ambos libros han sido actualizados por la FTA y servirán como base al master online que impartirán.

Buber Sariak, Premios Buber: gracias

Bueno, ayer fue un gran día: diariolinux.com fue votada y galardonada, en los premios Buber, como la web que mejor promociona el software libre. Muchas gracias a todos, en especial a los lectores fieles de este blog, que desde el 26 de Junio de 2001 siguen al pie del cañón. También, lógicamente, a todos los que han votado a favor, a la comunidad de amigos de DiarioLinux de Twitter, a los que incluso de animaron a acercarse a la entrega de premios y a toda la comunidad del software libre en general. Por supuesto, gracias finalmente al jurado de los premios, que al fin y a la postre, son los que han tomado la decisión final. Vuestros comentarios (en el blog y en persona) y muestras de apoyo son el combustible que hace que esta maquinaria avance y siga todos los días. Enhorabuena finalmente también al resto de candidatos, por su trabajo y dedicación. No abandonéis nunca.

No sé dónde dejar esta última nota, así que lo haré aquí: de todas las ponencias que hubo antes de los premios (dentro de la sección Datorrena 2010), no podéis perderos la que impartió Iker Sagasti, sobre «Internet y Valores». Nos tocó la fibra sensible y nos hizo reflexionar sobre la educación que recibimos en su día sobre valores y ética y lo que actualmente estamos llevando a la práctica. En muchas ocasiones hay una larga brecha. Como dice la madre de Iker: «Eres lo que haces, no lo que dices». En cuanto publiquen el vídeo del evento, pondré el enlace, para que esa ponencia no se pierda en el olvido.

PD: gracias a @damoto por la imagen que acompaña a este post 🙂

Por las noches veo zombies…

¿Qué es un proceso zombie (zombi según la DRAE) en Unix? Según la Wikipedia, es un proceso que ha completado su ejecución pero aún tiene una entrada en la tabla de procesos, permitiendo al proceso que le ha creado leer el estado de su salida. Metafóricamente, el proceso hijo ha muerto pero su «alma» (el valor de retorno de la operación) aún no ha sido recogida.

Vale. Y entonces, ¿qué es un proceso zombi? (como dirían mis alumnos tras una explicación «de libro») 🙂 Lo mejor es verlo con un ejemplo sencillito programado en C:

#include <stdio.h>
#include <stdlib.h>
 
int main()
{
 pid_t pid;
 
if ((pid = fork()) < 0)
        exit(1);
else if (pid == 0)
        exit(0);
 
sleep(120);
exit(0);
}

Nota: para compilar, guarda el código anterior en prueba.c y compila así: gcc -o prueba prueba.c

En la línea 8 se hace un fork(), es decir, el proceso actual (padre) genera un nuevo proceso (hijo). Ambos son «idénticos» (mismo área de código, datos, mismos identificadores de canal abiertos, etc.) y se ejecutan en paralelo (sí, con una sola CPU ese paralelismo es una mera «ilusión óptica» 😉 . La instrucción fork() devuelve un identificador -1 si ha habido algún error en la creación del hijo. Si la génesis (proceso de formación del proceso hijo) fue correcta, en la línea 10 tanto el proceso padre como el proceso hijo preguntan por el identificador devuelto por fork(). Aquí sí que hay una diferencia: al proceso padre, el sistema operativo le devolverá el PID de su proceso hijo. Al proceso hijo, el s.o. le devolverá un 0.

Así que la línea 11 sólo será ejecutada por el proceso hijo. Y casualidades de la vida, esa línea es un exit(0). Así que el proceso hijo acaba de morir. Pero el proceso padre sigue, línea 13, y se suspende durante 2 minutos, desentendiéndose del hijo que acaba de morir. De hecho, el padre podría intentar recoger el resultado devuelto por el hijo (un 0) sincronizándose mediante una llamada al sistema wait(&resultado) pero no lo hace, está durmiendo la mona durante 2 minutos 🙂 Así que el proceso hijo, está «muerto», pero su «alma» (el resultado 0 que aún está disponible para el padre si éste lo quiere) aún no ha sido recibida por nadie. Así que el proceso hijo no ha terminado de morir «del todo». Está en modo zombie.

Podemos comprobarlo ejecutando «prueba» y pidiendo la lista de procesos:

$ ./prueba

Verás algo como lo siguiente:

$ ps auxww| grep prueba
juanan   12851  0.0  0.0   1624   296 pts/1    S+   14:58   0:00 ./prueba
juanan   12852  0.0  0.0      0     0 pts/1    Z+   14:58   0:00 [prueba] <defunct>
juanan   12862  0.0  0.0   3236   792 pts/2    R+   14:58   0:00 grep prueba

La (Z) es indicador de modo zombie en el proceso. El padre (PID=12851) está durmiendo (S).