Browsed by
Autor: Manuel Domínguez-Dorado

Instalando un broker MQTT doméstico (II)

Instalando un broker MQTT doméstico (II)

En el artículo anterior explicaba que quería usar un thin client Fujitsu Futro S450 como broker MQTT permanente para mi entorno local. Expliqué cómo hice varias actualizaciones al hardware para que pudiese correr un broker MQTT de forma más o menos holgada y por poco dinero. Y así quedó el tema. En el artículo de hoy explicaré los pasos para el cambio de sistema operativo y la instalación de la primera versión del broker MQTT, que dejaré funcionando con su configuración por defecto.

Un nuevo sistema operativo para el Futro S450

Me gusta Linux, no lo puedo evitar. Desde siempre. Me da igual una distribución u otra. Como comenté, ya había instalado Lubuntu 14.04 en el Futro S450, por lo que no debería haber problema para correo sobre él la última versión Long Term Support (LTS) de Ubuntu Server. No necesito interfaz gráfico (ni lo quiero, con tan pocos recursos).

Descargar la ISO de Ubuntu Server 16.04.1

El procesador del Futro S450 es de 64 bits, así que el primer paso para la instalación es la descarga de la ISO de Ubuntu Server 16.04.1 en su versión de 64 bits. Desde https://www.ubuntu.com/download/server se puede descargar la imagen ISO, aunque recomiendo el Torrent que va bastante más rápido (el torrent también se descarga de ese enlace).

Instalaré Ubuntu Server 16.04.1

Una vez tengamos la ISO descargada, o bien creamos un CD arrancable (Ubuntu Server cabe en uno) o bien creamos una versión arrancable en cualquier memoria USB. El Futro S450 no tiene CD y, aunque se puede utilizar un CD externo USB, es mucho más cómodo volcar la ISO directamente a un pendrive. Yo usé uno de 8 GB que tenía por ahí. Perderá los datos, así que aseguraros que es un lápiz USB de estos que se usan para andar por casa sin nada importante dentro.

Crear un USB arrancable de Ubuntu Server 16.04.1

En Linux hay multitud de formas de crear un USB arrancable a partir de una imagen ISO. Con comandos de toda la vida de Linux, como dd o cat, o con herramientas gráficas. Hacía tiempo que no creaba un USB de arranque a partir de una ISO, pero la última vez lo hice en Linux y utilicé la utilidad Unetbootin. Esta vez hice lo mismo, pero por alguna razón Unetbootin no estampa correctamente la ISO sobre el pendrive y el Futro S450 no lo detecta como un disco de arranque. Me di cuenta tras varios intentos. Así que opté por crear el USB a partir de la ISO de otra forma: utilizando la herramienta Discos de Ubuntu, que es la distribución que uso ahora mismo en mi estación de trabajo.

Herramienta “Discos” de Ubuntu, para crear el USB arrancable

Los pasos son:

  • Introducir el USB en el cual se quiere grabar la ISO.
  • Abrir la herramienta Discos y seleccionar de la izquierda el volumen correspondiente a ese pendrive (es importante, a ver si vas a volcar la ISO sobre tu disco duro en lugar de sobre el pendrive, jeje).
  • Arriba a la derecha en la ventana, expandir el menú y seleccionar “Restaurar imagen de disco”.
  • Seleccionar la imagen ISO de Ubuntu Server que hemos descargado.

Y ya está. Te preguntará catorce veces para asegurarse de que vuelcas la ISO en el pendrive y no en otro lado y luego pedirá la clave de root. Finalmente aceptamos para crear la imagen sobre el disco USB. Aparecerá una barra de progreso que nos indicará cuándo ha finalizado.

Arrancar e instalar Ubuntu Server 16.04.1

Una vez creado correctamente el USB de arranque, la instalación no tiene ninguna diferencia por el hecho de que sea un thin client la máquina destino. Únicamente hay que poner cuidado de seleccionar el arranque desde USB. Para ello, simplemente hay que insertar el USB de arranque en el Futro S450 y al arrancar hay que pulsar <F12> y aparecerá el menú de arranque. Sólo hay que seleccionar el USB y pulsar <Enter>. Y la instalación comenzará como es habitual.

Ubuntu 16.04.1 instalándose

No voy a detallar la instalación de Ubuntu Server porque no es el propósito de este artículo; además Internet está plagada de manuales. Simplemente comentaré dos peculiaridades que yo he configurado. Por un lado, el particionado. Finalmente utilicé la unidad USB de 16 GB que tenía por casa, así que el Futro S450 ha quedado con una Compact Flash de 4 GB y un USB de 16GB. He configurado las particiones de la siguiente forma:

Compact Flash -> 1 partición ext4 de 4 GB -> Montada en /
USB -> 1 participación swap de 4 GB 
USB -> 1 partición ext4 de 12 GB -> Montada en /var

