DEV Community: Juan Carlos Isaza

De la idea al MVP: lanza tu producto en 2 semanas con Python

Juan Carlos Isaza — Sun, 23 Aug 2026 18:20:06 +0000

Tienes una idea. La tentación es construirla "completa" antes de enseñarla a nadie. Es el error más caro que se puede cometer: inviertes meses en funciones que quizá nadie quiere. Un MVP (Producto Mínimo Viable) le da la vuelta a eso.

Qué es (y qué no es) un MVP

Un MVP es la versión más pequeña de tu producto que permite validar una hipótesis con usuarios reales. No es un prototipo de mentira ni el producto final recortado: es lo justo para aprender si la gente lo quiere.

Lo que un MVP NO debe tener:

Panel de administración elaborado.
Múltiples integraciones "por si acaso".
Optimizaciones para una escala que aún no tienes.
Todas las funciones de la competencia.

Lo que sí: el flujo central que resuelve el problema, y una forma de medir si funciona.

Por qué Python acelera esto

Un stack Python moderno permite construir un MVP funcional en 1–2 semanas en lugar de meses:

FastAPI para la lógica y las APIs: rápido y con validación automática.
NiceGUI para la interfaz sin escribir JavaScript (ver este artículo).
SQLite o PostgreSQL para los datos: empieza simple, migra cuando haga falta.
Despliegue en un VPS modesto detrás de nginx.

Un solo desarrollador puede cubrir backend, frontend y despliegue, sin coordinar tres especialistas.

El proceso

Define la hipótesis: "los usuarios pagarán por X para resolver Y".
Recorta sin piedad: ¿cuál es el flujo mínimo que prueba eso?
Construye rápido con herramientas que no te frenen.
Lanza a usuarios reales y mide.
Itera con lo aprendido.

La meta no es el código perfecto: es aprender barato. Un MVP que te dice "esto no funciona" en dos semanas te ahorra meses.

¿Tienes una idea que validar?

En Xiliux desarrollo MVPs en Python de principio a fin, con precio y plazos cerrados. Cuéntame tu idea y te digo cómo llevarla a un producto probable en semanas: cotiza tu MVP.

RAG explicado: cómo darle a un LLM tu propia información

Juan Carlos Isaza — Sat, 22 Aug 2026 18:25:06 +0000

Un modelo de lenguaje sabe mucho del mundo, pero no sabe nada de tu empresa: tus manuales, tus políticas, tus productos. Y si le preguntas por algo que no sabe, puede inventar una respuesta que suena convincente. RAG (Retrieval-Augmented Generation) resuelve las dos cosas.

La idea

En lugar de esperar que el modelo "se sepa" tu información, se la das en el momento de la pregunta:

Indexas tus documentos: los divides en fragmentos y los conviertes en embeddings (vectores numéricos que capturan el significado).
Cuando llega una pregunta, buscas los fragmentos más parecidos a esa pregunta.
Le pasas al LLM la pregunta junto con esos fragmentos y le pides que responda usándolos.

El modelo ya no adivina: responde a partir de un contexto real que tú controlas. Y puedes pedirle que cite de dónde salió cada dato.

El patrón en Python

# 1. Indexado (una vez): fragmentos -> embeddings -> base vectorial
#    (con librerías como sentence-transformers + FAISS, o un servicio gestionado)

# 2. En cada pregunta: recuperar los fragmentos relevantes
fragmentos = base_vectorial.buscar(pregunta, k=4)
contexto = "\n\n".join(fragmentos)

# 3. Generar la respuesta con el contexto
from anthropic import Anthropic
client = Anthropic()

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system="Responde SOLO con la información del contexto. Si no está, dilo.",
    messages=[{
        "role": "user",
        "content": f"Contexto:\n{contexto}\n\nPregunta: {pregunta}",
    }],
)
print(resp.content[0].text)

Fíjate en la instrucción del system: pedirle que responda solo con el contexto y que admita cuando no sabe es lo que reduce drásticamente las alucinaciones.

¿Para qué sirve?

Asistentes de soporte que responden con tu documentación real.
Búsqueda interna en lenguaje natural sobre tus manuales o wikis.
Onboarding: un chatbot que conoce tus procesos.

Detalles que marcan la diferencia

Cómo divides los documentos (chunking) afecta mucho a la calidad.
Buenos embeddings y una base vectorial adecuada importan más que el modelo.
Citar las fuentes genera confianza y permite verificar.

RAG es hoy una de las formas más rentables de aplicar IA en un negocio: no reentrenas nada, y el asistente mejora con solo actualizar tus documentos.

