Igalia, donde trabajo, ha publicado su convocatoria
para el Igalia Coding Experience
2024.
El programa consiste en trabajar 450 horas, durante 3 a 6 meses (dependiendo de
la dedicación diaria acordada), en un proyecto de software libre dentro de la
lista presentada, con la guía de un compañero de Igalia, a cambio de €7,000.00.
La recepción de solicitudes terminará el 3 de abril.
El programa está abierto para quienes comienzan a internarse en la programación,
como estudiantes o entusiastas y desean aprender más y más rápido, en
prácticamente cualquier parte del mundo.
La carta de presentación y el currículum deberán estar en inglés, ya que
todas las comunicaciones, tanto con la comunidad del proyecto como con los
mentores, son en este idioma.
Se espera que el participante sea autónomo, proactivo, responsable y
disciplinado. El nivel técnico no es tan importante porque se desarrollará con
el trabajo, sin embargo, debe haber un interés y curiosidad por el área
seleccionada.
Un streamer «es una persona que hace emisiones en directo o en diferido, en
plataformas como YouTube y Twitch. El alcance de los realizadores de directos ha
crecido para incluir diferentes géneros que van desde jugar videojuegos hasta
tutoriales.» *.
El género más difundido entre los realizadores de transmisiones en vivo, es el
de los videojuegos, del cual no comparto la afición, por lo que no había
prestado mucha atención al fenómeno. No obstante, he comenzado a seguir
realizadores en vivo de filosofía y de opinión noticiosa. Los escucho mientras
estoy programando algo simple o lavo trastes o trapeo, y me gusta lo aprendo de
ellos.
Una rama evolutiva del streamer es el VTuber, que usa modelos digitales,
muchos inspirados en estilo de anime, generados por herramientas de software, y
comúnmente utilizan un medio de captura de movimiento para expresarse a través
de sus avatares. *.
Más allá de la sofisticación técnica y la paciencia necesaria para ser un
VTuber, hace cosa de un par de años, irrumpieron quienes transmiten sesiones
de programación en vivo, que no es friolera. Programar es una actividad que
exige mucha concentración de manera prolongada, más aún si es sobre tópicos
complejos, como programar un driver del kernel para una nueva GPU, por ejemplo.
Lo anterior dicho sirva para presentar a Asahi Lina,
una VTuber, que principalmente transmite su trabajo desarrollando el driver
para Linux de la GPU integrada en el chip M1 de
Apple, a través de ingeniería inversa.
Además de lo hace de manera innovadora: usando Rust en lugar de C (algo que lo
que ya hablamos aquí). Con esto, la complejidad
agregada, es algo que sólo ciertas mentes privilegiadas pueden manejar.
Dejo aquí una transmisión donde Lina programa, de manera ininterrumpida, por
doce hora seguidas, el driver. Por enumerar algunas cosas que me asombran:
Su arreglo para que con una sola salida de vídeo, programa en una computadora
(usando el editor Kate) y lo prueba
necesariamente en otra, por si se traba.
Su arreglo para mantener al personaje virtual.
Su facilidad para explicar lo que está haciendo. Es algo que yo no puedo.
Para programar tengo que sumirme en mis pensamientos y sólo puedo pronunciar
quejas y mentadas de madre.
Su capacidad para concentrarse por ese impresionante número de horas. Yo, a
las tres de programación profunda, me siento agotado y fastidiado.
Por las causas que ahora explicaré me vi en la obligación de cambiar, antes de
lo esperado, el sitio del GLiB a su versión estática.
El sitio del GLiB está hospedado en un servidor que alquilo donde también
hospedo otro sitios web. Lo actualicé a la última versión estable de Debian,
bookworm, que fue liberado en diciembre del año pasado, con actualización de
PHP a su versión 8.2, la cual ha endurecido su verificación de código.
Lamentablemente, GeekLog apenas ha
sido actualizado en los últimos dos años. Sí, contiene algunos cambios para
soportar PHP 8.2, pero no parecen ser suficientes. El proceso de actualización,
tanto a su última versión estable, 2.2.2, como a master, me falla,
precisamente, por estas verificaciones que ahora hace el intérprete. Además, hay
al menos un CVE que no ha
sido atendido por los mantenedores.
Por lo anterior, he decido ya no exponer a Internet el sitio en GeekLog y
adelantarme, prematuramente, a su migración a HTML estático. Pueden ver las
tareas que faltan para
que el sitio tenga la funcionalidad similar a la que teníamos con GeekLog.
Después de dedicarle más de 24 horas a la tarea, finalmente tenemos el
despliegue automático del
sitio web estático a través de la integración continua de GitHub.
En palabras un poco más simples, cuando se hace un Pull Request, GitHub hará
una serie de pruebas a los cambios realizados, conocidas como Integración
Continua, o CI, por sus siglas en inglés. En este caso se revisará la
ortografía del texto en MarkDown, así como su correcto formato, de acuerdo a
la especificación, y finalmente se generará el
sitio con Zola.
Una vez que estas pruebas son aprobadas, alguien con permisos puede hacer Push
a la rama main del repositorio. Cuando ocurre, se ejecuta otra acción de
GitHub: el despliegue. Con esto, se vuelve a generar el sitio y se transfiere
automáticamente al servidor web, es decir, se publica.
Esto se acerca mucho a mi visión de un sitio colaborativo para el Grupo Linuxero
del Bajío.
Abusando de mis magras vacaciones, continué un viejo proyecto que tenía atorado:
convertir este sitio en uno estático y eliminar el GeekLog, que todo código
ejecutándose en el servidor y con exposición pública es un motivo de
preocupación.
Pues ahora anuncio lo que llevo hecho, para dedicarme a otros pendientes, y
dejando la invitación a los que quieran colaborar para hacer una correcta
migración.
Hago énfasis en los issues abiertos por si alguien quiere hacerse cargo de
alguno de ellos: https://github.com/gliborgmx/static-glib/issues, no duden de
crear nuevos issues si encuentran algo, aunque, claro, los pull requests son más
apreciados.
Históricamente https://glib.org.mx ha usado
GeekLog como manejador de contenidos (CMS). Sin
embargo, mantener un CMS requiere un esfuerzo de administración que actualmente
no considero necesario, tal como actualizar el CMS, estar pendiente de agujeros
de seguridad de la infraestructura que necesita el CMS (PHP, MySQL, etc.). La
tendencia actual a usar generadores estáticos elimina mucho de este trabajo para
el administrador del servidor.
Este repositorio contiene la migración del https://glib.org.mx a un generador
estático en lenguaje Rust conocido como
Zola.
Mi plan es usar únicamente HTML
semántico en las plantillas,
y que todo el formato esté en CSS sin clases, en este caso con Pico
CSS.
El mecanismo para colaborar con artículos está aún por definir, aunque
definitivamente la carga de trabajo se traslada a los colaboradores, ya que debe
saber Markdown/CommonMark para escribir
contenido, y git para compartir sus textos, usando los
mecanismo de integración continua de GitHub.
Los grandes ausentes, por lo menos al comienzo, serán los comentarios, aunque en
un futuro podríamos migrarlos y soportarlos a través de Isso
comments, pero eso hay que discutirlo porque
implicarían retornar a los costos de mantenimiento de software.