Jorge Calderita's Blog

Astro to Saga

2026-04-17T19:06:06Z

Mi Problema 🤔

Mi portfolio funcionaba sobre Astro con Bun. Todo iba bien. Rápido, cómodo, sin quejas técnicas.

Pero había algo que no encajaba. Cada vez que abría el proyecto me encontraba con un package.json, un tailwind.config, un astro.config, y una carpeta node_modules con cientos de dependencias que ni sabía que existían. Esa sensación de perder el control sobre lo que hay dentro de tu propio proyecto me incomoda. Me gusta saber qué ejecuta mi código y por qué está ahí. Ya había eliminado Tailwind en una migración previa a vanilla CSS, pero el resto del ecosistema JavaScript seguía ahí.

Y al final, soy desarrollador Swift. Mi día a día es Swift. Y sin embargo, para generar mi propio portfolio dependía de un ecosistema completamente ajeno. Si alguien entraba en mi repositorio, no veía a un desarrollador Swift. Veía un proyecto JavaScript más.

La pregunta era sencilla: si confío en Swift para todo lo demás, ¿por qué no confío en Swift para esto?

Mi Solución 🧩

Me paré a pensar qué necesitaba realmente. Mi portfolio no es una aplicación web. No tiene estado ni interactividad compleja. Es un conjunto de páginas HTML estáticas generadas a partir de Markdown. No necesito React, ni Vue, ni hidratación. Necesito algo que lea Markdown, lo transforme en HTML y lo escriba en disco.

Encontré Saga, un generador de sitios estáticos en Swift. Deliberadamente minimalista: lee archivos, aplica transformaciones, escribe HTML. Lo que no incluye, lo decides tú. Además incluye hot reload para desarrollo, algo que no esperaba encontrar en un proyecto tan pequeño. Esa filosofía me convenció más que cualquier feature list.

Ventajas	Desventajas
Todo el stack en Swift — un solo lenguaje, sin cambio de contexto	Ecosistema pequeño — si algo no existe, lo construyes tú
HTML verificado por el compilador gracias al DSL tipado	Curva de aprendizaje con la sintaxis del DSL
Pipeline de imágenes nativo sin dependencias externas	Pipeline de imágenes solo funciona en macOS
Node eliminado del entorno local	Comunidad y documentación limitadas
Control total sobre cada dependencia del proyecto	Más trabajo inicial para funcionalidades que en otros frameworks vienen de serie

La reflexión de fondo

La decisión no fue técnica. Fue sobre coherencia. Quiero que si alguien visita mi repositorio, vea Swift. No digo que Astro sea malo — es excelente. Pero mi portfolio es mi tarjeta de presentación, y esa tarjeta tiene que hablar de mí.

Mi Resultado 🎯

El sitio que lees ahora mismo está generado con Saga, compilado con Swift, y desplegado sobre Cloudflare Workers sin que Node haya intervenido en mi máquina.

Lo que me sorprendió no fue el resultado técnico. Fue la sensación de coherencia. Abrir mi portfolio y ver que todo, desde la primera línea hasta el último deploy, es Swift me produce una tranquilidad difícil de explicar.

Si eres desarrollador Swift y tu portfolio corre sobre Node, no digo que debas cambiar. Digo que merece la pena preguntarse por qué. Al final, la herramienta que eliges para presentarte dice algo sobre ti. Yo elegí la que me representa.

Keep coding, keep running 🏃‍♂️

OnlyDNS

2026-04-17T19:06:06Z

Mi Problema 🤔

En el artículo anterior hablé de cómo La Liga bloqueaba mi web durante los partidos. Gente intentando visitar mi portfolio y mi blog se encontraba con que la página no cargaba, simplemente porque mi dominio pasaba por la infraestructura de Cloudflare, y La Liga bloqueaba rangos enteros de IPs de Cloudflare para frenar las retransmisiones ilegales.

Lo sabía. Lo documenté. Y me quedé ahí.

Durante meses no hice nada para solucionarlo. No por pereza ni por pensar que fuese complicado — sino por enfado. Mi web funcionaba perfectamente, era La Liga la que aplicaba bloqueos indiscriminados y la dejaba inaccesible. No era culpa mía. Así que me planté: no tenía por qué ser yo quien moviese ficha.

Así que no hice nada. Durante meses.

Lo que pasa es que tenía el proxy de Cloudflare activo — la famosa nube naranja. Mi web está alojada en Cloudflare Pages, así que todo está dentro del ecosistema de Cloudflare. Pero con el proxy activado, el tráfico pasa por la capa de CDN/proxy de Cloudflare, que usa unos rangos de IPs compartidas. Y esos rangos son precisamente los que La Liga bloqueaba.

Mi Solución 🧩

La solución es desactivar el proxy de Cloudflare y pasar al modo Solo DNS — la nube gris.

Con la nube naranja activa, Cloudflare es un “centro comercial”: todos los visitantes entran por la puerta de su proxy/CDN, que usa rangos de IPs compartidas con miles de sitios. Son esas IPs las que La Liga bloquea en masa para frenar las retransmisiones ilegales — y mi web queda como daño colateral.

Con la nube gris, Cloudflare pasa a ser solo un “director de tráfico”: resuelve el DNS y apunta directamente a Cloudflare Pages. Mi web sigue alojada en Cloudflare, pero el tráfico llega a través de los rangos de IPs de Pages — que son distintos a los del proxy y que La Liga no tiene en su lista de bloqueo.

El proceso en el panel de Cloudflare es este:

Entrar en el panel de Cloudflare y navegar a DNS > Registros (Records).
Buscar los registros que apuntan a la web — normalmente un registro A o CNAME con el nombre del dominio.
En la columna Estado del proxy, hacer clic en el interruptor con la nube naranja para convertirla en una nube gris (Solo DNS).
Guardar los cambios.

El cambio propaga en minutos. A partir de ese momento, el tráfico llega por una ruta distinta dentro de Cloudflare — una que no está en el punto de mira de los bloqueos de La Liga.

Como mi web es estática y sigue alojada en Cloudflare Pages, no noto prácticamente ninguna diferencia de velocidad. Pierdo algunas funciones de la capa proxy — como el firewall a nivel de CDN o la caché en sus edge nodes — pero para una web estática de portfolio esas ventajas son marginales comparadas con el beneficio de que la web funcione para todo el mundo durante los partidos.

Mi Resultado 🎯

Mi web ya carga durante los partidos de La Liga. Cualquier persona que intente visitar mi portfolio o blog mientras suena el himno de la Champions no se va a encontrar con una pantalla en blanco.

Cinco minutos. Un clic. Meses de problema resuelto.

La lección que me llevo no es técnica — es pragmática. Tuviese razón o no, mi problema o lo solucionaba yo o no lo iba a solucionar nadie. Y creo que tengo razón: mi web no tiene por qué ser daño colateral de los bloqueos de La Liga. Gracias, La Liga.

Keep coding, keep running 🏃‍♂️

My First Macro

2026-04-17T19:06:06Z

Mi Problema 🤔

En mi proyecto tengo decenas de modelos Fluent, y hay un bloque de código que se me repite en absolutamente todos ellos:

public static let space: String? = "sales"

@ID() public var id: UUID?
public init() {}

@Timestamp(.createdAt, on: .create) public var createdAt: Date?
@Timestamp(.updatedAt, on: .update) public var updatedAt: Date?
@Timestamp(.deletedAt, on: .delete) public var deletedAt: Date?

Siempre el mismo bloque. En cada modelo. Sin excepción.

El espacio de nombres cambia, pero la estructura es idéntica. Con cada modelo nuevo, copio y pego, ajusto el espacio y espero no olvidarme de nada. Con 30 modelos, ese boilerplate se convierte en ruido que me dificulta leer lo que realmente importa: la lógica del modelo.

Mi solución en Swift para este tipo de problemas es una macro.

Mi Solución 🧩

Una macro de Swift puede generar miembros nuevos en una clase o struct en tiempo de compilación. Exactamente lo que necesito. El resultado que busco es escribir esto:

@FluentModel(.sales)
public final class ProductModel: Model {
    public static let schema = "products"

    @Field(.name) public var name: String
}

Y que el compilador inyecte automáticamente space, id, init() y los tres timestamps. Sin escribirlos. Sin mantenerlos.

Estructura del paquete

Las macros en Swift requieren dos targets separados: la interfaz pública (lo que consumo como desarrollador) y el plugin (la implementación que ejecuta el compilador). En mi caso, ambos viven en el mismo paquete Macros:

Macros — declara la macro y el enum DatabaseSpace
MacrosPlugin — implementa la expansión con SwiftSyntax

DatabaseSpace — los espacios como tipos

Antes de definir la macro, necesito modelar los espacios de nombres disponibles. En lugar de usar strings sueltos, decidí que el enum DatabaseSpace los haga exhaustivos y seguros en tiempo de compilación:

public enum DatabaseSpace: String, CaseIterable, Sendable {
    case sales, warehouse
}

Esto permite escribir @FluentModel(.sales) en lugar de @FluentModel(“sales”). Si el espacio no existe, el compilador lo dice antes de ejecutar nada.

La declaración del macro

La interfaz pública de la macro es sorprendentemente compacta:

@attached(member, names: named(space), named(id), named(init), named(createdAt), named(updatedAt), named(deletedAt))
public macro FluentModel(_ space: DatabaseSpace? = nil) = #externalMacro(
    module: "MacrosPlugin",
    type: "FluentModelMacro"
)

El atributo @attached(member, names:) le dice al compilador dos cosas: que esta macro añade miembros a la declaración donde se aplica, y cuáles son los nombres exactos que va a generar. Declarar los nombres es obligatorio — Swift los necesita para resolver el árbol de símbolos antes de expandir la macro.

La implementación — FluentModelMacro

La implementación conforma el protocolo MemberMacro y devuelve un array de DeclSyntax — fragmentos de código Swift que el compilador inserta en el modelo:

import SwiftSyntax
import SwiftSyntaxMacros

public struct FluentModelMacro: MemberMacro {
    public static func expansion(
        of node: AttributeSyntax,
        providingMembersOf declaration: some DeclGroupSyntax,
        conformingTo protocols: [TypeSyntax],
        in context: some MacroExpansionContext
    ) throws -> [DeclSyntax] {
        [
            spaceDecl(from: node),
            "@ID() public var id: UUID?",
            "public init() {}",
            "@Timestamp(.createdAt, on: .create) public var createdAt: Date?",
            "@Timestamp(.updatedAt, on: .update) public var updatedAt: Date?",
            "@Timestamp(.deletedAt, on: .delete) public var deletedAt: Date?",
        ]
    }

    private static func spaceDecl(from node: AttributeSyntax) -> DeclSyntax {
        let value = node.arguments?.as(LabeledExprListSyntax.self)?
            .first?.expression.as(MemberAccessExprSyntax.self)
            .map { "\"\($0.declName.baseName.text)\"" } ?? "nil"
        return "public static let space: String? = \(raw: value)"
    }
}

El método expansion devuelve directamente el array de declaraciones, sin variables intermedias. Cada elemento es código Swift literal que el compilador inyecta tal cual en el modelo.

La clave está en spaceDecl, que encapsula toda la lógica de extracción y generación en un solo método. Navega el árbol sintáctico del atributo con SwiftSyntax usando optional chaining: accede a los argumentos como LabeledExprListSyntax, toma la primera expresión, la castea a MemberAccessExprSyntax (porque el argumento es un caso de enum como .sales) y con .map lo convierte en un string entrecomillado. Si cualquier paso de la cadena falla, el operador ?? devuelve “nil”. Finalmente, \(raw:) interpola el valor directamente en el DeclSyntax.

Por último, necesito un CompilerPlugin que registre la macro — es el punto de entrada que el compilador carga para saber qué macros están disponibles:

import SwiftCompilerPlugin
import SwiftSyntaxMacros

@main
struct MacrosPlugin: CompilerPlugin {
    let providingMacros: [Macro.Type] = [
        FluentModelMacro.self,
    ]
}

Mi Resultado 🎯

Con la macro instalada, cada modelo queda limpio y sin ruido:

@FluentModel(.sales)
public final class ProductModel: Model {
    public static let schema = "products"

    @Field(.name) public var name: String
    @OptionalField(.description) public var description: String?
}

El compilador expande @FluentModel(.sales) y genera automáticamente:

public static let space: String? = "sales"
@ID() public var id: UUID?
public init() {}
@Timestamp(.createdAt, on: .create) public var createdAt: Date?
@Timestamp(.updatedAt, on: .update) public var updatedAt: Date?
@Timestamp(.deletedAt, on: .delete) public var deletedAt: Date?

