Javi Blog

Mi historia: Cómo la RCP me dio una segunda oportunidad

2025-01-19T18:18:00+01:00

En mayo de 2024 mi corazón se detuvo mientras salía un rato en bici 💔. No recuerdo ese momento, pero sé que gracias a una persona que inició una rápida reanimación cardiopulmonar (RCP) pude salvar mi vida y recuperarme por completo.

Desafortunadamente, las paradas cardíacas son más comunes de lo que pensamos y pueden ocurrirle a cualquiera de tu entorno. Y lo importante es actuar con rapidez y efectividad.

La RCP es una técnica que puede marcar la diferencia entre la vida y la muerte. Cada minuto que pasa sin recibir RCP reduce las posibilidades de supervivencia y aumenta el riesgo de secuelas graves. En mi caso, gracias a esa rápida actuación, mis opciones para recuperarme aumentaron considerablemente.

Ser testigo de una parada cardíaca puede ser una experiencia traumática, pero saber cómo actuar puede transformar una situación desesperada en una oportunidad para salvar una vida.

Motivado por esta experiencia, decidí actualizar mis conocimientos en RCP y aprender a utilizar los desfibriladores externos automáticos que se encuentran en muchos lugares públicos. Considero que todos deberíamos estar preparados para ayudar a otros en una situación de emergencia.

Espero no tener la mala suerte de encontrarme en esa situación, pero dado el caso estaré preparado.

APRENDE CÓMO HACER UNA RCP EFECTIVA Y EL USO DEL DESA

Sé que no es un tema del que se hable mucho, pero creo firmemente que la formación en RCP debería ser más accesible y ampliamente difundida. Al aprender esta técnica básica, no solo estás preparado para salvar la vida de alguien, sino que también te estás dando a ti mismo conocimientos para mayor tranquilidad de tu entorno cercano.

El aparativo verde que econtramos ya en muchos sitios (DES o DESA) es realmente muy fácil de usar, nano es peligroso ni para el accidentado ni el que lo manipula, y es capaz de indicar paso a paso lo que debes hacer en todo momento.

Si aún no has realizado un curso de RCP, te animo a que lo hagas. Encontrarás muchas opciones disponibles en línea y en centros de formación y asociaciones cercanos a ti. ¡Cada persona capacitada puede marcar la diferencia!

Os comparto un vídeo donde otra persona explica su historia:

❤️

Lecturas junio de 2023

2023-06-25T00:00:00+02:00

Selección de algunos temas y libros interesantes leídos durante este mes.

Serving Files in Python: How FastAPI failed us!
https://medium.com/@alsadi/secret-sauce-is-zero-copy-single-context-switching-b749bd614dca
¡Nuestra materia no es cuántica!
https://www.astronoo.com/es/articulos/nuestra-materia-no-es-cuantica.html
¿Gran Hermano o anarquía? El futuro que viene antes de que termine el siglo XXI
https://www.yorokobu.es/gran-hermano-o-anarquia/
Jugar con datos a tenis
https://www.titonet.com/estrategia-digital/jugar-con-datos-a-tenis.html
La sociedad datificada
https://ethic.es/2022/11/la-sociedad-dataficada-big-data/
LIBRO: El project manager del futuro: Claves para una gestión eficaz y humana de proyectos IT
https://www.goodreads.com/book/show/158088164-el-project-manager-del-futuro
LIBRO: Las ideas fundamentales del Universo: Espacio, tiempo y movimiento
https://www.goodreads.com/book/show/123514358-las-ideas-fundamentales-del-universo
Lecturas pasadas

Lecturas julio de 2021 - semana 25

2021-07-05T00:00:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

What Color is Your Function?
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
Swoole: Is it Node in PHP or am I wrong?
https://tsh.io/blog/swoole-is-it-node-in-php-or-am-i-wrong/
A Look at the New PHP 8.1 Fibers Feature
https://betterprogramming.pub/a-look-at-the-new-php-8-1-fibers-feature-979489399918
Fibers in PHP: A new opportunity for async PHP?
https://clue.engineering/2021/fibers-in-php
Continuation-passing style (CPS)
https://es.wikipedia.org/wiki/Continuation-passing_style
Asynchronous PHP — Multiprocessing, Multithreading & Coroutines
https://divinglaravel.com/asynchronous-php

<< Semana anterior Semana siguiente >>

Lecturas junio de 2021 - semana 25

2021-06-28T00:00:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

PHP Performance: Additional CPU cores vs Faster CPU cores
https://haydenjames.io/php-performance-additional-cpu-cores-vs-faster-cpu-cores/
Firefox 87 trims HTTP Referrers by default to protect user privacy
https://blog.mozilla.org/security/2021/03/22/firefox-87-trims-http-referrers-by-default-to-protect-user-privacy/

<< Semana anterior Semana siguiente >>

Programación asíncrona, hilos y bloqueos

2021-06-25T14:02:00+02:00

Una de las grandes ventajas de la asincronía es poder aprovechar mucho más eficientemente los recursos de la CPU. Esto es así porque los algoritmos pueden ejecutarse de forma concurrente y coordinada en diferentes hilos, permitiendo que un proceso no tenga que bloquearse necesariamente esperando el resultado de una operación que ha delegado.

Voy a centrarme en uno de los que más impacto tiene sobre el rendimiento, el bloqueo de hilos por operaciones de entrada y salida (E/S o I/O en inglés).

Con el auge de los micro-servicios, el cloud y otros recursos vía internet, el reto ya no es el acceso a disco o a la base de datos en la red local, sino el acceso desde nuestras aplicaciones a todos esos recursos aún más lentos.

En programación tradicional síncrona, cuándo el código llega a un punto en el debe realizar esta operación de E/S, el hilo que lo ejecuta se bloquea, esperando una respuesta o un timeout del recurso. Como comentaba en la gestión de hilos esto es costoso de gestionar a nivel de kernel, ya que ha de desalojar el hilo de código y alojar el siguiente.

Con la programación asíncrona se nos abre nuevas posibilidades para aprovechar mejor los recursos como atender más peticiones, lanzar otras peticiones en paralelo, refrescar información en pantalla, etc.

One-thread-per-request (un hilo por petición)

Por ejemplo, en el desarrollo de un servicio que atienden a un número concurrente de clientes, la mayoría de los lenguajes suelen emplear este modelo para la gestión de recursos, donde lanzamos un nuevo hilo para cada petición a nuestra aplicación.

Funciona bien cuando tenemos poca carga o esta es muy estable, pero su rendimiento cae rápidamente en entornos de mucha carga, por el exceso de trabajo de la gestión de hilos y el consumo de memoria que supone, ya que muchos de esos hilos se encuentran bloqueados.

Seguro que habéis visto alguna vez el error 503 Server busy, y es que el servicio ya no puede atender más peticiones hasta que no se desatasque.

Dos modelos para la implementación de la asincronía

Vamos a ver dos modelos para implementar la programación asíncrona y que aprovecha las ventajas de los lightweight threads, donde el intercambio de hilos es mucho más rápido y más liviano en el microprocesador.

Estos modelos gestionan sus bloqueos dentro del espacio de usuario (user-level) antes que ocurran y sean llevados al kernel.

1. Thread based

También llamados work-stealing permiten que los hilos puedan delegar las operaciones de E/S a un grupo de hilos especializados (worker-threads), quienes completan la tarea de forma independiente. Al terminar suelen invocar a una función callback establecida por el hilo invocador.

Cuando el hilo delega esa operación este puede continuar su ejecución de forma asíncrona sin que el proceso se bloquee, permitiendo un control de cómo ha de comportarse después de la llamada hasta recibir la respuesta, como seguir haciendo más operaciones, atender nuevas peticiones o ceder el turno al siguiente hilo del proceso.

Los hilos delegados que ejecutan las acciones de E/S terminan finalmente bloqueados, pero la diferencia es que el bloqueo solo se produce en ese grupo de hilos y no en los hilos solicitantes. El rendimiento del proceso aumenta de forma importante, pues es capaz de continuar su ejecución en lugar de estar detenido en espera de resultados.

El reto lo tenemos ahora en cómo retornar el control al hilo invocador desde el hilo delegado. Hay varias respuestas posibles: el resultado esperado, un error desde la operación remota, o bien un timeout porque que el recurso no ha respondido.

El método habitual son las conocidas funciones de callback donde el hilo finaliza devolviendo el control al primer hilo junto con un posible resultado como parámetro. Algunos lenguajes utilizan para construir este escenario implementaciones como Promises o Futures. También es posible registrar diferentes callbacks en función de si es una respuesta correcta o un error, por ejemplo onSuccess o onError, etc.

Problemillas con este esquema

Para este modelo suele planificarse una configuración previa de cómo inicializar el pool de worker-threads. En una carga estable y conocida es sencillo, pero para una carga indeterminada puede suponer o un desperdicio de recursos (si inicializamos de más) o problemas de recursos (si inicializamos de menos).

Por otro lado, el bloqueo de hilos sigue produciéndose dentro del proceso, aunque sean en otro grupo de hilos, teniendo que gestionarse aún ese esquema de bloqueos BIO (Blocked I/O) Para un gran volumen puede suponer un más que significativo uso de recursos.

Por ejemplo, en los famosos comparadores de servicios, digamos seguros, cada petición lanza a su vez 20 peticiones a diferentes compañías externas para recoger información para comparar. Una petición lanzaría 21 hilos, 1000 peticiones en un intervalo de tiempo serían 21.000 hilos. Se puede ver aquí el drama de la gestión de esta cantidad de hilos, en muchos casos bloqueados esperando respuesta.

Una forma de crecer en recursos es ampliar horizontalmente los servidores repartiendo esas 1.000 peticiones. Pero tenemos otra opción mucho más eficiente, NIO (Non-blocking I/O), Event based, o Reactive programming.

El objetivo con non-blocking I/O es evitar el crecimiento de una gran cantidad de hilos bloqueados.