De tal forma que aquella rama que pueda tener un mayor crecimiento, por logs y por el propio almacenamiento del broker MQTT quede en el USB que tiene más espacio.

Instalaré OpenSSH

Y por otro lado, necesitaré un servidor SSH que me permita acceder remotamente ya que tal y como tengo pensado colocar el Futro S450 estará alto, sin teclado, ni ratón ni monitor. Así que durante el proceso de instalación, cuando se pregunta si se desea instalar un conjunto predefinido de paquetes, he deseleccionado todo excepto “OpenSSH server”, que dejará sshd escuchando en el puerto 22 al finalizar la instalación.

Configurar la red de forma estática

Por defecto, Ubuntu Server 16.04.1 configura la red para obtener su configuración a través de DHCP. Para un servidor, o se tiene configurado bien el servidor DHCP para asignar siempre la misma IP a la misma interfaz de red o si no no es la opción óptima, por lo que cambiaremos esta configuración para que la red esté definida estáticamente.

Fujitsu Futro S450 estorbando por el medio mientras instalo

Como comentaba, el thin client estará subido a una estantería y sin teclado ni monitor ni nada. Ahora lo tengo por el medio, pero eso se va a acabar en breve. Y como quiero acceder a él por SSH, quiero que siempre tenga una IP fija asignada y conocida por mí (por eso y porque nos hará falta a la hora de generar los certificados para soportar TLS). Para ello, abrimos el fichero /etc/network/interfaces:

sudo vi /etc/network/interfaces

Y modificamos la configuración de la interfaz eth0 para dejarla como sigue:

#Configuración de enp8s0
auto enp8s0
iface enp8s0 inet static
address 192.168.1.20
gateway 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4

La interfaz enp8s0 es la que a mí me crea Ubuntu automáticamente y corresponde a la interfaz Gigabit Ethernet. La IP 192.168.1.20 es la que quiero que tenga siempre el broker MQTT y 192.168.1.1 es la dirección de la pasarela de red. Para la dirección de la pasarela de red configuramos la misma que la de nuestra red local, que obtendréis con el comando:

route -n | grep "^0.0.0.0" | cut -c 17- | cut -c -16

El campo dns-nameserver especificado usará los servidores de nombre de Google para resolver nombres, que son de público acceso; no es necesario cambiarlos. Los dejaremos así.

A partir de este momento, accederé siempre de forma remota al Futro S450 a través de SSH con el siguiente comando:

ssh manolodd@192.168.1.20

Donde manolodd es el usuario no-root que cree durante la instalación de Ubuntu Server en el thin client y la dirección IP es la del Futro, como acabamos de ver unos párrafos atrás. Así que, salvo que se especifique lo contrario, los comandos de aquí en adelante se ejecutarán sobre el Fujitsu Futro y a él habré accedido previamente vía SSH.

Un broker MQTT para el Fujitsu Futro S450

¿Que broker MQTT instalo?

Existen numerosos brokers MQTT open source que cualquiera puede descargar y configurar. Unos son pesados y mastodónticos y otros ligeros y muy eficientes. Pero unos permiten una escalabilidad vertical y horizontal casi inacabable y otros no escalan más allá de de un simple core de la CPU. Así que, como en casi todas las ocasiones, la decisión vendrá determinada por los requisitos. En mi caso, los comenté en el primer artículo de esta serie: soportará muy poca carga, que sea suficiente, que de servicio sobre TLS y que soporte autenticación de usuarios y ACLs. Y, también, que pueda correr suficientemente bien en un thin client como el Fujitsu Futro S450.

Para este contexto, yo prefiero Mosquitto. Mosquitto MQTT es un broker MQTT que soporta la última especificación de MQTT realizada por OASIS, soporta TLS, tiene un sistema de plugins y pluings interesantes ya creados, soporta MQTT sobre Websockets, ACLs, autenticación… vamos, soporta bastante más de lo que yo requiero para este broker en concreto.

Instalaré Mosquitto MQTTY, aún más, está escrito en C, está en los repositorios de Ubuntu y se integra con cualquier Linux como un guante, como cualquier otro servicio del sistema. Tiene un rendimiento excepcional en producción y requiere muy pocos recursos. Aunque, por contra, tiene una escalabilidad horizontal prácticamente nula solo usará un core de la CPU aunque estén el resto ociosos; no tiene ninguna opción para clustering… ¡es para lo que es! Y es muy bueno. Y yo no voy a necesitar escalabilidad horizontal para este caso. Así que sin duda… Mosquitto.

Instalando Mosquitto

Como ya he comentado, Mosquitto se encuentra de serie en los repositorios oficiales de Ubuntu Server 16.04.1. Sin embargo, el repositorio oficial trae una versión bastante anticuada de Mosquitto, por lo que el primer paso que daré será añadir el repositorio de Mosquitto para Ubuntu, con lo siguiente:

sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
sudo apt-get update

Y ahora sí, instalamos Mosquitto MQTT broker con la siguiente orden:

sudo apt-get install mosquitto

lo cual, además de instalar Mosquitto, lo arranca y deja funcionando con la configuración por defecto (que en la mayoría de los casos podría ser más que suficiente).

Probando Mosquitto

El puerto por defecto utilizado para MQTT es el 1883. Como no hemos configurado nada al respecto, Mosquitto estará escuchando en dicho puerto; si utilizamos el comando:

netstat -ln --tcp

Su salida nos dará algo como esto:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State 
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN 
tcp6 0 0 :::22 :::* LISTEN 
tcp6 0 0 :::1883 :::* LISTEN

Donde se puede observar claramente que hay un servicio en el puerto 1883 tanto sobre TCP/IPv4 como sobre TCP/IPv6. Este servicio escuchando es Mosquitto sirviendo MQTT sin TLS.

Ahora que ya sabemos que Mosquitto está preparado, haremos una prueba en remoto, desde otra máquina con Linux. Yo lo haré desde mi estación de trabajo con Ubuntu, en la misma red local. Primero, antes de nada, instalaré en esta máquina el cliente de Mosquitto. Son herramientas muy útiles para hacer tests y ver que el broker está funcionando correctamente.

sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
sudo apt-get update
sudo apt-get install mosquitto-clients

Y a partir de ahí tendremos dos herramientas para hacer las pruebas como clientes: mosquitto_sub, para suscribirse a un topic concreto de Mosquitto y recibir aquello que se publique; y mosquitto_pub, para conectarse a Mosquitto y publicar un mensaje en un topic determinado. Usaremos ambas herramientas. Haremos una conexión remota hacia el broker con mosquitto_sub, sobre el topic “UnTopicCualquiera” y posteriormente desde otro terminal o desde otra máquina, nos conectaremos al broker para publicar el mensaje “Hola” en el topic “UnTopicCualquiera” del Mosquitto, que será recibido por el cliente que está suscrito a dicho topic.

Nos suscribimos al topic de forma remota:

mosquitto_sub -h 192.168.1.20 -t "UnTopicCualquiera" -v

Vemos que no ocurre nada. El proceso no vuelve a la shell sino que queda esperando a ver si algo se publica en ese topic. Ahora publicamos, de forma remota (desde otro terminal o desde otra máquina), sobre el mismo topic del Mosquitto:

mosquitto_pub -h 192.168.1.20 -t "UnTopicCualquiera" -m Hola

Vemos que el comando se ejecuta y termina, volviendo a la shell. Básicamente se ha conectado al broker MQTT, ha publicado el mensaje en el topic “UnTopicCualquiera” y se ha desconectado. Si vamos a la otra máquina o el otro terminal, donde estaba el cliente que se había suscrito al topic “UnTopicCualquiera”, vemos que ha recibido un mensaje que “alguien” (la publicación que se acaba de hacer con mosquitto_pub) ha publicado en ese topic.

mosquitto_sub -h 192.168.1.20 -t "UnTopicCualquiera" -v
UnTopicCualquiera Hola

Y sigue ahí, suscrito, esperando más mensajes hasta que pulsemos <Ctrl+C> para acabar el proceso.

Conclusión

Contar con un broker MQTT que haga de ESB con hardware de bajo coste y un bajo consumo de energía es algo muy, muy sencillo. Mosquitto es un broker MQTT muy potente y de alto rendimiento. Con la combinación de un Thin Client de 64 bits y Mosquitto, podemos tener broker MQTT para rato y desde  luego tendremos una base hacer aplicaciones muy interesantes IoT (o no), porque es muy sencillo conectar tu aplicación (app móvil, backend, web…) desde cualquier lenguaje de programación, a tu broker MQTT.

En cuanto tenga un hueco, haré un tercer artículo y os explicaré de forma rápida cómo configurar MQTT sobre TLS para poder acceder al broker remoto de forma segura y, si me da tiempo, explicaré también en qué consiste y como se configura el ACL y la autenticación en Mosquitto.

¿Tenéis comentarios? 🙂

Instalando un broker MQTT doméstico (I)

Instalando un broker MQTT doméstico (I)

Tengo configurado  en casa un Broker MQTT en un servidor Dell T310 Tower Server que utilizo generalmente para cuando estoy desarrollando aplicaciones “en plan serio”. Soporta TLS, autenticación y ACL en MySQL, clustering, tiene el kernel tuneado… Pero no lo tengo conectado permanentemente por eso de no gastar mucha luz. Sin embargo voy a necesitar un broker conectado permanentemente porque tengo un proyecto en marcha y lo quiero utilizar como Enterprise Service Bus (ESB). No necesitará soportar mucha carga, así que puedo hacer uso de un dispositivo más liviano. La idea es que el broker MQTT:

  • No consuma mucha energía.
  • Sea silencioso.
  • Sea suficiente.
  • De servicio sobre TLS.
  • Soporte autenticación de usuarios y ACL.