Y si un modelo no pertenece a ningún espacio de nombres — como las vistas — simplemente se omite el argumento:

@FluentModel()
public final class OrderSummaryModel: Model {
    public static let schema = "order_summaries"
}

En ese caso, space se genera como nil y Fluent ignora el prefijo de esquema.

Los beneficios en números: 32 modelos con la macro aplicada. 6 líneas eliminadas por modelo. Más de 190 líneas de boilerplate que ya no existen en el repositorio y que nunca más habrá que mantener.

Keep coding, keep running 🏃‍♂️

DB Admin vs Dev

2026-04-17T19:06:06Z

El problema 🤔

En muchos proyectos he visto cómo el código de la aplicación termina haciendo cosas que no le corresponden: crear roles, configurar parámetros del servidor de base de datos, gestionar permisos a nivel de instancia. Todo mezclado en el mismo sitio, como si fuera una sola responsabilidad.

Pero no lo es. La base de datos tiene dos mundos distintos: la administración 🛡️ y el desarrollo 💻.

Mezclarlos es uno de los errores más comunes, y también uno de los más costosos 💸. Un desarrollador que configura la instancia desde su código está cruzando una frontera que no le corresponde. Y un administrador que intenta decidir qué tablas o esquemas usa la aplicación está haciendo lo mismo desde el otro lado.

La idea 🧩

La separación es conceptualmente limpia: la administración pertenece al servidor, el desarrollo pertenece al código.

El territorio del administrador 🛡️

El administrador gestiona la instancia de la base de datos. Su trabajo incluye:

🔧 Configuración del servidor — parámetros de rendimiento, extensiones a nivel de instancia, ajustes que requieren reinicio
👤 Roles y credenciales — crear usuarios, asignar contraseñas seguras, definir quién puede conectarse
🗄️ Bases de datos — crearlas, establecer timeouts, revocar accesos por defecto

Todo esto es infraestructura 🔐. Son decisiones que se toman una vez, las ejecuta alguien con permisos de superusuario, y no tienen nada que ver con la lógica de negocio. Lo ideal es que vivan como scripts SQL versionados en el repositorio, pero separados del código de la aplicación.

El territorio del desarrollador 💻

El desarrollador gestiona la estructura de datos de la aplicación: esquemas, tablas, índices, vistas, y todo lo que necesita existir para que la aplicación funcione.

Esta responsabilidad se expresa a través de migraciones ✨ — piezas de código versionadas, reversibles y revisables como cualquier otro cambio. Da igual si usas Swift, Python, Go o TypeScript: el principio es el mismo. La estructura de datos de tu aplicación debe poder reproducirse automáticamente en cualquier entorno 🔄.

La zona gris: ¿admin o desarrollo? 🤷

Hay casos que parecen ambiguos. Los roles de base de datos son un buen ejemplo. El rol en sí — con su contraseña y permisos de conexión — es un concepto de infraestructura. Lo crea el administrador 🛡️.

Pero los permisos sobre tablas concretas — qué puede leer, qué puede escribir, sobre qué esquema — eso depende del desarrollador 💻. La tabla tiene que existir antes de que pueda tener permisos, así que esos permisos van en las migraciones, no en scripts de infraestructura.

La regla que yo aplico es sencilla: si el objeto existe antes que la aplicación, es administración. Si su existencia depende de que la aplicación lo cree, es desarrollo ✅.

El resultado 🎯

Cuando aplicas esta separación, el proceso de puesta en marcha queda claro y reproducible:

🛡️ El administrador prepara la instancia → servidor configurado, roles creados, base de datos lista
💻 El desarrollador ejecuta las migraciones → esquemas, tablas y permisos de aplicación aplicados automáticamente

Cada capa tiene su herramienta. El administrador no toca el código de la aplicación. El desarrollador no necesita credenciales de superusuario 🔒. Nadie pisa el territorio del otro.

Esta separación también facilita el trabajo en equipo 🤝: los scripts de administración los ejecuta quien tiene acceso al servidor, una sola vez. Las migraciones las ejecuta cualquier desarrollador del equipo en su entorno local, tantas veces como necesite.

La base de datos no es solo tuya como desarrollador. Pero la estructura de datos de tu aplicación, sí. 🏗️

Keep coding, keep running 🏃‍♂️

Migrate Spaces

2026-04-17T19:06:06Z

🧩 Problema

En el artículo anterior sobre Esquemas y Espacios vimos cómo asignar un espacio de nombres a un modelo usando la propiedad space. Muchos me preguntasteis lo mismo: ¿cómo se crean esos espacios en la base de datos? 🤔

La respuesta más habitual era hacerlo a mano, ejecutando un CREATE SCHEMA en la consola de PostgreSQL antes de lanzar las migraciones. Funciona, pero rompe algo fundamental: si la base de datos no existe o el entorno es nuevo, el proceso falla antes de llegar a las migraciones reales 💥.

El otro problema es que administrar espacios de nombres a mano no escala. En cuanto tienes varios entornos (desarrollo, staging, producción) o un equipo, mantener esa sincronía manual se convierte en una fuente de errores silenciosos 😬.

💡 Solución

La solución es convertir la creación de espacios de nombres en una migración más. De esta forma, se ejecuta automáticamente en el orden correcto, es reversible y está versionada junto al resto del código ✅.

La clave está en combinar FluentKit con SQLKit. FluentKit gestiona el ciclo de vida de las migraciones, pero para ejecutar SQL arbitrario necesitamos acceder al driver subyacente mediante el protocolo SQLDatabase. Para mantener el código organizado, encapsulamos los espacios de nombres en un enum con una acción que determina si se crean o se eliminan:

import FluentKit
import SQLKit

enum SRSchema: String, CaseIterable {
    case account, ai, device, location, sport, task, view

    enum Action {
        case create, drop
    }

    static func execute(_ action: Action, on db: Database) async throws {
        let sql = db as! any SQLDatabase
        let template: (String) -> String =
            switch action {
            case .create: { "CREATE SCHEMA IF NOT EXISTS \($0)" }
            case .drop: { "DROP SCHEMA IF EXISTS \($0) RESTRICT" }
            }
        for schema in allCases {
            try await sql.raw("\(unsafeRaw: template(schema.rawValue))").run()
        }
    }
}

struct SchemasMigration: AsyncMigration {
    func prepare(on db: Database) async throws {
        try await SRSchema.execute(.create, on: db)
    }

    func revert(on db: Database) async throws {
        try await SRSchema.execute(.drop, on: db)
    }
}

Algunos detalles importantes 📋:

SRSchema como CaseIterable: al iterar sobre allCases, nos aseguramos de que todos los espacios definidos se crean sin tener que listarlos manualmente en la migración. Añadir un nuevo espacio solo requiere agregar un caso al enum 🔄.
Action: el enum interno modela las dos operaciones posibles (create y drop), lo que permite reutilizar el mismo método execute tanto en el prepare como en el revert de la migración ♻️.
Switch expression: se usa una switch expression de Swift para seleccionar el template SQL según la acción. Cada rama devuelve un closure que genera la sentencia correspondiente, manteniendo la lógica compacta y legible 🧹.
CREATE SCHEMA IF NOT EXISTS: hace que la migración sea idempotente. Si el esquema ya existe, no falla, simplemente continúa 🛡️.
DROP SCHEMA … RESTRICT: en el revert, el modificador RESTRICT impide eliminar un esquema que contenga tablas. Es una red de seguridad que evita pérdidas accidentales de datos al revertir 🔒.
unsafeRaw: se usa para interpolar el nombre del schema directamente en el SQL. Es seguro aquí porque el valor proviene de un enum propio, nunca de input externo ⚠️.

📊 Resultado

Esta migración debe ser la primera en registrarse ☝️. Antes de crear cualquier tabla, los espacios de nombres tienen que existir. En el runner de migraciones, el orden queda así:

fluent.migrations.add(
    SchemasMigration()
)

Al ejecutar las migraciones en un entorno nuevo, el proceso completo es automático ⚡:

Y si en algún momento necesitas añadir un nuevo dominio, solo añades el caso al enum SRSchema y la próxima vez que se ejecuten las migraciones, el esquema aparece. Sin tocar la base de datos a mano, sin documentación extra que mantener 🎯.

Keep coding, keep running 🏃‍♂️

Tailwind to CSS

2026-04-17T19:06:06Z

🎨 ¿Por Qué Tocar Lo Que Funciona?

Mi portfolio llevaba meses funcionando perfectamente con Tailwind CSS. Todo iba bien. Los estilos estaban en su sitio, los componentes se veían geniales y la web cargaba rápido.

Entonces, ¿por qué cambiar?

Porque funcionar bien y funcionar de la mejor manera posible son cosas distintas. Y cuando te paras a analizar qué hay debajo del capó, a veces descubres que llevas una capa que no necesitas 🧅.

🤔 El Problema con Tailwind (en mi caso)

No me malinterpretéis: Tailwind CSS es una herramienta brutal. Lo he usado en proyectos profesionales y lo seguiré usando donde tenga sentido. Pero en un portfolio personal con Astro, empecé a notar ciertas cosas:

Dependencia innecesaria: 3 paquetes extra (tailwindcss, @tailwindcss/vite, @tailwindcss/typography) para un proyecto que no los necesitaba realmente 📦
Capa de abstracción: Tailwind genera CSS a partir de clases de utilidad. Es una capa entre lo que escribes y lo que el navegador interpreta. En un proyecto pequeño, esa capa suma sin aportar 🧱
Peso extra: El CSS generado incluía utilidades que no siempre aprovechaba al máximo. ~20KB de más que el usuario descargaba sin necesidad 📊
Menor control: Cuando quieres algo muy específico, acabas luchando contra el framework en vez de escribir directamente lo que necesitas ⚔️

💡 La Decisión: Vanilla CSS con Design Tokens

La idea era sencilla: eliminar Tailwind y sustituirlo por CSS vanilla con un sistema de design tokens usando custom properties de CSS.

¿Qué son los design tokens? Son variables CSS que definen tu sistema de diseño:

:root {
  --color-primary: oklch(0.55 0.2 260);
  --color-gray-100: oklch(0.97 0 0);
  --color-gray-900: oklch(0.21 0.006 285.75);

  --text-sm: 0.875rem;
  --text-base: 1rem;
  --text-xl: 1.25rem;

  --spacing: 0.25rem;
  --radius-lg: 0.5rem;

  --shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1);
  --transition-colors: color 0.15s, background-color 0.15s, border-color 0.15s;
}

Con esto tienes consistencia en todo el proyecto sin depender de ningún framework. Solo CSS puro que el navegador entiende directamente 🎯.

🔧 La Migración

El proceso fue migrar 38 archivos en un solo commit. Cada componente Astro pasó de usar clases de Tailwind a tener su propio bloque <style> con estilos scoped:

Antes (Tailwind):

<header class="flex items-center justify-between px-6 py-4 bg-white dark:bg-gray-900">
  <nav class="flex gap-4">
    <a class="text-sm font-medium text-gray-700 hover:text-blue-500">Blog</a>
  </nav>
</header>

Después (Vanilla CSS):

<header class="header">
  <nav class="nav">
    <a class="nav-link">Blog</a>
  </nav>
</header>

<style>
  .header {
    display: flex;
    align-items: center;
    justify-content: space-between;
    padding: calc(var(--spacing) * 4) calc(var(--spacing) * 6);
    background-color: var(--color-white);
  }

  :global(.dark) .header {
    background-color: var(--color-gray-900);
  }

  .nav {
    display: flex;
    gap: calc(var(--spacing) * 4);
  }

  .nav-link {
    font-size: var(--text-sm);
    font-weight: 500;
    color: var(--color-gray-700);
    transition: var(--transition-colors);
  }

  .nav-link:hover {
    color: var(--color-blue-500);
  }
</style>

¿Más líneas? Sí. ¿Más claro y mantenible? Absolutamente ✅.

📚 Lo Que Aprendí por el Camino

La migración no fue solo “quitar Tailwind y poner CSS”. Hubo trampas interesantes que vale la pena compartir:

Estilos scoped y <slot>

En Astro, los estilos dentro de <style> son scoped por defecto. Esto significa que cada componente recibe un atributo único (data-astro-cid-*) y los estilos solo afectan a ese componente.

El problema: el contenido que llega por <slot> no recibe ese atributo. Si un componente padre intenta estilizar lo que viene por slot, los estilos no se aplican 😱.

La solución: usar :global() para los selectores que afectan a contenido slotted:

.container :global(a) {
  color: var(--color-primary);
  text-decoration: underline;
}

opacity vs transparencia de fondo

Con Tailwind usaba clases como bg-opacity-70. Al migrar, el primer instinto fue usar la propiedad opacity. Error: opacity afecta al elemento entero, incluidos sus hijos 👶.

La solución correcta: color-mix() para transparencia solo en el fondo:

.modal-overlay {
  /* MAL: afecta a todo */
  opacity: 0.7;

  /* BIEN: solo el fondo es transparente */
  background-color: color-mix(in oklab, var(--color-gray-900) 70%, transparent);
}

📊 Los Resultados

Los números hablan por sí solos:

~20KB menos de CSS entregado al navegador 📉
3 dependencias eliminadas del package.json 🗑️
0 capas de abstracción entre tu código y el navegador 🎯
Build más rápido al no necesitar el procesamiento de Tailwind ⚡
Control total sobre cada línea de CSS que se genera 🎛️

El package.json pasó de tener tailwindcss, @tailwindcss/vite y @tailwindcss/typography a no tener ninguna dependencia de estilos. Solo CSS puro.

Y lo mejor: se eliminó el archivo tailwind.config.mjs por completo. Una configuración menos que mantener 🧹.

🏗️ La Arquitectura Final

El sistema de estilos quedó organizado en 4 archivos CSS:

Archivo	Responsabilidad
design-tokens.css	Colores, tipografía, espaciado, sombras, transiciones
base-reset.css	Reset CSS mínimo y utilidades como .sr-only
prose.css	Tipografía para contenido del blog con soporte dark mode
layout.css	Clases de layout globales (.bodyLayout, .mainLayout)

Todo importado desde un único global.css. Limpio, predecible y sin magia negra 🧙‍♂️.

💭 Reflexión Final

Migrar de Tailwind CSS a vanilla CSS no es para todos ni para todos los proyectos. En equipos grandes o proyectos con muchos desarrolladores, Tailwind sigue siendo una opción fantástica por su consistencia y velocidad de desarrollo.

Pero en un proyecto personal como un portfolio con Astro, donde el rendimiento importa y el control total es un lujo que puedes permitirte, quitarte esa capa de abstracción es liberador 🕊️. De hecho, acabé llevando esta filosofía aún más lejos y migré todo el portfolio de Astro a Swift — cuento la historia completa en Astro to Saga.

Es como pintar un cuadro: puedes usar plantillas y herramientas que te guíen, o puedes coger el pincel y crear exactamente lo que tienes en mente. Ambas opciones son válidas. Pero cuando el lienzo es tuyo, pintar a mano tiene su encanto 🎨.

Keep coding, keep running 🏃‍♂️

Cupertino MCP

2026-04-17T19:06:06Z

🍎 El Problema de la Documentación de Apple

Si desarrollas para iOS, macOS o cualquier plataforma de Apple, conoces el drill perfecto:

Estás programando tranquilamente 💻
Necesitas consultar cómo funciona algo en SwiftUI 🤔
Abres Safari / tu navegador favorito 🌐
Buscas en Google / DuckDuckGo 🔍
Entras a la documentación oficial de Apple 📚
Lees, entiendes, vuelves a tu IDE 🔄
Repites el proceso 47 veces al día 😵

O peor aún: le preguntas a tu IA favorita y te da información desactualizada o directamente alucinada porque su conocimiento no está actualizado con las últimas versiones de Swift o SwiftUI 🤖❌.

¿Y si te dijera que hay una forma mejor?

💡 Cupertino MCP: La Solución

Cupertino MCP es una herramienta que indexa localmente toda la documentación de Apple y la pone disponible para tu IA mediante el Model Context Protocol (MCP).

Traducido a cristiano: es como darle a tu IA (Claude, en mi caso) un acceso directo y verificado a toda la documentación oficial de Apple 🎯.

¿Cuánta documentación estamos hablando?

📄 302,424+ páginas de documentación oficial

🧰 307 frameworks indexados

📦 9,699 paquetes Swift catalogados

💾 606 proyectos de código de ejemplo de Apple

📱 Human Interface Guidelines completas

📖 Swift Evolution proposals (~400 propuestas)

🏛️ Apple Archive guides (documentación legacy pero valiosa)

Todo esto, disponible offline, sin necesidad de internet, y sin riesgo de alucinaciones de la IA 🛡️.

🎯 Precisión Absoluta

Cuando Claude me responde sobre APIs de Apple, ya no adivina. Busca en la documentación oficial real y me da información 100% verificada.

Nada de: “Creo que en SwiftUI 6 se usa así…” ❌

Ahora es: “Según la documentación oficial de SwiftUI 6…” ✅

⚡ Velocidad de Desarrollo

Antes:

Pregunta → Espera respuesta → Duda → Abrir Safari →
Buscar en Google → Leer docs → Volver al IDE → Implementar

Ahora:

Pregunta → Respuesta con documentación oficial → Implementar

Ahorro brutal de tiempo en cada consulta 🏎️.

📊 Búsqueda Súper Potente

Cupertino usa SQLite FTS5 con ranking BM25. En cristiano: búsquedas ultra-rápidas (menos de 100ms) con resultados relevantes ordenados por importancia.

Puedes filtrar por:

Framework específico 🧰
Versión de plataforma (iOS 17, macOS 14, etc.) 📱
Tipo de documentación (API, ejemplos, guías) 📚
Búsqueda en código de ejemplo 💻

🧠 Aprendizaje Contextualizado

No solo obtengo la API correcta, también obtengo:

Ejemplos de código reales de Apple 📝
Mejores prácticas documentadas 👍
Patrones de diseño oficiales 🎨
Alternativas y deprecaciones ⚠️

Es como tener un mentor de Apple dentro de Claude 🍎🤝🤖.

💭 Reflexión Final

Cupertino MCP es un ejemplo perfecto de cómo las herramientas de IA se vuelven realmente útiles cuando tienen acceso a información verificada y actualizada.

No se trata de darle más poder a la IA para que “adivine mejor”. Se trata de conectarla con fuentes fiables para que te dé respuestas precisas.

Si desarrollas para ecosistemas de Apple, Cupertino MCP es una inversión de 5 minutos (instalación) que te ahorrará horas cada semana. Y si usas Claude Code como yo, la experiencia se vuelve aún mejor 💎.

¿Lo recomiendo? Absolutamente. Es obligatorio si desarrollas con Swift, SwiftUI o cualquier framework de Apple 🍎.

¿Es para todo el mundo? Solo si desarrollas para plataformas Apple. Si trabajas con otras tecnologías, busca herramientas similares (seguro hay equivalentes para Android, web, etc.) 🔍.

Keep coding, keep running 🏃‍♂️

Which AI

2026-04-17T19:06:06Z

🎭 Déjà Vu: Los Frameworks Web 2.0

¿Recuerdan aquella época dorada donde cada semana aparecía un nuevo framework web?

Uno más moderno, más rápido, más potente, más bonito… Uno que venía a “matar” a todos los anteriores y que iba a convertirse en el único framework que necesitarías usar jamás 💀.

Spoiler: ninguno mató a nadie, y ahora tenemos más frameworks que nunca 😂.

Pues bien, bienvenidos a la era de las IAs: el mismo concepto, pero con esteroides 🚀.

📱 La Fatiga de las Notificaciones

Imagina la escena: estás tranquilamente programando con tu IA de confianza, flujo de trabajo perfecto, productividad al máximo… y de repente:

📢 Notificación: ”¡Nueva IA revolucionaria lanzada!”

🎥 Video: “Cómo usarla en 10 minutos”

📝 Tutorial: “Integrala en tu workflow HOY”

💡 Thread: “Por qué deberías cambiarte ahora mismo”

Y aquí viene lo más divertido: el creador de contenido que hace 1 hora tenía un video explicando “Por qué la antigua IA es el futuro”, ahora tiene otro video sobre “Por qué la nueva IA es mejor que todo” 🎪.

No los culpo, eh. Es su trabajo mantenerse actualizados y crear contenido relevante. Pero como consumidor… es agotador 😅.

🏃‍♂️ La Carrera Imposible

Si ya es complicado seguir las actualizaciones diarias de la IA que estás usando (y créeme, son muchísimas actualizaciones), imagínate ponerte a:

Probar cada nueva IA que sale ✅
Aprender su interfaz y peculiaridades 📚
Integrarla en tu workflow 🔧
Compararla con las que ya usas ⚖️
Decidir si vale la pena el cambio 🤔

Resultado: Misión imposible 🎯.

Y no me malinterpreten: me encanta tener opciones. De hecho, es maravilloso que exista tanta competencia e innovación. Más opciones = más mejor 👍🏻.

🚫 Mi Línea Roja

Ahora bien, hay algo en lo que soy tajante:

Jamás usaré una IA que requiera permisos totales desde el principio 🔒.

Nada de “Dame acceso completo a tu máquina y confía en mí”. Eso no va conmigo.

Mi filosofía es clara:

📋 Dime qué vas a hacer (o planifícalo)
👀 Yo reviso los cambios
✅ Yo apruebo (o no apruebo)
🚀 Entonces procedes

No al libre albedrío de la IA con permisos de administrador. Control total es mi mantra, como ya conté en mi artículo sobre Claude Code 💪.

🌐 Ya No Es Solo un Modelo

Y aquí está lo realmente fascinante: la IA ya no es simplemente “un modelo” o “una app” que instalas y usas.

Ahora tenemos ecosistemas completos 🏗️:

Modelos base + fine-tuned ⚙️
Integraciones con IDEs 💻
Plugins y extensiones 🔌
APIs y SDKs 📡
Plataformas de orquestación 🎼
Herramientas especializadas 🛠️

Es increíble la velocidad a la que todo esto está evolucionando. Lo que era ciencia ficción hace 2 años, ahora es tu asistente de código diario 🤖.

🎢 Viviendo una Época Increíble

Al final del día, creo que estamos viviendo algo histórico 🎊:

🥊 Batalla de los IDEs: VSCode vs. Cursor vs. WindSurf vs. Zed vs…

⚔️ Batalla de los Frameworks: React vs. Vue vs. Svelte vs. Solid vs…

🤖 Batalla de las IAs: Claude vs. ChatGPT vs. Gemini vs. Copilot vs…

Es agotador intentar seguirlo todo, lo admito. A mí personalmente me resulta imposible 🙃.

Pero también es emocionante. Cada día hay algo nuevo que aprender, algo que probar, algo que te hace replantear cómo trabajas.

🎯 Reflexión Final

La moraleja de todo esto es simple:

No necesitas usar todo. De verdad, no lo necesitas 🙅‍♂️.

Encuentra las herramientas que funcionen para ti, aprende a usarlas bien, mantente actualizado con sus novedades, y está bien que de vez en cuando explores alternativas.

Pero no te vuelvas loco intentando estar en todas las olas a la vez. Elige tu tabla de surf 🏄‍♂️, aprende a usarla bien, y disfruta del viaje.

Y si un día decides cambiar de tabla, pues adelante. Pero que sea una decisión consciente, no una reacción al FOMO (Fear Of Missing Out) creado por 47 notificaciones simultáneas 😂.

Feliz coding (con la IA que prefieras) 🚀

Keep coding, keep running 🏃‍♂️

Conferences 25

2026-04-17T19:06:06Z

iOSConfSG

📅 15-17 de enero

📍 Singapur, 🇸🇬

🔗 iosconf

🎥 youtube

AppDevCon

📅 18–21 de marzo

📍 Ámsterdam, 🇳🇱

🔗 appdevcon

🎥 videos

Swift Heroes

📅 8–9 de abril

📍 Turín, 🇮🇹

🔗 swiftheroes

🎥 youtube

try! Swift Tokyo

📅 9–11 de abril

📍 Tokio, 🇯🇵

🔗 tryswift

🎥 youtube

Deep Dish Swift

📅 27–29 de abril

📍 Chicago, 🇺🇸

🔗 deepdishswift

🎥 youtube

iOSKonf

📅 13–15 de mayo

📍 Skopje, 🇲🇰

🔗 ioskonf

🎥 youtube

Swift Craft

📅 19–21 de mayo

📍 Kent, 🇬🇧

🔗 swiftcraft

🎥 youtube

WWDC

📅 9–13 de junio

📍 Cupertino, 🇺🇸

🔗 apple

🎥 youtube

NSSpain

📅 17-19 septiembre

📍 Logroño, 🇪🇸

🔗 nsspain

🎥 youtube

Swift Connection

📅 6–7 de octubre