2. Event based

En este modelo las operaciones de E/S se van a tratar como eventos dentro de la aplicación. La aplicación que necesita lanzar esta operación ya no necesitará crear un grupo de hilos separados para esto y su consiguiente gestión.

El sistema operativo suele ofrecer servicios para que las aplicaciones deleguen de forma asíncrona sus operaciones de E/S. Por ejemplo, en el caso de derivados de unix y según la distribución tenemos por ejemplo epoll. Estos toman la operación junto con un callback, y cuando obtiene el resultado interrumpe al hilo invocador y este último recupera la respuesta para continuar.

El hilo que registra esta operación no se bloquea y puede continuar su proceso. El sistema operativo puede ser mucho más eficiente que si se implementa esto a nivel de aplicaciones. Las aplicaciones por tanto no desperdician recursos para lidiar con todo esto, y tienen así la posibilidad de trabajar con una mayor carga con un código mucho más simple.

Nodejs utiliza este modelo basado en eventos en su implementación event loop. Utiliza un hilo único para gestionar una cola de peticiones e internamente gestiona la E/S utilizando los servicios de epoll del kernel, aunque hay otros como kqueue.

En esta ocasión no he querido profundizar mucho más en el artículo, porque para lo que buscaba conocer me pareció suficiente. Espero que sea útil. Y lo dicho, si hay errores o es confuso agradezco que me contactéis.

Lecturas junio de 2021 - semana 24

2021-06-21T00:00:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

Criptoeconomía: Bitcoin
  https://www.sumapositiva.com/p/bitcoin
La Era de los Datos (i): definiciones básicas
  https://www.titonet.com/estrategia-digital/la-era-de-los-datos-i-definiciones-basicas.html

<< Semana anterior Semana siguiente >>

Lecturas mayo de 2021 - semana 21

2021-05-30T23:53:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

CHAR(1) to boolean transformation while migrating to PostgreSQL
  https://www.migops.com/blog/2021/04/25/char1-to-boolean-datatype-transformation-while-migrating-to-postgresql
Le pire piège dans lequel tombent les développeurs
  https://www.jesuisundev.com/piege-developpeurs/

<< Semana anterior Semana siguiente >>

Lecturas mayo de 2021 - semana 18

2021-05-09T23:03:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

PostgreSQL at low level: stay curious!
  https://erthalion.info/2019/12/06/postgresql-stay-curious/
Evolution of tree data structures for indexing: more exciting than it sounds
  https://erthalion.info/2020/11/28/evolution-of-btree-index-am/
Dijkstra: El programador humilde
  http://nummolt.blogspot.com/2019/08/el-programador-humilde.html

<< Semana anterior Semana siguiente >>

Programadores humildes, martillos, clavos y Dijkstra

2021-05-09T22:00:00+02:00

Hoy he reservado tiempo para leer el discurso de Dijkstra: "The humble programmer" (El programador humilde). Quiero compartir esta breve reflexión porque 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?

¿Cuántas veces hemos llevado al límite nuestra recién aprendida herramienta martillo.io? Encajando desarrollos que fácilmente podrían haberse llevado a cabo con técnicas y tecnologías más adecuadas. Podemos hablar incluso del uso de frameworks, arquitecturas y metodologías como martillos; también infraestructuras diseñadas con martillo, ..., y seguro que podemos hablar de más casos similares y en otras profesiones.

Todo esto parte de uno de los argumentos de los seis que lista, para hacer notar que nuestro objetivo no es hacer programas sino construir soluciones que obtengan el comportamiento deseado. Este quinto argumento ha sido la base de esta breve reflexión.

Quien tenga la curiosidad del texto completo al final encontrarás el enlace.

Edsger W. Dijkstra

El programador humilde

(...)

El quinto argumento tiene que ver con la influencia de la herramienta que estamos tratando de usar sobre nuestros propios hábitos de pensamiento. Observo una tradición cultural, que probablemente tiene sus raíces en el Renacimiento, de ignorar esta influencia, considerar la mente humana como el maestro supremo y autónomo de sus artefactos.

Pero si empiezo a analizar los hábitos de pensamiento de mí mismo y de mis semejantes, llego, me guste o no, a una conclusión completamente diferente, a saber: Que las herramientas que estamos tratando de usar y el lenguaje o la notación que estamos usando para expresar o registrar nuestros pensamientos, ¡son los principales factores que determinan lo que podemos pensar o expresar!

El análisis de la influencia que los lenguajes de programación tienen en los hábitos de pensamiento de sus usuarios, y el reconocimiento de que, por ahora, la capacidad intelectual es, con mucho, nuestro recurso más escaso, juntos nos dan una nueva colección de criterios para comparar los méritos relativos de los distintos lenguajes de programación. El programador competente es plenamente consciente del tamaño estrictamente limitado de su propio cráneo; por lo tanto, aborda la tarea de programación con total humildad y, entre otras cosas, huye de los trucos ingeniosos como de la peste.

En el caso de un lenguaje de programación conversacional bien conocido, me han dicho desde varios lados que tan pronto como una comunidad de programación está equipada con un terminal para él, ocurre un fenómeno específico que incluso tiene un nombre bien establecido: se llama "las frases de una sola línea". Toma una de dos formas diferentes: un programador coloca un programa de una línea en el escritorio de otro y con orgullo dice lo que hace y agrega la pregunta "¿Puedes codificar esto con menos símbolos?", ¡Como si tuviera alguna relevancia conceptual! - o simplemente preguntar "¡Adivina qué hace!". De esta observación debemos concluir que este lenguaje como herramienta es una invitación abierta a trucos ingeniosos, y aunque exactamente esta pudiera ser la exposición pública de algunos de los recursos disponibles de aquellos a quienes les gusta mostrar cuán inteligentes son, lo siento, pero debo considerar esto como una de las cosas más condenatorias que se pueden decir sobre un lenguaje de programación.

Otra lección que deberíamos haber aprendido del pasado reciente es que el desarrollo de lenguajes de programación “más ricos” o “más poderosos” fue un error en el sentido de que estas monstruosidades barrocas, estos conglomerados de idiosincrasias, son realmente inmanejables, tanto mecánica como mentalmente. Veo un gran futuro para lenguajes de programación muy sistemáticos y muy modestos. Cuando digo "modesto", quiero decir que, por ejemplo, no solo la "cláusula for" de ALGOL 60, sino incluso el "bucle DO" de FORTRAN podrían verse expulsados por ser demasiado barrocos.

He realizado un pequeño experimento de programación con voluntarios realmente experimentados, pero algo bastante inesperado apareció. Ninguno de mis voluntarios encontró la solución obvia y más elegante. Tras un análisis más detallado, esto resultó tener una fuente común: su noción de repetición estaba tan estrechamente relacionada con la idea de una variable controlada asociada que se fuera incrementando, que se bloquearon mentalmente sin poder ver lo obvio. Sus soluciones fueron menos eficientes, innecesariamente difíciles de entender, y les llevó mucho tiempo encontrarlas. Fue una experiencia reveladora pero también impactante para mí.

Finalmente, en un aspecto, uno espera que los lenguajes de programación del mañana difieran mucho de lo que estamos acostumbrados hasta ahora: y en un grado mucho mayor que hasta ahora, deberían invitarnos a reflexionar en la estructura de lo que escribimos, en todas las abstracciones necesarias para enfrentar conceptualmente la complejidad de lo que estamos diseñando.

Hasta aquí en cuanto a la mayor adecuación de nuestras herramientas futuras, ha sido la base del quinto argumento.

Como comentario adicional, me gustaría insertar una advertencia para aquellos que identifican la dificultad de la tarea de programación con la lucha contra las deficiencias de nuestras herramientas actuales, porque podrían concluir que, una vez que nuestras herramientas sean mucho más adecuadas, la programación ya no ser un problema. La programación seguirá siendo muy difícil, porque una vez que nos hayamos liberado de la circunstancia engorrosa actual, nos encontraremos libres para abordar los problemas que ahora están más allá de nuestra capacidad de programación.

(...)

Créditos

ACM Turing Lecture 1972
(EWD340) The Humble Programmer by Edsger W. Dijkstra
https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

Fuente traducción: http://nummolt.blogspot.com/2019/08/el-programador-humilde.html

Lecturas abril de 2021 - semana 17

2021-05-02T23:58:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

What really happened at Basecamp
  https://www.platformer.news/p/-what-really-happened-at-basecamp
Spring Webflux: EventLoop vs Thread Per Request Model
  https://dzone.com/articles/spring-webflux-eventloop-vs-thread-per-request-mod
Practical SQL for Data Analysis: What you can do without Pandas
  https://hakibenita.com/sql-for-data-analysis

<< Semana anterior Semana siguiente >>

Hilos, concurrencia y programación asíncrona

2021-04-25T19:27:00+02:00

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 en este artículo es tratar de explicar algunos conceptos que me he encontrado sobre los hilos y cómo funcionan.

Empiezo definiendo un hilo como una secuencia de código a ejecutar. Cada hilo es seleccionado y llevado por turnos hacia el procesador iniciando así su ejecución. Esto se hace con un algoritmo planificador (scheduler) que será normalmente gestionado desde el sistema operativo (kernel).

Voy a ver algunas diferencias de los planificadores sobre cuando es delegado al sistema operativo (kernel-level), o cuando el planificador es un servicio proporcionado por el lenguaje o una librería, y que se ejecuta a nivel de usuario (user-level).

Pero un hilo también puede ser visto desde el punto de vista de un microprocesador, y como me fascina el funcionamiento de los micros he arañado un poco más para entrar a ver cómo es por dentro este asunto con el siguiente apartado.

El microprocesador y la concurrencia, y cómo es el multithreading

En un microprocesador también existe el concepto de hilos de ejecución. El micro no conoce el todo de un programa, solo se limita a ejecutar secuencias de código con un contexto que se inicializa en sus registros, básicamente para el acceso a memoria y comienzo de la ejecución.

