DEV Community: Tu codigo cotidiano

Construye tu primer servidor MCP con Python: de archivos Markdown a herramientas reutilizables

Tu codigo cotidiano — Tue, 03 Nov 2026 16:09:39 +0000

¿Y si pudieras convertir una carpeta de documentos Markdown en herramientas que otras aplicaciones puedan descubrir e invocar mediante un protocolo estándar?

Eso es precisamente lo que construiremos utilizando Python y Model Context Protocol (MCP).

¿Qué es MCP?

Model Context Protocol es un protocolo abierto que permite que aplicaciones cliente se comuniquen con servidores que ofrecen herramientas y otras capacidades.

No es un modelo de inteligencia artificial y tampoco necesitas contratar una API de IA para aprender a utilizarlo.

El proyecto: un servidor MCP para consultar notas

En este tutorial desarrollamos un servidor local con tres herramientas:

listar_notas()
buscar_notas(consulta)
leer_nota(nombre)

Sus responsabilidades son sencillas:

listar_notas() enumera los documentos Markdown permitidos.
buscar_notas() busca texto en el contenido de las notas.
leer_nota() recupera el contenido de un archivo validado.

El proyecto separa la comunicación MCP de la lógica que administra los archivos.

Cliente MCP
    ↓
Servidor MCP (server.py)
    ↓
NotesStore (notas_core.py)
    ↓
Documentos Markdown

No se trata solamente de hacer funcionar el servidor

También exploramos decisiones de ingeniería importantes:

Validación de nombres para rechazar rutas no permitidas.
Restricción de tamaño y cantidad de documentos.
Manejo de errores controlados.
Pruebas unitarias y de integración con pytest.
Ejecución de un cliente Python.
Inspección visual con MCP Inspector.

El servidor es un ejemplo educativo de solo lectura, no un sistema de aislamiento completo para ejecutar con archivos no confiables.

¿Qué aprenderás?

Al terminar, comprenderás cómo un cliente descubre herramientas, cómo invoca operaciones con argumentos estructurados y cómo recibe resultados mediante MCP.

También podrás ampliar el proyecto para integrar tus propios documentos.

No necesitas un LLM ni claves de API. Solo Python, curiosidad y ganas de comprender cómo funciona el protocolo.

📚 Tutorial completo en Tu Código Cotidiano:

https://tucodigocotidiano.yarumaltech.com/leer_tutoriales/crea-tu-primer-servidor-mcp-con-python-herramientas-para-consultar-documentos-markdown/

El tutorial incluye código fuente, ejemplos, pruebas y ejercicios para seguir experimentando.

¿Qué herramienta MCP te gustaría construir después?

Harvest Now, Decrypt Later: ¿por qué Internet está cambiando su criptografía?

Tu codigo cotidiano — Mon, 02 Nov 2026 12:49:00 +0000

Imagina que alguien intercepta hoy una comunicación cifrada.

No puede leerla.

No conoce las claves.

No tiene capacidad para romper los mecanismos criptográficos utilizados.

Pero decide almacenarla.

Diez años después, una nueva generación de computadoras podría permitirle analizar esa información con técnicas que hoy no están disponibles.

¿Podría recuperar datos que parecían protegidos para siempre?

Esta es la pregunta detrás de una amenaza conocida como Harvest Now, Decrypt Later (HNDL).

Y explica por qué la criptografía poscuántica se está convirtiendo en una prioridad real para la seguridad de Internet.

El problema no comienza cuando llega la computadora cuántica

La computación cuántica promete resolver determinadas clases de problemas matemáticos de formas muy diferentes a la computación convencional.

En particular, una computadora cuántica suficientemente potente y tolerante a fallos podría comprometer algoritmos de clave pública basados en problemas como la factorización de enteros o el logaritmo discreto.

Eso incluye mecanismos clásicos como RSA y determinados sistemas de intercambio de claves basados en curvas elípticas.

Pero hay una distinción importante:

No toda la criptografía actual quedaría automáticamente inutilizada.

La amenaza es especialmente relevante para ciertos mecanismos de clave pública. Los algoritmos simétricos presentan un panorama diferente.

El problema es que algunas comunicaciones capturadas hoy podrían depender de mecanismos vulnerables a futuros ataques cuánticos.

¿Qué tiene que ver esto con HTTPS?

Cuando navegamos por Internet, TLS permite establecer conexiones protegidas entre clientes y servidores.

En una conexión TLS moderna, el establecimiento de claves y el cifrado del tráfico cumplen funciones diferentes.

Primero se establece material secreto compartido.

Después se utiliza criptografía simétrica para proteger los datos intercambiados.

Una conexión que dependa exclusivamente de un intercambio clásico vulnerable a ataques cuánticos futuros podría exponer información histórica si un adversario conserva los datos necesarios.

Eso convierte el tiempo en una variable de seguridad.

Si un secreto solo necesita mantenerse privado durante unas horas, su riesgo es diferente del de una historia clínica o un documento confidencial que debe permanecer protegido durante décadas.