Como tengo en mi casa principalmente máquinas con Linux, me apetece que el broker funcione también sobre Linux aunque, como siempre, utilizaré lo que sea necesario utilizar. No soy talibán.

El dispositivo liviano

Siempre me ha gustado aprovechar la tecnología hasta su límite de vida. Ya tenemos bastante con la obsolescencia programada como para recortar aún más la vida de toda esa cacharrería que vamos acumulando. Hace unos años compré un thin client Fujitsu Futro S450. Después de un tiempo de uso lo reciclé como centro multimedia conectado a la tele. Y ahora que ya no lo necesito para ese papel, creo que será un dispositivo ideal para actuar como broker MQTT. Cuando lo reciclé como centro multimedia borré el sistema operativo que tenía (eLux) y le instalé Lubuntu, que ha funcionado perfectamente. Así que no creo que tenga problemas para correr un Ubuntu Server.

Fujitsu Futro S450

Sus características principales son:

  • Procesador AMD Sempron TF20 800 MHz.
  • 1 GB DDR2 SODIMM.
  • 512 MB Compact Flash.
  • AMD Radeon X1250 (hasta 1920×1200).
  • Gigabit Ethernet.
  • Refrigeración pasiva.
  • 18 W de consumo a pleno funcionamiento.

Es un aparato bastante decente para muchas cosas y que se puede encontrar hoy en día en Ebay por 10€, así que no hay excusa.

Ampliando el Fujitsu Futro S450

Excepto por la capacidad de la Compact Flash (512 MB), creo que me serviría con las características de fábrica; pero de todas manera le aumentaré la RAM ahora que está bien de precio. Así que el primer paso es abrirlo y sustituir la Compact Flash por una de mayor capacidad y tasa de transferencia.

Interior del Fujitsu Futro S450

He comprado una de 4GB de la marca Kingston (11 €, más de lo que vale el Futro de 2ª mano en Ebay, jeje). Y la actualización es bien sencilla: quitar un par de tornillos, abrir la carcasa, sacar la Compact Flash de 512 MB del zócalo donde está conectada y poner en su lugar la nueva Compact Flash de 4 GB. Fin de la actualización.

La nueva Compact Flash de 4 GB

Con la memoria ocurre exactamente lo mismo. el módulo se encuentra insertado en su zócalo correspondiente y únicamente hay que extraerlo y poner en su lugar el módulo nuevo. Yo en este caso he instalado un módulo de 2GB para doblar la memoria del Futro. La he comprado por 14€ en Amazon.

Módulo SODIMM de 2GB instalado

Aprovechando que estaba abierta la carcasa, me dio por desmontar el disipador del procesador para echarle un vistazo. El part number grabado en el mismo (AMGTF20HAX4DN) indica que es un AMD Ahtlon 64 TF20, no un Sempron. Pero no le doy más vueltas. Cierro todo de nuevo y… voilà, ya tengo el dispositivo preparado. Durante el arranque, el Futro ha detectado la Compact Flash como un nueva nueva unidad de 4GB y la memoria de 2GB. Así que tengo ya actualizado todo el hardware que quería y que es necesario.

Por otra parte, en casa tengo una memoria USB Sandisk Cruzer de 16GB que igual le añado para tener algo de memoria swap o para montar alguna partición extra. En realidad no es que haga falta, pero como lo tengo en un cajón, a lo mejor le doy un uso. Lo decidiré en el momento de la instalación 🙂

Memoria USB Sandisk Cruzer 16GB

Si no hay problemas, y espero que no los haya porque tengo poco tiempo, los pasos deberían ser:

  • Instalar Ubuntu Server 16.04 y configurar SSHD.
  • Instalar el broker MQTT y las bibliotecas necesarias.
  • Crear y configurar los certificados correctamente.
  • Iniciar el broker MQTT.

Iré contando en los próximos días los avances según tenga tiempo para poder dedicarle, porque últimamente estoy por los pelos 🙂

La inversión en educación (TIC) desde mi óptica

La inversión en educación (TIC) desde mi óptica

Hace más de 25 años yo era un adolescente y tuve la buena suerte de ganar un ordenador  en un concurso. Un ordenador con 640 KB DE RAM, su ratón, su disco duro de 30 MB, disquetes de 3,5” de baja densidad, monitor con escala de grises, MS-DOS y Windows 1… que tuve más de un año encima de la mesa sin saber qué hacer con él. Ni yo ni ninguno de mis amigos de la época. Alguno de ellos tenía ordenador tipo Amstrad CPC464, Sinclar ZX Spectrum, Amstrad PCW 8256, etc. Y básicamente lo que hacían con ellos era alquilar juegos en formato casete de un videoclub, copiarlos y jugar.