Un micro con un núcleo sólo podrá ejecutar un único flujo de código (hilo), en cambio tenemos procesadores multi-núcleo pueden tener paralelismo real con varios flujos de código en ejecución (multi-hilo). Normalmente cada hilo tiene su propio direccionamiento, espacio de memoria, registros, etc., pero no siempre es así como veremos luego.

El sistema operativo es quién se encarga de repartir esos flujos de ejecución en los núcleos disponibles, gestionando la concurrencia de los procesos en una cola vía prioridades, estados, etc.

El multithreading de una CPU (HyperThreading en Intel, SMT en AMD, etc.) permite que un mismo núcleo pueda ejecutar 2 hilos independientes, pero con la particularidad de que esos dos hilos deben pertenecer al mismo proceso. Esto es así porque ambos hilos deben compartir el mismo contexto de ejecución como la cache, el espacio direccionamiento virtual, etc., aunque no sus registros.

Hasta aquí el fascinante mundo del microprocesador, pero luego veremos qué ventajas tiene eso de compartir el contexto entre hilos pertenecientes a un mismo proceso.

Procesos, hilos y fibras

En un ordenador pueden funcionar en paralelo muchos procesos correspondientes a unas cuantas aplicaciones y servicios del sistema operativo. Los procesos se pueden dividir en hilos de ejecución, un proceso con un único hilo es el caso más simple. La clave para la gestión de la concurrencia y la prioridad entre las aplicaciones estará en cómo y cuándo se hace el relevo entre los diferentes hilos en el procesador.

Tenemos dos estrategias básicas para estos relevos:

Preemptive multitasking, normalmente gestionado por el sistema operativo (kernel-level) y que en un tiempo predefinido, interrumpe al hilo para poner el siguiente sin tener en cuenta lo que está ejecutándose en ese momento.
Cooperative multitasking, el relevo lo lleva a cabo un planificador que está dentro del entorno de ejecución del propio proceso, vía librerías propias del lenguaje o facilitadas por el sistema operativo. Suele ser ejecutado a nivel de usuario (user-level), y donde se tiene la posibilidad de que un hilo pueda ceder su turno a otro hilo vía código. Las corrutinas son los casos más claros de esto último.

Esta estrategia cooperativa es una de las bases de la programación asíncrona. Aquí somos nosotros los que podemos controlar la concurrencia entre los hilos, ya sea directamente con sentencias deliberadas de paso de turno, o indirectamente delegando la gestión de los turnos al compilador o intérprete, que conoce bien la estructura de la aplicación.

La cooperación entre hilos nos permite optimizar mejor los recursos y prioridades, porque conocemos mejor que el sistema operativo cómo deben bloquearse y cuándo ceder el turno entre los hilos en ejecución.

Procesos (process)

Cuando lanzamos una aplicación, o un comando, o levantamos un servicio, a nivel del sistema operativo creamos un proceso (realmente a veces es un poco más complejo). El proceso se mantiene en ejecución hasta su finalización, pasando para el sistema operativo entre los estados de:

Listo para ejecución (otros procesos tienen la prioridad)
Suspendido (por ejemplo esperando el final de una operación de E/S)
En ejecución (le toca el turno de procesador)

Agrupa todo el código y los recursos necesarios como los apuntadores a ficheros, sockets, variables globales, espacio de memoria asignado, etc. Un proceso puede estar compuesto por varios hilos de ejecución concurrente, y muy importante, todos los hilos comparten el direccionamiento virtual y todos los recursos globales del proceso.

A partir de aquí vamos a ver al proceso como secuencias de hilos que son gestionados por el planificador del sistema operativo, que dirige la ejecución concurrente intercambiando los hilos disponibles. El momento de cambio ocurre principalmente por que se bloquea el hilo esperando un recurso de E/S o bien se le acaba el tiempo asignado (preemptive multitasking), se sustituye por el siguiente de la cola.

CEl desalojo de un proceso por otro es relativamente costoso porque supone guardar la tabla de direccionamiento (TLB), guardar el estado del proceso, su espacio de variables y recursos, invalidación de la cache del procesador, etc., y cargar todo lo anterior del siguiente proceso. Vamos, como desenchufar y recoger todo de la mesa porque viene otro a trabajar ahí.

Un motivo por el cual un sistema puede degradarse de forma significativa es cuando muchos procesos se bloquean y son suspendidos debido al acceso a recursos (ficheros o recursos de red). Esto provoca que tengan que ser desalojados y posteriormente recuperados, teniendo que dedicar el procesador demasiado tiempo con los cambios de contexto.

Una operación de cambio de un proceso puede llegar a consumir hasta 10⁶ ciclos de procesador y también supone un significativo gasto de memoria donde mantener todo el contexto de los procesos.

Hilos (threads)

Cuando un proceso se divide en diferentes hilos de código, todos se ejecutan de forma concurrente. Esta división tiene ventajas como que una operación bloqueante en uno de los hilos (como un acceso a un recurso) no tenga necesariamente que suspender el proceso completo.

También son especialmente útiles cuando un servicio lanza hilos (estática o dinámicamente) para atender a muchos clientes de forma independiente y concurrente para cada hilo. Estos comparten el código, sus variables y recursos globales, aunque no directamente su información local.

Otra ventaja de los hilos se da cuando el planificador desaloja un hilo por otro que también pertenece a un mismo proceso, es mucho menos costoso porque todos los hilos comparten toda la información del proceso, salvo la pila, registros y las variables locales del hilo si existieran. Un kernel moderno puede tener todo esto en cuenta y el cambio de contexto así es mucho más simple y rápido. En el ejemplo anterior de la mesa, me vale con llevarme mis cosas personales y dejar que el siguiente utilice el mismo ordenador, flexo, etc. pero abriendo su propia aplicación, el cambio es más rápido.

Vamos a diferenciar los kernel threads, user threads y fibers (fibras), estrategias para lidiar con la concurrencia y sobre todo con los costosos bloqueos de los hilos.

kernel threads
El sistema operativo puede ofrecer un servicio nativo de gestión de hilos que se ejecuta a nivel del kernel. El proceso crea y delega la gestión de la ejecución de los hilos al kernel. El funcionamiento es el que ya hemos visto para procesos. El sistema operativo puede aprovechar la ventaja de conocer qué hilos pertenecen a un mismo proceso para intercambios más eficientes de hilos, y también la posibilidad de aprovechar el multithread si está disponible.

Pero cuando el kernel interrumpe al hilo, no sabe en qué momento lo hace, se le acaba su tiempo y es desalojado. Por ejemplo cuando un hilo a punto de finalizar es desalojado y debe esperar a su próximo turno para terminar sus últimas instrucciones.

Esto es importante tenerlo en cuenta para cuando veamos el siguiente tipo de planificación basado en cooperative multitask y las ventajas que supone.

user threads
En estos casos no delegamos la gestión de los hilos directamente al sistema operativo, sino que disponemos de un planificador (runtime) en una capa por encima del kernel que decide que hilo del proceso dispone de acceso al procesador. Se denominan user threads porque ese planificador se ejecuta en el espacio de usuario (user-level).

La concurrencia de los hilos se pueden implementar de muchas formas, e incluso de forma híbrida usando los propios recursos del sistema operativo. Por ejemplo tenemos el concepto de los green threads o virtual threads, que no utiliza el sistema nativo del kernel para gestionar los hilos. En su lugar se utiliza un runtime o una máquina virtual del propio compilador / intérprete del lenguaje, tenemos por ejemplo la JVM de java.

Con este tipo de planificador el intercambio de hilos puede ser ajustado al máximo en función de lo que deba conservar como contexto entre los hilos involucrados. No es lo mismo una función invariante, una corrutina, un generador, etc. Así se permite al planificador utilizar la máxima eficiencia para desalojar el hilo anterior y alojar el siguiente. Esto significa por ejemplo que quizás no deba guardar y recuperar todos los registros del procesador para ese cambio de hilo.

Se suele utilizar la concurrencia cooperativa entre hilos, y es especialmente útil para la programación asíncrona. Piensa como los async, away, yield, etc., hacen posible esa concurrencia cooperativa anticipando cuando un hilo se bloquea o pasa el turno de ejecución a otro hilo.

Aún así las operaciones de E/S siguen suponiendo un reto, pero existen estrategias que permiten trasladar los bloqueos a otros hilos o procesos especializados a los que se delega esta ejecución, evitando el bloqueo del hilo principal que simplemente continua o es detenido de una forma más ordenada en favor de otros hilos. Podemos intuir aquí cómo pueden funcionar las Promises, Futures, ...

Para el sistema operativo los user threads son un hilo más que está ejecutando, todo lo que hace el planificador del lenguaje dentro de ese hilo cambiando flujos de código es completamente transparente para el kernel. Los sistemas operativos más modernos incluso ofrecen recursos para hacer todo esto de forma híbrida entre planificador del runtime junto con el kernel para mejorar la eficiencia y la seguridad.

fibers (fibras)
Dentro de los user threads y de la concurrencia cooperativa tenemos un tipo de hilos muy especializados donde suele emplearse el concepto de fibra (fiber). Son flujos de código que de forma cooperativa van pasándose el control entre ellos y el intercambio de hilos es notablemente más ligero a nivel de ciclos de procesador.

Son gestionados íntegramente dentro del espacio del lenguaje, creando, inicializando y lanzando las fibras necesarias. Las fibras no son una subdivisión de los hilos, más bien podemos verlos como una especialización más eficiente de hilos que se crean y que cooperan entre ellos.

Se asemejan mucho al concepto de corrutinas y son fragmentos de código que no suelen finalizar, se suspende y reanuda bajo demanda y puede ir acompañadas por una transmisión de datos, guardar estados previos o compartir datos entre ejecuciones.