ML-KEM: una respuesta diseñada para el futuro

En agosto de 2024, el NIST publicó el estándar FIPS 203, que especifica ML-KEM.

ML-KEM es un mecanismo de encapsulación de claves diseñado para permitir que dos participantes establezcan un secreto compartido utilizando técnicas basadas en problemas matemáticos para los que no se conocen ataques cuánticos eficientes capaces de romper sus parámetros recomendados.

Algo especialmente interesante es que no necesitamos una computadora cuántica para utilizar criptografía poscuántica.

Los algoritmos se ejecutan en computadores convencionales.

La palabra poscuántica describe el modelo de amenazas frente al cual se busca resistencia, no el hardware necesario para ejecutarlos.

¿Por qué combinar algoritmos clásicos y poscuánticos?

Una estrategia de transición consiste en utilizar mecanismos híbridos.

Por ejemplo, un intercambio de claves puede combinar X25519 con ML-KEM y derivar secretos utilizando los resultados de ambos.

La idea es no depender exclusivamente de un solo mecanismo criptográfico.

Bajo una combinación correctamente diseñada, la protección puede mantenerse si al menos uno de los componentes conserva las propiedades de seguridad esperadas.

Pero migrar Internet no consiste simplemente en cambiar una función criptográfica.

También hay que considerar certificados digitales, firmas, bibliotecas, protocolos, infraestructura heredada, interoperabilidad y rendimiento.

El mundo ya está preparando la transición

El 27 de octubre de 2026, el NIST publicó nuevas directrices para orientar la migración hacia estándares de criptografía poscuántica.

Esto no demuestra que ya exista una computadora cuántica capaz de romper los principales sistemas criptográficos desplegados a gran escala.

Demuestra algo diferente: la transición es suficientemente compleja como para comenzar antes de que esa amenaza se materialice.

Y hay una razón adicional.

Los datos interceptados hoy no pueden protegerse retroactivamente simplemente actualizando mañana el servidor que los transmitió.

Una pregunta de ingeniería

Quizás la cuestión más importante no sea cuándo tendremos una computadora cuántica capaz de atacar determinados sistemas.

Quizás sea esta:

¿Cuánto tiempo necesita seguir siendo secreta la información que estamos transmitiendo hoy?

Esa pregunta cambia la forma de diseñar sistemas seguros.

La criptografía no debe proteger únicamente frente a las capacidades presentes de un atacante. También debe considerar la vida útil de los datos.

🎙️ Una explicación en menos de cuatro minutos

En Tu Código Cotidiano, preparamos un episodio donde Javier y Laura exploran esta amenaza, el funcionamiento de la criptografía poscuántica y por qué Internet está adoptando nuevos mecanismos de protección.

El episodio está narrado en español y pensado para personas interesadas en tecnología, ingeniería y seguridad.

🎧 Escuchar: ¿Y si roban tus datos hoy para descifrarlos en 10 años?

https://tucodigocotidiano.yarumaltech.com/escuchar-podcast/y-si-roban-tus-datos-hoy-para-descifrarlos-en-10-anos-criptografia-poscuantica/

Para profundizar, puedes consultar la documentación oficial:

NIST — Post-Quantum Cryptography

NIST — FIPS 203: ML-KEM

NIST — Transición a estándares poscuánticos (2026)

Pregunta para la comunidad:

Si estuvieras diseñando hoy una API que almacena datos sensibles durante veinte años, ¿incluirías criptografía poscuántica desde el inicio o esperarías a que la adopción fuera más amplia?

Cómo conectar una IA con tus datos usando MCP y Python

Tu codigo cotidiano — Fri, 30 Oct 2026 21:13:13 +0000

Cómo conectar una IA con tus datos usando MCP y Python

¿Una inteligencia artificial puede consultar tu inventario en lugar de inventar una respuesta?

Para explorar esta pregunta construí StockBridge, un servidor MCP en Python que permite a un asistente consultar productos, precios y existencias desde un archivo JSON.

¿Qué es MCP?

Model Context Protocol (MCP) es un protocolo que permite conectar aplicaciones de inteligencia artificial con herramientas y fuentes de información externas.

En nuestro ejemplo, el funcionamiento es:

Usuario → Asistente de IA → Servidor MCP → Inventario JSON

El asistente solicita una consulta, el servidor ejecuta una función Python y devuelve los resultados.

Construyendo StockBridge

El proyecto utiliza Python, el SDK mcp==2.3.0 y un inventario ficticio de cinco productos.

Implementé dos herramientas:

buscar_producto(nombre): encuentra productos por nombre.
productos_por_agotarse(limite=5): identifica productos cuyas existencias están por debajo de un límite.

Esta es la segunda herramienta:

@mcp.tool()
def productos_por_agotarse(limite: int = 5) -> BajoStock:
    if type(limite) is not int or limite < 0:
        raise ToolError("Límite inválido")

    encontrados = sorted(
        (p for p in INVENTARIO if p["stock"] < limite),
        key=lambda p: (p["stock"], p["id"])
    )

    return {
        "productos": encontrados,
        "total": len(encontrados),
        "limite": limite
    }

