Buscando commits malos con el Inspector Gadget

Hay una situación que todo desarrollador acaba viviendo al menos una vez. Te vas un viernes a casa contento con el código funcionando, pero al día siguiente, o tres días después, o una semana más tarde, abres el proyecto y algo ya no va. Y lo peor es que no tienes ni idea de cuándo se rompió.

Lo primero que hace uno es revisar los últimos cambios. Ves que en los últimos 10 commits no se ha tocado nada relacionado con lo que falla (genial). Tendré que mirar más commits diría uno. Pero si el repo involucra a varios compañeros, el historial de commits puede ser bastante extenso. Además, un bug que encuentras hoy no tiene por qué haberse introducido hace poco, igual lleva dos meses en el repositorio.

Let's get into Microservices (together)

Why would anyone define microservices as an architecture choice?

If you're already familiar to microservices, then the answer to the question above might seem quite obvious. But if you aren't, like me, then you might learn some new concept today.

So, I've recently got his book titled "Building Microservices: Designing Fine-Grained Systems" by Sam Newman and I'm going to write some content as I read, and understand, it :).

Mi opinión sobre el uso irresponsable de la inteligencia artificial y sus consecuencias

Me gustaría dar mi punto de vista sobre el mal uso que se le da (en muchas ocasiones) a la inteligencia artificial en el entorno laboral. Cuando digo IA me refiero a ChatGPT, Gemini, Claude, etc. indistintamente.

Como ingeniero y desarrollador de software sé perfectamente el tiempo y esfuerzo que supone hacer ciertas tareas. Pueden ser tareas de código (implementar una nueva funcionalidad sobre la que hay poca documentación en internet), o escribir un estado del arte sobre cierta tecnología y para un determinado propósito. Quizás podría ser algo tan simple como responder a una pregunta que te hace un compañero: "Hey, Chati GPT, ¿cuál es la mejor herramienta para capturar tráfico en Ubuntu 22?"; y le "copipasteas" la respuesta a tu compañero casi sin haberla leído y, ni mucho menos, razonado o contrastado.

Principio de Mínimo Privilegio: qué acceso le das al cliente en tu repo de GitHub durante su desarrollo

Hace tiempo que quería investigar sobre este tema. Como desarrollador, entiendo que es normal encontrarse en este tipo de nuevas situaciones y no saber cómo gestionarlas de primera mano. El contexto es el siguiente: estás llevando a cabo el desarrollo de un software (llamémoslo Ajile) para un cliente (llamémoslo Uartec) y durante la contratación nos comprometimos a realizar una transferencia tecnológica (del desarrollo de Ajiile, en este caso). Uartec nos pide acceso al repositorio privado en el que se lleva a cabo este desarrollo, lo que nos hace preguntarnos: ¿qué nivel de acceso le damos?

Digamos que Ajile está subido en un repositorio de GitHub privado dentro de mi organización, Devsoft. Se acordó desde el principio que así sería, por razones de comodidad y organizativas. Para que Uartec tenga acceso al código necesita permisos de lectura, como mínimo. Pero, ¿solo de lectura? ¿O algo más?

En ocasiones veo sockets raw: cómo trabaja el kernel de Linux a nivel de red

Creo que este post puede ser muy interesante y además un buen ejercicio para recordar las capas del modelo TCP/IP. Surge de una necesidad de gestionar a nivel de bit paquetes de red: identificar y parsear cabeceras de las capas L3 y L4 (red y transporte). Esto hecho en C++ desde un host Linux usando la API de sockets estándar pero a un nivel más bajo de lo habitual.

Mi intención es reflejar con claridad las diferencias entre distintos tipos de sockets que podemos crear y qué aporta cada uno, para poder elegir con criterio según las necesidades de cada quien. Primero repasaremos conceptualmente dos o tres tipos de sockets y el nivel de la pila en el que trabajan; después lo aterrizaremos con ejemplos de código en C++ y algún diagrama sencillo para entender exactamente qué bytes llegan a nuestro recvfrom() en cada escenario.

Configurando un socket para recibir datagramas UDP en un puerto concreto

Una necesidad my común como la de recibir datagramas UDP en un puerto concreto puede llevarnos a crear sockets como:

#include <sys/socket.h>

int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

Donde lo importante está en i) AF_INET especificando que la comunicación usará direcciones IPv4, en ii) SOCK_DGRAM especificando que las comunicaciones estarán basadas en datagramas, y en iii) IPPROTO_UDP que dice al kernel que solo nos interesan datagramas UDP. Se definien así parámetros asociados al direccionamiento IP (capa de red) y al tipo de transporte basado en datagramas. Opcionalmente, también podríamos bindear el socket a un puerto fijo en el que recibir los datagramas:

Un vistazo a SCHC para entender cómo facilita el envío de paquetes IP comprimidos en enlaces restringidos

SCHC (Static Context Header Compression) es un estándar definido en el RFC 8724 que especifica un mecanismo de compresión y fragmentación de paquetes diseñado para entornos con recursos extremadamente limitados. Su objetivo principal es reducir el tamaño de las cabeceras de protocolos de las capas de red, transporte o aplicación mediante el uso de contextos estáticos previamente compartidos entre cada nodo de la comunicación.

Más allá de la compresión de cabeceras, el esquema de fragmentación adaptado a enlaces con tamaño de trama muy reducido, como en redes LPWAN, incorpora modos de operación con confirmación (ACK-on-Error y ACK-Always). Esto permite controlar la fragmentación y recuperar fragmentos perdidos en el propio enlace, mediante confirmaciones y retransmisiones, algo especialmente útil en radioenlaces/LPWAN con pérdidas.

Cabecera IPv6 sin extensiones (40 bytes - 320 bits)

Tras la compresión/fragmentación de paquetes con SCHC, lo que viaja por el enlace no es un paquete IP/IPv6 válido, puesto que su cabecera ha sido comprimida y ya no contiene toda la información necesaria. En su lugar, es un residuo SCHC + RuleID + fragmentos (si hay), por lo que solo un receptor SCHC con el mismo contexto puede reconstruir el paquete IP/IPv6 original.

Esto se vuelve útil, incluso necesario en redes LPWAN porque las restricciones en el enlace suelen ser muy limitantes, con tamaños máximos de transferencia de unas cuantas decenas de bytes (50-200 aprox.). Teniendo en cuenta que el par de cabeceras IPv6+UDP sin extensiones ya ocupa 48 bytes, la compresión se hace muy necesaria.