Amstrad PC2086/30 ¡Qué recuerdos!

¡Me había tocado una mierda de ordenador!… o eso pensaba. Con el tiempo aprendí a encenderlo y manejar relativamente bien MS-DOS y hacer cuatro cosas con el espartano Windows que a todos mis amigos fascinaba pero que a mí no me valía para jugar ni para nada. Hasta que un profesor de matemáticas, Andrés, me comentó que él había hecho un curso de programación en C – ¿programación? ¿qué era eso? – y me prestó el material del curso y el compilador. Tardé como 6 meses en hacer mi primer hola mundo. Y a partir de ahí empecé a descubrir el fascinante mundo de la informática.

Sin libros, sin nadie con quien compartir información y sin el Internet que ahora parece que ha estado ahí siempre, pero que lógicamente no estaba, avanzaba muy despacio. Fue ahí cuando otro de mis profesores de matemáticas, Abilio, me permitió utilizar un ordenador de una sala del instituto que tenía módem y conexión a la Red Telefónica Básica (RTB) para experimentar. Había leído en una revista cómo acceder a Ibertext y al Bulletin Board System (BBS). Me costó, pero a partir de ahí obtuve ingentes cantidades de información (muy ordenada y buena en la época; no había paja): noticias sobre programación y hacking de Fidonet, cursos de ensamblador, cursos de BASIC… ¡Hasta que me cerraron el grifo! A 21 pesetas por minuto de conexión tras un tiempo en mi instituto me dijeron que no podían seguir dándome acceso.

BBS. ¡Buscar y encontrar!

Creo que nunca han llegado a sospechar lo que esa oportunidad cambió mi vida. Hubo tres momentos clave: ganar “una mierda de ordenador que no me permitía jugar”, abrirme el mundo de la programación en C y darme acceso al mundo a 21 pesetas el minuto.

A la información obtenida durante los meses que pude tener conexión le saqué un partido inimaginable. Y eso que estaba en inglés y empezaba la década de los 90 (mi proto-inglés no podía ser más rudimentario). En torno al 1991 programaba relativamente bien en C, BASIC y ensamblador del 8086. Me hacía mis propios juegos y programas para mi “mierda de ordenador” (que ya empezaba a entender que no lo era tanto) y, definitivamente, decidí que querría estudiar Ingeniería en Informática al finalizar el bachillerato. Y así fue.

Muchas veces tendemos a creer que la inversión en material en los centros de enseñanza, no tiene mucho sentido. Y seguramente en gran parte de los casos es así; es una forma rápida y sencilla de “quemar dinero público” y de que el político de turno pueda hacerse unas cuantas fotos. Se ve como un derroche. Lo mismo con respecto a la dotación de personal docente y su reciclaje. Pero algo tengo bien claro; yo hoy no sería Ingeniero en informática de no ser porque han confluido dos hechos particulares:

  • He tenido la suerte de coincidir con maestros y profesores cualificados y dedicados durante mis estudios de E.G.B. y Bachillerato. Y con “dedicados” me refiero a “más allá de lo exigible por su propia condición profesional”.
  • Tener la suerte de estudiar en un centro donde había equipamiento que seguramente para la época era considerado un derroche o un exceso y donde existía la voluntad de ponerlo “al servicio” del alumnado.

Así que, cuando me vienen a la cabeza ideas del tipo “que derroche”, “vaya forma de malgastar el dinero”, aun sabiendo que en gran parte es cierto, me gusta imaginar que en algún rincón hay un/a niño/niña investigando cómo funciona un cierto “artilugio” ayudado por un docente implicado y que, quizás, le esté cambiando la vida sin saberlo.

2ª Gastro-reunión de GIDIP (Mérida)

2ª Gastro-reunión de GIDIP (Mérida)

El Project Management Institute (PMI) es la organización internacional sin ánimo de lucro bajo cuyo paraguas se creó la Certificación Project Management Professional (PMP), de la cual es garante. PMP está basada en el conjunto de buenas prácticas PMBoK (Project Management Base of Knowledge) y es, de facto, el estándar más internacional en cuanto a gestión de proyectos se refiere. Además, es una certificación convertida en estándar por el American National Standards Institute (ANSI).

Organizativamente PMI se estructura en Capítulos (generalmente abarcando el territorio de un país o gran parte de un país) y, en algunos casos, dichos capítulos se componen además de varias ramas llamadas Branches, como extensión de los Capítulos sobre otros territorios. En España existen tres capítulos: el de Madrid, el de Barcelona y el de Valencia, siendo el más relevante con bastante diferencia, el de Madrid (por entidad, patrocinios, número de asociados, etc).