Este fragmento forma parte del servidor completo, donde se definen mcp, BajoStock, ToolError e INVENTARIO.

El decorador @mcp.tool() permite registrar la función como una herramienta que un cliente MCP puede descubrir y ejecutar.

Resultados de la consulta

Al ejecutar la herramienta con limite=5, obtuvimos:

Producto	Existencias	Precio
Miel 250 g	0	$18.000 COP
Café en grano 500 g	2	$28.000 COP
Café molido 500 g	3	$24.000 COP

Los productos y precios son ficticios, pero la consulta se realiza sobre el archivo JSON.

¿Cómo sabemos que realmente funciona?

No quería limitarme a mostrar una respuesta aparentemente correcta.

Por eso desarrollé 11 pruebas automatizadas: diez verificaciones funcionales y una prueba de integración que inicia el servidor y se comunica mediante MCP sobre stdio.

También conecté StockBridge con GitHub Copilot en Visual Studio Code.

Durante la demostración, Copilot ejecutó la herramienta productos_por_agotarse y utilizó sus resultados.

Esto demuestra una diferencia importante:

No es lo mismo que una IA genere una respuesta a que consulte datos mediante una herramienta verificable.

Tutorial completo

Documenté el proyecto paso a paso en TuCodigoCotidiano.

El tutorial explica cómo crear el inventario JSON, construir el servidor Python, validar datos, ejecutar pruebas, utilizar MCP Inspector y conectar las herramientas con GitHub Copilot.

Incluye el código necesario para reproducir el laboratorio.

Leer el tutorial completo: MCP con Python, permite que una IA consulte tu inventario

Conclusión

MCP permite construir asistentes que pueden utilizar herramientas para acceder a información específica.

Pero también necesitamos verificar las llamadas, validar los datos y controlar los permisos.

Una cosa es que una IA responda. Otra muy distinta es demostrar que consultó los datos.

¿Qué herramienta conectarías primero a un asistente mediante MCP?

Bitácora Git: convierte cambios en una historia verificable

Tu codigo cotidiano — Tue, 27 Oct 2026 17:01:07 +0000

Un laboratorio educativo para aprender Git y GitHub conectando cambios, decisiones, revisiones, pruebas y firmas.

Inspiración:
Un proyecto puede conservar todas sus versiones y seguir siendo difícil de entender. Quería crear una práctica donde cada cambio tuviera un motivo y una evidencia que permitiera comprobarlo.

El laboratorio:
La guía propone construir bitacora-git, un pequeño proyecto en Python que normaliza títulos. Una mejora incorpora el rechazo de entradas vacías y permite recorrer un flujo completo de desarrollo.

Quien siga la práctica aprenderá a preparar cambios, crear commits claros, trabajar con ramas, abrir pull requests y configurar pruebas automáticas. Después resolverá un conflicto, recuperará un commit y localizará una regresión con git bisect.

El recorrido termina con firmas SSH, una etiqueta de entrega y la comprobación desde un clon limpio.

Qué aporta:
Cada etapa conecta una decisión con una evidencia concreta. También explica los límites: unas pruebas correctas cubren determinados casos y una firma válida requiere comprobar la confianza en la clave.

Tecnologías:
Git, GitHub, Python, unittest, PowerShell y GitHub Actions.

Guía y procedimiento:
https://tucodigocotidiano.yarumaltech.com/leer_guias/git-y-github-convierte-cambios-en-una-historia-verificable/

Python 3.15: ¿lazy import acelera tus programas? Una prueba real

Tu codigo cotidiano — Tue, 13 Oct 2026 10:24:30 +0000

Python 3.15 se lanzó oficialmente el 9 de octubre de 2026, incorporando nuevas características para mejorar la expresividad del lenguaje y ofrecer más control sobre la ejecución de nuestros programas.

Pero hay una diferencia importante entre conocer una novedad y comprobar su funcionamiento.

Decidí instalar Python 3.15.0 en Windows y realizar un pequeño experimento.

¿Qué sucede con lazy import?

Tradicionalmente, cuando Python encuentra una instrucción import, carga e inicializa el módulo correspondiente.

Python 3.15 incorpora la posibilidad de realizar importaciones diferidas mediante la nueva sintaxis lazy import.

Esto permite aplazar la inicialización de determinados módulos hasta que sean utilizados.

El experimento

Preparé un módulo llamado modulo_pesado.py con una espera artificial de dos segundos durante su inicialización.

Después comparé dos situaciones:

Una importación tradicional mediante import modulo_pesado.
Una importación diferida mediante lazy import modulo_pesado.

Utilicé time.perf_counter() para medir los tiempos.

Resultados

Operación	Tiempo observado
Importación tradicional	2,006 s
Declaración con lazy import	0,000 s
Primer uso del módulo diferido	2,002 s

