Tema: design
-
Pipeline, fan-out, orquestador y panel crítico: 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 crítico conviene a resultados que necesitan revisión frente a varios criterios; cada patrón multiplica el coste en tokens y añade una capa de coordinación que puede fallar por sí sola.
-
Event sourcing and CQRS: what they buy and what they cost
Event sourcing stores every state change as an immutable event and derives current state by replay; CQRS separates the write model from read models. Both add auditability and flexibility at the price of complexity and eventual consistency.
-
Technical debt as a metaphor and as a decision
Technical debt describes the future cost of a shortcut; the metaphor is useful when the debt is deliberate and tracked, and misleading when it excuses careless work or is used to describe every imperfection.
-
Agent memory design: what to persist, what to summarise and what to forget
An agent's memory has three tiers: the context window, a task scratchpad and a durable store across sessions; decide per item which tier it belongs to, keep durable memory small and reviewable, and delete what is no longer true.
-
Privacy review checklist for a feature
Ten questions a reviewer answers before a feature ships: inventory of new personal data, minimisation decisions, retention job, access and access logging, export and deletion coverage, preference purposes, third-party flows, a short LINDDUN pass, test data, and a recorded result; engineering properties only, no legal assessment.
-
Dark mode with prefers-color-scheme, color-scheme and light-dark()
Dark mode has three parts: the prefers-color-scheme media query to detect the user's choice, the color-scheme property (and meta tag) to tell the browser which schemes the page supports so form controls, scrollbars and the canvas follow, and light-dark() or custom properties to swap palette values without duplicating rules.
-
The test-driven development loop
Write a failing test, make it pass with the simplest change, then refactor with the tests green; the loop keeps design decisions small and gives every line a reason to exist.
-
Dataclasses for plain records
dataclasses generate __init__, __repr__ and equality from annotated fields; frozen dataclasses give immutable value objects, slots reduce memory, and field(default_factory=...) avoids shared mutable defaults.
-
Recognising code smells before refactoring
Code smells are surface symptoms (long methods, large classes, feature envy, shotgun surgery, primitive obsession) that suggest a deeper design problem; naming them gives a vocabulary for review and a trigger for refactoring.
-
Designing exceptions in a Python library
Define one base exception per library, derive specific errors from it, raise with context, chain causes with 'raise ... from', and catch narrowly at the boundary where the failure can be handled.
-
Modelling states with Literal, Enum and TypedDict
Replace free strings and loose dictionaries with Literal unions, enumerations and TypedDicts so that impossible states are rejected by the type checker and documented in one place.
-
When should a team split a monolith into services?
Open question: which observable signals (deployment coupling, team boundaries, scaling needs, incident patterns) have preceded successful extractions of services from a monolith, and which extractions were later reversed?
-
Human approval gates in agent workflows: which actions need one
An approval gate pauses an agent before an action and lets a person allow or deny it; gate actions that are irreversible, externally visible, costly or privilege-changing, keep the rest automatic, and show the person exactly what would run.
-
Starting with a monolith beats starting with microservices
Hypothesis: new products that begin as a well-structured monolith reach a stable domain model faster and with fewer operational failures than those that begin as microservices; splitting later along proven boundaries is cheaper.
-
Privacy threat modelling with LINDDUN in outline
Walk a data flow diagram element by element against the seven LINDDUN threat types (linking, identifying, non-repudiation, detecting, data disclosure, unawareness and unintervenability, non-compliance), record scenarios per element, and pick mitigations from a short menu; a one-session format modelled on a STRIDE session.
Legible por máquina: JSON