A mediados de 2014, varios ingenieros y arquitectos de Extremadura comenzamos a trabajar de forma voluntaria y espontánea para diseñar y fundar un Branch del Capítulo de Madrid de PMI con el ámbito territorial de Extremadura y Castilla La Mancha (⅓ del territorio nacional). Los Branches, reconocidos por PMI, permiten extender los servicios de los Capítulos más allá de sus áreas geográficas habituales. Con ello pretendíamos acercar los servicios del Capítulo de Madrid de PMI a Extremadura y Castilla La Mancha de una forma mucho más cercana y sobre el terreno.

ext_clm_logo-1b
Logo del Branch

En Septiembre de 2015, un año después, se crea el Branch de Extremadura y Castilla la Mancha del Capitulo de Madrid de PMI cuya presentación oficial, multitudinaria, se hizo en la Escuela Politécnica de Cáceres. En esta presentación se constató la ilusión de todos los asistentes por la gestión de proyectos y también la necesidad de conformar un grupo de interés en gestión de proyectos que no sólo estuviese enfocado a PMI sino en cualquier otra metodología/certificación de dirección de proyectos o incluso ninguna, de forma que este grupo fuera agnóstico en cuanto al método.

Creación del GIDIP

Casi un año después, en Septiembre de 2016, tras grandes esfuerzos para buscar fórmulas que permitiesen la creación de este grupo y, lo que es más importante, su gestión, coordinación y mantenimiento, se creo el el Grupo de Interés en Dirección Integrada de Proyectos (GIDIP), patrocinado inicialmente y en la actualidad por el Branch Extremadura y Castilla la Mancha del Capítulo de Madrid de PMI pero abierto a la coordinación y el patrocinio de cualquier interesado en que siga funcionando.

151118_logo-gidip
Logo del GIDIP

Las características de este grupo son:

  • Se basa 100% en el trabajo de voluntarios
  • Es abierto a cualquier persona.
  • Es gratuito para los participantes.
  • Se celebra de forma asidua.
  • Todos los participantes hacen que evolucione hacia donde ellos quieran
  • Celebra reuniones en lugares distintos de Extremadura y Castilla La Mancha.
  • Busca la participación de personas de distintos ámbitos o profesiones
  • Busca la puesta en común de experiencias reales en la dirección de proyectos para un crecimiento profesional de los participantes
  • Busca el establecimiento de lazos de colaboración entre personas que trabajan en proyectos por lo que se hace en un ambiente distendido e informal.

Tras la primera reunión del grupo en Badajoz, con abundante asistencia, los participantes establecieron los temas prioritarios a tratar en las siguientes reuniones, la cadencia de las mismas y el formato.

2ª Reunión del GIDIP: Gestión del Alcance

Siguiendo lo propuesto por los participantes en GIDIP en la reunión de Badajoz de Septiembre de 2016, la segunda reunión del GIDIP se ha celebrado en Mérida, el 27 de Octubre de 2016. Como se  votó en la primera reunión el tema seleccionado para la reunión fue la gestión del alcance de los proyectos, en su sentido más amplio.

Asistieron una treintena de amigos de Extremadura y Castilla – La Mancha; principalmente de la provincia de Badajoz dado que se celebraba en Mérida. Las reuniones de GIDIP suelen ser bastante informales porque lo que se trata es de conocerse, tocarse y hablar, como si se estuviese en un bar con amigos hablando de un tema interesante (generalmente es justo eso). Esta vez sin embargo, debido a problemas de última hora con la localización donde se iba a celebrar inicialmente, se tuvo que hacer en la sala del Hotel Velada. Muy bonito, muy profesional… y muy formal; demasiado para el grupo. Así que durante los primeros minutos de la gastro-reunión, nos dedicamos a desmantelar un poco la organización tan cuidada que habían preparado los el hotel.

Ya cómodos, disfrutamos de los relatos de dos ponentes excepcionales: José Manuel Honrado y Miguel Ángel de la Calle que nos contaron sus experiencias, relacionadas con la gestión del alcance desde dos puntos de vista distintos. José Manuel habló sobre proyectos privados de internacionalización en América Latina, con problemas reales de un proyecto concreto, y Miguel Ángel nos estuvo comentando la gestión del alcance en proyectos europeos, principalmente del H2020, también desde un punto de vista bastante práctico y con casos reales.

gidip2-participantes
Participantes en la 2ª Gastro-reunión de GIDIP

Siguió la reunión con un turno de debate abierto, con preguntas a los ponentes y entre los propios participantes relativas a la gestión del alcance que resultó muy interesante por cuanto se pudo comprobar las distintas problemáticas dependiendo del sector y el tipo de proyecto.

Finalmente, la velada se extendió casi una hora más, de pie, donde pudimos disfrutar de un pequeño bufet con algo que llevarse a la boca y unos vinitos y cerveza, que por algo lo llamamos gastro-reunión. Y durante todo este tiempo, los asistentes se entremezclaron hablando y compartiendo ideas y experiencias luciendo los gomets circulares que hemos utilizado para “anunciar” nuestros intereses al resto de compañeros. En definitiva, una experiencia muy positiva que repetiremos en breve.