¿Quieres un asistente con tus datos?

En Xiliux construyo sistemas RAG en Python de principio a fin. Cuéntame qué información quieres poner a trabajar: contacto.

Cifrado híbrido: por qué combinar criptografía clásica y post-cuántica

Juan Carlos Isaza — Fri, 21 Aug 2026 18:25:21 +0000

Cuando aparece un algoritmo criptográfico nuevo, surge una tensión: los algoritmos clásicos (como X25519 o Ed25519) llevan años resistiendo ataques, pero son vulnerables a un futuro ordenador cuántico; los post-cuánticos (como ML-KEM o ML-DSA) resisten a lo cuántico, pero son más recientes y menos probados. El cifrado híbrido resuelve la tensión: usa los dos a la vez.

La idea en una frase

Combina un algoritmo clásico y uno post-cuántico de forma que el sistema solo se rompe si ambos fallan simultáneamente.

Un atacante clásico tendría que romper el algoritmo post-cuántico; un atacante cuántico tendría que romper el clásico y además el post-cuántico. Ganas seguridad frente al futuro sin apostar todo a un algoritmo joven.

Dos lugares donde aplicarlo

Intercambio de claves (cifrar para un destinatario). Se combinan:

X25519 — intercambio de claves clásico, rápido y muy probado.
ML-KEM-1024 — el mecanismo de encapsulado post-cuántico del NIST, en su nivel más alto.

Las dos claves resultantes se mezclan con una función de derivación (HKDF) ligada al contexto, de modo que ninguna por separado basta.

Firmas digitales (autenticidad). Se combinan:

Ed25519 — firma clásica.
ML-DSA-87 — firma post-cuántica del NIST.

El mensaje se acepta solo si ambas firmas verifican (un combinador tipo AND).

Un principio que nunca se rompe

Hay una regla de oro en criptografía, el principio de Kerckhoffs: un sistema debe ser seguro aunque el atacante conozca todo su diseño; la seguridad vive en la clave, no en ocultar el formato. Un buen sistema híbrido usa primitivas públicas y auditadas (XChaCha20-Poly1305 para cifrar, Argon2id para derivar claves de contraseñas, HKDF para separar dominios) y nunca inventa criptografía propia.

Cómo lo aplica Quipu

Quipu es una librería libre que implementa exactamente este enfoque para datos en reposo: cifrado híbrido X25519 + ML-KEM-1024, firma híbrida Ed25519 + ML-DSA-87, y solo primitivas verificadas por debajo. Está en nivel de seguridad NIST 5 (CNSA 2.0) y es de código abierto, así que cualquiera puede revisar cómo funciona.

Nota honesta: Quipu compone primitivas estándar, pero la composición aún no ha pasado una auditoría criptográfica independiente. Para secretos reales de alto valor, esa auditoría externa es el sello que conviene esperar.

¿Necesitas proteger datos en reposo con visión de futuro? Hablemos.

¿Qué es la criptografía post-cuántica y por qué deberías migrar ya?

Juan Carlos Isaza — Thu, 20 Aug 2026 18:15:58 +0000

La criptografía que protege hoy tus datos —claves, HTTPS, firmas— se apoya en problemas matemáticos que los ordenadores actuales no pueden resolver en un tiempo razonable. Un ordenador cuántico suficientemente grande sí podría resolver algunos de ellos. Eso es la criptografía post-cuántica: algoritmos diseñados para resistir tanto a ordenadores clásicos como cuánticos.

La amenaza no es solo del futuro

Podrías pensar: "no existe todavía un ordenador cuántico que rompa mi cifrado, así que puedo esperar". El problema es un ataque llamado "harvest now, decrypt later" (cosecha ahora, descifra después):

Un adversario captura hoy tu tráfico cifrado y lo guarda. Cuando dentro de unos años exista la capacidad cuántica, lo descifra.

Si tus datos deben seguir siendo secretos dentro de 10 años (historiales médicos, secretos industriales, datos personales), la amenaza es presente, no futura. Los datos que cifras hoy con criptografía clásica podrían leerse mañana.

Los nuevos estándares del NIST

El NIST (el organismo estadounidense de estándares) finalizó en 2024 los primeros algoritmos post-cuánticos, tras años de análisis público:

ML-KEM (antes CRYSTALS-Kyber): para intercambio de claves — cómo dos partes acuerdan una clave secreta de forma segura.
ML-DSA (antes CRYSTALS-Dilithium): para firmas digitales — cómo verificar que un mensaje es auténtico y no fue alterado.

