DEV Community: Tu codigo cotidiano

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.

Python Didn't Crash. The Result Was Still Wrong.

Tu codigo cotidiano — Wed, 26 Aug 2026 20:50:27 +0000

One of the most dangerous bugs isn't a SyntaxError.

It isn't an exception.

It doesn't even produce a traceback.

Sometimes Python executes your entire program successfully...

…and gives you the wrong answer.

Consider this:

def calcular_total(precios, descuento):
subtotal = sum(precios)
total = subtotal - descuento
return total

precios = [120000, 80000]
descuento = 0.10

print(calcular_total(precios, descuento))

Expected:

180000

Actual:

199999.9

Python isn't broken.

Our assumption is.

And that's where debugging becomes much more interesting.

A mistake I made when learning to debug was asking:

“What should I print?”

A better question is:

“What do I need to observe to prove or reject my hypothesis?”

That changes debugging from guessing into an experiment:

Reproduce → Hypothesis → Measure → Evidence → Conclusion

For example:

Are the inputs correct?
Is subtotal correct?
Is descuento what we expect?
At which exact operation does the state become wrong?

Once you know that:

subtotal = 200000 ✓
descuento = 0.10 ✓

the search space becomes tiny.

The suspicious operation is now:

subtotal - descuento

That's the real goal of debugging:

Turn “something is wrong” into one small, testable question.

I wrote a practical guide showing this process with print(), type(), repr(), breakpoint() and step-by-step state inspection.

Full guide:
https://tucodigocotidiano.yarumaltech.com/leer_guias/depuracion-aprende-a-encontrar-el-error-antes-de-culpar-a-python/

Python Exceptions: From a Crashing Program to Controlled Error Handling

Tu codigo cotidiano — Mon, 24 Aug 2026 23:50:50 +0000

What should your Python program do when reality doesn’t follow the happy path?

I published a new practical guide on errors and exceptions in Python.

Instead of starting by memorizing try, except, else, and finally, the guide begins with a program that crashes because of unexpected input and builds the solution step by step.

It covers traceback reading, ValueError, ZeroDivisionError, specific exception handling, else, finally, raise, common mistakes, and a final program that survives invalid input.

The main idea:

Exception handling is not about hiding errors. It is about designing what your program should do when something goes wrong.

Full guide in Spanish:
https://tucodigocotidiano.yarumaltech.com/leer_guias/errores-y-excepciones-en-python-evita-que-tu-programa-muera-en-el-intento/

De Ionic a PostgreSQL: qué ocurre realmente cuando creamos una tarea

Tu codigo cotidiano — Tue, 18 Aug 2026 20:41:48 +0000

De Ionic a Posts una tarea

Aprender Django, Angular o PostgreSQL por separado es relativamente sencillo.

El verdadero salto ocurre cuando intentamos entender cómo todas esas tecnologías colaboran dentro de una aplicación real.

Supongamos que tenemos una aplicación móvil para administrar tareas y el usuario pulsa:

Crear tarea

¿Qué ocurre después?

La respuesta completa se parece a esto:

Ionic / Angular
      ↓
   HTTP + JSON
      ↓
Django REST Framework
      ↓
   Django ORM
      ↓
PostgreSQL

1. Angular recoge la información

El formulario mantiene temporalmente valores como:

título;
descripción;
estado;
fecha límite.

Pero esos datos todavía no forman parte del estado permanente del sistema.

2. El cliente construye una petición HTTP

Angular utiliza un servicio para enviar los datos hacia nuestra API.

El frontend no debería conectarse directamente a PostgreSQL.

Su trabajo es solicitar una operación al backend.

3. Django REST Framework recibe el JSON

Aquí comienza una de las partes más importantes.

El servidor no debería confiar ciegamente en lo enviado desde la interfaz.

Django REST Framework valida el contrato de la petición y permite que las reglas del dominio permanezcan centralizadas en el servidor.

4. El backend aplica las reglas

Una tarea puede tener, por ejemplo, solamente tres estados válidos:

pendiente;
pospuesta;
completada.

También podemos implementar reglas como:

identificar tareas próximas a vencer;
conservar información de auditoría;
asignar usuarios;
realizar eliminación lógica en lugar de destruir registros.

Estas decisiones pertenecen al dominio de la aplicación, no simplemente a la interfaz.

5. El ORM persiste la información

Una vez validada la operación, Django utiliza su ORM para escribir los cambios en PostgreSQL.

Ahora sí existe una representación persistente de la tarea.

6. La API responde

Django REST Framework serializa nuevamente la entidad y devuelve JSON al cliente.

7. Ionic actualiza la interfaz

Angular recibe la respuesta y actualiza el estado visible de la aplicación.

Tenemos entonces un ciclo completo:

interfaz → API → reglas → persistencia → API → interfaz

Y esa misma arquitectura puede reutilizarse cuando llevamos la aplicación a Android utilizando Ionic y Capacitor.

Construí un tutorial completo donde implementamos este proyecto paso a paso utilizando:

Django REST Framework
PostgreSQL
Docker
Angular
Ionic
CaD, filtros, soft delete, auditoría, cambios de estado y tareas próximas a vencer.

👉 Tutorial completo en español:

https://tucodigocotidiano.yarumaltech.com/leer_tutoriales/construye-una-app-fullstack-con-django-rest-postgresql-angular-ionic-y-android/

Si estás aprendiendo arquitectura fullstack, mi recomendación es que no te concentres únicamente en hacer funcionar cada tecnología.

Intenta seguir el recorrido completo de una sola operación desde la pantalla hasta la base de datos y de vuelta.

Ahí es donde muchas piezas empiezan a tener sentido.

What Physically Happens When You Ask an AI a Question?

Tu codigo cotidiano — Tue, 11 Aug 2026 22:18:14 +0000

We often think about artificial intelligence as something purely digital.

You type a question.

Press Enter.

A few seconds later, an answer appears.

But physically, a surprising amount of infrastructure has been involved during those few seconds.

Your question first travels through networking infrastructure toward a data center. There, the text is transformed into tokens that can be processed by an AI model.

Specialized hardware—often GPUs or other accelerators—performs billions of mathematical operations to calculate what should come next.

That computation requires electricity.

Electricity produces heat.

Heat requires cooling.

And all of this happens while networking systems move information between your device, servers, memory, storage and computing accelerators.

In other words, an AI response is not simply “generated by software.”

It is the result of a physical chain involving:

Networks
Data centers
GPUs and accelerators
Memory
Electricity
Cooling systems
Large-scale distributed computing

I recently explored this idea in a new episode of TuCodigoCotidiano:

🎧 ¿Qué ocurre físicamente cuando le preguntas algo a una IA?

https://tucodigocotidiano.yarumaltech.com/escuchar-podcast/que-ocurre-fisicamente-cuando-le-preguntas-algo-a-una-ia/

The episode is in Spanish and focuses on understanding the physical infrastructure behind something we now do every day: asking an AI a question.

ai #machinelearning #computerscience #technology

DEV Community: Tu codigo cotidiano

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?

Python Didn't Crash. The Result Was Still Wrong.

Python Exceptions: From a Crashing Program to Controlled Error Handling

De Ionic a PostgreSQL: qué ocurre realmente cuando creamos una tarea

De Ionic a Posts una tarea

1. Angular recoge la información

2. El cliente construye una petición HTTP

3. Django REST Framework recibe el JSON

4. El backend aplica las reglas

5. El ORM persiste la información

6. La API responde

7. Ionic actualiza la interfaz

What Physically Happens When You Ask an AI a Question?

ai #machinelearning #computerscience #technology

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