Anímate a la siguiente gastro-reunión

La verdad es que no se me ocurre ningún motivo para no asistir habitualmente a GIDIP. Es gratuito, sin compromiso, sin rollos. Se habla de proyectos, se comparten ideas, se aprende, se hacen amigos y contactos… Así que apúntate para la siguiente:

Puedes estar al día de lo que ocurre en GIDIP en:

¡Vamos, anímate!

Simulador OpenSimMPLS

Simulador OpenSimMPLS

Muy de tarde en tarde, siempre hay alguna ocasión en la que uno desarrolla algo pensando en que será un proyecto “discreto” y sin embargo acaba dándose cuenta de que su proyecto tiene una aceptación insospechada. A mi me ocurrió eso con el simulador OpenSimMPLS;  Inicialmente, desarrollé este el simulador en el contexto de mi proyecto final de carrera (PFC) en 2004. El PFC en sí consistía en el diseño de una series de tecnologías que permitían recuperar paquetes perdidos en una red MPLS (Multi Protocol Label Switching) de forma local, evitando la retransmisión extremo-extremo de segmentos TCP (Transmission Control Protocol)  completos y, en definitiva, permitiendo ciertos niveles de Garantía de Servicio (GoS) al tráfico de la red. Así durante meses hice reingeniería de protocolos de comunicación y diseño de algoritmos y búferes, etc. Un trabajo bastante concienzudo. El proyecto se llamó “Soporte de Garantía de Servicio (GoS) sobre MPLS mediante Técnicas Activas”. OpenSimMPLS fue un desarrollo accesorio, necesario para comprobar que las tecnologías diseñadas suponían un avance objetivo y empírico; y aunque lo desarrollé con el mayor esmero posible, no pensé que tuviese demasiado impacto más allá del contexto del proyecto. Aún así lo liberé bajo GPL 2.0+ por si a alguien podía venirle bien.

opensimmpls-retrievals

Expansión

Las ideas técnicas de mi PFC han sido utilizadas en diversas universidades y en algunas propuestas más desarrolladas en tésis de máster, tésis doctorales e incluso en proyectos de empresas privadas. Pero lo que realmente ha “triunfado” ha sido OpenSimMPLS, el simulador en sí. Como aproximadamente dos años después de finalizarlo, el número de descargas comenzó a aumentar exponencialmente. Es el tiempo que tardan las publicaciones de revistas y congresos científicos en “surtir efecto” y llegar a la comunidad científica. Comenzaron a descargarlo de todos los continentes y en unos cinco años, en 2010-2011, ya se estaba utilizando en más de 130 países. Me sorprendió este número y mucho más cuando supe que la ONU reconoce “sólo” 194 países en todo el mundo. ¡Guau! Casi un 70% de todos los países del mundo. Comenzaron a llegarme consultas desde multitud de centros de investigación, universidades y empresas que lo estaban usando, desde U.S.A. hasta Arabia Saudí o Japón. E incluso una organización de Estados Unidos nominó al proyecto como mejor proyecto para enseñanza de ingeniería.

Lo más sorprendente es que creé OpenSimMPLS para demostrar que las mejoras que yo proponía para un dominio MPLS suponían un avance real con respecto al MPLS “habitual”. Y sin darme cuenta, lo que había hecho era un simulador MPLS bastante completo. Las extensiones creadas en el contexto de mi PFC se podían utilizar o no, pero como simulador MPLS OpenSimMPLS tiene unas ventajas enormes para docencia. Y es principalmente ahí donde se estaba utilizando: en docencia de redes MPLS en universidades de todo el mundo. También en I+D, aunque esto de forma más secundaria.

opensimmpls-repo-git

Problemas para crecer