Estos ya no son experimentos académicos: son estándares que gobiernos y grandes empresas están empezando a exigir.

Cifrado híbrido: el enfoque prudente

Los algoritmos post-cuánticos son nuevos, y "nuevo" en criptografía significa "menos probado". Por eso la mejor práctica actual es híbrida: combinar un algoritmo clásico bien establecido con uno post-cuántico. El resultado solo se rompe si ambos caen a la vez. Ganas protección post-cuántica sin renunciar a décadas de confianza en la criptografía clásica.

¿Por dónde empezar?

Inventaría dónde usas criptografía y qué datos deben durar años.
Prioriza los datos en reposo de larga vida (los más expuestos al "harvest now").
Adopta cifrado híbrido en vez de reemplazos de golpe.
Usa librerías que compongan primitivas verificadas, no criptografía casera.

Este último punto es clave, y es la filosofía detrás de Quipu, una librería libre de cifrado híbrido post-cuántico para datos en reposo. Si te interesa proteger tus datos frente a la amenaza cuántica, hablemos.

Automatiza tareas repetitivas con un bot en Python

Juan Carlos Isaza — Wed, 19 Aug 2026 18:22:46 +0000

Cada tarea manual y repetitiva que haces cada semana es tiempo (y dinero) que un script de Python puede recuperarte. La automatización no es solo para grandes empresas.

Primero: ¿qué vale la pena automatizar?

Busca tareas repetitivas, basadas en reglas y frecuentes. Algunos ejemplos habituales:

Descargar y consolidar informes cada mañana.
Copiar datos entre una web y una hoja de cálculo.
Enviar recordatorios o alertas.
Vigilar precios o cambios en una página.

Una regla práctica: si puedes explicar la tarea como una lista de pasos sin excepciones, probablemente se puede automatizar.

Las herramientas del ecosistema Python

requests / httpx para hablar con APIs y webs.
BeautifulSoup / Playwright para web scraping (Playwright cuando la página carga con JavaScript).
pandas para transformar datos.
APScheduler o cron para ejecutarlo en un horario.
Bots de Telegram o Discord para recibir avisos donde ya estás.

Un ejemplo mínimo

Vigilar el título de una página y avisar si cambia:

import requests
from bs4 import BeautifulSoup

def titulo(url):
    html = requests.get(url, timeout=10).text
    return BeautifulSoup(html, "html.parser").title.string.strip()

anterior = titulo("https://example.com")
# ...ejecutado por cron cada hora...
actual = titulo("https://example.com")
if actual != anterior:
    print("¡Cambió!")  # aquí enviarías un mensaje de Telegram

De script a bot fiable

Un script que corre en tu portátil es un buen comienzo, pero un bot fiable vive en un servidor, registra lo que hace, maneja errores (reintentos, tiempos de espera) y te avisa si algo falla. Ese salto —de experimento a herramienta en la que confías— es donde más aporta un desarrollador.

¿Tienes una tarea que odias hacer a mano?

Probablemente se pueda automatizar. Cuéntame cuál es y te digo cómo abordarla: contacto.

NiceGUI: crea una aplicación web en Python sin escribir JavaScript

Juan Carlos Isaza — Tue, 18 Aug 2026 18:45:05 +0000

Si sabes Python pero el frontend te frena, NiceGUI es una de las mejores noticias de los últimos años: te permite construir aplicaciones web completas —con botones, formularios, gráficos y navegación— usando solo Python.

¿Qué es NiceGUI?

Es un framework construido sobre FastAPI (backend) y Quasar/Vue (frontend). Tú escribes Python; NiceGUI genera la interfaz en el navegador y mantiene sincronizado el estado por ti. No necesitas HTML, CSS ni JavaScript para empezar.

Lo simple que es

Una app con un botón que muestra un mensaje son literalmente cuatro líneas:

from nicegui import ui

ui.button('Saludar', on_click=lambda: ui.notify('¡Hola!'))

ui.run()

La jerarquía de la interfaz se expresa con context managers, que reflejan cómo se anidan los elementos:

with ui.card():
    ui.label('Iniciar sesión').classes('text-xl font-bold')
    usuario = ui.input('Usuario')
    clave = ui.input('Clave', password=True)
    ui.button('Entrar', on_click=lambda: entrar(usuario.value, clave.value))

Añadir estado reactivo, formularios, tablas o rutas (@ui.page('/panel')) es igual de directo.

¿Para qué es ideal?