El valor de 0,000 segundos está redondeado a tres decimales. No significa que la declaración tenga un costo absolutamente nulo.

Además, la espera utilizada era artificial, por lo que estos números no representan una mejora general de rendimiento.

¿Qué aprendí?

lazy import no elimina el costo de importar un módulo: cambia el momento en que se realiza.

Puede resultar útil en herramientas de línea de comandos, aplicaciones con funcionalidades opcionales o proyectos con numerosas dependencias.

Sin embargo, también hay que considerar que la inicialización y los posibles errores de importación pueden ocurrir más tarde.

La recomendación es medir antes de optimizar.

Otras novedades de Python 3.15

Además de las importaciones diferidas, esta versión incorpora mejoras interesantes:

frozendict: diccionarios cuyas entradas no pueden modificarse.
sentinel: marcadores únicos para diferenciar la ausencia de un valor de None.
Unpacking en comprensiones: nuevas formas de combinar colecciones mediante * y **.
UTF-8 por defecto: un comportamiento más uniforme en el manejo de texto.
Tachyon: herramientas integradas para analizar dónde consume tiempo un programa.

Guía completa en español

En Tu Código Cotidiano publiqué una guía dedicada a Python 3.15, que incluye instalación en Windows, ejemplos ejecutables y pruebas de sus seis novedades destacadas.

Puedes consultar gratuitamente la primera parte. El contenido restante forma parte de la membresía Premium.

Leer Python 3.15 desde cero: instalación, seis novedades y pruebas reales

Y ahora una pregunta para la comunidad:

¿Qué novedad de Python 3.15 consideras más útil para proyectos reales?

Publicado por Tu Código Cotidiano.

Python Virtual Environments Finally Explained: venv, pip and Dependencies

Tu codigo cotidiano — Tue, 06 Oct 2026 16:41:39 +0000

Python Virtual Environments Finally Explained: venv, pip and Dependencies

A Python virtual environment isn't a tiny virtual machine.

It's a much simpler idea:

Give each project its own Python dependency context.

Imagine two projects:

Project A → package 1.x
Project B → package 2.x

If both projects depend on the same global Python installation, sooner or later those requirements can collide.

With virtual environments:

Project A → .venv → package 1.x
Project B → .venv → package 2.x

Each project gets its own dependency space.

Activating isn't magic

When you activate a virtual environment, you're not starting another operating system.

You're mainly changing which executables your shell finds first.

That's why this is such a useful diagnostic:

python -c "import sys; print(sys.executable)"

Instead of trusting the (.venv) label, ask Python which interpreter is actually running.

The same idea applies to pip

I prefer:

python -m pip install requests

because it makes the relationship explicit:

chosen Python
→ its pip
→ its packages

And the environment shouldn't be precious

A useful mental model is:

The environment is disposable. The recipe to rebuild it isn't.

That's why we usually keep things like:

source code
requirements.txt
.gitignore

in Git, but not the entire .venv directory.

I wrote a complete visual guide covering:

venv
activation
pip
direct vs transitive dependencies
requirements.txt
Git
rebuilding environments
common debugging mistakes

Full guide in Spanish:

https://tucodigocotidiano.yarumaltech.com/leer_guias/entornos-virtuales-y-dependencias-cada-proyecto-en-su-propia-burbuja/

One question for Python developers:

Can you delete your virtual environment today and rebuild it without guessing what was installed?

El candado no significa lo que crees: qué protege realmente HTTPS

Tu codigo cotidiano — Mon, 05 Oct 2026 13:19:26 +0000

Hay una idea que hemos aprendido casi automáticamente al navegar por Internet:

🔒 Candado = página segura.

Pero no es exactamente así.

HTTPS puede ofrecer una conexión criptográficamente protegida con una página que, aun así, pertenece a un atacante.

Entonces, ¿qué protege realmente HTTPS?

HTTPS protege la conexión

Cuando visitas una dirección que comienza con https://, HTTP funciona sobre TLS.

Antes de intercambiar normalmente el contenido de la página, navegador y servidor realizan un TLS handshake.

De forma simplificada, durante ese proceso deben resolver varias cosas:

cómo protegerán la comunicación;

cómo establecerán claves;

cómo comprobará el navegador la identidad del servidor;

y cómo sabrán si los datos fueron modificados.

El resultado es un canal protegido entre ambos extremos.

Confidencialidad

Imagina que estás conectado a una red Wi-Fi y escribes una contraseña.

Sin protección criptográfica adecuada, alguien situado en el camino podría intentar observar el tráfico.

TLS cifra el contenido de la comunicación.

Eso significa que capturar los paquetes no debería permitir simplemente leer tu contraseña, una cookie de sesión o los datos HTTP intercambiados.

Integridad

Cifrar no es suficiente.

También necesitamos saber que alguien no cambió los datos mientras viajaban.

Supongamos que una aplicación envía:

transferir 100.000 pesos

Un atacante situado en medio de la comunicación no debería poder transformarlo silenciosamente en:

transferir 1.000.000 de pesos

TLS utiliza mecanismos criptográficos que permiten detectar alteraciones en los datos protegidos.

Autenticación

Aquí aparecen los certificados digitales.

El servidor presenta un certificado relacionado con el dominio que estás visitando y demuestra que posee la clave privada correspondiente.

Tu navegador comprueba, entre otras cosas, la cadena de confianza, el dominio y la validez del certificado.

Eso ayuda a evitar que cualquier servidor pueda simplemente afirmar:

“Yo soy ese sitio web”.

¿Y de dónde sale la clave para cifrar?

Esta es una de las partes más interesantes.

Al principio, navegador y servidor todavía no comparten el secreto que utilizarán para proteger la sesión.

Durante el handshake utilizan criptografía de clave pública e intercambio de claves para conseguir material secreto compartido.

Después pueden derivar claves de sesión.

Y una vez establecida la sesión, la mayor parte de la comunicación puede protegerse mediante criptografía simétrica, mucho más eficiente para grandes cantidades de datos.

Conceptualmente:

Navegador
↓
TLS handshake
↓
Certificado + autenticación
↓
Intercambio de claves
↓
Claves de sesión
↓
Canal HTTP protegido
↓
Servidor

Entonces… ¿qué significa realmente el candado?

Aquí está la distinción importante.

HTTPS puede decirte que estás manteniendo una conexión protegida con el dominio que aparece en tu navegador.

Pero no puede garantizar que la persona que creó ese dominio tenga buenas intenciones.

Un atacante puede registrar un dominio parecido al de un banco, obtener un certificado válido y construir una página de phishing.

Y entonces ocurre algo curioso:

TLS puede proteger perfectamente tu contraseña mientras viaja hacia el atacante.

La criptografía funcionó.

El problema estaba en que nosotros confiamos en el sitio equivocado.

HTTPS tampoco significa anonimato

TLS protege el contenido de la comunicación que transporta, pero no hace invisible toda tu actividad en Internet.

Direcciones IP, DNS, características de las conexiones y otros metadatos pueden seguir proporcionando información dependiendo de la arquitectura utilizada.

Por eso HTTPS es una pieza fundamental de la seguridad web, pero no es una capa mágica.

La próxima vez que veas el candado…

No pienses simplemente:

“Esta página es segura”.

Una interpretación mucho mejor sería:

“Mi navegador ha establecido un canal criptográficamente protegido con este dominio”.

Detrás de ese pequeño candado hay certificados, firmas digitales, intercambio de claves, criptografía simétrica y décadas de ingeniería de seguridad.

🎙️ Hice un episodio de menos de cuatro minutos de Tu Código Cotidiano donde Javier y Laura explican toda esta historia de forma conversacional:

https://tucodigocotidiano.yarumaltech.com/escuchar-podcast/que-protege-hoy-https/

Pregunta para la comunidad: ¿qué otra tecnología usamos todos los días pero casi nunca nos detenemos a pensar cómo funciona?

I built Deception Mesh: an open-source Rust MVP for defensive cybersecurity telemetry

Tu codigo cotidiano — Thu, 01 Oct 2026 14:41:18 +0000

I just published Deception Mesh, an open-source cybersecurity MVP built in Rust.

Project page: https://tucodigocotidiano.yarumaltech.com/proyectos/deception-mesh/

GitHub: https://github.com/tucodigocotidiano/deception-mesh

Why I built it

Most small projects and learning environments think about security only after something goes wrong.

Firewalls, authentication and monitoring are important, but there is another useful defensive idea:

What if we could deploy small decoy services that are not real production systems, but can help us observe suspicious behavior?

That is the core idea behind Deception Mesh.

Instead of exposing only real services, the project uses lightweight decoy sensors that can capture suspicious HTTP and SSH activity and turn it into structured telemetry.

What Deception Mesh does

Deception Mesh is a defensive MVP.

It is not an offensive tool.

It does not try to exploit systems.

It does not provide attack automation.

Its purpose is to help observe suspicious interactions against decoy services and make those events easier to inspect.

The MVP includes:

HTTP decoy sensor
SSH decoy sensor
REST API
JWT authentication
Role-based access control
Webhook notifications
CSV export
Docker deployment
Documentation for local execution and testing

The technical idea

The project is based on a simple flow:

A suspicious client interacts with a decoy service.
The sensor captures the event.
The system stores or exposes the event as structured telemetry.
The operator can review the signal through logs, CSV exports, API responses or webhook notifications.

The goal is not to replace enterprise security platforms.

The goal is to show that a small, understandable and auditable deception layer can be built with practical software engineering.

Why Rust

I chose Rust because it is a strong fit for infrastructure-oriented security projects.

It gives a good balance between performance, memory safety and explicit design.

For a project that handles network-facing components, Rust also encourages discipline around error handling, data structures and system boundaries.

What I wanted to prove

With this MVP, I wanted to validate four things:

A deception-based security concept can be implemented without building a huge platform.
Rust can be used to create small defensive sensors with clean architecture.
Security telemetry can be made understandable for developers and students.
A project can be useful even when its scope is intentionally limited.

That last point matters.

This is not presented as a finished commercial product.

It is a validated MVP with a clear defensive scope and room for improvement.

Who this project is for

This project may be useful for:

Software engineering students
Cybersecurity students
Backend developers
Rust learners
People interested in defensive infrastructure
Anyone curious about deception-based security

It can also be a starting point for discussions around telemetry, detection, infrastructure hardening and practical security engineering.

Current limitations

The project is intentionally honest about its current stage.

It is an MVP.

It still needs more hardening, better testing, stronger deployment guidance and deeper validation before being treated as production-ready.

That is part of the reason I am publishing it openly.

I want feedback, technical criticism and ideas from people who care about building useful defensive systems.

Final thoughts

Deception Mesh started as a practical experiment, but it became a valuable learning project around cybersecurity, Rust, backend systems and telecommunications.

If you are interested in open-source cybersecurity, defensive telemetry or Rust-based infrastructure, I would be happy if you take a look.

GitHub: https://github.com/tucodigocotidiano/deception-mesh

Feedback, issues, stars and technical suggestions are welcome.

¿Cómo puede tu celular conectarse directamente con un satélite?

Tu codigo cotidiano — Mon, 07 Sep 2026 23:16:10 +0000

Imagina esto:

Estás en una carretera, una montaña o una zona rural.

Miras tu teléfono.

Sin servicio.

No hay una torre celular suficientemente cerca, pero cientos de kilómetros sobre tu cabeza pasa un satélite.

¿Podría tu mismo teléfono conectarse con él?

En determinados servicios, la respuesta ya es sí.

Y técnicamente es fascinante.

Una torre celular que se mueve por el espacio

Una forma sencilla de entender Direct to Cell es imaginar ciertos satélites como una extensión de la infraestructura de una red móvil.

El teléfono sigue teniendo enormes limitaciones:

transmite con relativamente poca potencia;
utiliza una antena diminuta;
no fue diseñado como una gran terminal satelital.

Por eso buena parte de la dificultad está del otro lado del enlace.

El sistema satelital necesita detectar señales extremadamente débiles, gestionar haces de cobertura y mantener comunicación mientras el satélite se desplaza rápidamente respecto al usuario.

Y entonces aparece Doppler

Una torre terrestre normalmente permanece en el mismo lugar.

Un satélite LEO no.

Su velocidad relativa provoca desplazamiento Doppler en la señal, mientras cambian continuamente distancia, retardo y geometría del enlace.

La red tiene que compensar todo eso mientras intenta ofrecer al teléfono una experiencia que se parezca, en lo posible, a conectarse a una red móvil convencional.

De la red terrestre a las NTN

Aquí entran las Non-Terrestrial Networks (NTN).

La evolución de las redes móviles está integrando cada vez más componentes terrestres y satelitales.

Eso abre una posibilidad interesante:

En ciudades y lugares con alta demanda seguimos utilizando infraestructura terrestre por su enorme capacidad.

Pero cuando esa cobertura desaparece, una red satelital podría convertirse en una capa adicional de conectividad.

No significa “Internet ilimitado desde cualquier lugar”.

La capacidad sigue siendo limitada y existen requisitos de espectro, compatibilidad, regulación y acuerdos con operadores.

Pero incluso poder mantener mensajería o determinados servicios donde antes había cero conectividad cambia bastante las cosas.

Hicimos un episodio para explicarlo

En el nuevo episodio de Tu Código Cotidiano, Javier y Laura explican Direct to Cell desde cero:

LEO
espectro móvil
Doppler
estaciones base en el espacio
NTN
limitaciones actuales
cobertura rural

Todo en menos de cuatro minutos y sin asumir conocimientos avanzados de telecomunicaciones.

🎧 Escuchar episodio:

https://tucodigocotidiano.yarumaltech.com/escuchar-podcast/tu-celular-conectado-directamente-a-satelites-como-es-posible/

La pregunta que más me interesa es esta:

¿Crees que la conectividad satelital terminará siendo simplemente otra capa de nuestras redes móviles, hasta el punto de que los usuarios ni siquiera notemos cuándo cambiamos de una torre terrestre a un satélite?

How to Organize Python Code with Modules and Packages — A Practical Beginner Guide

Tu codigo cotidiano — Thu, 03 Sep 2026 15:54:20 +0000

A Python program can work perfectly and still become difficult to maintain.

That usually happens when one file slowly starts doing everything:

program.py

├── register expenses
├── save CSV files
├── calculate totals
├── generate reports
└── run the program

Nothing is necessarily broken.

The problem is that finding and changing one responsibility starts requiring you to understand several unrelated parts of the file.

The first useful question

When a Python project grows, don't start by asking:

How many lines should a file have?

A better question is:

Which responsibilities belong together, and which ones should be able to change separately?

