Unos breves apuntes de lo que he ido descubriendo sobre Edge Computing o traducido como computación de frontera, qué pretende resolver y cómo lo hace.

Quiero conocer mejor como funciona la asincronía internamente en los hilos, y principalmente con el reto más importante que resuelve, las operaciones de E/S (Entrada/Salida).

Hoy he reservado tiempo para leer el discurso de Dijkstra "The humble programmer" (El programador humilde) de 1972. Hay un párrafo que me ha recordado aquello de que para un martillo todo son clavos o ¿cómo nuestras herramientas terminan moldeando nuestros desarrollos?

En mi “aproximación profunda” sobre la programación asíncrona, he querido estudiar la base de esa asincronía. Así que en última instancia me he visto envuelto en comprender el funcionamiento sobre la gestión de los hilos. Mi objetivo es poder explicar los conceptos que me he encontrado sobre los hilos y cómo funcionan.

Después de la lectura de libro, considero que debería ser uno de los libros de cabecera de cualquiera que trabaje en el mundo del desarrollo de software, ya sea front, back, junior, senior, arquitecto o apagafuegos. Especialmente este último. Cualquier organización que le suene bien el término "value-driven" debería también tomar en cuenta los principios DevOps.

Las organizaciones deben propiciar un entorno seguro a sus trabajadores donde experimentar, extraer aprendizajes y compartirlos. Solo así podemos mejorar de forma continuada nuestro flujo de trabajo.

Este principio nos habla de la necesidad de tener un buen sistema de información y herramientas que nos den feedback inmediato de todo lo que está ocurriendo en nuestro flujo de trabajo y en nuestro sistema (PARTE 3).

El uso más típico de la función de agregación COUNT es count(*) donde ponemos en las condiciones del WHERE qué es lo que queremos contar. Pero la sintaxis permite hacer mucho más y suele ser más eficiente que traer todos los datos y hacerlo desde nuestro propio código.

Al igual que una optimizada cadena de montaje en una fábrica, hay que crear una cadena de valor para que fluya eficientemente desde el inicio del desarrollo hasta la entrega real del valor al cliente. Tenemos que trabajar de forma continua toda nuestra value stream para que sea lo más rápida y fiable posible (PARTE 2).

Por qué no puede ser tan buena idea que nuestros datos maestros estén acoplados a una aplicación, y es mejor que estén centralizados en una única API.

Master Data Management (MDM) se puede traducir como Gestión de Datos Maestros, y su objetivo básico es organizar todos los datos críticos de la empresa en un solo punto.

Una reflexión personal en voz alta para ordenar mis ideas y encontrar claridad en lo que quiero hacer.

Muchas veces dije que comenzaba otra nueva etapa en el blog, pero nunca era el momento, que lo haré cuando tenga tiempo, y la verdad es que nunca lo tendré.

La falsa sensación de control de nuestros datos en las redes sociales. No es tan privado como nos lo cuentan

Qué son las deudas técnicas en el desarrollo de software, por qué pueden ser útiles y cómo deberías controlarlo