📍 París, 🇫🇷

🔗 swiftconnection

🎥 youtube

SwiftLeeds

📅 7–8 de octubre

📍 Leeds, 🇬🇧

🔗 swiftleeds

🎥 youtube

Pragma Conference

📅 30–31 de octubre

📍 Bolonia, 🇮🇹

🔗 pragmaconference

🎥 youtube

Do iOS

📅 12-13 de noviembre

📍 Amsterdam, 🇳🇱

🔗 do-ios

🎥 youtube

Keep coding, keep running 🏃‍♂️

Async Concurrent Map

2026-04-17T19:06:06Z

Problema

En aplicaciones backend con Vapor, cuando procesamos grandes volúmenes de datos de forma concurrente, nos enfrentamos a un dilema de optimización:

Procesamiento secuencial con asyncMap: garantiza control sobre los recursos, pero es lento al procesar elementos uno a uno.
Procesamiento totalmente concurrente con concurrentMap: maximiza la velocidad, pero puede saturar recursos al lanzar miles de tareas simultáneas.

Por ejemplo, al procesar 10,000 registros con llamadas a APIs externas:

asyncMap: 10,000 llamadas secuenciales → muy lento pero controlado.
concurrentMap: 10,000 llamadas simultáneas → muy rápido pero puede agotar conexiones/memoria.

Necesitamos una solución que combine ambos enfoques: dividir el trabajo en grupos manejables y procesar cada grupo de forma concurrente, equilibrando velocidad y uso de recursos.

Solución

Extendemos Collection con una función que combina chunking (división en grupos) y procesamiento concurrente, permitiendo configurar el tamaño de los grupos y timeout por chunk.

extension Collection where Element: Sendable {
    func asyncConcurrentMap<T: Sendable>(
        chunkSize: Int? = nil,
        timeout: Double? = nil,
        _ transform: @escaping @Sendable (Element) async throws -> T
    ) async throws -> [T] {
        guard let chunkSize else {
            return try await concurrentMap(transform)
        }

        return try await chunks(ofCount: chunkSize)
            .asyncMap(timeout: timeout) {
                try await $0.concurrentMap(transform)
            }.flatMap { $0 }
    }
}

Puntos clave:

Si no se especifica chunkSize, usa concurrentMap puro (procesamiento totalmente concurrente).
Si se especifica chunkSize, divide la colección en grupos con chunks(ofCount:).
Procesa los chunks secuencialmente con asyncMap (con timeout opcional).
Dentro de cada chunk, procesa los elementos concurrentemente con concurrentMap.
Aplana los resultados con flatMap para devolver un array unificado.

Resultado

// Procesar 10,000 registros en chunks de 100
// 100 tareas concurrentes a la vez, 100 veces
let results = try await records.asyncConcurrentMap(
    chunkSize: 100,
    timeout: 30.0
) { record in
    try await apiClient.process(record)
}

Beneficios de esta aproximación:

⚡ Balance perfecto: combina la velocidad del procesamiento concurrente con el control del procesamiento secuencial por chunks.

🎯 Control de recursos: limita la cantidad de tareas simultáneas al tamaño del chunk, evitando saturación.

⏱️ Timeout por chunk: detecta y maneja chunks problemáticos sin bloquear todo el procesamiento.

🔧 Flexibilidad total: usa chunking cuando lo necesites, o procesamiento concurrente puro cuando no.

📊 Escalabilidad: permite procesar millones de registros ajustando el tamaño del chunk según los recursos disponibles.

Si necesitas ejecución paralela pura, lo cubrí en Concurrent Map. Y si tus chunks secuenciales necesitan rate limiting entre ellos, añadí esa capacidad en Async Map Timeout.

Esta solución es la evolución natural de asyncMap y concurrentMap, combinando lo mejor de ambos mundos para optimizar el procesamiento de datos masivos en aplicaciones backend.

Keep coding, keep running 🏃‍♂️

Async Map Timeout

2026-04-17T19:06:06Z

Problema

En el post sobre AsyncMap vimos cómo procesar colecciones de forma secuencial asíncrona. Sin embargo, al trabajar con APIs externas que implementan rate limiting, nos enfrentamos a un problema crítico:

// Procesar 1000 URLs secuencialmente
let results = try await urls.asyncMap { url in
    try await apiClient.fetch(url)  // ⚠️ 1000 llamadas sin pausa
}
// Error 429: Too Many Requests

Realizar llamadas consecutivas sin pausas puede:

Exceder límites de rate: APIs rechazan con 429 Too Many Requests.
Saturar servicios externos: sobrecarga de conexiones simultáneas.
Desperdiciar recursos: forzar reintentos consume más tiempo y ancho de banda.
Bloqueos temporales: algunas APIs bloquean la IP tras múltiples infracciones.

Necesitamos una forma de controlar el ritmo de las operaciones secuenciales, añadiendo pausas intencionales entre cada procesamiento.

Solución

Actualizamos asyncMap añadiendo un parámetro opcional timeout que introduce una pausa configurable después de procesar cada elemento.

extension Sequence {
    func asyncMap<T>(
        timeout: Double? = nil,
        _ transform: (Element) async throws -> T
    ) async throws -> [T] {
        var results = [T]()
        results.reserveCapacity(underestimatedCount)
        for element in self {
            try await results.append(transform(element))
            if let timeout {
                try await Task.sleep(for: .seconds(timeout))
            }
        }
        return results
    }
}

Cambios clave respecto a la versión original:

✨ Parámetro timeout: Double? = nil opcional y retrocompatible.

⏱️ Si se especifica timeout, añade Task.sleep(for: .seconds(timeout)) después de cada elemento.

🔄 Mantiene el comportamiento original cuando no se especifica timeout (sin pausas).

📊 Permite ajustar dinámicamente el rate limiting según los límites de cada API.

Resultado

// Rate limiting: 1 llamada por segundo
let results = try await urls.asyncMap(timeout: 1.0) {
    try await apiClient.fetch($0)
}

// Rate limiting agresivo: 1 llamada cada 5 segundos
let results = try await endpoints.asyncMap(timeout: 5.0) {
    try await scraper.parse($0)
}

// Sin timeout: comportamiento original (máxima velocidad)
let results = try await localFiles.asyncMap {
    try await processFile($0)
}

Beneficios de esta actualización:

⏱️ Rate limiting configurable: controla el ritmo de llamadas según los límites de cada API.

🛡️ Prevención de bloqueos: evita errores 429 y suspensiones temporales de IP.

🔄 Retrocompatibilidad total: sin timeout funciona exactamente igual que antes.

🎯 Flexibilidad por caso de uso: ajusta el timeout según la tolerancia del servicio externo.

📊 Procesamiento predecible: calcula fácilmente el tiempo total (n elementos × timeout).

Esta actualización convierte asyncMap en una herramienta completa para procesamiento secuencial controlado, ideal para integración con APIs que imponen límites de tasa y necesitan un flujo de peticiones regulado.

Keep coding, keep running 🏃‍♂️

Copy To

2026-04-17T19:06:06Z

Problema

En aplicaciones backend con Vapor, a menudo necesitamos exportar grandes volúmenes de datos desde la base de datos a archivos para diferentes propósitos: backups, análisis offline, integración con sistemas externos, o auditorías de datos.

Usar consultas tradicionales con Fluent para luego serializar los resultados manualmente presenta varios inconvenientes:

Alto consumo de memoria: cargar miles de registros en memoria para procesarlos uno a uno.
Procesamiento lento: serialización manual a CSV requiere iterar y formatear cada registro.
Falta de optimización: no aprovecha las capacidades nativas de exportación del motor de base de datos.
Complejidad innecesaria: gestión manual de formatos, escapado de caracteres y manejo de valores nulos.

Para escenarios de exportación masiva, necesitamos una estrategia que aproveche las capacidades nativas de PostgreSQL para generar archivos de forma eficiente.

Solución

Extendemos Database con una función que ejecuta el comando COPY … TO de PostgreSQL, permitiendo exportar datos directamente desde el schema de la tabla a archivos CSV en el sistema de archivos.

extension Database {
    func exportCSV(
        _ model: any Model.Type,
        file: PathEnum)
        async throws {
        let query = SQLQueryString(
            """
            COPY \"\(unsafeRaw: model.space ?? "public")\".
            \"\(unsafeRaw: model.schema)\"
            TO '\(unsafeRaw: file.rawValue)'
            WITH (FORMAT csv, HEADER true, DELIMITER ',',
            QUOTE '"', ESCAPE '"', NULL '')
            """
        )

        try await self.sqlDatabase
            .raw(query).run()
    }
}

Puntos clave:

Usa COPY … TO de PostgreSQL, el método más eficiente para exportación masiva.
El parámetro model.space soporta schemas personalizados (por defecto “public”).
model.schema obtiene automáticamente el nombre de la tabla del modelo Fluent.
Configuración CSV estándar: headers incluidos, delimitadores y manejo correcto de valores nulos.
Utiliza unsafeRaw para interpolación directa en la query SQL.

Resultado

func exportRegions() async throws {
    try await db.exportCSV(
        LocationRegionModel.self, 
        file: file
    )
}

Beneficios de esta aproximación:

🚀 Performance óptimo: COPY … TO es mucho más rápido que serialización manual.

💾 Eficiencia de recursos: PostgreSQL escribe directamente al archivo sin cargar datos en memoria de la aplicación.

📦 Formato consistente: el motor de base de datos garantiza un CSV válido con escapado correcto.

🔧 Integración nativa: aprovecha capacidades optimizadas del motor PostgreSQL.

📊 Escalabilidad: permite exportar millones de registros sin impacto en el rendimiento de la aplicación.

Esta solución es el complemento perfecto para importCSV, formando un par de funciones que permite movimiento bidireccional de datos entre PostgreSQL y el sistema de archivos de forma eficiente y confiable. Si aún no has visto la parte de importación, explico cómo construirla usando COPY FROM de PostgreSQL en Copy From.

Keep coding, keep running 🏃‍♂️

Copy From

2026-04-17T19:06:06Z

Problema

En aplicaciones backend con Vapor, cuando necesitamos insertar grandes volúmenes de datos en la base de datos (migraciones iniciales, importación de catálogos, carga masiva desde APIs externas), usar .save() en un bucle genera múltiples transacciones individuales.

Esto resulta en:

Alta latencia: cada insert abre/cierra conexión y transaction overhead.
Pobre throughput: no aprovecha las capacidades de inserción masiva del motor de base de datos.
Riesgo de timeout: operaciones lentas que pueden fallar en entornos con límites de tiempo.

Para escenarios de importación masiva (miles o millones de registros), necesitamos una estrategia de bulk insert que aproveche las capacidades nativas de PostgreSQL.

Solución

Extendemos Database con una función que ejecuta el comando COPY de PostgreSQL, permitiendo importar archivos CSV directamente desde el sistema de archivos al schema de la tabla.

extension Database {
    func importCSV(
        _ model: any Model.Type,
        file: PathEnum
        ) async throws {
        let query = SQLQueryString(
            """
            COPY \"\(unsafeRaw: model.space ?? "public")\".
            \"\(unsafeRaw: model.schema)\"
            FROM '\(unsafeRaw: file.rawValue)'
            WITH (FORMAT csv, HEADER true, DELIMITER ',',
            QUOTE '"', ESCAPE '"', NULL '')
            """
        )

        try await self.sqlDatabase
            .raw(query).run()
    }
}

Puntos clave:

Usa COPY de PostgreSQL, el método más rápido para bulk insert desde archivos.
El parámetro model.space soporta schemas personalizados (por defecto “public”).
model.schema obtiene automáticamente el nombre de la tabla del modelo Fluent.
Configuración CSV estándar: headers, delimitadores y manejo de valores nulos.
Utiliza unsafeRaw para interpolación directa en la query SQL.

Resultado

private func importRegions() async throws {
    try await db.importCSV(
        RegionModel.self,
        file: .LocationFile("regions", .csv)
    )
}

Beneficios de esta aproximación:

🚀 Performance extremo: COPY es hasta 10-100x más rápido que inserts individuales.

📦 Transacción atómica: toda la importación ocurre en una sola operación, garantizando consistencia.

💾 Eficiencia de recursos: minimiza el uso de memoria y conexiones de base de datos.

🔧 Integración nativa: aprovecha capacidades optimizadas del motor PostgreSQL.

📊 Escalabilidad: permite importar millones de registros sin degradación significativa.

Notas