For example, an expense tracker could evolve from one large file into:

expense_tracker/
├── main.py
└── finance/
├── init.py
├── expenses.py
├── files.py
└── reports.py

Now the structure itself tells us something:

expenses.py handles expense logic.

files.py handles persistence.

reports.py handles calculations and summaries.

main.py coordinates the program.

That is the real value of modules and packages: they help the code communicate its structure.

A tiny example

Instead of keeping every function in main.py, we can create a module:

file: finance/expenses.py

def add_expense(expenses, date, category, amount):
expenses.append({
"date": date,
"category": category,
"amount": amount
})

Then use it from another file:

file: main.py

from finance.expenses import add_expense

expenses = []

add_expense(
expenses,
"2026-09-02",
"Food",
18000
)

The behavior is simple, but the important change is architectural:

the responsibility now has a clear home.

The mistake to avoid

Learning modules doesn't mean creating one file for every function.

This:

calculator/
├── add.py
├── subtract.py
├── multiply.py
└── divide.py

is not automatically better than:

calculator.py

More files do not always mean better organization.

The goal is not fragmentation.

The goal is clarity.

Want the full visual walkthrough?

I wrote a complete step-by-step guide in Spanish on TuCódigoCotidiano.

It covers:

modules and packages;

import;

init.py;

if name == "main";

absolute and relative imports;

circular imports;

pycache;

when to split code — and when not to.

👉 Read the complete guide:

https://tucodigocotidiano.yarumaltech.com/leer_guias/modulos-y-paquetes-organiza-tu-codigo-sin-perderte/

If you're moving from small Python scripts to projects with multiple files, this is exactly the transition the guide is designed to explain.

¿Qué ocurre realmente cuando ejecutas un contenedor Docker?

Tu codigo cotidiano — Mon, 31 Aug 2026 15:10:41 +0000

¿Qué ocurre realmente cuando ejecutas un contenedor Docker?

Escribes:

docker run nginx

Unos segundos después nginx está funcionando.

Puede parecer que Docker acaba de crear una pequeña computadora dentro de tu computador.

Pero eso no es realmente lo que ocurre.

Todo comienza con una imagen

Docker necesita una imagen que contenga los elementos necesarios para ejecutar la aplicación.

Las imágenes normalmente están construidas mediante capas.

Eso permite reutilizar partes que ya existen en el sistema y evita descargar o almacenar todo nuevamente.

Después aparece el contenedor

Docker utiliza la imagen como base y crea un entorno donde ejecutará la aplicación.

Aquí aparece una diferencia fundamental:

una imagen y un contenedor no son lo mismo.

La imagen es reutilizable.

El contenedor es una instancia creada a partir de ella.

En el fondo hay procesos

En Linux, un contenedor no necesita ejecutar un sistema operativo completo independiente.

La aplicación se ejecuta como uno o varios procesos que comparten el kernel del host.

Entonces, ¿cómo consigue Docker que parezca un entorno independiente?

Namespaces: aislamiento

Linux dispone de mecanismos llamados namespaces.

Gracias a ellos, un proceso puede tener una visión aislada de elementos como:

procesos
interfaces de red
puntos de montaje
usuarios
hostname

Para la aplicación, parece que existe dentro de su propio entorno.

Cgroups: controlar recursos

También necesitamos evitar que un contenedor consuma todos los recursos de la máquina.

Para eso Linux dispone de los cgroups.

Permiten gestionar y contabilizar recursos como:

CPU
memoria
entrada y salida

Docker utiliza estos mecanismos para aplicar límites a los contenedores.

¿Qué ocurre con la red?

Docker también puede crear redes virtuales.

Por ejemplo:

docker run -p 8080:80 nginx

Aquí estamos indicando que el tráfico recibido en el puerto 8080 del host pueda llegar al puerto 80 utilizado por nginx dentro del contenedor.

¿Y los datos?

Un contenedor puede eliminarse.

Pero nuestros datos muchas veces deben sobrevivir.

Para eso existen los volúmenes.

Los volúmenes permiten almacenar información fuera de la capa efímera del contenedor.

Son especialmente importantes cuando trabajamos con bases de datos.

Entonces, ¿qué hay detrás de `docker run`?

Podemos visualizarlo así:

IMAGEN
   ↓
PROCESO
   ↓
AISLAMIENTO
   ↓
CONTROL DE RECURSOS
   ↓
RED
   ↓
ALMACENAMIENTO
   ↓
CONTENEDOR

Docker hace que toda esta coordinación parezca sencilla.

Y esa es precisamente una de sus mayores virtudes.

🎧 En Tu Código Cotidiano preparé un episodio corto explicando todo este recorrido:

¿Qué ocurre dentro de Docker cuando ejecutas un contenedor?

https://tucodigocotidiano.yarumaltech.com/escuchar-podcast/que-ocurre-dentro-de-docker-cuando-ejecutas-un-contenedor/

Tu programa funciona… pero olvida todo: persistencia de datos con Python

