Tema: design
-
Pipeline, fan-out, orquestador y panel de críticos: qué patrón multiagente conviene a cada tarea
Un pipeline conviene a tareas con una secuencia fija de transformaciones; el fan-out paralelo conviene a subpreguntas independientes o a intentos repetidos sobre los que votar; un orquestador con trabajadores conviene a tareas cuya descomposición solo se conoce en tiempo de ejecución; un panel de críticos conviene a resultados que necesitan revisión frente a varios criterios; cada uno multiplica el costo en tokens y añade una capa de coordinación que puede fallar por sí misma.
-
Event sourcing y CQRS: qué se gana y qué cuesta
Event sourcing almacena cada cambio de estado como un evento inmutable y obtiene el estado actual reproduciéndolos; CQRS separa el modelo de escritura de los modelos de lectura. Ambos añaden capacidad de auditoría y flexibilidad al precio de mayor complejidad y de consistencia eventual.
-
La deuda técnica como metáfora y como decisión
La deuda técnica describe el coste futuro de un atajo; la metáfora resulta útil cuando la deuda es deliberada y se registra, y engañosa cuando sirve para excusar un trabajo descuidado o para describir cualquier imperfección.
-
Diseño de la memoria de un agente: qué conservar, qué resumir y qué olvidar
La memoria de un agente tiene tres niveles: la ventana de contexto, un cuaderno de tareas y un almacén duradero entre sesiones; decidir por elemento a qué nivel pertenece, mantener la memoria duradera pequeña y revisable, y eliminar lo que ya no es cierto.
-
Lista de comprobación de revisión de privacidad para una funcionalidad
Diez preguntas que quien revisa responde antes de publicar una funcionalidad: inventario de los datos personales nuevos, decisiones de minimización, tarea de retención, acceso y registro de acceso, cobertura de exportación y eliminación, finalidades de preferencia, flujos con terceros, una pasada breve de LINDDUN, datos de prueba y un resultado registrado; solo propiedades de ingeniería, sin evaluación jurídica.
-
Modo oscuro con prefers-color-scheme, color-scheme y light-dark()
El modo oscuro consta de tres partes: la media query prefers-color-scheme para detectar la elección del usuario, la propiedad color-scheme (y la etiqueta meta) para indicar al navegador qué esquemas admite la página de modo que los controles de formulario, las barras de desplazamiento y el lienzo la sigan, y light-dark() o propiedades personalizadas para intercambiar los valores de la paleta sin duplicar reglas.
-
El ciclo del desarrollo guiado por pruebas
Escribir una prueba que falle, hacerla pasar con el cambio más simple y luego refactorizar con las pruebas en verde; el ciclo mantiene pequeñas las decisiones de diseño y da una razón de ser a cada línea.
-
Dataclasses para registros simples
dataclasses genera __init__, __repr__ y la igualdad a partir de campos anotados; las dataclasses frozen dan objetos de valor inmutables, slots reduce la memoria, y field(default_factory=...) evita valores por defecto mutables compartidos.
-
Reconocer los code smells antes de refactorizar
Los code smells son síntomas superficiales (métodos largos, clases grandes, feature envy, shotgun surgery, obsesión por lo primitivo) que sugieren un problema de diseño más profundo; nombrarlos aporta un vocabulario para la revisión y un disparador para la refactorización.
-
Diseño de excepciones en una biblioteca de Python
Definir una excepción base por biblioteca, derivar de ella los errores específicos, lanzarlos con contexto, encadenar las causas con 'raise ... from' y capturar de forma acotada en el límite donde el fallo se puede manejar.
-
Modelar estados con Literal, Enum y TypedDict
Sustituir las cadenas libres y los diccionarios sueltos por uniones Literal, enumeraciones y TypedDicts, de modo que el verificador de tipos rechace los estados imposibles y estos queden documentados en un solo lugar.
-
¿Cuándo conviene que un equipo divida un monolito en servicios?
Pregunta abierta: qué señales observables (acoplamiento en el despliegue, límites entre equipos, necesidades de escalado, patrones de incidentes) han precedido a extracciones exitosas de servicios desde un monolito, y qué extracciones se revirtieron más tarde.
-
Puntos de aprobación humana en flujos de trabajo con agentes: qué acciones requieren uno
Un punto de aprobación pausa al agente antes de una acción y permite que una persona la autorice o la deniegue. Conviene aplicarlo a acciones irreversibles, visibles externamente, costosas o que cambian privilegios, dejar el resto en automático y mostrar a la persona exactamente qué se ejecutaría.
-
Empezar con un monolito es mejor que empezar con microservicios
Hipótesis: los productos nuevos que arrancan como un monolito bien estructurado alcanzan antes un modelo de dominio estable y sufren menos fallos operativos que los que arrancan con microservicios; dividir más adelante, siguiendo fronteras ya probadas, resulta más barato.
-
Modelado de amenazas de privacidad con LINDDUN: resumen del método
Recorra un diagrama de flujo de datos elemento por elemento con los siete tipos de amenaza de LINDDUN (vinculación, identificación, no repudio, detección, divulgación de datos, desconocimiento e imposibilidad de intervenir, incumplimiento), registre escenarios por elemento y elija mitigaciones de un menú breve; formato de una sola sesión basado en una sesión STRIDE.
Legible por máquina: JSON