_{Fuente: http://www.cs.us.es/~fsancho/?e=234}

Con las fibras podemos ver claramente como funcionan a bajo nivel los generadores, iteradores, listas infinitas, etc.

Espero haber sido claro y preciso en las explicaciones. Pero si no ha sido así, por favor, no dudes en ponerte en contacto conmigo.

Lecturas abril de 2021 - semana 16

2021-04-25T13:03:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

Asynchronous Programming with Thread Pools
  https://kislayverma.com/programming/asynchronous-programming-with-thread-pools-2/
Event-Based Asynchronous Programming
  https://kislayverma.com/programming/event-based-asynchronous-programming/
12 hábitos del pensador sistémico
  https://www.polymatas.com/habitos-pensador-sistemico/

<< Semana anterior Semana siguiente >>

Lecturas abril de 2021 - semana 14

2021-04-11T23:53:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

El arduo camino hacia el pensamiento complejo
  https://www.polymatas.com/camino-pensamiento-complejo/
Independence, autonomy, and too many small teams
  https://kislayverma.com/organizations/independence-autonomy-and-too-many-small-teams/
Overcoming IO overhead in micro-services
  https://kislayverma.com/programming/overcoming-io-overhead-in-micro-services/

<< Semana anterior Semana siguiente >>

Lecturas marzo de 2021 - semana 13

2021-04-05T20:42:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

La orquestación como una función estratégica clave en la empresa
  https://singularsolving.com/orquestacion-estrategica/
Una introducción a los sistemas complejos
  https://www.polymatas.com/introduccion-sistemas-complejos/
The Feynman Learning Technique
  https://fs.blog/2021/02/feynman-learning-technique/
Una internet más saludable es posible
  https://2020.internethealthreport.org/es-sinopsis-del-informe/

<< Semana anterior Semana siguiente >>

Lecturas marzo de 2021 - semana 12

2021-03-29T19:22:00+02:00

Selección de algunos artículos interesantes leídos durante la semana.

Data at Basecamp with Jane Yang
  https://www.speedwins.tech/posts/jane-yang-from-basecamp
C’est la faute du développeur
  https://www.jesuisundev.com/la-faute-du-developpeur/
Fastest Way to Load Data Into PostgreSQL Using Python
  https://hakibenita.com/fast-load-data-python-postgresql
Engineering for Performance: Ghost Queries
  https://blog.appsignal.com/2021/03/23/engineering-for-performance-ghost-queries.html

<< Semana anterior Semana siguiente >>

Lecturas marzo de 2021 - semana 11

2021-03-22T07:47:00+01:00

Selección de algunos artículos interesantes leídos durante la semana.

Por qué la sobrecarga cognitiva arruina tu aprendizaje
  https://www.polymatas.com/la-sobrecarga-cognitiva-arruina-tu-aprendizaje/
Stop Obsessing Over Development Velocity, Focus on This Instead
  https://itamargilad.com/velocity-vs-impact/
Wikipedia data engineering practices with Nuria Ruiz
  https://www.speedwins.tech/posts/some-words-with-nuria-ruiz
El pensamiento de segundo orden es tan escaso como necesario
  https://www.polymatas.com/pensamiento-segundo-orden/

<< Semana anterior Semana siguiente >>

Lecturas marzo de 2021 - semana 10

2021-03-14T20:35:00+01:00

Selección de algunos artículos interesantes leídos durante la semana.

Why is MongoDB’s SSPL Bad For You? 
https://www.percona.com/blog/2020/06/16/why-is-mongodbs-sspl-bad-for-you/
Why SSPL is Bad For You, Part 2 (+ elastic)
  https://www.percona.com/blog/2021/02/02/why-sspl-is-bad-for-you-part-2/
Out of Control (paradigms, refactoring, control flow, data, code)
  https://kevlinhenney.medium.com/out-of-control-97ed6efa2818
Large-scale filtering of data provides serendipitous surprises
  https://queue.acm.org/detail.cfm?id=3446917

<< Semana anterior Semana siguiente >>

Lecturas febrero de 2021 - semana 7

2021-02-22T23:07:00+01:00

Selección de algunos artículos interesantes leídos durante la semana.

When dev goes DevOps 
https://www.jesuisundev.com/en/when-dev-goes-devops/
L’incroyable ego des développeurs
  https://www.jesuisundev.com/ego-des-developpeurs/
Minimally Invasive (and More Accurate) Analytics: GoAccess and Athena/SQL
  https://brandur.org/minimal-analytics
Why did I create my own database?
  https://tiagosilvapereira3.medium.com/why-did-i-create-my-own-database-85efbb2a8bc8
Idempotent Receiver
  https://martinfowler.com/articles/patterns-of-distributed-systems/idempotent-receiver.html
The Raft Consensus Algorithm
  https://raft.github.io/

<< Semana anterior Semana siguiente >>

Lecturas febrero de 2021 - semana 6

2021-02-14T18:47:00+01:00

Selección de algunos artículos interesantes leídos durante la semana pasada.

Why I Built Litestream 
https://litestream.io/blog/why-i-built-litestream/
Managing developer identities in autonomous teams
  https://kislayverma.com/organizations/managing-developer-identities-in-autonomous-teams/

<< Semana anterior Semana siguiente >>

Lecturas febrero de 2021 - semana 5

2021-02-09T13:47:00+01:00

Selección de algunos artículos interesantes leídos durante la semana pasada.

Data Quality at Airbnb - Part 1 
https://medium.com/airbnb-engineering/data-quality-at-airbnb-e582465f3ef7
Data Quality at Airbnb - Part 2
https://medium.com/airbnb-engineering/data-quality-at-airbnb-870d03080469
¿Qué son los “unit economics” en una startup y por qué son importantes?
  https://www.kewlona.es/2021/01/unit-economics-en-una-startup/

<< Semana anterior Semana siguiente >>

Lecturas enero de 2021 - semana 4

2021-02-02T07:52:00+01:00

Selección de algunos artículos interesantes leídos durante la semana pasada.

El orden no es importante.

Construcción de un datalake in house 
http://dondeestaavinashcuandoselenecesita.com/2021/01/como-construir-data-lake.html
Charlando sobre slicing vertical
https://danilat.com/weblog/2021/01/27/product-slicing-lean-coffee
4 Types of Comprehensions In Python
https://towardsdatascience.com/4-types-of-comprehensions-in-python-2fbeafdf2fda
Python Lists vs Sets
  https://towardsdatascience.com/python-lists-vs-sets-39bd6b5745e1

<< Semana anterior Semana siguiente >>

Lecturas enero de 2021 - semana 2

2021-01-18T21:12:00+01:00

Selección de algunos artículos interesantes leídos durante la semana pasada.

El orden no es importante.

How we processed 12 trillion rows during Black Friday 
https://blog.tinybird.co/2020/12/21/how-we-setup-real-time-analytics-service-to-process-12-trillion-rows-during-black-friday/
Re-Introducing Hash Indexes in PostgreSQL
https://hakibenita.com/postgresql-hash-index
Some SQL Tricks of an Application DBA
https://hakibenita.com/sql-tricks-application-dba
Introducing Ray: a debugging tool for pragmatic developers
https://freek.dev/1868-introducing-ray-a-debugging-tool-for-pragmatic-developers
Microservices — architecture nihilism in minimalism's clothes
  https://vlfig.me/posts/microservices

<< Semana anterior Semana siguiente >>

Lecturas enero de 2021 - semana 1

2021-01-11T11:12:00+01:00

Selección de algunos artículos interesantes leídos durante la semana pasada.

El orden no es importante.

Porqué gestionar es patear culos 
https://lapastillaroja.net/2021/01/porque-gestionar-es-patear-culos/
La innovación cae en las manos equivocadas: no son los datos, son las personas
https://blogs.elconfidencial.com/tecnologia/tribuna/2021-01-01/digitalizacion-innovacion-kpmg-dee-hock-simon-sinek_2891776/
What I’ve Learned in 45 Years in the Software Industry
https://www.bti360.com/what-ive-learned-in-45-years-in-the-software-industry/
El role de un engineering manager: One on Ones
https://medium.com/@flopezluis/el-role-del-engineering-manager-one-on-ones-eb23bc24686a
El role de un engineering manager: Gestionando el bajo rendimiento
https://medium.com/@flopezluis/el-rol-del-engineering-manager-gestionando-el-bajo-rendimiento-cd3968dd69a5
El mayor cambio al convertirte en manager
  https://ivanmalagon.com/el-mayor-cambio-al-convertirte-en-manager

<< Semana anterior Semana siguiente >>

Lecturas diciembre de 2020 - semana 53

2021-01-04T11:44:00+01:00

Selección de algunos artículos interesantes leídos durante la semana pasada.

El orden no es importante.

PHP: Sunsetting Faker library 
https://marmelab.com/blog/2020/10/21/sunsetting-faker.html
What is Microsoft doing with Linux? Everything you need to know about its plans for open source
https://www.techrepublic.com/article/what-is-microsoft-doing-with-linux-everything-you-need-to-know-about-its-plans-for-open-source/
What Is Encryption at Rest, and Why Is It Important for Your Business?
https://brightlineit.com/encryption-at-rest-important-business/
Using JSONB in PostgreSQL: How to Effectively Store and Index JSON Data in PostgreSQL
https://dzone.com/articles/using-jsonb-in-postgresql-how-to-effectively-store
Bye bye Mongo, Hello Postgres
  https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres

Siguiente semana >>

Lectura del libro "The DevOps Handbook"

2020-11-01T00:01:00+01:00

The Devops Handbook (1/4)

Autores: Gene Kim, Jez Humble, Patrick Debois, & John Willis

Estuve leyendo durante varias semanas el libro The DevOps Handbook. 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 IT que le suene bien el término "value-driven" debería tomar muy en cuenta los principios DevOps.

Como se define en la wikipedia, DevOps es un conjunto de prácticas que combina el desarrollo del software y a las operaciones de IT para su despliegue y puesta en marcha. El libro entra a fondo en los detalles fundacionales que trataré de explicar en siguientes posts.

Para empezar, no es un perfil, ni es el nuevo título para un rol de operaciones, se trata de construir (de forma iterativa) una arquitectura de trabajo para que el desarrollo de software sea cada vez más ágil, fiable y seguro. Pasando del miedo a mover una especie de bomba en cada despliegue, a la seguridad de un entorno extremadamente robusto y amigable. Así como disponer de herramientas que facilitan el aprendizaje y la experimentación de todo lo que pasa en nuestro sistema.

En resumen implementar un pipeline de trabajo utilizando la automatización del trabajo repetitivo y eliminación de procesos que aportan muy poco, desde el desarrollo hasta producción, a través de testing continuo y monitorización. Participando en este pipeline todos los actores implicados en el proceso.

Una analogía que podemos ver en este vídeo de youtube.

DevOps se ha basado en los Principios Lean, la Teoría de las Limitaciones, el Sistema de Producción de Toyota, entre otras fuentes relativas al aprendizaje, ingeniería de resiliencia, seguridad psicológica en el trabajo, etc.

Una cadena de valor (término fundamental en DevOps) es sencillo de ver en los procesos una fábrica. En DevOps, una cadena de valor (tecnológica) consiste en convertir una hipótesis de negocio en un sistema tecnológico que entrega valor real al cliente de forma sistemática.

Fuente: winwire.com

Existe en muchas empresas un enfrentamiento tradicional de objetivos entre Desarrollo que pretende entregar nuevo software (valor), y Operaciones que quiere tener los entornos lo más estables y seguros posible (mantener). Existe así una frontera de facto entre lo que ocurre en desarrollo y lo que ocurre en producción, donde ni unos ni otros disponen de la visión completa de ese valor que se pretende entregar. Sin un buen alineamiento de incentivos y metas, cada equipo se centrará en sus propias metas.

Objetivo

El objetivo principal es reducir el tiempo de entrega de valor desde que se decide hasta que ya está a disposición del cliente, también llamado “lead time”. Esto se consigue orquestando un flujo del trabajo de desarrollo eficiente y muy automatizado, con una información inmediata de lo que está ocurriendo con nuestro código y disponiendo de un entorno robusto donde poder extraer fácilmente información y resultados de experimentación, aprendiendo así con los mínimos riesgos posibles.

La meta es conseguir un flujo altamente eficiente para el desarrollo: testing, despliegue y feedback inmediato del nuevo despliegue, permitiendo corregir o mejorar gracias al nuevo conocimiento adquirido de la observación en producción. Entendible rápidamente gracias a que el lead time es a corto plazo y no de meses o años. Un código escrito hace meses y que se despliega hoy es mucho más difícil de corregir las intenciones que uno reciente.

Una compañía con una implementación DevOps fuerte tendrá un equipo técnico de alto rendimiento, más satisfechos con su trabajo, con menos miedos ya que el entorno es más robusto y es más fácil de detectar problemas, y será rápido de arreglar en caso de que las cosas no vayan del todo bien. Los costes de los errores son mucho más asumibles gracias a una alta velocidad de resolución y un entorno más amigable para recolectar información y aprendizajes.

Estructura del libro

El libro se divide en 3 caminos (the three ways) que hay que recorrer:

Primer camino: Principio de Flow
Acelerar la entrega de valor al cliente.
Segundo camino: Principio de Feedback
Nos permite crear sistemas de trabajo cada vez más seguros.
Tercer camino: Principio de Aprendizaje Continuo y Experimentación
Fomentar una cultura de alta confianza y un enfoque científico para la mejora de los procesos.

The DevOps Handbook: Principio de Continual Learning

2020-10-25T09:29:00+01:00

The DevOps Handbook: Principio de Aprendizaje continuo y Experimentación (4/4)

Última parte del libro The DevOps Handbook

El último principio nos indica el camino para mejorar como desarrolladores y como equipos mediante la creación de una cultura que lo propicie. Estructuras extremadamente rígidas y caminos muy marcados pueden impedir descubrir nuevo conocimiento y mejoras. Una cultura del miedo basada en temer castigos o reprimendas públicas incide directamente en la seguridad psicológica del equipo, pues paraliza la experimentación o encontrar otras maneras de hacer las cosas.

Por el contrario en equipos de alto rendimiento, con altas dosis de libertad y seguridad para la búsqueda de otros enfoques, les permiten encontrar nuevos caminos que nos llevan a mejorar los resultados de nuestra cadena de valor. Los errores deben ser vistos como una inversión controlada, destinos intermedios para alcanzar la excelencia individual y de equipo.

Nuestro entorno de trabajo debe estar diseñado de forma que los errores sean fácilmente asumidos y corregidos en nuestro flujo (Flow), rápidamente detectado y entendida su naturaleza (Feedback) y extracción de aprendizaje del accidente (Continual Learning and Experimentation) Lo contrario impide salirse de los caminos marcados porque quizá los errores son costosos de solucionar en nuestro flujo de trabajo (no Flow), difícil de detectar y comprender las implicaciones del error (no Feedback) y evitar todo lo posible aventurarse a terrenos fuera del camino (no Learning & Experimentation)

El camino del Aprendizaje y Experimentación no es gratuito, debemos reservar tiempo para ello. Debe ser una actividad definida y planificada donde el aprendizaje del resultado (positivo o negativo), sea un aprendizaje no solo individual si no que se transmita a toda la organización, permitiendo nuevos avances gracias al conocimiento extraído.

En entornos estables es incluso muy útil provocar errores o problemas ficticios para entender como se comporta nuestro sistema y nuestra organización, probando cómo reaccionamos y posteriormente qué debemos cambiar para incrementar nuestra resiliencia.

Entorno de seguridad psicológica y abierto al aprendizaje

Un entorno poco seguro en una empresa de tecnología es devastador dada la naturaleza de entornos complejos que suelen llevar entre manos. En organizaciones poco propicias a una cultura de seguridad suelen esconderse los problemas y huir hacia delante, hasta que la situación se vuelve insostenible haciendo mucho más costosas y dramáticas las soluciones de los problemas y futuros cambios (deuda técnica).

Ron Westrum categoriza tres tipo de organizaciones:

Organizaciones patológicas: Altas dosis de miedo y amenazas. La información no se comprarte y se esconden los problemas.
Organizaciones burocráticas: Muchas reglas y procesos, a menudo internos por departamentos o equipos. Los fallos son achacados a incumplimientos de dichas reglas o procesos que no animan a salir del camino.
Organizaciones generadoras: Organizaciones que activamente buscan nuevos caminos y formas de hacer las cosas, compartiendo los aprendizajes y responsabilidades de los errores y aciertos.

Patológicas	Burocráticas	Generadoras
Orientada al poder	Orientada a las reglas	Orientada a resultados
Información escondida	Información ignorada	Información buscada
Baja cooperación	Moderada cooperación	Alta cooperación
Responsabilidades eludidas	Responsabilidades compartimentadas	Riesgos y responsabilidades compartidos
Mensajeros despreciados	Mensajeros rechazados	Mensajeros entrenados
Desalentando puentes entre equipos	Tolerado puentes entre equipos	Alentando puentes entre equipos
Culpabilización de los errores	Judicialización de los errores	Investigación de errores
Novedad arruinada	Novedad que lleva a problemas	Novedad implementada

Reservar tiempo para la mejora del trabajo diario

Si no tenemos espacio para mejorar nuestro trabajo y procesos, no será posible progresar y evitar errores. Incluso puede ir degradándose con el tiempo. Mike Orzen, autor de Lean IT dice que "Incluso más importante que nuestro trabajo diario es la mejora de nuestro trabajo diario".

No disponer de tiempo para pagar nuestras deudas técnicas ni tiempo para probar alternativas, pone en peligro y empobrece respectivamente nuestro trabajo diario.

Transformar descubrimientos locales en mejoras globales

Cuando nuevos aprendizajes emergen en nuestro trabajo deben existir mecanismos y espacios que permitan que el nuevo conocimiento adquirido fluya a todo el equipo y a la organización.

Ejemplos: fomentar los post-mortem después de un problema importante encontrado, o incentivar la experimentación y compartir públicamente los resultados con la organización.

Uno de los mecanismos es disponer de repositorios accesibles en la organización donde encontrar toda la información de los post-mortem, experimentos, código, librerías compartidas, etc. Incluso totalmente públicas.

Líderes que refuerzan la cultura del aprendizaje y experimentación

Los líderes deben allanar el camino para que el equipo pueda mejorar su trabajo diario, facilitando un entorno que permita todo lo comentado anteriormente. Deben permitir que los cambios ocurran, en pequeños incrementos y siempre con la complicidad del equipo y la organización.

Otro de sus papeles como líderes es ayudar a los compañeros estilo coaching mediante la tutorización de los experimentos, hipótesis, alternativas, etc. No tanto para evitar errores sino para incentivar ofreciendo seguridad arropando el emprendimiento del experimento, y ayudar a elegir las batallas correctas.

The DevOps Handbook: Principio de Feedback

2020-10-17T20:53:00+02:00

The DevOps Handbook: Principio de Feedback (3/4)

Tercera parte del libro The DevOps Handbook

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 nuestra cadena de valor y nuestro sistema. Con estos datos podremos reaccionar rápido y mitigar las posibles consecuencias de un error durante nuestro trabajo. También la oportunidad de aprender cómo se desenvuelve nuestro sistema y evitar cometer los mismos errores.

Esta información debe obtenerse fácilmente, ser rápida, precisa y frecuente para no llegar demasiado tarde o darnos pereza en la búsqueda. Idealmente nuestro cliente ni debe enterarse de nuestros problemas con el despliegue de una nueva funcionalidad. El peor escenario es que tenga que ser él quien nos alerte de que nuestra cosa no funciona, con las consecuencias que eso conlleva.

Si detectamos en fases tempranas el problema, más sencillo y barato será arreglarlo. Cuanta más granularidad y relación tengamos entre toda la información recopilada, más directa, rápida y precisa será la solución que haya que aplicar, y menores las consecuencias del error que haya que reparar.

El feedback no solo es a nivel de errores técnicos o de diseño, sino también información de cómo está funcionando nuestro flujo de trabajo. Una información clave por ejemplo es detectar un cuello de botella o fallos en un punto concreto, si no se resuelve rápidamente hará que toda la cadena se resienta. Y cuanto más tardemos más complicado será solucionarlo pues habrá ido avanzando por todo el flujo.

Trabajar con seguridad en sistemas complejos

Una de las características típicas de los sistemas con los que trabajamos es que suelen ser complejos. Con tantos componentes y todos los posibles caminos que pueden tomar, los fallos se vuelven inevitables por dicha complejidad. Es difícil para alguien conocer el detalle suficiente para poder prever todos los posibles puntos de fallo. Esto hace que los errores sean desgraciadamente habituales, especialmente en el momento de los cambios.

Un buen diseño de una telemetría de las aplicaciones y de los sistemas es fundamental, si nos permite alertas tempranas de los problemas hará que podamos trabajar con mucha mayor confianza y seguridad.

Ver los problemas a medida que ocurren

Tenemos que poder validar nuestras decisiones de implementación o diseño lo más pronto posible. Esto solo ocurre si disponemos de ese feedback inmediato y automatizado del sistema. Debemos construir un flujo bidireccional entre nuestro trabajo y la información obtenida al integrarlo, actuando con la nueva información en mejorar de iterativamente el trabajo hasta obtener el resultado esperado.

En contraposición tenemos el waterfall en el cual después de muchas semanas o meses de trabajo, en la primera integración los problemas son más difíciles de abordar por su tamaño y por el tiempo que hace que se decidieron e implementaron las cosas, haciendo todo mucho más costoso.

Es también importante tener una alta calidad en la información obtenida en todas las fases de nuestro flujo de trabajo, los defectos y desviaciones del objetivo se encuentran así fácil y rápidamente. Solo con información completa y fiable podremos realmente aprender y conseguir mejorar nuestro trabajo.

Parada de emergencia

Cuando algo va mal y aparecen errores o problemas importantes en nuestro value stream, debemos parar y ponernos todos a investigar las causas y aplicar las mejoras necesarias para solventarlo. Esto permite un aprendizaje global inmediato del problema, sus implicaciones y posibles relaciones con otros procesos, y lo que es fundamental es que se aborda en sus fases más tempranas y el problema no va avanzando por la cadena.

Es un error, por ejemplo, aparcar una solución (deuda técnica) hasta un momento en el que ya es más complicado solucionar, donde se han integrado encima más cosas y donde el tiempo ha hecho mella en nuestro entendimiento del problema. Si lo dejamos pasar solo conseguiremos tener más adelante nuevas tareas y más complicadas.

Un ejemplo podemos verlo con la integración continua cuando rompemos los tests, si la solución no es obvia todo el equipo debe ponerse a trabajar codo con codo con el responsable de la rotura para solucionar el problema, permitiendo que emerja un nuevo aprendizaje, sobre todo para el responsable del error. Una parada necesaria de la cadena de trabajo para que luego todo vuelva a continuar con el ritmo esperado.

Aunque parezca poco intuitivo, detectar problemas importantes en fases tempranas y parar la maquinaria para resolver problemas es la manera más efectiva y barata de que los errores no vayan creciendo de manera incontrolada y oscura, así como una buena oportunidad para aprender cómo funciona realmente nuestro sistema.

Trabajar la calidad en la misma fuente

De poco sirve que solo un equipo de calidad revise nuestro trabajo semanas después, a la vuelta posiblemente hayamos olvidado información importante que nos permita entender el porqué se tomaron dichas decisiones. En su lugar debemos proporcionar todas las herramientas necesarias para comprobar la calidad del trabajo en el mismo sitio donde se produce.

Por ejemplo con tests automáticos profundos y feedaback inmediato de las pruebas que revisan que el nuevo código es correcto, se integra correctamente, es eficiente y no tiene problemas de seguridad. Con esta información el programador tiene la certeza de que su cambio no tiene implicaciones negativas, y si las tiene entonces consigue nuevo conocimiento del por qué para futuras decisiones. La inmediatez del feedback permite que los cambios que deba hacer sean minutos después, no dentro de varios días o semanas.

De poco sirve acabar una tarea sin tener completa certeza de que funcionará correctamente en un sistema más grande. Solo podríamos asegurar con tests unitarios y parciales que la nueva funcionalidad cumple con la salida esperada, pero poco más. También tiene poca utilidad preparar un elaborado informe de pruebas o documentación de implementación que otro equipo leerá tiempo después ya desfasado, y que posiblemente no haya tenido en cuenta otras funcionalidades adicionales que desconoce.

Es muy importante que el equipo conozca la motivación de una funcionalidad y no solo un resultado esperado, así el trabajo será mucho más certero y menos idas y vueltas tendrá la integración de los componentes, mejores pruebas de la funcionalidad por parte del desarrollador o integrador, y no meras pruebas del código. Soluciones hay muchas pero correctas para el negocio serán menos.

Posibilidades de la función COUNT de SQL

2020-10-17T10:32:00+02:00

Cosas que se pueden hacer con la función SQL COUNT()

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 y listo. Pero la sintaxis de COUNT y SQL permiten hacer muchas más cosas y además suele ser más eficiente que traer todos los datos y hacerlo desde nuestro propio código.

La sintaxis de los ejemplos mostrados aquí es para MySQL pero es similar con PostgreSQL, Oracle, MSQL, etc.

Contar todas filas de una query

Esta es la más común, contar las filas devueltas por una sentencia SQL:

SELECT COUNT(*) FROM products WHERE active=1

Agrupando por una o varias columnas

También bastante común agrupar por columnas y devolver la cuenta de cada una:

SELECT price, COUNT(*) FROM products GROUP BY price

Agrupa cada uno de los valores distintos de price y nos muestra cuantos hay de cada valor.

Teniendo en cuenta una columna

Veamos la siguiente variante donde cambiamos el * (que se refiere a todas las filas) por un campo concreto:

SELECT COUNT(price) FROM products

En este caso lo que hará es devolvernos la cuenta de todas las filas cuyo campo price no sea null (el 0 no es nulo). Similar a:

SELECT COUNT(*) FROM products WHERE price IS NOT NULL

Cuantos elementos distintos hay en una columna

Obtención del número de valores diferentes de una columna.

SELECT COUNT(DISTINCT price) FROM products

Agrupa todos los elementos price distintos y que no sean nulos, contamos así el número de elementos diferentes de la columna. También es posible añadir una expresión en lugar de un campo como veremos a continuación.

Contar con expresiones

La función COUNT permite no solo campos sino también añadir expresiones con IF, IFNULL y CASE. Vamos con un ejemplo:

SELECT COUNT(IF(declared = 'new', 1, NULL)) FROM products

Como sabemos, COUNT cuenta elementos no nulos, lo que hacemos con la expresión es anular lo que no cumple nuestra condición y contará solo resultados cuya condición devuelve un valor no nulo. De forma análoga se puede reescribir como:

SELECT COUNT(CASE WHEN declared = 'new' THEN 1 ELSE NULL END) FROM products

SELECT COUNT(*) FROM products WHERE declared='new'

Pero una de las ventajas de utilizar expresiones en COUNT (u otras funciones de agregación que permiten expresiones) es poder calcular diferentes resultados en una misma query, y si tiene un índice asociado aprovecharnos de las ventajas que esto conlleva. Por ejemplo:

SELECT
    COUNT(IF(declared = 'new', 1, NULL)) nuevos,
    COUNT(IF(declared = 'used', 1, NULL)) usados,
    COUNT(IF(declared = 'broken', 1, NULL)) rotos
FROM products

Suponiendo que tenemos un índice sobre el campo declared aprovecharemos una respuesta más eficiente de la base de datos en lugar de obtener millones de productos y recorrer nosotros mismos los resultados para clasificar los diferentes valores; o evitando lanzar 3 queries diferentes. Si no existe índice asociado la base de datos tendrá que leer toda la tabla para calcular el resultado.

Otro ejemplo:

SELECT
    COUNT(IF(declared = 'new', 1, NULL)) nuevos,
    COUNT(IF(active = 1, 1, NULL)) activos
FROM products

Aquí estamos utilizando dos campos diferentes, y en el caso de MySQL que solo utiliza un índice, tendría que hacer un fullscan de la tabla para obtener los resultados, salvo que tengamos un índice compuesto sobre esos dos campos en cuyo caso sí obtendríamos las ventajas de utilizar un índice para esos dos COUNT.

Otras funciones de agregación y más expresiones

En SQL tenemos otras funciones de agregación como son AVG, MAX, MIN, SUM, STD, etc. que también pueden hacer uso de las expresiones que hemos visto para COUNT. Un ejemplo:

SELECT
    COUNT(IF(price > 0 AND active = 1, 1, NULL)) en_venta,
    COUNT(IF(price = 0 OR active = 0, 1, NULL)) nulos,
    MAX(IF(active = 1, price, 0)) precio_max,
    AVG(IF(price > 0 AND active = 1, price, NULL)) precio_medio,
    SUM(IF(price > 0 AND active = 1, price, 0)) suma_total
FROM products

NOTA: Para AVG los valores nulos no se tienen en cuenta para la media, en el ejemplo anterior se utiliza NULL para ello y la expresión descarta así precios 0 o negativos. Si utilizáramos un 0 en lugar de NULL (como el caso de SUM), esos 0 se tendrían en cuenta en el cálculo de la media.

Conclusión

Suele ser útil delegar a la base de datos muchos de los cálculos, evitamos el tráfico de datos entre la base de datos y la aplicación si realmente solo queremos obtener una estadística. Si además tenemos una correcta estrategia de índices aprovecharemos la eficiencia de la base de datos para realizar este trabajo.

The DevOps Handbook: Principio de Flow

2020-10-03T20:01:00+02:00

The DevOps Handbook: Principio de Flow (2/4)

Segunda parte del libro The DevOps Handbook

Una de las claves que veremos en este principio es la reducción del tiempo para desplegar cambios o nuevas funcionalidades, reduciendo la complejidad y el tiempo necesario para disponer de un incremento de valor en producción, el lead time. Pequeños incrementos donde toda la cadena trabaja con un único objetivo global, no en diferentes objetivos aislados según el equipo.

Fuente: cloudbees.com

Las claves de este principio son las siguientes:

Hacer el trabajo visible

Una clara diferencia entre el trabajo de una fábrica y el nuestro es que en la fábrica el flujo trabajo es visible y en cierta manera previsible. Para ver como fluye el trabajo en nuestra value stream debemos conseguir algo similar. Solo así podremos ver qué lleva más tiempo, dónde se bloquea o la cantidad de trabajo pendiente.

Ejemplos pueden ser los tableros kanban o de sprint planning, o las múltiples re-implementaciones de tableros que nos permiten visualizar y medir en qué punto se encuentra el trabajo.

Sólo de esta manera los stakeholders pueden ser capaces de conocer el volumen, las dificultades o priorizar mejor en función del trabajo pendiente. También podremos así proponer mejoras en los puntos más problemáticos, como hacer mejoras en nuestra cadena de trabajo o dar más apoyo donde realmente es necesario.

Limitar el trabajo en curso (WIP)

WIP: Work In Progress

En los equipos de desarrollo es común la llegada urgencias como errores, necesidades imperiosas, ocurrencias. Imaginemos el coste en el caso de una fábrica cuya cadena de producción se interrumpa de esa forma.

En el caso de tecnología el coste de las urgencias suele ser muy poco visible y además por desgracia ya presuponemos los retrasos de los proyectos software. Pero, ¿y si conseguimos eliminar de la ecuación los retrasos por trabajo no planificado?

Debemos evitar la existencia del trabajo en paralelo, cada cambio de contexto supone un esfuerzo y un tiempo perdido, que por desgracia también resta energía porque tenemos que lidiar con el multitasking para volver una y otra vez al trabajo principal.

Reducir el tamaño del trabajo

Otra de las claves para un flujo suave y ágil es reducir el tamaño del bloque de trabajo. En lugar de disponer un gran bloque que lleva meses desarrollar, es mucho más eficiente pequeños bloques de días o pocas semanas hasta ponerlo en producción.

Una de las claves Lean en reducir los tiempos de entrega y el aumento de la calidad, y se consigue disminuyendo el tamaño los bloques de trabajo. Grandes bloques pueden provocar una mayor presión sobre los trabajos en curso (WIP), una pérdida de calidad del resultado y unos tiempos de entrega muy altos.

Un ejemplo para el nuestro caso, trabajar con bloques pequeños donde podremos codificar, testear y desplegar de una forma rápida, y recibir información de su integración en producción de forma rápida. Esto nos permite resolver de forma casi inmediata cualquier incidencia o deuda técnica, ya que tenemos fresco el contexto de trabajo. El incremento de calidad así es más que notable.

Reducir el número de pasos (transferencia entre equipos)

Cada vez que se transfiere trabajo de un equipo a otro se requiere comunicación, reuniones, coordinación, verificaciones, etc., en resumen, se añade tiempo extra y cierta pérdida de información entre las transferencias.

En nuestra cadena de trabajo podemos reducir el número de transferencias automatizando procesos del flujo de trabajo, y reorganizando los equipos para permitir mayor autonomía en la entrega de valor al cliente desde su inicio hasta el final.

Identificar limitaciones de nuestro flujo y resolver de forma continua

Cuando en nuestra cadena de trabajo existe una limitación importante, debemos abordar una solución para resolver esa restricción. Algunos casos de nuestro flujo de trabajo con el desarrollo pueden ser:

Disponer de un entorno de trabajo automatizado self-service, donde no tendremos que dedicar tiempo para configurarnos uno, o depender de que alguien nos provea de dicho entorno para trabajar, testear, etc.
Automatizar el despliegue del código, donde están automatizados todos y cada uno de los pasos que hay que seguir para poner nuestro código en producción, en un tiempo mínimo y con una seguridad controlada.
Automatización de tests, en lugar de tener flujos de tests manuales propios o delegar todo a equipos dedicados, automatizar la gran mayoría de ellos para que puedan ser ejecutados bajo demanda o durante los despliegues.
Arquitectura desacoplada, proveer de mayor autonomía para completar los cambios, eliminando dependencias que no aportan valor y mejorando también la productividad del desarrollador.

Eliminar dificultades y pérdidas de tiempo de la cadena de valor

Esto es otro de los principios Lean: eliminar actividades que no mejoran el resultado de ninguna manera.

En el caso del desarrollo:

Trabajo parcialmente acabado, debemos evitar llenar nuestro WIP de tareas inacabadas que solo hacen ruido pero que no aportan nada. Se vuelven obsoletas y pierden valor con el tiempo.
Extra-procesos, tareas o actividades que no añaden nada al resultado, como pueden ser documentación no necesaria, revisiones o aprobaciones que no aportan nada.
Extra-funcionalidades, añadir mayor complejidad y esfuerzo en requerimientos no solicitados que luego requerirán de revisiones, testing o mantenimiento.
Multitasking, añadir varias tareas a una misma persona, que como ya hemos visto antes supone una pérdida de tiempo con los cambios de contexto y de calidad por la pérdida de foco.
Esperas, evitar retrasos por paradas que impiden un flujo continuo, esto puede incentivar el multitasking.
Movimiento, trasladar trabajo entre personas o equipos requiere de tiempo de comunicación y esfuerzo de transferencia de información. Evitar el traspaso de tareas hace ganar tiempo y eficacia.
Información defectuosa, información incorrecta, parcial o compleja genera derroche de tiempo en solucionar posteriormente errores, que cuanto más tarde se detecten más tiempo conlleva.
Trabajo manual o no habitual, todo proceso que no puede automatizarse o se realiza forma no habitual, suele significar pérdida de tiempo y riesgos.
Trabajo heroico, cuando un flujo de trabajo está bien establecido no es normal que haya actos de trabajo extraordinarios para llevar adelante una puesta en producción. Esto resta energía y entusiasmo al equipo, especialmente cuando se vuelven habituales.

Ley de Conway

Formulado en 1967 por un programador llamado Melvin Conway:

Las organizaciones dedicadas al diseño de sistemas [...] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones.

Esto nos viene a indicar que según las estructuras de los equipos así podría ser el diseño de nuestras aplicaciones, como ejemplo nos ilustra como un equipo hizo un compilador que se ejecutaba en una fase, mientras otro equipo hizo lo propio en dos fases porque tenían su equipo dividido en dos grupos.

Es posible que si diseñamos un proceso basado en cómo se hace actualmente, por ejemplo si tratamos de automatizar el trabajo manual de un almacén, si trasladamos el conocimiento tal cual, nuestro diseño será tan eficiente o ineficiente como el procedimiento original.

Reflexión y un ejercicio de claridad

2020-08-19T12:13:00+02:00

Llevo semanas con algo dando vueltas por mi cabeza y necesito escribirlo y explicarlo para ordenar mis ideas.

En mi trabajo actual hay cambios importantes en el sentido que tenemos mucho por hacer pero también mucho que definir, y todo está mezclado. No podemos parar, pero tampoco podemos dejarnos llevar sin más. Lo más fácil siempre es atender a las urgencias para calmarlas y resolver el problema acuciante de turno, y por desgracia entro demasiadas veces al juego. Es lo más sencillo y da la tranquilidad inmediata de que estás con algo. Pero sabes que no.

Me considero buen técnico, capaz de resolver muchos problemas gracias a una buena base de conocimiento, la curiosidad, y de experiencia adquirida. Pero me he dejado llevar por el torbellino en varios de los trabajos que he tenido, porque mis compañeros y jefes consideraban también que era lo importante, así que mi experiencias no han sido tan completas. Hasta ahora.

En la vida es necesario que te quiten el suelo de vez en cuando para que tengas que prestar atención. A veces tienes que golpearte contra el muro un par de veces o más. Hay que dejar que se quemen algunas cosas que parecían importantes pero que una vez quemadas ves que no era tan vitales.

Hay que investigar el por qué se incendian y no gastar el tiempo solo en apagar esos fuegos, que muchas veces dan igual porque alguien o algo prenderá de nuevo la mecha. Me preparé como ingeniero para construir buenas soluciones, no para ser un héroe del día a día.

Uno de los mejores ejercicios que he hecho ha sido plantearme dónde quiero ir realmente, qué quiero hacer. Este ejercicio de Claridad es la base fundamental para ir a parar a algún sitio de forma consciente. Tratar de resistir donde no quiero ir. Evitar llegar de casualidad. Dando muchas vueltas he llegado a veces a sitios interesantes, y está bien, pero creo que cuando se toma el timón se disfruta mucho más, y el resultado es mucho más placentero.

Qué tiene que ver saber lo que quiero con lo que estoy haciendo, pues tan simple como dificultar el hecho de dejarme llevar. Entrar más fácilmente en las contradicciones de lo que quieres sobre lo que haces realmente. Si te acercan o no a tus objetivos.

Este ejercicio de lo que quiero hacer no puede cubrir solo la parte profesional, sino que parte desde lo más personal que ya no va por separado. Ahora es una tarea recursiva de alinear lo que quiero sobre los siguientes pasos a dar, de cumplir un plan o reconstruirlo cuando cambia. Y esto es más fácil cuando ya sabes donde quieres ir.

Las redes sociales y la privacidad

2014-09-16T12:41:00+02:00

Sobre este tema se han escrito muchísimos bytes, pero yo también quiero escribir sobre mi punto de vista personal. Llevo trabajando en temas de redes sociales desde hace ya más de 4 años, cuando mi socio Álex y yo decidimos lanzar la red social redciclista.com.

Poco nos podíamos imaginar que facebook nos iba a pegar tan fuerte a las redes sociales verticales o temáticas. Nuestra idea inicial era abordar un nicho en el que las relaciones giran sobre un mismo interés: el ciclismo, e intereses más particulares como carretera, montaña, BMX, etc. Pero no, facebook quiere tener a todo el mundo y con todos los temas, en un mix que puede volver loco a los que comienzan.

Sobre tus datos privados

Hay un tema que ahora pocos nos detenemos a pensar seriamente, la privacidad de nuestros datos y nuestras acciones. Suele preocuparnos por si nos van a enviar publicidad masiva (spam), o nos van a contactar gente de la que no tenemos interés, pero para mi lo más preocupante es saber qué va a ser de mis datos, mi actividad y lo que se deducirá de ello.

Los propietarios siempre han de tener todo el control sobre con quién lo comparten y qué comparten. Como ejemplo, en Red Ciclista puedo existir con mis datos en privado y sólo los conoceré yo, sin tener la obligación de compartirlo públicamente con nadie.

En cualquier red social, un dato que se haga en algún momento público ya estará disponible para cualquier persona o robot que pueda acceder, y posteriormente ser archivado fuera de tu control. También puedo compartir solo con un amigo o un familiar, pero este a su vez puede hacer luego lo que quiera con ello.

Todos tenemos amigos especialmente activos en las redes sociales, que te acaban etiquetando los sitios más insospechados.

Tenemos que tener muy claro que el borrado o modificación de una información no va a implicar que esta desaparezca, es muy probable que esa información, ya archivada, esté relacionada contigo hasta el fin de los tiempos. Un ejemplo: internet archive

Sobre el servicio gratuito

Qué hacen con mis datos públicos y privados redes como facebook, twitter, google+, etc. Lee las condiciones legales y verás que por poco más casi les vendes tu alma. Normalmente seguimos adelante sin mirar, porque entonces sólo te queda una opción: no estar, decidir entre tener el servicio o no, estar relacionado o no.

Podemos pensar siendo tantos millones de usuarios pasaremos desapercibidos, pero no es completamente cierto, tus datos están filtrados y categorizados como no te lo puedes ni imaginar. Los algoritmos que se utilizan pueden encasillarnos con una fiabilidad impresionante en los temas que supuestamente nos interesan o te interesarán en el futuro.

Las empresas detrás de las redes sociales utilizan estos jugosos datos para que, de forma anónima, otras empresas puedan ofrecerte los clavos reforzados que estás buscando para tu casita de madera en los Montes de Toledo, y de paso unas mosquiteras que no habías pensado aún poner. Esto es publicidad muy segmentada a tus intereses, incluso aquellos más inconfesables.

Sobre ser anónimo

Si protegemos los datos para que no sean públicos así deberían quedar, anónimos. El perfil será conocido sólo dentro de esa red social y a los que hemos dado permiso. Los anunciantes que utilizan los servicios de anuncios de la red social no deberían saber nada de forma particular, ni aunque hayamos puesto los datos públicos. La red social sólo vende categorías de perfiles. Un anunciante normalmente quiere llegar a un perfil tipo y le dará igual como nos llamemos. Pero atención, podrían querer saber más cosas de nosotros.

Si alguien o una entidad quiere conocernos de forma concreta, a partir de unos pocos datos personales y las relaciones con gente, podrían sacar un perfil de cómo somos y qué hacemos, cualquiera que acceda a herramientas tan sencillas como los buscadores y las redes sociales puede investigar la vida de una persona con cierta actividad en internet, al punto de llegar casi a conocer sus hábitos. ¿Quién no ha buscado compañeros de clase para ver qué es de su vida o cómo son ahora?

Ahora tenemos un nuevo comportamiento, subir a internet nuestra ubicación habitual, con nuestros logros deportivos, paseos, quedadas, citas, etc. Está claro que no solo podrían saber de nosotros sino que también pueden encontrarnos sin dificultad alguna. Como ejemplo real, puedo conocer el lugar donde está un conocido mio, todo lo tuitea con la ubicación activada.

Más preocupante es la captura de datos de algunos gobiernos para ver si somos malas personas. Todos creemos que estamos hoy a salvo, ya que no hacemos nada sospechoso ni nada que no haga ya la mayoría, nos sentimos ocultos en la muchedumbre. Bueno, en cierta forma es cierto que es muy poco probable que un don nadie sea vigilado de una forma ta particular, pero los falsos positivos existen o incluso en algún momento podemos dejar de ser un don nadie, y ya es tarde, estamos ahí mismo expuestos.

¿LinkedIn es fiable para hacer negocios? ¿Y para buscar compañeros, inversores? ¿Publico ahí mi business plan? ¿Quién más tiene acceso a todas esta mina de oro?

Sobre el control de tus datos

El único control que nos queda es usar sentido común, es decir, no compartir nada que no quieres que se sepa de ti públicamente. Tan fácil y a veces tan complicado como eso.

Si quieres hacerte un selfie con un desnudo integral, y crees que está a salvo en tu teléfono, pues quizás deberías pensarlo de nuevo.

El único dato controlado es aquel que no ha sido puesto disponible.

Sobre el derecho al olvido

Hace poco que Europa exigió a google el cumplimiento de lo que se conoce como el derecho al olvido, es decir que alguien pueda solicitar a los buscadores que eliminen alguna información personal.

Muy difícil, incluso aunque google lo elimine de sus índices o de los resultados, la información podrá seguir apareciendo en muchos otros sitios que guardaron en su momento la información. Tu "enemigo" habrá capturado eso que no quieres que se sepa, y lo publicará las veces que haga falta. Es más cuanto más notoria sea tu oposición más visibilidad podrá tener lo que quieres ocultar.

Efecto Streisand

Conclusión

No muestres lo que no quieres que se sepa, y si ya lo has hecho, borra o modifica silenciosamente. La vida que uno lleva suele ser poco o nada interesante para terceros, hasta que ocurre algo que puede llevarte a ser foco de atención y decidas que mucha información no debería estar ahí, quizás sea tarde.

Cuida con quien te relacionas en las redes, no todos buscan ser amiguetes.

Separa las relaciones profesionales de las más privadas, tienes diferentes tipologías de redes sociales para hacerlo, o diferentes cuentas. Si te es posible, no relaciones una red social con otra de forma directa, ni indirecta utilizando el mismo email, nick, foro, teléfono, etc.

La deuda técnica intencionada en el desarrollo

2014-09-01T03:43:00+02:00

Hoy (2014) he aprendido una nueva definición que me ha llamado la atención por el nombre, y que a lo largo de mi trabajo como programador he tenido que lidiar con ello. Nunca le había conocido un nombre hasta hoy: deuda técnica (technical debt en su origen inglés), aunque de alguna manera siempre he sido consciente de su existencia y de sus consecuencias.

Se trata a la deuda como algo malo a evitar, pero me voy a centrar en la utilidad de la deuda intencionada que dejamos pendiente de saldar con conocimiento de causa y sus posibles consecuencias.

¿En qué consiste la deuda técnica intencionada?

Si has trabajado en proyectos de desarrollo de software con una pobre planificación, o bien con una fecha demasiado ajustada para cumplirla, o quizás por otros motivos, es fácil que te haya llevado a optar por una solución provisional menos óptima, por ser más simple y rápida.

¡Ojo!, una deuda técnica intencionada no es sinónimo de una chapuza o la típica ñapa, esta deuda es un compromiso para satisfacer unos requisitos más básicos y cumplir con una demo o una primera entrega preliminar. Este compromiso permite tomar un camino más rápido con la promesa de, mediante un refactoring o reescritura del código, resolverlo posteriormente de forma más correcta.

Un ejemplo típico es hacer un código más sencillo con una optimización muy básica que soportará un volumen de accesos bajo. La deuda técnica pendiente podría ser refactorizar cambiando la arquitectura o el código para implementar colas, caches o una optimización de la base de datos.

Otro ejemplo es relajar la seguridad de la aplicación para una demo a un cliente, aquí es más evidente que no pagar la deuda podría ser muy doloroso al paso a producción.

A nivel de diseño también podrías adquirir una deuda técnica intencionada, pero estas son más complicadas y poco recomendables salvo que esté bien justificado y controlado. Este tipo de deuda en diseño ha de documentarse muy bien hacia abajo para tener en cuenta este detalle en la codificación. El posterior pago de la deuda probablemente llevará mucho más esfuerzo o rehacerlo casi todo, pero la ventaja de que sabré mucho más de lo que pretendo solucionar y lo que no debo implementar.

Documenta tus deudas y gestiónalas

Es importante que todas estas deudas que vamos dejando estén documentadas para no olvidar por qué existen. En mi caso solía documentar lo más importante mediante listas de pendientes, pero después de acumular muchas deudas tenía la sensación de que era mejor rehacerlo todo según aumentaba su volumen, y lo que es peor, si no documentas olvidas el motivo de la deuda.

Así que toma conciencia que existen las deudas técnicas y utilizarlas en mi opinión no es malo, te permite desarrollar y probar más rápido. A cambio has de tener en cuenta que en algún momento has de incorporar el pago de esas deudas al flujo de trabajo, y mejor cuanto antes, que los intereses luego pueden ser muy altos o directamente inasumibles.

Si no incluyes el pago de tus deudas técnicas en tu metodología de trabajo, y en un tiempo razonable, entonces tu código no será óptimo, dejará de cumplir los requisitos reales para los que se escribió y finalmente quedarán pegotes para la posteridad.

// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42