MVPs y prototipos: validar una idea en días, no semanas.
Dashboards internos y paneles de datos.
Herramientas internas para tu equipo, sin montar un frontend aparte.
Demos de modelos de IA o scripts que necesitan una interfaz.

¿Cuándo NO es la mejor opción?

NiceGUI renderiza en el cliente, así que para sitios donde el SEO del contenido es crítico (un blog, una landing pública que debe posicionar) conviene complementarlo con buenas meta etiquetas y datos estructurados, o valorar renderizado en servidor. Para aplicaciones, dashboards y herramientas internas es una elección excelente y muy productiva.

Rendimiento y despliegue

Una app NiceGUI se despliega como cualquier app de FastAPI/Uvicorn, normalmente detrás de nginx con systemd. Sirve los estáticos desde nginx y usa ui.run(show=False) en producción para no abrir un navegador en el servidor.

¿Quieres una app así?

Este mismo portafolio está hecho con NiceGUI. Si necesitas un MVP, un dashboard o una herramienta interna en Python, escríbeme.

Cómo integrar un LLM (Claude o GPT) en tu aplicación Python

Juan Carlos Isaza — Mon, 17 Aug 2026 18:30:04 +0000

Integrar un modelo de lenguaje (LLM) en una aplicación Python es hoy más sencillo de lo que parece, y abre la puerta a chatbots, asistentes internos, extracción de datos y automatización con lenguaje natural. En esta guía verás el patrón completo, con código real.

1. Elige el proveedor

Los tres más usados son Anthropic (Claude), OpenAI (GPT) y Google (Gemini). Todos exponen una API HTTP con un SDK de Python oficial, y la lógica de tu app apenas cambia entre ellos. En los ejemplos usaré Claude, pero el patrón es idéntico en los demás.

Instala el SDK y guarda tu clave en una variable de entorno, nunca en el código:

pip install anthropic
export ANTHROPIC_API_KEY="tu-clave"

2. La llamada mínima

El patrón es siempre el mismo: envías una lista de mensajes y recibes una respuesta.

from anthropic import Anthropic

client = Anthropic()  # lee ANTHROPIC_API_KEY del entorno

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Resume en una frase: la fotosíntesis..."}
    ],
)
print(resp.content[0].text)

Dos detalles importantes: resp.content es una lista de bloques (comprueba .type antes de leer .text), y max_tokens limita la longitud de la respuesta.

3. Streaming para una buena experiencia

En una interfaz, esperar a que se genere todo el texto se siente lento. El streaming muestra la respuesta token a token, como en ChatGPT:

with client.messages.stream(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Escribe un email de bienvenida."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

Para salidas largas, el streaming además evita que la petición supere el tiempo de espera de la conexión.

4. Salida estructurada (JSON fiable)

Si necesitas que el modelo devuelva datos en un formato exacto (por ejemplo para guardarlos en una base de datos), pide un esquema JSON en vez de parsear texto libre. Esto elimina la clase de bugs más común al integrar IA: respuestas con formato impredecible.

5. Buenas prácticas para producción

Controla el coste: fija un max_tokens razonable y cachea respuestas repetidas. Los SDKs modernos soportan prompt caching, que abarata mucho el contexto reutilizado.
Maneja errores y reintentos: las APIs fallan; los SDKs oficiales ya reintentan errores 429 y 5xx con backoff exponencial. Captura las excepciones tipadas (RateLimitError, etc.) en lugar de comparar cadenas de texto.
Protege tus claves: variables de entorno, rotación periódica y permisos mínimos.
Elige el modelo según la tarea: un modelo grande para razonamiento complejo, uno más pequeño y rápido para clasificación de alto volumen.

¿Necesitas ayuda?

En Xiliux integro LLMs en aplicaciones Python de principio a fin: chatbots, automatización con IA y asistentes internos. Si tienes una idea, hablemos.

i18n sin gettext: traducciones en JSON con claves de punto

Juan Carlos Isaza — Sun, 16 Aug 2026 18:29:59 +0000

Quieres que tu app hable español e inglés. Buscas cómo, y el ecosistema te empuja a gettext o Babel: ficheros .po, un paso de compilación a .mo, herramientas de extracción. Potente, sí. Pero para una app pequeña o mediana es un peaje que no querías pagar — solo necesitabas un t() honesto.

Lo resolví tantas veces que lo empaqueté: dotkey-i18n, Python puro, sin dependencias. Tus traducciones son JSON que cualquiera puede editar:

// locales/es.json
{
  "login": { "welcome": "Hola, {name}", "submit": "Entrar" },
  "menu":  { "reports": "Informes", "settings": "Ajustes" }
}

from dotkey_i18n import Translator

tr = Translator("locales", default_lang="es")
tr.t("login.welcome", name="Juan")     # "Hola, Juan"
tr.t("menu.reports", lang="en")        # "Reports"

Tres detalles que marcan la diferencia

Claves con notación de punto. t("login.submit") navega el JSON anidado. Agrupas las cadenas por pantalla o módulo sin claves planas kilométricas.

Fallback al idioma por defecto. Si una clave falta en el idioma pedido, se busca en el idioma por defecto antes de rendirse. Tus traducciones pueden ir incompletas —la vida real— sin dejar huecos en blanco en la interfaz.

Nunca revienta la interfaz. Una clave que no existe devuelve la propia clave (un marcador visible, no una excepción a mitad de render). Una interpolación con un campo que falta devuelve el texto sin formatear. Un JSON corrupto se trata como vacío. Nada de esto tumba la pantalla.

Agnóstico del framework

El idioma actual entra por un lang_getter inyectable, así el mismo Translator sirve en NiceGUI, Flask, FastAPI o un script suelto:

# NiceGUI: idioma desde la sesión del usuario
tr = Translator("locales", default_lang="es",
                lang_getter=lambda: app.storage.user.get("idioma"))

# Flask
tr = Translator("locales", lang_getter=lambda: session.get("lang"))

La prioridad es clara: lang= explícito → lang_getter() → idioma por defecto.

De dónde viene

Salió del servicio i18n de un sistema de gestión de informes bilingüe. Estaba atado al framework —leía el idioma directamente de la sesión de NiceGUI—; al extraerlo se desacopló con el lang_getter, y se le añadió el fallback al idioma por defecto que el original no tenía. Extraer para publicar suele mejorar el código original: lo obliga a no depender de su casa.

pip install dotkey-i18n

Código y tests (notación de punto, fallback, claves ausentes, JSON corrupto; verificados por mutación): github.com/isazajuancarlos/dotkey-i18n.

Notificar a varios canales sin que un fallo tumbe al resto

Juan Carlos Isaza — Sat, 15 Aug 2026 18:28:19 +0000

Quieres mandar la misma notificación a varios sitios: Slack, Discord, un webhook, un email. La primera versión es un for de tres líneas:

for canal in canales:
    canal(mensaje)

Y funciona en las demos. Hasta que un día Discord devuelve un 500, canal(mensaje) lanza, y el email y el Slack que iban detrás nunca salen. Peor: te enteras por el usuario que no recibió la alerta, no por un log.

Dos cosas fallan en ese for:

No aísla. La primera excepción corta el reparto entero.
No reporta. O cada canal se traga su error en un try/except disperso, o el fallo se pierde.

La forma correcta

Aísla cada canal y recoge el resultado. Lo empaqueté como fanout-broadcast —Python puro, sin dependencias— porque lo reescribía en cada proyecto:

from fanout_broadcast import Broadcaster

bc = Broadcaster()
bc.add("discord",  a_discord)
bc.add("telegram", a_telegram)
bc.add("email",    a_email, enabled=False)   # apagado por ahora

report = bc.broadcast("¡Nueva versión publicada!")

if not report.ok:
    for o in report.failed:
        log.error("%s falló: %s", o.name, o.error)

broadcast llama a todos los canales habilitados, captura la excepción de cada uno por separado, y sigue con el siguiente. Un Discord caído ya no impide que salga el email. Al final tienes un reporte:

report.ok           # ¿ningún canal falló?
report.delivered    # los que entregaron
report.failed       # los que lanzaron (cada uno con su .error)
report.skipped      # los que estaban deshabilitados

Encender y apagar sin ramificar el código

Cada canal tiene un interruptor, en runtime o por variable de entorno:

from fanout_broadcast import env_enabled

bc.add("discord", a_discord, enabled=env_enabled("discord"))  # mira DISCORD_ENABLED

Esto importa más de lo que parece: separa qué canales existen de cuáles están activos hoy, sin comentar código ni meter if por todos lados. Apagas un canal problemático con una variable de entorno, no con un despliegue.

Escalar, pero después de intentarlo todo

A veces sí quieres que un fallo se propague. La diferencia está en cuándo:

report = bc.broadcast(mensaje)
report.raise_for_failures()   # lanza DESPUÉS de haber intentado todos

Al revés que el for ingenuo, que aborta en el primero. Intentas todos los canales, y solo entonces decides si el conjunto fue un fracaso.

De dónde viene

Salió de un agente que publicaba en varias redes a la vez. Extraje solo la fontanería: qué se publica y a quién es la lógica de cada aplicación; el cómo repartir con aislamiento y reporte es genérico, y sirve igual para notificaciones, alertas o webhooks. Por eso es una librería, no un for.

pip install fanout-broadcast

Código y tests (centrados en el aislamiento de fallos, verificados por mutación): github.com/isazajuancarlos/fanout-broadcast.

Cuando tu clasificador parpadea: histéresis para señales que oscilan

Juan Carlos Isaza — Sat, 08 Aug 2026 18:19:23 +0000

Tienes una señal que a cada observación te dice en qué estado estás: un monitor de salud que dice OK o CAÍDO, un detector de conectividad, un clasificador de modo. Y cerca del umbral oscila: OK, CAÍDO, OK, CAÍDO, OK. Cada cambio dispara algo —una alerta, un failover, entrar o salir de una posición— y de repente tu sistema está temblando por ruido, no por una transición real.

Es el mismo problema que resuelve el termostato de tu casa desde hace un siglo, y la solución tiene nombre: histéresis. No cambies de estado hasta que el nuevo se haya sostenido.

La regla, en una frase

Un estado nuevo solo se confirma tras repetirse N observaciones consecutivas. Si el candidato cambia o revierte antes de llegar a N, la cuenta se reinicia. El estado vigente se mantiene estable; los parpadeos se ignoran.

Lo empaqueté como librería —hysteresis-state, Python puro, sin dependencias— porque lo reescribía una y otra vez:

from hysteresis_state import HysteresisState

estado = HysteresisState("OK", confirmations=3)

for lectura in stream:                 # "OK" / "CAIDO"
    actual = estado.update(lectura)    # solo cambia tras 3 lecturas seguidas
    if estado.changed:                 # ¿esta lectura provocó la transición?
        alertar(actual)

Aliméntalo con OK, CAÍDO, OK, CAÍDO, OK y no pasa nada: ningún candidato se sostuvo. Hacen falta tres CAÍDO seguidos para que el cambio se confirme.

El detalle que casi siempre falta: histéresis asimétrica

Un umbral único tiene un problema sutil. Si exiges 3 confirmaciones para entrar en fallo, también tardas 3 en salir — y a veces quieres justo lo contrario: caer rápido a lo seguro, volver despacio a lo arriesgado. Es el comportamiento de un disyuntor eléctrico: salta a la primera, se rearma con cautela.

Se resuelve dejando que el umbral dependa de la transición:

# 1 confirmación para caer a "CAIDO", 5 para volver a "OK"
conf = lambda desde, hacia: 1 if hacia == "CAIDO" else 5
estado = HysteresisState("OK", confirmations=conf)

estado.update("CAIDO")   # cae al instante
# ...ahora hacen falta 5 "OK" seguidos para volver

Por qué no basta con "promediar"

La tentación es suavizar con una media móvil y umbralizar. Funciona para señales numéricas, pero se rompe con estados discretos (no promedias OK y CAÍDO), introduce retardo en todas las transiciones por igual, y no te da la asimetría de arriba. La histéresis por confirmación es la herramienta correcta cuando lo que oscila es una etiqueta, no un número.

De dónde salió

Esto nació dentro de un bot de trading. Su cerebro de régimen clasificaba el mercado en tendencia / rango / caos, y cerca de los umbrales parpadeaba: cada parpadeo congelaba o reactivaba la operativa, que es exactamente lo que no quieres que pase por ruido. La histéresis lo calmó. Pero el mecanismo no sabe nada de mercados —es anti-flapping para cualquier señal discreta—, así que lo liberé.

pip install hysteresis-state

Código y tests (con los casos límite del conteo y la asimetría, verificados por mutación): github.com/isazajuancarlos/hysteresis-state.

Dos formas en que un backtest te miente (y cómo evitarlas)

Juan Carlos Isaza — Fri, 07 Aug 2026 18:23:26 +0000

Pruebas una estrategia, o un modelo, sobre datos históricos. El backtest da un número bonito. Y luego, en real, no aparece. Casi siempre es una de estas dos ilusiones — y las dos se descartan con muy poco código.

Empaqueté las dos correcciones como librería: honest-eval, Python puro, sin dependencias. Salieron de un bot de trading, pero el rigor no tiene nada de específico al trading.

Ilusión 1: el modelo vio el futuro

Partir los datos con el clásico train_test_split aleatorio es correcto para datos independientes. En una serie temporal es un desastre silencioso: mete muestras de mañana en el conjunto de entrenamiento, y el modelo "predice" en el test cosas que en producción todavía no habrían pasado. La métrica sale inflada, y confías en un edge que no existe.

El test honesto es siempre el futuro: el tramo más reciente en el tiempo.

from honest_eval import temporal_split

train_idx, test_idx = temporal_split(timestamps, test_frac=0.20, embargo=24)
X_tr, X_te = X[train_idx], X[test_idx]

Devuelve índices, así lo aplicas a numpy, pandas o listas por igual.

El embargo cierra una fuga más sutil: si tu etiqueta mira h pasos adelante, una muestra de entrenamiento a menos de h del corte ya conoce parte del resultado del test. embargo=h descarta ese borde. La métrica baja — pero por fin es la real out-of-sample.

Ilusión 2: la variante ganó por suerte

Tienes varias variantes y quieres la mejor. Eliges la de mayor media. Error: con pocas muestras, eso premia la varianza, no la ventaja. La variante más ruidosa suele quedar arriba por azar.

Dos correcciones, ambas dentro de select_best_variant:

Aparear. Mide variante y baseline sobre el mismo ensayo y trabaja con δ = variante − baseline. La varianza común del ensayo se cancela en la resta, y te quedas con la señal.

Exigir cota inferior de confianza > 0. Gradúa una variante solo si media − z·SE > 0: "incluso siendo pesimista dentro del margen de confianza, sigue por encima del baseline".

from honest_eval import select_best_variant

variants = {
    "chandelier": [0.8, 1.1, -0.2, 0.9, 1.0, 0.7],
    "momentum":   [2.0, -1.5, 3.0, -0.5, 1.2, -1.0],   # media alta, muy dispersa
}

elegido = select_best_variant(variants, z=1.6449, min_effective_n=5)
politica = elegido.name if elegido else "baseline"

momentum puede tener la media más alta y aun así no graduar: su dispersión hunde la cota inferior. Eso es exactamente lo que quieres que pase — es el mecanismo que rechaza al ganador de suerte.

Cuando lo reciente pesa más

Si el proceso cambia con el tiempo, pondera por recencia. El tamaño de muestra efectivo de Kish (Σw)² / Σw² evita que unas pocas muestras muy pesadas se hagan pasar por muchas:

from honest_eval import halflife_weight

weights = [halflife_weight(now - t, halflife=7*86400) for t in exit_ts]
variants = {"chandelier": (deltas, weights)}

No crean señal — dejan de fabricarla

Ninguna de las dos inventa edge: eso son datos y buenas features. Lo que hacen es dejar de fabricarlo donde no lo hay. Son el mínimo para no mentirte antes de arriesgar algo real.

pip install honest-eval

Repo, tests (con la matemática anclada a mano y verificada por mutación) y detalle: github.com/isazajuancarlos/honest-eval.

Por qué tu bot recibe 403 de Cloudflare (y cómo endurecer un cliente ccxt)

Juan Carlos Isaza — Thu, 06 Aug 2026 18:31:54 +0000

Si automatizas un exchange con ccxt, tarde o temprano lo verás en los logs: rachas cortas de 403 Forbidden que pegan a fetch_balance, a los OHLCV o al saldo de earn, y que desaparecen solas a los pocos minutos. No es que tu API key esté mal. Es el WAF (Cloudflare) que muchos exchanges ponen delante de su REST, challengueando a algo que "parece un bot".

Y tu bot es un bot — pero uno legítimo, operando tu propia cuenta contra la API oficial. El problema no es de permisos, es de reputación de cliente HTTP. Esto va de reducir los falsos positivos del WAF, no de evadir ningún control de acceso.

Dos capas que lo mitigan

Saqué este patrón de un bot propio sobre OKX, tras varias rachas de 403, y lo publiqué como librería: ccxt-resilience (Apache-2.0).

1. Que el WAF challengue menos: `harden`

Un cliente ccxt por defecto se anuncia como lo que es. Ajustar un User-Agent de navegador, la cabecera Accept-Language y un timeout holgado hace que Cloudflare lo desafíe con menos frecuencia:

import ccxt
from ccxt_resilience import harden

exchange = harden(ccxt.okx({
    "apiKey": ...,
    "secret": ...,
    "password": ...,
}))

harden toca un cliente ya construido, devuelve el mismo objeto (encadenable) y nunca rompe su construcción: si algo falla al fijar los atributos, los deja como estaban.

2. Reintentar solo lo que se debe: `with_retry`

La tentación es envolver todo en un try/except que reintente. Es una trampa: reintentar un error de credenciales o de fondos solo gasta tiempo, termina igual de mal, y esconde bugs de lógica detrás de esperas.

La clave es reintentar únicamente lo transitorio —403/Cloudflare, 429, timeouts— con backoff exponencial y jitter, y re-lanzar los errores reales en el acto:

from ccxt_resilience import with_retry

balance = with_retry(exchange.fetch_balance)

ohlcv = with_retry(exchange.fetch_ohlcv, "BTC/USDT", timeframe="1m",
                   attempts=4, base=1.0, max_s=8.0)

Un error de autenticación se re-lanza inmediatamente, sin reintentar. Y si se agotan los intentos, se re-lanza la última excepción, para que tu manejador de fail-safe siga gobernando (por ejemplo, devolver el último valor cacheado).

La espera del intento i es min(max_s, base * 2**i) + rand()*base: crece de forma acotada y el jitter evita que varios clientes reintenten sincronizados.

La clasificación es explícita

Lo que hace o no reintetable a una excepción no está escondido: es una función que puedes inspeccionar y sustituir.

from ccxt_resilience import is_transient_error

# ¿Un 403 de Cloudflare? Sí. ¿Una clave inválida? No.
is_transient_error(Exception("403 Forbidden Cloudflare"))   # True
is_transient_error(Exception("invalid api key"))            # False

Con ccxt instalado clasifica también por tipo de excepción (DDoSProtection, RequestTimeout…); sin él, por el mensaje. Por eso ccxt es dependencia blanda: la librería funciona con o sin él. Y si tu caso es otra API, with_retry acepta tu propio predicado de reintento.

Instalación

pip install ccxt-resilience

El código, los tests y el detalle están en el repo: github.com/isazajuancarlos/ccxt-resilience. Es infraestructura pequeña y sin estado; úsala por partes.

DEV Community: Juan Carlos Isaza

De la idea al MVP: lanza tu producto en 2 semanas con Python

Qué es (y qué no es) un MVP

Por qué Python acelera esto

El proceso

¿Tienes una idea que validar?

RAG explicado: cómo darle a un LLM tu propia información

La idea

El patrón en Python

¿Para qué sirve?

Detalles que marcan la diferencia

¿Quieres un asistente con tus datos?

Cifrado híbrido: por qué combinar criptografía clásica y post-cuántica

La idea en una frase

Dos lugares donde aplicarlo

Un principio que nunca se rompe

Cómo lo aplica Quipu

¿Qué es la criptografía post-cuántica y por qué deberías migrar ya?

La amenaza no es solo del futuro

Los nuevos estándares del NIST

Cifrado híbrido: el enfoque prudente

¿Por dónde empezar?

Automatiza tareas repetitivas con un bot en Python

Primero: ¿qué vale la pena automatizar?

Las herramientas del ecosistema Python

Un ejemplo mínimo

De script a bot fiable

¿Tienes una tarea que odias hacer a mano?

NiceGUI: crea una aplicación web en Python sin escribir JavaScript

¿Qué es NiceGUI?

Lo simple que es

¿Para qué es ideal?

¿Cuándo NO es la mejor opción?

Rendimiento y despliegue

¿Quieres una app así?

Cómo integrar un LLM (Claude o GPT) en tu aplicación Python

1. Elige el proveedor

2. La llamada mínima

3. Streaming para una buena experiencia

4. Salida estructurada (JSON fiable)

5. Buenas prácticas para producción

¿Necesitas ayuda?

i18n sin gettext: traducciones en JSON con claves de punto

Tres detalles que marcan la diferencia

Agnóstico del framework

De dónde viene

Notificar a varios canales sin que un fallo tumbe al resto

La forma correcta

Encender y apagar sin ramificar el código

Escalar, pero después de intentarlo todo

De dónde viene

Cuando tu clasificador parpadea: histéresis para señales que oscilan

La regla, en una frase

El detalle que casi siempre falta: histéresis asimétrica

Por qué no basta con "promediar"

De dónde salió

Dos formas en que un backtest te miente (y cómo evitarlas)

Ilusión 1: el modelo vio el futuro

Ilusión 2: la variante ganó por suerte

Cuando lo reciente pesa más

No crean señal — dejan de fabricarla

Por qué tu bot recibe 403 de Cloudflare (y cómo endurecer un cliente ccxt)

Dos capas que lo mitigan

1. Que el WAF challengue menos: harden

2. Reintentar solo lo que se debe: with_retry

La clasificación es explícita

Instalación

1. Que el WAF challengue menos: `harden`

2. Reintentar solo lo que se debe: `with_retry`