Esta implementación utiliza COPY … FROM con archivos del sistema. Actualmente existe una issue abierta en Vapor para implementar soporte nativo de COPY … FROM STDIN, que permitiría realizar bulk inserts directamente desde memoria sin necesidad de archivos intermedios.

Estoy vigilando esta issue de manera activa para integrar esta funcionalidad cuando esté disponible, lo que proporcionará una API aún más flexible y eficiente para operaciones de importación masiva.

Si también necesitas la operación inversa — exportar datos de PostgreSQL a archivos CSV — lo cubrí en Copy To.

Keep coding, keep running 🏃‍♂️

Swift Package

2026-04-17T19:06:06Z

El dilema de las dependencias rotas

Cuando trabajas con Swift Package Manager (SPM), eventualmente te encontrarás con un error de compilación que parece no tener sentido. Has intentado compilar varias veces, has reiniciado Xcode, pero el error persiste. La solución muchas veces está en limpiar correctamente las cachés y artefactos de SPM, pero ¿qué comando usar?

Existen múltiples formas de “limpiar” en SPM, cada una con un propósito específico. Usar el comando equivocado puede no resolver tu problema o, peor aún, forzarte a descargar gigabytes de dependencias nuevamente.

Los cuatro caminos para limpiar

SPM ofrece tres comandos oficiales más una alternativa manual. Cada uno afecta diferentes partes del sistema:

Comando	Elimina .build local	Elimina Package.resolved	Elimina caché global
swift package clean	❌ (solo binarios compilados)	❌	❌
swift package reset	✅ (completo)	✅	❌
swift package purge-cache	❌	❌	✅
rm -rf .build	✅ (completo)	❌	❌

Swift package clean

swift package clean

Qué hace:
Elimina únicamente los binarios compilados finales dentro de la carpeta .build, pero mantiene dependencias descargadas y archivos intermedios.

Cuándo usarlo:

Después de cambiar configuraciones de compilación
Para forzar una recompilación completa sin re-descargar dependencias
Cuando los binarios están corruptos pero las fuentes están bien

💡 No descarga dependencias nuevamente ni resuelve problemas de caché de paquetes.

Swift package reset

swift package reset

Qué hace:
Elimina completamente la carpeta .build (incluyendo dependencias descargadas) y el archivo Package.resolved.

Cuándo usarlo:

Cuando hay conflictos en las versiones de dependencias
Después de cambios importantes en Package.swift
Para resolver errores de “dependencia no encontrada”
Cuando Package.resolved está desactualizado o corrupto

⚠️ La próxima compilación descargará y resolverá todas las dependencias desde cero. Esto puede tardar varios minutos dependiendo de la cantidad de paquetes.

Swift package purge-cache

swift package purge-cache

💡 Disponible desde Swift 5.7 en adelante.

Qué hace:
Elimina la caché global de paquetes ubicada en:

~/Library/Caches/org.swift.swiftpm/

Esta caché contiene repositorios clonados y artefactos binarios compartidos entre todos tus proyectos.

Cuándo usarlo:

Cuando múltiples proyectos tienen el mismo problema
Después de actualizar Xcode o herramientas de Swift
Para liberar espacio en disco (puede ocupar varios GB)
Cuando sospechas que la caché global está corrupta

⚠️ Todos tus proyectos tendrán que re-descargar dependencias comunes.

rm -rf .build

rm -rf .build

Qué hace:
Elimina manualmente la carpeta .build completa, similar a reset pero sin tocar Package.resolved. Es menos agresivo que reset porque no re-resuelve dependencias.

Cuándo usarlo:

Para limpiar artefactos de compilación manteniendo la resolución de versiones
En scripts de CI/CD donde quieres control total
Cuando swift package reset no está disponible

💡 Preserva Package.resolved, lo que significa que las versiones de dependencias no se re-resolverán.

Estrategia de resolución de problemas

Nivel 1: Limpieza ligera

swift package clean

💡 Prueba primero lo menos invasivo. Resuelve el 30% de los problemas.

Nivel 2: Reset completo del proyecto

swift package reset

💡 Si el nivel 1 falla. Resuelve el 60% de los problemas restantes.

Nivel 3: Purgar caché global

swift package purge-cache
swift package reset

💡 Para problemas persistentes o que afectan múltiples proyectos.

Nivel 4: Nuclear

rm -rf .build
rm Package.resolved
swift package purge-cache

💡 Última opción. Borrón y cuenta nueva total.

Casos de uso reales

Escenario 1: Error después de actualizar Xcode

swift package purge-cache
swift package reset

💡 Las herramientas de compilación cambiaron y la caché puede tener artefactos incompatibles.

Escenario 2: Conflicto de versiones de dependencias

swift package reset

💡 Necesitas re-resolver todas las dependencias con las nuevas restricciones.

Escenario 3: Espacio en disco lleno

swift package purge-cache

💡 La caché global puede crecer hasta varios GB sin que lo notes.

Escenario 4: CI/CD builds

rm -rf .build

💡 En entornos de integración continua, quieres builds limpios pero reproducibles con Package.resolved versionado.

Entendiendo los componentes

.build (local)

Artefactos de compilación del proyecto actual
Dependencias descargadas específicas del proyecto
Archivos intermedios de compilación

Package.resolved

“Lockfile” que fija versiones exactas de dependencias
Garantiza builds reproducibles
Debe versionarse en Git para proyectos compartidos

Caché global

Compartida entre todos tus proyectos Swift
Contiene clones de repositorios de dependencias
Artefactos binarios pre-compilados
Puede alcanzar varios GB con el tiempo

Mejores prácticas

✅ Versiona Package.resolved en Git para garantizar que todo el equipo use las mismas versiones

✅ Usa reset después de cambios en Package.swift para asegurar una resolución limpia

✅ Purga la caché periódicamente si trabajas con muchos proyectos

✅ En CI/CD, mantén Package.resolved pero elimina .build para builds limpios

❌ No ignores .build en .gitignore - ya está ignorado por defecto

❌ No borres Package.resolved a menos que realmente necesites re-resolver versiones

Conclusión

Entender la diferencia entre estos comandos te ahorra tiempo y frustración. No todos los problemas de compilación necesitan una limpieza nuclear:

clean → Solo binarios compilados
reset → Proyecto completo + Package.resolved
purge-cache → Caché global compartida
rm -rf → Control manual quirúrgico

La próxima vez que SPM te muestre un error extraño, ya sabes exactamente qué herramienta usar.

Keep coding, keep running 🏃‍♂️

Subprocess

2026-04-17T19:06:06Z

Problema

Al trabajar con procesos externos en aplicaciones Swift, la clase tradicional Process presenta varias limitaciones importantes:

Gestión manual de recursos: Requiere configuración explícita de URLs ejecutables, argumentos y manejo de salidas
Falta de soporte async/await: Utiliza métodos síncronos que bloquean el hilo de ejecución
Manejo complejo de errores: Dificulta la captura y procesamiento de errores del proceso hijo
Configuración verbosa: Cada ejecución requiere múltiples líneas de configuración repetitiva

En el código anterior, necesitaba ejecutar Ghostscript para convertir archivos PDF a imágenes PNG, pero la implementación con Process resulta extensa y poco elegante.

func _PDFToImages(
    _ fileName: PathEnum
) async throws {
    let process = Process()

    process.executableURL = URL(
        fileURLWithPath: "/opt/homebrew/bin/gs"
    )

    process.arguments = [
        "-dNOPAUSE", "-dBATCH",
        "-dQUIET", "-sDEVICE=png16m",
        "-r300",
        "-sOutputFile=\(fileName.rawValue)-%d.png",
        fileName.rawValue.appending(".pdf"),
    ]

    try process.run()
    process.waitUntilExit()
}

Solución

La nueva librería Subprocess de Apple proporciona una API moderna y robusta para la ejecución de procesos en Swift. Esta librería multiplataforma ofrece soporte nativo para async/await y gestión automática de recursos.

Características principales:

✅ API nativa async/await para operaciones no bloqueantes.

✅ Gestión automática de recursos y limpieza de procesos.

✅ Control granular de salidas (stdout, stderr).

✅ Verificación de estado de terminación integrada.

✅ Sintaxis concisa y expresiva.

La implementación modernizada utiliza la función run de Subprocess:

func _PDFToImages(
    _ fileName: PathEnum
) async throws {
    let result = try await run(
        .path(.init("/opt/homebrew/bin/gs")),
        arguments: [
            "-dNOPAUSE", "-dBATCH",
            "-dQUIET", "-sDEVICE=png16m",
            "-r300",
            "-sOutputFile=\(fileName.rawValue)-%d.png",
            fileName.rawValue.appending(".pdf"),
        ],
        output: .discarded,
        error: .string(limit: .max)
    )

    try guardAndLogError(
        result.terminationStatus == .exited(0),
        message: result.standardError,
        status: .internalServerError
    )
}

Parámetros clave:

.path: Especifica el ejecutable de forma directa
output: .discarded: Descarta la salida estándar ya que no necesitamos procesarla
error: .string(limit: .max): Captura errores como string para logging
result.terminationStatus: Verifica que el proceso terminó exitosamente

Resultado

La migración a Subprocess transforma el código de gestión de procesos en una solución más limpia, segura y eficiente:

Beneficios obtenidos:

🚀 Rendimiento mejorado con operaciones asíncronas reales.

🔒 Mejor manejo de errores con captura integrada de stderr.

📝 Código más legible con menos configuración manual.

⚡ Integración perfecta con el ecosistema moderno de Swift concurrency.

La nueva implementación no solo reduce la complejidad sino que también mejora la robustez del sistema al proporcionar mejor visibilidad de errores y un manejo más elegante de la ejecución asíncrona en aplicaciones Vapor.

Nota sobre DYLD_LIBRARY_PATH

En versiones anteriores de Swift, existía un problema conocido con la variable de entorno DYLD_LIBRARY_PATH al ejecutar procesos externos. Debido a las restricciones de System Integrity Protection (SIP) de macOS, esta variable era eliminada automáticamente al lanzar subprocesos, lo que causaba errores de “Library not loaded” en ciertos casos.

La solución temporal requería configurar manualmente las rutas de las librerías usando install_name_tool con @rpath, o bien establecer la variable DYLD_LIBRARY_PATH en su lugar.

¡Buenas noticias! 🎉 Este problema ha sido resuelto en las versiones más recientes de Swift. La librería Subprocess maneja correctamente las variables de entorno del sistema, incluida DYLD_LIBRARY_PATH, sin necesidad de configuraciones adicionales.

Keep coding, keep running 🏃‍♂️

Json Snake Case

2026-04-17T19:06:06Z

Problema

Cuando integramos APIs REST, es muy común que las claves JSON vengan en snake_case (por ejemplo, first_name) mientras que en Swift modelamos las propiedades en camelCase (firstName).
Si no configuramos nada, nos toca escribir CodingKeys a mano en cada modelo o aceptar errores de decodificación.

Buscamos una forma centralizada y reutilizable de:

Decodificar JSON sin CodingKeys manuales.
Codificar nuestros modelos al enviar datos.
Mantener el mismo comportamiento tanto en apps iOS/macOS (URLSession) como en Vapor (req/res content).

Solución

Creamos extensiones de JSONDecoder y JSONEncoder que exponen constructores de conveniencia y atajos estáticos snakeCase.
Ventajas:

Cero boilerplate en los modelos: evita CodingKeys repetitivas.
Nombre autoexplicativo al usarlas: JSONDecoder.snakeCase / JSONEncoder.snakeCase.
Consistencia en todo el proyecto (cliente y servidor).

extension JSONDecoder {
    convenience init(keyDecodingStrategy: KeyDecodingStrategy) {
        self.init()
        self.keyDecodingStrategy = keyDecodingStrategy
    }

    static var snakeCase: JSONDecoder {
        .init(keyDecodingStrategy: .convertFromSnakeCase)
    }
}

extension JSONEncoder {
    convenience init(keyEncodingStrategy: KeyEncodingStrategy) {
        self.init()
        self.keyEncodingStrategy = keyEncodingStrategy
    }

    static var snakeCase: JSONEncoder {
        .init(keyEncodingStrategy: .convertToSnakeCase)
    }
}

Nota: si un modelo necesita un nombre de clave específico, puedes seguir usando CodingKeys localmente; la estrategia snake_case actuará como valor por defecto.

Resultado

Ejemplos de uso

// iOS / macOS: leer datos
let data: Data = ...
let user = try JSONDecoder.snakeCase
    .decode(UserDTO.self, from: data)

// iOS / macOS: enviar datos
let body = CreateUserDTO(firstName: "Ada", lastName: "Lovelace")
request.httpBody = try JSONEncoder.snakeCase.encode(body)