Tu codigo cotidiano — Thu, 27 Aug 2026 20:16:50 +0000

Tu programa funciona… pero olvida todo

Imagina que estás creando un pequeño programa en Python para registrar gastos:

gastos = []

gastos.append({
    "categoria": "Comida",
    "valor": 18000
})

print(gastos)

Todo funciona.

Pero cierras el programa, lo ejecutas nuevamente y gastos vuelve a estar vacío.

¿Por qué?

Porque tener información dentro de una variable no significa haberla guardado permanentemente.

Memoria no es persistencia

Mientras nuestro programa está ejecutándose puede trabajar con listas, diccionarios, números y otros objetos.

Pero si queremos encontrar esa información después de cerrar el programa necesitamos representarla fuera de ese ciclo de ejecución.

Una de las formas más sencillas de hacerlo es utilizando archivos.

with open("nota.txt", "w", encoding="utf-8") as archivo:
    archivo.write("Mi primer dato persistente")

Ahora la información puede continuar existiendo incluso después de que Python termine.

Tres letras importantes: r, w y a

Cuando empezamos a trabajar con archivos hay tres modos especialmente útiles:

r → leer
w → escribir desde cero
a → añadir

Hay que tener especial cuidado con w: si el archivo ya contenía información, podemos reemplazarla.

Si queremos añadir algo sin borrar lo anterior:

with open("nota.txt", "a", encoding="utf-8") as archivo:
    archivo.write("\nOtra línea")

¿TXT, CSV o JSON?

Una forma sencilla de pensarlo es observar la estructura de nuestros datos.

TXT

Útil cuando queremos guardar texto sencillo.

CSV

Tiene sentido cuando nuestros datos se parecen a una tabla:

fecha,categoria,valor
2026-08-27,Comida,18000
2026-08-27,Transporte,6500

Python incluye el módulo csv, por lo que no necesitamos construir el archivo concatenando comas manualmente.

JSON

Empieza a resultar interesante cuando nuestros datos contienen claves, listas, números, booleanos o estructuras anidadas.

La decisión no consiste simplemente en memorizar tres extensiones.

Consiste en preguntarnos:

¿qué forma tienen mis datos?

Ese cambio de perspectiva hace mucho más sencillo entender la persistencia.

Preparé una guía completa en español donde desarrollamos el recorrido desde memoria y archivos TXT hasta CSV y JSON, con ejemplos paso a paso:

👉 https://tucodigocotidiano.yarumaltech.com/leer_guias/archivos-de-texto-csv-y-json-datos-que-sobreviven-al-programa/

Una frase resume bastante bien todo el concepto:

El programa puede terminar. Los datos no tienen por qué desaparecer.

DEV Community: Tu codigo cotidiano

Construye tu primer servidor MCP con Python: de archivos Markdown a herramientas reutilizables

¿Qué es MCP?

El proyecto: un servidor MCP para consultar notas

No se trata solamente de hacer funcionar el servidor

¿Qué aprenderás?

Harvest Now, Decrypt Later: ¿por qué Internet está cambiando su criptografía?

Cómo conectar una IA con tus datos usando MCP y Python

Cómo conectar una IA con tus datos usando MCP y Python

¿Qué es MCP?

Construyendo StockBridge

Resultados de la consulta

¿Cómo sabemos que realmente funciona?

Tutorial completo

Conclusión

Bitácora Git: convierte cambios en una historia verificable

Python 3.15: ¿lazy import acelera tus programas? Una prueba real

¿Qué sucede con lazy import?

El experimento

Resultados

¿Qué aprendí?

Otras novedades de Python 3.15

Guía completa en español

Python Virtual Environments Finally Explained: venv, pip and Dependencies

Python Virtual Environments Finally Explained: venv, pip and Dependencies

Activating isn't magic

The same idea applies to pip

And the environment shouldn't be precious

El candado no significa lo que crees: qué protege realmente HTTPS

I built Deception Mesh: an open-source Rust MVP for defensive cybersecurity telemetry

Why I built it

What Deception Mesh does

The technical idea

Why Rust

What I wanted to prove

Who this project is for

Current limitations

Final thoughts

¿Cómo puede tu celular conectarse directamente con un satélite?

How to Organize Python Code with Modules and Packages — A Practical Beginner Guide

file: finance/expenses.py

file: main.py

¿Qué ocurre realmente cuando ejecutas un contenedor Docker?

¿Qué ocurre realmente cuando ejecutas un contenedor Docker?

Todo comienza con una imagen

Después aparece el contenedor

En el fondo hay procesos

Namespaces: aislamiento

Cgroups: controlar recursos

¿Qué ocurre con la red?

¿Y los datos?

Entonces, ¿qué hay detrás de docker run?

Tu programa funciona… pero olvida todo: persistencia de datos con Python

Tu programa funciona… pero olvida todo

Memoria no es persistencia

Tres letras importantes: r, w y a

¿TXT, CSV o JSON?

Entonces, ¿qué hay detrás de `docker run`?