OpenSimMPLS pasó un riguroso proceso de calidad durante su desarrollo, principalmente porque iba a ser utilizado para validar resultados de I+D y por tanto debía evitarse que el simulador fuera el punto débil del proceso. Y de hecho pocos bugs se han reportado en su historia (no nos engañemos, los ha habido, pero muy pocos). La mayor parte de las consultas que desde distintos lugares han hecho a lo largo de su historia están relacionadas con:

  • Facilidad para extender las funcionalidades de los nodos MPLS. Ciertamente el simulador no estaba especialmente diseñado para ello; se desarrollo para un momento y un objetivo concreto. Pedían algo más modular, tipo plugins.
  • Documentación en inglés. Fallo gordo. Al desarrollarlo sin pensar en que iba a tener ese alcance, clases, métodos, atributos, documentación interna y externa… estaban en español. Bastante bien documentado, eso si, pero en español. Al menos el código fuente esta internacionalizado y el simulador aparece en español o inglés dependiendo de dónde se ejecute. Pero claro, extender un código que está en un idioma que no conoces, es complicado.
  • El proyecto hace uso de características que con el paso de tiempo Java ha dejado como deprecated y muchas personas comentan la posibilidad de actualizar el simulador para que haga uso de las características de los Java más modernos.
  • El proyecto estaba en SourceForge sobre un repositorio CVS (Concurrent Version System). En 2004 no era inusual, pero ya más adelante Subversion primero y Git después han suplido a CVS que casi se ha extinguido. Bien, pues desarrolladores de todos los lugares pedían el cambio de repositorio.
  • Problemas de licencias. Otros desarrolladores querían ampliar el simulador pero querían aprovechar componentes que ya tenían y con otras licencias incompatibles con la licencia GPL utilizada por OpenSimMPLS. No hubiera hecho caso a estas peticiones si no se hubieran repetido incesantemente y de forma recurrente desde multitud de lugares del mundo.
  • No existía una comunidad. Ciertamente no. No pensaba que el proyecto tendría tanta transcendencia y no me preocupé de que la hubiera hasta que me di cuenta que habría sido buena idea… pero ya era tarde.

O sea, que la mayor parte de los problemas del proyecto no han sido tanto del aumento de uso, sino del paso del tiempo. Necesitaba ser “remozado”. Y yo, que hacía más e una década que acabé el proyecto, me vi dedicando cada vez más “ratos” a la semana contestando preguntas, modificando funciones, etc. Había que cambiar algo, de raíz.

Relanzamiento del proyecto

La mayor parte de las cosas que pedían en uno y otro lugar eran más o menos sencillas. Cuestión sólo de echar ratos. Así pues puse en marcha un plan de modernización de OpenSimMPLS que le permitiera seguir siendo un proyecto fresco y actual y que facilitar su extensión a medio plazo:

  • Cambio del repositorio original CVS en SourfeForge a un nuevo repositorio Git en GitHub.
  • El cambio de licencia. En ese momento era GPL 3.0+ y me incliné por una licencia más permisiva y amigable con el software comercial. La Apache Software License 2.0 (había que revisar contribuciones y librerías de terceros para ver si era factible).
  • Actualización de la interfaz de usuario, con un nuevo look and feel más moderno.
  • La centralización de todo en GitHub, incluida la antigua web, que pasaría al Wiki de GitHub.
  • La refactorización del código fuente para cambiar el nombre de variables, métodos, clases, atributos, interfaces… al inglés.
  • La traducción/refactorización de toda la documentación interna del proyecto al inglés.
  • Identificar, en el código, los lugares donde es necesario hacer modificaciones para corregir algún aspecto o actualizar para versiones superiores de Java.
  • Creación de un canal de comunicación par dudas o para compartir conocimiento del simulador:
Web de OpenSimMPLS
Web de OpenSimMPLS

No todas las medidas están finalizadas aún. De hecho algunas aún no han empezado. Pero una gran parte sí. Especialmente aquello que más impide que el proyecto sea extendido por terceros: la traducción al inglés y la refactorización del código. Esa tarea está bastante avanzada. Al igual que el tema de los repositorios o el cambio de licencia. Con ello, espero que este proyecto viva al menos otros 10 años bien tal como está o bien como un fork que evolucione de forma paralela. Ya hay forks del proyecto en GitHub que no han podido hacer pull requests dado que yo estoy en pleno proceso de ejecución de las tareas descritas 🙁 ¡Sorry! En cualquier caso, las descargas del proyecto son más o menos constantes de unas 1.000 cada mes, ya que las releases están intactas y listas para usarse.

Pues este es el proyecto OpenSimMPLS. Si quieres contribuir, usarlo, saber más o compartir experiencias, no dudes en ponerte en contacto a través de cualquier a de los medios descritos.

¡Estoy de mudanza!

¡Estoy de mudanza!

Después de mucho meditarlo, he decidido renovar mi web. No es que la tuviese abandonada ni mucho menos, pero lo cierto es que mantener una web programada a pelo y esperar que sea responsive y que sea utilizada para crear contenido dinámico, es esperar demasiado.

Hasta ahora la web tenía contenido estático o que cambiaba con muy poca frecuencia. Pero se me ha antojado crear un blog además de tener los contenidos habituales de la web, por lo que necesito instalar un CMS en condiciones. Así que, durante las próximas semanas estaré de mudanza, pasando contenidos de un lado a otro, seleccionando contenidos nuevos y contenidos a eliminar… y reparando todo aquello que vaya rompiendo (es lo que tiene hacer estas cosas de madrugada).

Si mientras tanto necesitas alguna cosa que estuviese en la web y que ahora no encuentras, no dudes en ponerte en contacto y me lo comentas.

¡Nos leemos pronto!