// Vapor
let input = try req.content
    .decode(CreateUserDTO.self, using: JSONDecoder.snakeCase)

Con estos atajos obtenemos:

Menos errores y mayor legibilidad: las propiedades permanecen en camelCase idiomático Swift.
Interoperabilidad inmediata con APIs legacy en snake_case.
Configuración única y reutilizable en todo el proyecto (tests incluidos).

Esto estandariza cómo serializamos/parseamos JSON sin sacrificar claridad ni control fino cuando hace falta.

Keep coding, keep running 🏃‍♂️

Array to dictionary

2026-04-17T19:06:06Z

Problema

Al trabajar con listas de modelos (por ejemplo, resultados, eventos o usuarios), a menudo necesitamos acceso O(1) por identificador para búsquedas, merges o deduplicación.

Sin embargo, en muchos dominios el id puede ser opcional (UUID?) hasta que el backend lo asigne. Si construimos un diccionario directamente, aparecen dos fricciones:

Hay que filtrar los elementos sin ID para evitar entradas inválidas.
Debemos garantizar unicidad de las claves o el constructor de Dictionary(uniqueKeysWithValues:) fallará en tiempo de ejecución si hay duplicados.

Solución

Extendemos Array (cuando sus elementos son Identifiable con ID == UUID?) para exponer toDictionary().
La función usa compactMap para descartar elementos sin ID y construye el diccionario con Dictionary(uniqueKeysWithValues:).

Precondición: los IDs existentes deben ser únicos en la colección. Si esperas colisiones, considera una variante con Dictionary(_, uniquingKeysWith:) para resolver duplicados.

extension Array where Element: Identifiable, Element.ID == UUID? {
    func toDictionary() -> [UUID: Element] {
        Dictionary(uniqueKeysWithValues: self.compactMap {
            guard let id = $0.id else { return nil }
            return (id, $0) }
        )
    }
}

Notas:

Los elementos con id == nil no se incluyen.
El acceso por clave es O(1) y simplifica merges/joins en memoria.

Resultado

Un helper pequeño y claro para pasar de un array a un mapa por ID:

Más rápido de consultar O(1).
Más seguro: evita insertar elementos sin identificador.
Más expresivo y reutilizable en servicios y view models.

Keep coding, keep running 🏃‍♂️

Schedule Queues

2026-04-17T19:06:06Z

Problema

Cuando usamos Vapor Queues para planificar trabajos, la API típica es:

app.queues
    .schedule(MyJob()).hourly().at(0)

Esto planifica cada hora. Si queremos ejecutarlo cada N minutos (p. ej., cada 5, 10 o 15), tenemos que registrar manualmente varios .at(…), lo que acaba en código repetitivo, propenso a errores (minutos duplicados/olvidados) y poco legible.

Solución

Extraemos un helper sobre Application.Queues que registra el mismo ScheduledJob múltiples veces dentro de la hora usando un stride con paso minutes. Así, con una sola llamada expresamos: “ejecútalo cada N minutos”.

extension Application.Queues {
    func scheduleEvery(
        _ job: ScheduledJob, 
        minutes: Int
    ) {
        for minuteOffset in stride(
            from: 0, 
            to: 60, 
            by: minutes
        ) {
            schedule(job).hourly()
                .at(.init(integerLiteral: minuteOffset))
        }
    }
}

Puntos clave:

Usa stride(from: 0, to: 60, by: minutes) para generar los offsets de minuto dentro de la hora.
Por cada offset se registra hourly().at(…), evitando duplicar lógica.
Si minutes no divide 60, la última ejecución será el mayor múltiplo < 60 (p. ej., minutes = 7 ⇒ 0, 7, 14, …, 56).

Resultado

Ejemplo de uso:

func configure(_ app: Application) throws {
    app.queues.scheduleEvery(MyJob(), minutes: 5)
}

Una API concisa y autoexpresiva para tareas periódicas cortas:

Menos boilerplate: una sola llamada registra todos los disparos.
Menos errores: sin listas manuales de .at(…) ni minutos duplicados.
Legible y testeable: el patrón es evidente y fácil de verificar.

Keep coding, keep running 🏃‍♂️

Async Task List

2026-04-17T19:06:06Z

Problema

En sistemas distribuidos con microservicios, un proceso complejo puede generar dificultades de control y fiabilidad. Una solución es dividirlo en tareas atómicas, lo que permite un control más granular del flujo, mejorar la observabilidad, asegurar la idempotencia y facilitar la recuperación ante fallos.

El reto es diseñar un patrón que permita una degradación controlada, de modo que el fallo de una tarea no afecte al flujo completo, garantizando resiliencia y tolerancia a fallos en entornos de producción.

Solución

Crear un task executor que orquesta tareas asíncronas.
La función execute envuelve cada tarea, gestiona errores con do-catch como circuit breaker, actualiza el estado en caso de éxito, registra y persiste los fallos, y asegura una transacción atómica para mantener la consistencia de datos.

func execute(
    status: StatusEnum,
    process: ProcessModel,
    _ work: () async throws -> ProcessModel
) async throws {
    do {
        let job = try await work()
        process.setStatus(job.status)
    } catch {
        process.setError(type: status, message: "\(error)")
    }
    try await repo.updateProcess(process)
}

Resultado

Esta implementación ofrece una abstracción de alto nivel que permite una orquestación precisa de procesos asíncronos complejos con garantías de atomicidad y durabilidad.

🎯 Separation of Concerns: cada tarea aísla su contexto de ejecución y su gestión de errores.

🔄 Workflow Orchestration: posibilita encadenar tareas mediante el pipeline pattern.

📊 Observability: genera un audit trail completo para depuración y monitorización.

⚡ Performance: mantiene alta concurrencia sin comprometer la consistencia de datos.

🛡️ Resilience: incorpora fail-fast y recovery patterns automáticos.

try await execute(status: .loadImages, process: process) {
    // Your implementation
}

Keep coding, keep running 🏃‍♂️

Multi-Step Process

2026-04-17T19:06:06Z

Problema

En sistemas distribuidos y procesos de backend, es común que una operación compleja requiera ejecutar múltiples pasos secuenciales con dependencias entre sí: creación de ficheros, subida, generación de respuestas, validación, limpieza, etc.
Controlar este flujo de estados es crítico para:

Garantizar que cada paso se ejecute en el orden correcto.
Permitir la recuperación en caso de error o reinicio del sistema.
Mantener la consistencia de datos incluso si el proceso se interrumpe.

Sin una estrategia clara, el código puede volverse frágil, difícil de escalar y propenso a errores.

Solución

Se implementa una función de gestión de estado por etapas que controla el avance de un ProcessModel a través de su ciclo de vida.
La idea es encapsular la lógica de transición de estado en una única función que evalúa el estado actual y ejecuta la acción correspondiente, hasta que el proceso alcanza su estado final.

El patrón se apoya en un bucle repeat-while que vuelve a evaluar el estado tras cada operación, garantizando que las transiciones ocurran de forma determinista y resiliente.

func checkProcess(
    _ process: ProcessModel
) async throws {
    var process = process
    var status = process.status

    repeat {
        status = process.status
        process = try await checkStatus(process)
    } while status != process.status
}

func checkStatus(
    _ process: ProcessModel
) async throws -> ProcessModel {
    switch process.status {
        case .filesCreated: 
            try await _uploadFiles(process)
        case .filesUploaded: 
            try await _createResponses(process)
        case .responsesCreated, .responsesReasoning: 
            try await _checkResponses(process)
        case .responsesCompleted: 
            try await _deleteFiles(process)
        case .filesDeleted: 
            try await _deleteResponses(process)
        case .responsesDeleted: 
            try await _finishResponses(process)
        case .responsesFinished: 
            try await _deleteProcess(process)
        default: process
    }
}

Claves de la implementación:

Centralización de estados: un único punto de control define todas las transiciones.
Reevaluación continua: el bucle repeat-while permite avanzar automáticamente mientras haya cambios de estado.
Aislamiento de operaciones: cada caso del switch delega en funciones especializadas (_uploadFiles, _createResponses, etc.), manteniendo el código limpio y testeable.

Resultado

Este patrón de gestión de procesos multi‑etapa aporta:

Resiliencia: cada transición es atómica y se puede reintentar si ocurre un fallo.
Escalabilidad: agregar nuevos pasos solo requiere añadir un nuevo caso al switch.
Claridad: el flujo completo del proceso se entiende con una sola lectura.

Ejemplo de aplicación: pipelines de procesamiento de datos, flujos de publicación de contenido, o cualquier proceso de larga duración que requiera control preciso de cada etapa sin comprometer la integridad de los datos.

Keep coding, keep running 🏃‍♂️

Concurrent Map

2026-04-17T19:06:06Z

Problema

Cuando procesamos colecciones en Swift, el método map ejecuta las transformaciones de forma secuencial.
En operaciones intensivas o que implican I/O —como peticiones HTTP, lectura de archivos o consultas de base de datos— esto puede ser un cuello de botella.
El objetivo es aprovechar la concurrencia para ejecutar múltiples transformaciones en paralelo, garantizando seguridad con Sendable y manejo de errores.

Solución

Se crea una extensión de Sequence que añade concurrentMap.
Internamente usa withThrowingTaskGroup, lo que permite:

Lanzar una tarea por cada elemento de la secuencia.
Ejecutar todas las transformaciones en paralelo, respetando el modelo de concurrencia estructurada de Swift.
Propagar automáticamente el primer error que se produzca, cancelando las tareas restantes.

El uso de @Sendable asegura que tanto los elementos como el resultado sean seguros en entornos concurrentes.
De esta manera, cualquier operación asíncrona puede beneficiarse de la ejecución en paralelo sin sacrificar la claridad del código.

extension Sequence where Element: Sendable {
    func concurrentMap<T: Sendable>(
        _ transform: @escaping @Sendable (Element) async throws -> T
    ) async throws -> [T] {
        try await withThrowingTaskGroup(of: T.self) { group in
            for element in self {
                group.addTask {
                    try await transform(element)
                }
            }
            return try await group.reduce(into: []) { 
                $0.append($1) 
            }
        }
    }
}

Resultado

Con concurrentMap se consigue una ganancia de rendimiento significativa en operaciones asíncronas que pueden ejecutarse en paralelo.
El patrón respeta las reglas de concurrencia estructurada de Swift, evita data races y mantiene el mismo estilo declarativo que map, por lo que su adopción en proyectos existentes es sencilla.

Ejemplo de uso:

let urls: [URL] = [...]
let contents = try await urls.concurrentMap {
    try await fetchContent(from: $0)
}

Este enfoque es ideal para peticiones HTTP en lotes, procesamiento de imágenes, lectura masiva de datos o cualquier escenario que requiera máximo paralelismo seguro.

Si necesitas orden garantizado o limitar el consumo de recursos a una tarea a la vez, lo cubrí en Async Map. Y si quieres combinar ambas estrategias — procesamiento concurrente dentro de chunks controlados — lo construí en Async Concurrent Map.

Keep coding, keep running 🏃‍♂️

Async Map

2026-04-17T19:06:06Z

Problema

Cuando procesamos colecciones con transformaciones asíncronas, el método map no sirve porque sus closures no pueden ser async.
Una solución ingenua sería usar un bucle for con await, pero se pierde legibilidad y un manejo de errores homogéneo.
El objetivo es disponer de un map secuencial que acepte funciones async throws, preserve el orden de los elementos y simplifique el flujo de trabajo.

Solución

Se crea una extensión de Sequence que añade asyncMap.
Su ejecución es secuencial dentro de la misma tarea, lo que permite:

Mantener el orden determinista de los resultados.
Limitar el consumo de recursos ejecutando solo una operación a la vez.
Propagar de manera uniforme el primer error que se produzca, deteniendo el proceso.

extension Sequence {
    @inlinable
    func asyncMap<T>(
        _ transform: @escaping @Sendable (Element) async throws -> T
    ) async throws -> [T] {
        var results: [T] = []
        results.reserveCapacity(underestimatedCount)
        for element in self {
            let value = try await transform(element)
            results.append(value)
        }
        return results
    }
}

Resultado

Con asyncMap se obtiene un flujo claro y seguro para transformaciones asíncronas sin paralelismo.
Es especialmente útil cuando:

Necesitamos orden garantizado.
Debemos limitar el consumo de recursos (una tarea en vuelo).
Existe dependencia entre las operaciones.

Si necesitas ejecución en paralelo en lugar de secuencial, exploré ese enfoque en Concurrent Map. Y si tus llamadas secuenciales alcanzan límites de tasa, añadí un mecanismo de timeout en Async Map Timeout.

Ejemplo de uso:

let urls: [URL] = [...]
let contents = try await urls.asyncMap {
    try await fetchContent(from: $0)
}

Keep coding, keep running 🏃‍♂️

Guard and LogError

2026-04-17T19:06:06Z

Problema

En múltiples secciones de mi código necesito ejecutar tres operaciones cada vez que manejo un Optional:

Desempaquetar el contenido del Optional
Registrar un error en el sistema de logs si el valor es nil
Lanzar una excepción cuando el valor no existe

Este patrón se repite frecuentemente, generando código duplicado y reduciendo la mantenibilidad.

Solución

La estrategia consiste en encapsular las tres operaciones en funciones reutilizables que trabajen de forma coordinada.

Función auxiliar: logError

func logError(
    _ message: String, 
    status: HTTPResponseStatus
) throws -> Never {
    self.logMessage(message, level: .error)
    throw Abort(status, reason: message)
}

Esta función ejecuta el registro del error en el sistema de logs y posteriormente termina la ejecución lanzando una excepción Abort. El tipo de retorno Never es fundamental, ya que indica al compilador que esta función nunca retorna normalmente, garantizando que la ejecución se interrumpa completamente.

Función principal: guardAndLogError

func guardAndLogError<T>(
    _ optional: T?,
    message: String,
    status: HTTPResponseStatus = .noContent
) throws -> T {
    guard let optional else {
        try logError(message, status: status)
    }
    return optional
}

Esta función genérica implementa el patrón completo:

Utiliza guard let para desempaquetar el Optional de forma segura
Si el valor es nil, invoca logError() para registrar el fallo y terminar la ejecución
Si contiene un valor, lo retorna exitosamente

La genericidad T permite usar esta función con cualquier tipo de dato opcional.

Resultado

Con esta implementación, una sola línea de código ejecuta las tres operaciones requeridas: desempaquetado seguro, logging de errores y manejo de excepciones.

let fileName = try guardAndLogError(
    fileName, 
    message: "Valor fileName no encontrado"
)

Beneficios

✅ Reducción de código duplicado

✅ Manejo consistente de errores

✅ Logs centralizados y estructurados

✅ Reutilización mediante genericidad

Extensibilidad

Este patrón puede extenderse para casos de uso más específicos:

// Para validaciones booleanas
func guardAndLogError(
    _ condition: Bool, 
    message: String
) throws { ... }

// Para arrays
func guardAndLogError<T>(
    _ optionals: T?..., 
    message: String
) throws -> [T] { ... }

// Para tuplas
func guardAndLogError<T, U>(
    _ first: T?, 
    _ second: U?
    , message: String
) throws -> (T, U) { ... }

Keep coding, keep running 🏃‍♂️

Esquemas y Espacios

2026-04-17T19:06:06Z

Esquema y Espacio de Nombres

Al definir un modelo de datos en Vapor, es posible especificar el schema, que corresponde al nombre de la tabla en la base de datos. Sin embargo, para mantener una arquitectura organizada, es recomendable agrupar las tablas en diferentes espacios de nombres según criterios funcionales, en lugar de concentrarlas todas en el esquema predeterminado. Esta práctica facilita la separación lógica por dominios o módulos de la aplicación.

Implementación

Para asignar una tabla a un espacio de nombres específico, se debe sobrescribir la propiedad estática space en el modelo. Esta propiedad permite definir el namespace donde residirá la tabla, proporcionando una organización más granular de la estructura de base de datos.

public final class LocationCityModel: Model {
    public static let schema = "cities"
    public static let space: String? = "location"

    @ID() public var id: UUID?
    @Field(.name) public var name: String

    public init() { }
}

Consideración

Es fundamental declarar la propiedad space como tipo String? (opcional). Si se declara como String (no opcional), no se sobrescribirá la propiedad heredada del protocolo Model, sino que se creará una nueva propiedad con el mismo nombre. Esto ocasionará que el framework ignore la configuración del espacio de nombres, manteniendo las tablas en el esquema predeterminado sin indicación de error aparente.

Si te preguntas cómo crear estos espacios de nombres automáticamente en la base de datos, explico cómo convertirlo en una migración en Migrate Spaces.

Keep coding, keep running 🏃‍♂️

Índices Parciales

2026-04-17T19:06:06Z

Índices Parciales

Un índice parcial es un índice que se crea únicamente sobre un subconjunto de filas de una tabla, definido mediante una condición WHERE específica. En lugar de indexar todas las filas, el índice solo incluye aquellas que cumplen ciertos criterios, lo que puede mejorar el rendimiento y reducir el espacio utilizado.

En mi caso particular, necesitaba indexar campos en función de si sus valores eran NULL o NOT NULL. Por ejemplo, los siguientes índices parciales en SQL:

CREATE INDEX index_field_null 
ON table(field) 
WHERE field IS NULL;

CREATE INDEX index_field_not_null 
ON table(field) 
WHERE field IS NOT NULL;

También es posible crear índices parciales que involucren múltiples columnas:

CREATE INDEX index_field1_null_field2_null 
ON table(field1, field2) 
WHERE field1 IS NULL AND field2 IS NULL;

CREATE INDEX index_field1_not_null_field2_not_null 
ON table(field1, field2) 
WHERE field1 IS NOT NULL AND field2 IS NOT NULL;

No todas las bases de datos admiten índices parciales, en mi caso particular estoy usando PostgreSQL

Problema

Por defecto, Vapor no ofrece soporte directo para la creación de índices parciales, ya que la generación estándar de índices no contempla la inclusión de una cláusula WHERE en la definición del índice.

El siguiente fragmento de código crea un índice normal, ya sea sobre uno o varios campos, pero no permite especificar una condición para un índice parcial:

try await db.sqlDatabase
    .create($0.key)
    .on(table)
    .colums($0.colums)
    .run()

Este código funciona para crear índices simples, pero carece de la capacidad para agregar un predicado WHERE.

Este fragmento ha sido adaptado por mí; el método .create del constructor original expone más opciones de configuración, pero en este ejemplo muestro una implementación personalizada y simplificada que uso actualmente.

Alternativa

La forma más directa de crear índices parciales es ejecutar sentencias SQL en crudo raw SQL, tal como se mostró en los ejemplos iniciales. Esto implica construir un método para ejecutar en crudo las sentencias CREATE INDEX con la cláusula WHERE correspondiente.

Aunque efectivo, este enfoque pierde la ventaja de la abstracción y seguridad que ofrece Vapor al construir migraciones y esquemas de base de datos mediante código Swift.

Solución

El builder SQLCreateIndexBuilder admite un predicado opcional predicate. Si este no es nil, agrega una cláusula WHERE al índice.

Por ello, extendí este builder para incluir un método where que acepta una lista de columnas y un tipo de índice parcial (por ejemplo, null o not null). Este método construye la expresión lógica adecuada para el predicado y la asigna al índice.

extension SQLCreateIndexBuilder {
    @discardableResult
    func `where`(
        _ columns: [FieldKey],
        _ partialIndex: SQLPartialIndexEnum?
    ) -> Self {
        guard let partialIndex else {
            return self
        }
        let op: SQLBinaryOperator = partialIndex == .null ? .is : .isNot

        let conditions = columns.map {
            self.where($0, op)
        }

        let combined: SQLBinaryExpression = conditions.dropFirst()
            .reduce(conditions[0]) { .init($0, .and, $1) }

        return self.where(combined)
    }

    private func `where`(
        _ column: FieldKey,
        _ binary: SQLBinaryOperator
    ) -> SQLBinaryExpression {
        .init(
            left: SQLIdentifier(column.description),
            op: binary,
            right: SQLLiteral.null
        )
    }

    private func `where`(_ expression: SQLExpression) -> Self {
        self.createIndex.predicate = expression
        return self
    }
}

Este código permite invocar el método where para uno o varios campos, especificando si se desea un índice parcial para valores NULL o NOT NULL. Si no se proporciona un valor para partialIndex, se devuelve el índice sin predicado, comportándose como un índice normal.

La lógica consiste en crear una lista de expresiones binarias SQLBinaryExpression para cada columna, combinándolas con el operador lógico AND y asignando el resultado como predicado del índice.

Resultado

Con esta extensión, ahora puedo crear índices parciales de forma sencilla en Vapor, agregando únicamente una línea al código original:

try await db.sqlDatabase
    .create($0.key)
    .on(table)
    .colums($0.colums)
    .where($0.colums, $0.partial)
    .run()

Donde $0.partial es un valor opcional que indica el tipo de índice parcial deseado null o not null.

Notas finales

Este enfoque está diseñado específicamente para índices parciales basados en la presencia o ausencia de valores NULL en columnas. Sin embargo, la implementación puede adaptarse para soportar otras condiciones y casos de uso más complejos, simplemente modificando la construcción del predicado.

La solución ofrece una forma limpia y reutilizable de crear índices parciales dentro del ecosistema Vapor, manteniendo la coherencia y seguridad del código Swift.

Si además quieres organizar tus tablas en espacios de nombres usando la propiedad space de Fluent, lo cubrí en Esquemas y Espacios.

Keep coding, keep running 🏃‍♂️

Mi primera condición de carrera

2026-04-17T19:06:06Z

De refactor a condición de carrera en Swift

Durante un proceso de refactorización para convertir una funcionalidad previamente secuencial en una concurrente, me encontré con un problema clásico: garantizar la unicidad de los registros cuando múltiples tareas intentan crear eventos al mismo tiempo. Aunque el objetivo era mejorar el rendimiento procesando miles de eventos en paralelo usando Swift, la transición expuso un desafío típico de concurrencia: evitar duplicados y mantener la integridad de los datos bajo acceso simultáneo.

Actor con array

private actor EventsActor {
    private var events: [SportEventModel] = []

    func getOrCreate(
        name: String, 
        cityId: UUID, 
        build: () async throws -> EventModel
    ) async throws -> EventModel {
        if let event = events.first(
            where: { 
                $0.normalizedName == name 
                && $0.$city.id == cityId 
            }
        ) { return event }

        let event = try await build()
        events.append(event)
        return event
    }
}

Ventajas:

Simplicidad.
Seguridad frente a condiciones de carrera.

Desventaja:

Búsqueda ineficiente en grandes volúmenes O(n).

Actor con diccionario

private actor EventsActor {
    private var events: [String: EventModel] = [:]

    func getOrCreate(
        name: String, 
        cityId: UUID, 
        build: () async throws -> EventModel
    ) async throws -> EventModel {
        let key = "\(name)\(cityId.uuidString)"
        if let event = events[key] { 
            return event 
        }
        let event = try await build()
        events[key] = event
        return event
    }
}

Ventajas:

Búsqueda e inserción rápida O(1).
Ideal para grandes volúmenes de datos.

Bug:

Condición de carrera lógica

Condición de carrera lógica

Cuando múltiples tareas concurrentes intentan crear el mismo evento, todas pueden comprobar que no existe y proceder a crearlo al mismo tiempo.
Solo una de las instancias resultantes se almacena, mientras que el resto se convierten en “huérfanas”, lo que provoca inconsistencias y referencias rotas en otras estructuras de datos.

Por ejemplo: dos tareas concurrentes comprueban si un evento existe. Ambas ven que no, ambas lo crean, pero solo una sobrevive en el diccionario; la otra referencia ahora está perdida.

Solución

Para evitar esto, es necesario serializar no solo el acceso sino también la creación por clave:
Si ya hay una creación en curso para esa clave, las tareas concurrentes deben esperar el resultado de la primera, asegurando que todas compartan exactamente el mismo recurso.

private actor EventsActor {
    private var events: [String: EventModel] = [:]
    private var builds: [String: Task<EventModel, Error>] = [:]
    
    func getOrCreate(
        name: String, 
        cityId: UUID, 
        build: @Sendable @escaping () async throws -> EventModel
    ) async throws -> EventModel {
        let key = "\(name)\(cityId.uuidString)"
        if let event = events[key] { 
            return event 
        }

        if let building = builds[key] { 
            return try await building.value 
        }
        
        let buildTask = Task { 
            try await build() 
        }
        builds[key] = buildTask
        
        let event = try await buildTask.value
        events[key] = event
        builds.removeValue(forKey: key)
        return event
    }
}

Lecciones aprendidas

Un actor por sí solo no previene condiciones de carrera lógicas del tipo “check-then-act”.
En escenarios concurrentes, serializar la construcción del recurso por clave es fundamental para mantener la integridad de los datos.
Es esencial probar bajo carga y escenarios concurrentes, no solo en modo secuencial.

Keep coding, keep running 🏃‍♂️

Timestamps en Migraciones

2026-04-17T19:06:06Z

Timestamps

Si eres como yo, cuando diseñas un modelo de base de datos quieres que todas las tablas incluyan siempre tres campos clave:

createdAt: indica cuándo se creó el registro.
updatedAt: refleja la última vez que se actualizó.
deletedAt: marca cuándo se eliminó de forma lógica (sin borrar físicamente el registro).

Problema

Como se puede observar, en cada migración tenemos que escribir manualmente los tres campos de timestamp. Esto no solo es repetitivo, sino que también es propenso a errores si olvidamos algún campo o escribimos mal el tipo de dato.

try await db.schema(model)
    .id()
    .field(.name, .string, .required)
    .field(.createdAt, .datetime, .required)
    .field(.updatedAt, .datetime, .required)
    .field(.deletedAt, .datetime)
    .create()

Solución

La solución es crear una extensión de SchemaBuilder que agregue un método timestamps(). Esta extensión encapsula la lógica repetitiva en un solo lugar, haciendo el código más limpio y mantenible.

extension SchemaBuilder {
    func timestamps() -> Self {
        self.field(.createdAt, .datetime, .required)
            .field(.updatedAt, .datetime, .required)
            .field(.deletedAt, .datetime)
    }
}

Resultado

Ahora nuestras migraciones son mucho más limpias y legibles. Llamando a .timestamps() agregamos los tres campos necesarios. Esto reduce la posibilidad de errores y hace que el código sea más fácil de mantener.

try await db.schema(model)
    .id()
    .field(.name, .string, .required)
    .timestamps()
    .create()

Keep coding, keep running 🏃‍♂️

☁️ Servidor en la nube

2026-04-17T19:06:06Z

☁️ Cloud Server

Cuando trabajas con backend, a no ser que estés trabajando en una red local y no vaya a salir nada de lo que hagas hacia afuera, vas a necesitar sí o sí un servidor en la nube y cuanto antes mejor 🚀.

Trabajar en local está muy bien, pero tener un servidor en la nube es un paso hacia adelante, y es mejor empezar cuanto antes para tener un servidor de desarrollo en la nube.

🔧 Arquitecturas de CPU

Conforme la tecnología avanza, cada vez hay más opciones tanto en proveedores como en tecnología de procesadores 💻:

AMD 🔴:
- ✅ Excelente relación precio/rendimiento
- ✅ Arquitectura x64 madura y estable
- ✅ Amplia compatibilidad con software
- ✅ Ideal para aplicaciones de alto rendimiento
Intel 🔵:
- ✅ Líder histórico en el mercado de servidores
- ✅ Excelente soporte empresarial
- ✅ Optimizaciones específicas para aplicaciones legacy
- ✅ Rendimiento consistente y predecible
ARM 🍃:
- ✅ El último en llegar pero con gran potencial
- ✅ Eficiencia energética superior
- ✅ Mejor precio por núcleo
- ✅ Ideal para microservicios y contenedores
- ✅ Menor consumo = menor costo operativo
- ⚠️ Algunas limitaciones de compatibilidad con software legacy

💰 Free Tier - Oracle Cloud

Yo he optado por Oracle Cloud y el free tier que tiene, el cual te ofrece un servidor ARM, ya que para mí es la opción que mejor se adapta a mis necesidades 🎯.

🖥️ VM.Standard.A1.Flex (Ampere ARM)

⏱️ Hasta 3.000 OCPU-horas al mes

🧠 Hasta 18.000 GB-horas de memoria al mes

🚀 1 servidor con 4 OCPUs + 24 GB RAM funcionando 24/7

🔄 O varias instancias más pequeñas (ejemplo: 4 × 1 OCPU + 6 GB RAM)

💾 Hasta 200 GB combinados entre volúmenes de arranque y bloques

♾️ Gratuito indefinidamente, siempre dentro de los límites del plan

⚠️ Oracle puede reclamar instancias inactivas (sin uso significativo en 7 días)

🌍 Puede haber restricciones regionales por falta de capacidad

💸 100% gratis dentro del plan Always Free

Keep coding, keep running 🏃‍♂️

Claude Code

2026-04-17T19:06:06Z

🤔 ¿Qué es Claude Code para mí?

Para alejarme de lo que habla todo el mundo 😂, voy a contaros sobre inteligencia artificial desde mi experiencia personal.

He integrado Claude Code en mis proyectos, pero para mí es mucho más que una herramienta: es mi asistente digital 👥, un miembro más de mi equipo de desarrollo, una extensión de mis capacidades o, como bien representa la imagen, mi sombra tecnológica 🌑.

No me sustituye ni creo que sustituya a ningún desarrollador en estos momentos. Claude Code es tan bueno como lo seas tú o como sepas utilizarlo 💡.

📋 Mis Reglas de Oro

Tengo cuatro reglas fundamentales que aplico religiosamente con Claude Code:

🔍 Control Total de Cambios

Yo reviso todo antes de implementar cualquier cambio
No tiene permisos para modificar archivos sin mi aprobación
Flujo: Me proporciona el plan → Reviso los cambios → Los entiendo → Los apruebo (o no)
Esta regla es súper importante para mí. Darle permisos ciegos no va con mi filosofía 🚫

📝 Claude.md como Biblia del Proyecto

Trabajo intensamente el archivo CLAUDE.md
Defino qué es el proyecto y establezco guidelines claras
Es mi manera de “entrenar” a Claude sobre mi estilo y preferencias
Resultado: Respuestas más alineadas con mi visión 🎯

⚙️ Configuración Inteligente

Configuro sus settings con rutas de documentación oficial
Cuando hago preguntas sobre tecnologías específicas, utiliza fuentes oficiales
Esto garantiza respuestas más precisas y actualizadas 📚

🚀 Trabajo Colaborativo, No Dependencia

Nunca parto de un IDE vacío
Siempre trabajo sobre una base de código que ya he desarrollado
Mi flujo: Empiezo a crear → Me atascos → Pregunto a Claude
Pregunta recurrente: ”¿Hay una manera más limpia y eficiente de hacer este código?” 🤝

💡 Imaginación sin límite

Y aquí viene lo interesante: Claude Code no es solo para programar 🎨. Puedes usarlo para lo que se te ocurra. Solo hazte esta pregunta:

¿Cómo puedo hacer que esta idea funcione con Claude Code?

Una de las formas más geniales en las que lo uso fuera de programación es con mi consumo de contenido técnico:

Consumo muchísimo contenido de programación:

🎓 Cursos online

💊 Píldoras de conocimiento

🎤 Conferencias y talks

🗣️ Debates técnicos

🎧 Podcasts especializados

🛠️ Talleres prácticos

El problema típico: Estás programando y recuerdas haber visto algo útil en un vídeo, pero… ¿cuál era? ¿En qué minuto? 😅

Mi solución con Claude:

Le pregunto: ”¿Dónde se habla de esto?”
Me devuelve:
- 📹 El vídeo o vídeos específicos
- ⏰ El timestamp exacto donde se menciona
- 📄 Un pequeño resumen del contenido

Resultado: ¡Maravilloso! ✨ Acceso instantáneo a todo mi conocimiento consumido.

🎯 Reflexión Final

Claude Code se ha convertido en mi sombra tecnológica. No es magia, no hace el trabajo por ti, pero si sabes usarlo correctamente, puede potenciar enormemente tu productividad y creatividad.

La clave está en establecer límites claros, mantener el control y usarlo como lo que realmente es: un asistente excepcional que amplifica tus capacidades, no que las reemplaza 🚀.

Keep coding, keep running 🏃‍♂️

Amo Vapor

2026-04-17T19:06:06Z

❤️ Swift del lado servidor

Cuando cursé el Swift Full Stack Bootcamp en Apple Coding Academy, uno de los módulos que se nos impartió fue Swift del lado servidor a través del framework Vapor.

Nada más comenzar con la parte teórica, mi corazón empezó a palpitar con fuerza y simplemente, a mitad de aquella primera clase, ya estaba completamente enamorado.

Así que, si me preguntan “¿Cuál fue tu módulo favorito del Bootcamp?”, sin lugar a dudas diría que este.

👍🏻 ¿Por qué me gusta?

Siempre he pensado que la parte de backend es el cerebro de cualquier aplicación o web.
Es ahí donde está toda la chicha: donde se procesa la información (normalmente desde una base de datos) y se prepara para que el usuario final la reciba de la forma más sencilla y transparente posible.

Que quede claro: no menosprecio el frontend.
De hecho, me parece admirable la gente que crea diseños increíbles: auténticos héroes para mí, porque eso es algo que personalmente me resulta imposible… aunque con SwiftUI me entiendo bastante bien.

🧸 Jugando con Vapor

En próximas entradas del blog iré profundizando mucho más, pero ya puedo contar que me he dedicado a jugar mucho con Vapor:

📦 Paquete individual para configurar distintos servicios

🌐 Servidor gRPC

🗂 Modelo de datos con vistas (incluidas materialized views), índices, permisos por aplicación y esquemas

🧮 Enumerados con migraciones automáticas

🔑 PassKey

📊 Bulk inserts para poblar grandes volúmenes de datos

⏱ Tareas programadas con asincronía

… y mucho más 🚀

A lo largo de distintas entradas del blog contaré un poco de todo.
Eso sí: aunque Vapor y Swift del lado servidor me guste mucho, no todo será sobre backend… habrá espacio para muchos otros temas que me entusiasman.

Keep coding, keep running 🏃‍♂️

¡Gracias, La Liga!

2026-04-17T19:06:06Z

Mi web bloqueada en partidos de La Liga

Si estás intentando visitar mi web durante un partido de La Liga y no carga, no te lo estás imaginando: en realidad, está siendo bloqueada.

En España, La Liga aplica medidas antipiratería muy agresivas, y una de ellas consiste en bloquear el acceso a sitios web alojados en la red de Cloudflare durante los partidos en directo. Desafortunadamente, esto significa que si tu web está alojada en Cloudflare —como la mía— puedes verte afectado aunque no estés emitiendo ni distribuyendo ningún contenido ilegal.

Cloudflare protege y acelera millones de sitios web en todo el mundo, pero debido a la política de La Liga, rangos enteros de IP o nodos CDN pueden ser incluidos en listas negras, lo cual afecta a innumerables webs legítimas.

¿Por qué sucede esto?

La Liga utiliza sistemas automatizados y bloqueos a nivel DNS para restringir el acceso a lo que considera fuentes potenciales de piratería.
Cloudflare es utilizado por todo tipo de sitios, incluidos aquellos que sí albergan retransmisiones ilegales —por lo que sus IPs se marcan.
Como resultado, muchas webs inocentes se bloquean durante los partidos, simplemente por compartir infraestructura.

¿Qué puedes hacer?

Si estás en España y no puedes acceder a mi portfolio durante un partido, vuelve a intentarlo más tarde.
Si te pica la curiosidad, existen herramientas online para comprobar si un dominio está siendo bloqueado.
O puedes usar una VPN para evitar temporalmente la restricción (solo para visitar mi portfolio, claro 😅).

Es un ejemplo frustrante de cómo una aplicación excesiva de medidas digitales puede dañar la web abierta —incluso portfolios pequeños como el mío.

”¡Gracias, La Liga!”

Actualización: Finalmente encontré una solución sencilla para este problema. Si quieres saber cómo lo resolví en 5 minutos, lee Only DNS.

Keep coding, keep running 🏃‍♂️

Mi primer artículo

2026-04-17T19:06:06Z

🚀 ¡Gran actualización en mi sitio web!

Hoy lanzo una importante actualización de mi sitio web personal, que ahora está construido con Astro y Tailwind.

He añadido la posibilidad de escribir artículos — ¡y este es el primero!
A partir de ahora, compartiré mis experiencias, descubrimientos y desafíos diarios como desarrollador Swift.
También puede que comparta algo de mi vida personal.

⚡️ Sin calendario fijo:
Publicaré siempre que tenga algo relevante que compartir — ya sean problemas, soluciones, curiosidades o nuevas tecnologías que esté explorando.

Con esta nueva versión, me puedo centrar únicamente en escribir artículos en Markdown; todo lo demás está completamente automatizado.

Si te interesa Swift, iOS, visionOS, Vapor, desarrollo full-stack con Swift y Web, o simplemente quieres acompañarme en este camino — ¡bienvenido!

Keep coding, keep running 🏃‍♂️