DEV Community: Axel Espinosa

Cómo proteger tu proyecto de paquetes maliciosos en npm

Axel Espinosa — Sat, 04 Apr 2026 05:57:09 +0000

Haces npm install, confías en que todo está bien, y sin saberlo un script malicioso ya se ejecutó en tu máquina. Así funcionan los ataques de supply chain en npm: infectan paquetes populares (o sus dependencias) y usan los lifecycle scripts para correr código antes de que te des cuenta.

Este tipo de ataque se viene hablando desde el 2022 pero los atacantes lo han utilizado con mayor frecuencia debido al alcance que logran tener en el ecosistema de npm. Un ejemplo reciente: Shai Hulud.

En este post te explico cómo funcionan estos ataques y qué configuraciones puedes aplicar hoy para proteger tus proyectos.

¿Qué es un "supply chain attack" o ataque a la cadena de suministro?

Este tipo de ataque se caracteriza por infectar alguna parte del ciclo de entrega del software.
Muchos proyectos tienen este ciclo de vida:

Escribir el código
Instalar paquetes
Mandar a un ambiente de CI/CD
Enviar proyecto a producción

Los ataques de supply chain se insertan en uno de estos pasos comprometiendo toda la cadena de pasos siguientes.

¿Cómo se infecta una librería?

Los atacantes no siempre comprometen el paquete popular directamente. Muchas veces infectan una dependencia interna de ese paquete.

Tu al instalar el paquete popular, sin saberlo estás instalando también el código de la dependencia infectada.

¿Cómo funcionan los lifecycle scripts en npm?

Los ataques recientes han utilizado una funcionalidad del gestor de paquetes de npm: la capacidad de ejecutar scripts antes o después de la instalación de un paquete.

A esto se le llaman "lifecycle scripts". Muchos paquetes los usan de manera legítima para preparar pasos previos a la instalación, como la compilación de paquetes nativos. Aunque la documentación de npm recomienda evitarlos, algunos paquetes los necesitan, y es precisamente esa característica la que los paquetes infectados utilizan.

Como esto es un proceso que sucede antes de que se instale el paquete, nosotros no nos percatamos de lo que se ejecuta. Los paquetes con malware ejecutan todos los pasos que necesitan para infectar tu equipo, robar información y después dejar todo limpio como si nada hubiera pasado. Eso es lo más crítico.

¿Cómo proteger tu proyecto de paquetes maliciosos en npm?

Hay varias medidas que podemos tomar. Vamos una por una.

No actualices versiones a lo loco

Es muy común utilizar herramientas como npm-check-updates para actualizar dependencias automáticamente. Siempre queremos tener lo último y pensamos que eso es lo correcto, pero realmente introducimos un vector de ataque.

La última versión puede traer malware. Mejor revisa qué se publicó, qué cambió en el changelog y si hay reportes antes de actualizar.

Bloquea los lifecycle scripts

Como vimos, es por estos scripts que muchos de los ataques suceden. Podemos desactivarlos al instalar una dependencia.

De manera individual:

npm install --ignore-scripts <pkg>

De manera global:

npm config set -g ignore-scripts true

O por proyecto con el archivo .npmrc:

ignore-scripts=true

Esto se agregó en la versión v11 de npm.

Bloquea instalaciones desde Git

Adicional a esto necesitas configurar el flag de allow-git para evitar que se instalen paquetes desde algún repositorio de Git en vez del registro de npm.

npm install --ignore-scripts --allow-git=none <pkg>

# global
npm config set -g allow-git none

# .npmrc
ignore-scripts=true
allow-git=none

Fija la versión de tus dependencias

Algo que yo particularmente no sabía es que fijar las versiones es una buena práctica. Estamos acostumbrados a instalar con npm install y asumir que el símbolo ^ al inicio de la versión en package.json está bien.

Pero ese ^ significa que al actualizar puedes descargar cualquier versión del paquete que no haga un salto de major version (el primer número). Es decir, si tienes la versión 1.x.x, npm puede instalar cualquier 1.y.z sin preguntarte.

Para fijar la versión exacta:

npm install --save-exact <pkg>

# global
npm config set -g save-exact true

# .npmrc
save-exact=true

No instales la versión más reciente

Otra precaución: evita instalar el paquete más reciente que existe. Esto puede pasar cuando haces un npm update o instalas el paquete por primera vez.

Muchos de los infectados en los ataques fue porque se publicó una versión nueva y muchas personas la instalaron de inmediato. Al paso de unas horas los contribuidores del paquete se dieron cuenta de que el paquete había sido comprometido.

Para evitar esto existe min-release-age: configuras cuánto tiempo debe haber pasado desde que se publicó un paquete para que npm lo instale.

npm install --min-release-age 3 <pkg>

# .npmrc
min-release-age=3 # 3 dias (npm usa días)

Esta configuración está disponible a partir de la versión v11 de npm.

Tu `.npmrc` defensivo mínimo

Así queda el .npmrc mínimo para tus proyectos:

save-exact=true
ignore-scripts=true
min-release-age=3

Y en CI, siempre npm ci --ignore-scripts, nunca npm install.

Considerar pnpm

pnpm es una alternativa a npm que bloquea los lifecycle scripts por defecto. Personalmente lo estoy usando para mis proyectos porque reduce el consumo de espacio (optimiza los node_modules) y porque trae estas protecciones incluidas.

Bloqueo de dependencias y builds

Por defecto, pnpm bloquea los scripts de pre/post instalación. Si algún paquete legítimo los necesita (como esbuild o next), puedes permitirlo explícitamente en el pnpm-workspace.yml:

# Permitir dependencias que sí pueden usar los lifecycle scripts (pnpm 10+)
allowBuilds:
  esbuild: true
  next: true

strictDepBuilds: true # Muestra error si alguna dependencia no listada hace uso de lifecycle scripts

Tiempo de antigüedad

Como en npm, puedes configurar el tiempo mínimo que debe haber pasado para instalar un paquete:

allowBuilds:
  esbuild: true
  next: true

strictDepBuilds: true

minimumReleaseAge: 1440 # mínimo 24 hrs (pnpm usa minutos)

Snyk recomienda que usemos al menos 21 días como periodo para instalar una nueva dependencia.

¿Cómo funciona `trustPolicy`?

pnpm asigna un nivel de confianza a cada versión publicada de un paquete, basado en cómo fue publicada. Los niveles de mayor a menor son:

Trusted Publisher: publicado vía GitHub Actions con OIDC (el CI firma criptográficamente que el paquete viene de un workflow específico en un repo específico)
Provenance: tiene una prueba verificable de npm que confirma dónde y cómo se construyó el paquete
Signatures: tiene firma del registry de npm
Sin evidencia: publicado sin ninguna señal de confianza

Si configuras trustPolicy: no-downgrade, pnpm compara el nivel de confianza de la versión que vas a instalar con el de versiones anteriores del mismo paquete. Si la confianza baja (por ejemplo, un paquete que siempre se publicó desde CI de repente aparece publicado sin ninguna evidencia), pnpm aborta la instalación.

Revisar antes de instalar

No instales paquetes de manera ciega. Existen herramientas que te ayudan a revisarlos antes.

npq

npq te ayuda a revisar lo que piensas instalar antes de siquiera instalarlo. Te advierte de posibles vulnerabilidades.

npx npq install express --dry-run

A partir de lo que veas puedes decidir si instalas la última versión o te esperas.

Socket Firewall

Socket Firewall es similar a npq pero además te permite usarlo con el manejador de paquetes de Python (uv). Personalmente no lo he utilizado, pero lo mencionan en las buenas prácticas.

Medidas adicionales

Evitar el uso de .env con información sensible

No tengas tus claves de producción, tokens o lo que sea importante en tu .env de manera plana como solíamos hacerlo. Si bien no subimos esta información a GitHub, en los ataques de supply chain los paquetes maliciosos tienen acceso al entorno donde se ejecutan. Esto quiere decir: tus accesos están expuestos.

Una alternativa es usar secretos. En su blog, Liran te explica cómo hacerlo.

Usa devcontainers

Personalmente ya sabía que existían pero no suelo trabajar con ellos. En las buenas prácticas de seguridad de Node.js mencionan la opción de usarlos para aislar los ataques y reducir el área de ataque a únicamente ese contenedor.

Si te gustaría un tutorial, déjame un comentario.

Verifica tu ambiente

Para verificar si tu ambiente ya bloquea los pre/post scripts puedes probar este paquete creado específicamente para eso. Si la instalación falla, significa que tus protecciones están funcionando.

  npm install @lavamoat/preinstall-always-fail

No estamos 100% seguros

Con estas prácticas reducimos el área de ataque, pero lo importante es mantenernos atentos a las noticias de seguridad y reducir el número de paquetes instalados si es posible.

Entre menos paquetes tengas, menos área de ataque y menos dependencias que vigilar. JavaScript ha evolucionado tanto que muchas cosas que antes necesitaban una librería hoy son triviales de hacer de forma nativa, o la librería estándar de Node.js ya las incluye.

Con un .npmrc bien configurado ya reduces la mayoría de los vectores de ataque. Recuerda revisar tus paquetes con npq o algún otra herramienta antes de instalarlos.

¿Ya tenías alguna de estas configuraciones? ¿Usas alguna otra medida? ¿Hay algo que no sea correcto? Deja tus comentarios.

Disclaimer: no soy experto en seguridad. Esto es información recopilada para mi propio uso y para ayudar a los demás.

npm install tips para la seguridad

Axel Espinosa — Tue, 31 Mar 2026 19:10:23 +0000

Actualización: Escribí un artículo sobre lo minimo que debes hacer para protegerte

Hay un nuevo ataque en el ecosistema de npm y con esto crece la duda de cómo prevenir infectarse.

Compartamos los mejores consejos para evitar infectarse en los comentarios para mantenernos seguros.

Empiezo ⬇️

¿Qué son los arrays y para qué sirven? Explicación sencilla

Axel Espinosa — Fri, 20 Mar 2026 18:40:05 +0000

Bienvenido a esta serie de artículos donde cubrimos temas fundamentales de computación. Hoy platicaremos sobre arrays, una de las estructuras de datos más utilizadas en cualquier lenguaje de programación.

Pero antes de entrar de lleno, necesitamos hablar sobre la memoria. Específicamente, la memoria RAM.

En estos ejemplos usaremos JavaScript como lenguaje principal y algunos ejemplos básicos de C. No necesitas ser experto en ninguno de los dos.

Cómo funciona la RAM

Todas las computadoras utilizan memoria para funcionar. En particular, hablamos de la memoria RAM, la cual almacena información temporal sobre los programas que estás ejecutando. Cuando digo temporal es porque, cuando la computadora se apaga, toda esa información se pierde y, al encender, la memoria vuelve a estar limpia. Es como si la RAM tuviera mala memoria.

Al hablar de memoria RAM, es inevitable hablar de direcciones y sé lo que estás pensando. ¿Cómo que direcciones?

Déjame darte un ejemplo que me ayudó a entender este concepto:

Imagina un elevador en un edificio. Cada piso tiene un número: 0, 1, 2, 3... y en cada piso hay exactamente una oficina con información. Cuando presionas el botón del piso 42, el elevador no necesita detenerse en cada piso antes. No importa si es el piso 1 o el 99, el tiempo de llegada es prácticamente el mismo. Así funciona la RAM: cada posición de memoria tiene una dirección numérica y tu computadora accede a cualquiera de forma instantánea, sin recorrer las anteriores.

¿Qué es un array?

Ahora imagina que una empresa renta 5 pisos consecutivos para sus 5 departamentos, todos del mismo tamaño. Eso es un array: una secuencia de datos del mismo tipo, almacenados en posiciones contiguas de memoria. Si sabes en qué piso empieza la empresa y cuánto ocupa cada departamento, puedes llegar a cualquiera de ellos con el elevador sin recorrer los demás.

La contigüidad importa porque, como vimos en la analogía, podemos acceder de manera directa a cualquier elemento sin necesidad de recorrer los anteriores. Tu computadora calcula la dirección exacta del elemento que necesitas y va directo.

En un momento vamos a ver cómo lucen los arrays en código. Por ahora, quédate conmigo para hablar de los tipos de arrays que existen.

Arrays estáticos

Los arrays en su forma original son un bloque de memoria contigua con un tamaño fijo. No pueden crecer ni reducirse después de creados. Este tipo de arrays lo vemos en lenguajes como C, donde tú tienes que decirle explícitamente al lenguaje cuántos espacios debe reservarte en la memoria.

Volviendo a la analogía: la empresa rentó exactamente 5 pisos. Si después necesita un sexto, no hay forma de crecer en el mismo lugar.

Ventajas: predecible en memoria, sin costo adicional de redimensionamiento.
Limitaciones: Si necesitas más espacio, no puedes agregarlo.

Este es un ejemplo de cómo se ve un array estático en C:

int my_array[10] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

Aquí le estamos diciendo a C: "Reserva espacio para exactamente 10 números enteros". Ni más ni menos.

Arrays dinámicos

Los arrays dinámicos resuelven la limitación principal de los estáticos: no necesitas saber de antemano cuántos elementos vas a almacenar. Crecen conforme vas insertando elementos.

¿Cómo funciona esto por debajo? Cuando el array se llena, el lenguaje crea uno nuevo más grande en otra parte de la memoria y copia todos los elementos. Siguiendo la analogía: cuando la empresa necesita más pisos, se muda a un edificio más grande y lleva todo consigo.

Ventajas: flexibilidad, no necesitas definir un tamaño desde el inicio.
Desventajas: la cantidad de memoria no es predecible y la "mudanza" tiene un costo.

En lenguajes como JavaScript y Python, los arrays dinámicos vienen integrados por defecto:

const array = [1, 2, 3, 4, 5];

array = [1, 2, 3, 4, 5]

En JavaScript no necesitas preocuparte por declarar el tamaño. El lenguaje se encarga de todo por debajo.

Estáticos vs. Dinámicos

Ahora que conoces ambos tipos, aquí va una comparación directa:

Característica	Array estático	Array dinámico
Tamaño	Fijo, definido al crear	Crece automáticamente
Flexibilidad	Baja	Alta
Uso de memoria	Predecible	Variable
Costo de inserción	No aplica (tamaño fijo)	O(1) amortizado, O(n) al crecer
Lenguajes comunes	C, C++	JavaScript, Python, Java (ArrayList)

En la práctica, la mayoría de lenguajes modernos usan arrays dinámicos por defecto. Pero entender los estáticos te da una mejor perspectiva de lo que sucede por debajo.

Operaciones comunes

Vamos a platicar sobre lo que puedes hacer con los arrays. Todos los ejemplos están en JavaScript.

Acceso por índice

El acceso por índice nos permite seleccionar un elemento a partir de su posición. Como en el elevador: tú sabes directamente a qué piso vas.

Los arrays tienen una forma particular de numerar sus elementos. Se empieza a contar a partir del 0.

const array = ["🥸", "☺️", "👻", "🐆", "👾", "🐶"];
array[0]; // nos devuelve "🥸"
array[1]; // nos devuelve "☺️"
array[5]; // nos devuelve "🐶"

Insertar al final

Podemos insertar elementos al final del array utilizando el método push().

const array = ["🥸", "☺️", "👻", "🐆", "👾", "🐶"];
array.push("👏🏻");
// resultado: ["🥸", "☺️", "👻", "🐆", "👾", "🐶", "👏🏻"]

Eliminar el último elemento

Podemos eliminar el último elemento del array con pop(). Este método además te devuelve el elemento que eliminó.

const array = ["🥸", "☺️", "👻", "🐆", "👾", "🐶"];
const eliminado = array.pop();
console.log(eliminado); // "🐶"
// resultado: ["🥸", "☺️", "👻", "🐆", "👾"]

Obtener longitud

Podemos obtener la longitud de nuestro array con la propiedad length. Esto nos dice cuántos elementos contiene.

const array = ["🥸", "☺️", "👻", "🐆", "👾", "🐶"];
console.log(array.length); // 6

Recorrer los elementos

Algo muy utilizado en los programas es recorrer un array, ya sea para mostrar qué elementos hay dentro o para buscar algún elemento. En JavaScript puedes hacer este recorrido con for, forEach o map.

const array = ["🥸", "☺️", "👻", "🐆", "👾", "🐶"];

for (let i = 0; i < array.length; i++) {
  console.log(array[i]);
}

Si te das cuenta, aquí acabamos de utilizar lo que aprendimos en los conceptos anteriores. Usamos el acceso por índice con array[i]. El for nos ayuda a repetir algo muchas veces y en nuestro ejemplo, vamos aumentando el valor del índice para ir de izquierda a derecha. Y también usamos .length para saber cuántos elementos tiene el array.

Modificar el inicio del array

Podemos hacer modificaciones al inicio del array o en el medio. El detalle es que estas operaciones requieren pasos adicionales. Déjame explicarte.

Cuando tienes un array, hablamos de posiciones contiguas en memoria.

Si insertamos un elemento al inicio, necesitamos desplazar todos los elementos una posición a la derecha para hacer espacio. Primero se mueven los elementos y luego se inserta el nuevo.

Y al contrario, si eliminamos un elemento del inicio, tenemos que mover todos los elementos que le seguían una posición hacia la izquierda para llenar el hueco.

Esto hace que sea más costoso que insertar o eliminar al final. En JavaScript podemos hacer estas operaciones con unshift() para insertar al inicio y shift() para eliminar del inicio.

const array = ["☺️", "👻", "🐆"];

// Insertar al inicio
array.unshift("🥸");
// resultado: ["🥸", "☺️", "👻", "🐆"]

// Eliminar del inicio
array.shift();
// resultado: ["☺️", "👻", "🐆"]

Costo de las operaciones

Pero no todo es miel sobre hojuelas. Como vimos, es muy fácil trabajar con los arrays pero las operaciones tienen un costo. El costo de las operaciones nos lo indica Big O, una notación matemática que nos ayuda a conocer cuánto tarda una operación a medida que el array crece. Nos ayuda a identificar la mejor estructura de datos para lo que necesitamos.

En esta tabla te dejo el costo de las operaciones que vimos:

Operación	Complejidad
Acceso por índice	O(1)
Buscar un elemento	O(n)
Insertar al final	O(1)*
Insertar al inicio	O(n)
Eliminar al final	O(1)
Eliminar al inicio	O(n)

* Amortizado. Ocasionalmente O(n) cuando el array dinámico necesita crecer.

Las operaciones O(1) indican que toman tiempo constante. No importa cuántos elementos haya en el array, el tiempo va a ser el mismo. Por eso acceder por índice es tan rápido: tu computadora calcula la dirección exacta y va directo, como el elevador.

Las operaciones O(n) quieren decir que toman un tiempo lineal: entre más elementos haya, más tiempo tarda. Por eso insertar al inicio es costoso: hay que mover todos los elementos una posición.

Si quieres saber más sobre Big O y complejidad algorítmica, dime en los comentarios y preparo un artículo dedicado.

Construye tu propia implementación de un array

Vamos a construir tu propia implementación de un array. Para este ejercicio debemos asumir que no tenemos los métodos especiales que vimos anteriormente. Vamos a utilizar el acceso por índices para todo.

Implementaremos los métodos: get(index), push(item), pop() y delete(index).

El objetivo es que entiendas qué pasa por debajo cuando usas un array y los métodos que los lenguajes de alto nivel nos proporcionan.

class MyArray {
  constructor() {
    this.length = 0;
    this.data = {};
  }

  get(index) {
    if (index < 0 || index >= this.length) {
      throw new Error("Índice inválido");
    }
    return this.data[index];
  }

  push(item) {
    this.data[this.length] = item;
    this.length++;
    return this.length;
  }

  pop() {
    if (this.length === 0) {
      throw new Error("El array está vacío");
    }
    const lastItem = this.data[this.length - 1];
    delete this.data[this.length - 1];
    this.length--;
    return lastItem;
  }

  delete(index) {
    if (index < 0 || index >= this.length) {
      throw new Error("Índice inválido");
    }
    const item = this.data[index];
    this._shiftItems(index);
    return item;
  }

  _shiftItems(index) {
    for (let i = index; i < this.length - 1; i++) {
      this.data[i] = this.data[i + 1];
    }
    delete this.data[this.length - 1];
    this.length--;
  }
}

Probemos nuestra implementación:

const miArray = new MyArray();
miArray.push("🥸");
miArray.push("☺️");
miArray.push("👻");
miArray.push("🐆");

console.log(miArray.get(0)); // "🥸"
console.log(miArray.get(2)); // "👻"
console.log(miArray.pop()); // "🐆"
miArray.delete(1);
console.log(miArray.get(1)); // "👻"

Este código puedes probarlo en RunJS o de una forma visual en PythonTutor que tiene soporte para JavaScript y te muestra el paso a paso.

Fíjate en el método _shiftItems: ahí puedes ver exactamente por qué eliminar un elemento del inicio o del medio es O(n). Tenemos que recorrer todos los elementos que están después del índice eliminado y moverlos una posición.

Te reto a que implementes el método unshift(item) para agregar elementos al inicio. Comparte tu solución en los comentarios. 💪

Conclusión

Entender los arrays al principio puede ser intimidante. Recuerdo que yo no entendía cómo recorrer un array con for, pero con la práctica puedes dominarlo.

Vimos cómo funciona la memoria RAM con la analogía del elevador, los arrays estáticos y los arrays dinámicos. Recuerda que los arrays dinámicos vienen en los lenguajes de alto nivel como Python o JavaScript, así que no debes preocuparte por declarar los elementos que necesitas de antemano. Pero aun así es bueno tener el entendimiento de lo que sucede por debajo. Eso nos da un mayor panorama.

En el siguiente artículo vamos a cubrir strings como estructura de datos. Y después de eso, vamos a ver patrones de entrevista con arrays y strings.

Espero que el artículo te sirva. Coméntame si te gustaría que aborde algún tema con mayor profundidad. Gracias por leer. 🙌🏻

Cómo construí un videojuego usando Kiro

Axel Espinosa — Sat, 14 Mar 2026 02:00:17 +0000

Quería hacer un videojuego, pero no sabía por dónde empezar. No tenía experiencia en desarrollo de juegos y tampoco estaba familiarizado con los conceptos necesarios. Usé Kiro y terminé construyendo un clon del dinosaurio de Chrome con un cavernícola huyendo de un T-Rex.

En este artículo te cuento cómo lo hice: los problemas que aparecieron, cómo los resolví y los prompts que usé por si quieres replicarlo.

Vibecoding

¿Cómo construyes un juego sin saber hacer juegos? Con vibecoding.

El vibecoding es una forma de prototipar y darle vida a tus ideas sin seguir una metodología formal. Tú describes lo que quieres y la IA lo construye. No es para producción, pero funciona perfecto para algo que quieres probar rápido.

El juego lo creé con Kiro, un editor que convierte tus ideas en código. Mi rol fue simple: supervisar que los resultados me gustaran. Yo dirigía; Kiro ejecutaba.

La idea

Quería construir una versión del clásico dinosaurio de Chrome. Pero en vez de un dinosaurio saltando cactus, quería un cavernícola huyendo de un T-Rex. Algo con personalidad propia.

La mecánica:

Un cavernícola corre de izquierda a derecha
Un T-Rex lo persigue desde atrás
Aparecen obstáculos: cactus que hay que saltar, pterodáctilos que hay que esquivar agachándose
Cada colisión atrasa al cavernícola y el dinosaurio se acerca
Si el dinosaurio te alcanza, game over 💀

Conceptos rápidos

Antes de contarte el proceso, quiero repasar tres conceptos para que tengas contexto de lo que hace el código por debajo. Si ya los conoces, salta directo a "El proceso".

POO (Programación Orientada a Objetos)

¿Recuerdas esa clase donde veías diagramas UML y hablaban de herencia (lamentablemente no monetaria)? Pues ese paradigma finalmente se usa en algo divertido.

En los videojuegos, la POO es clave porque cada elemento del juego (el cavernícola, el dinosaurio, los obstáculos) es un objeto con su propio estado y comportamiento. Eso facilita mucho el modelo mental cuando tienes decenas de cosas moviéndose en pantalla. Si quieres un repaso completo, aquí tienes.

Por si no recuerdas, una clase se ve así:

class Game {
  constructor(props) {
    this.name = "dino-chase";
  }
}

FPS (Frames Per Second)

Concepto sencillo pero poco entendido. Los FPS son el número de imágenes que tu computadora logra mostrar en un segundo.

Imagina un cuaderno donde dibujas en cada hoja una secuencia de una persona moviéndose. Cuando pasas las hojas rápido, el dibujo parece cobrar vida. Eso son los FPS.

Lo más común es 30, 60 y 120 FPS. Cuantos más FPS, más fluidos se sienten los movimientos. Y eso depende mucho del hardware donde se ejecuta el juego.

Game Loop

El game loop es el corazón de cualquier videojuego. Es un bucle que se repite continuamente y hace tres cosas:

Recibe los eventos del usuario (presionar una tecla, mover el mouse)
Actualiza el estado interno de los personajes y el mapa (por eso necesitamos POO)
Redibuja la pantalla con las nuevas posiciones, vidas, puntajes, etc.

Este ciclo se repite hasta que el juego termina.

El proceso

Aquí es donde se pone interesante. El juego no salió bien a la primera. Ni a la segunda. Fueron varias iteraciones, cada una resolviendo algo que solo descubrí jugando.

Si quieres replicar lo que hice, puedes usar Kiro. En este tutorial aprendes a instalar Kiro y, si te registras, obtienes créditos gratis para poder replicar lo que hice. No te vas a gastar ni la mitad de créditos haciendo este juego.

0. Preparar el proyecto

Antes del primer prompt necesitas un proyecto de Vite y unos sonidos. Abre tu terminal y corre esto:

pnpm create vite@latest game-with-kiro -- --template vanilla
cd game-with-kiro
pnpm install

Después crea la carpeta public/game-assets/audio/ y agrega 3 archivos .wav. El juego los va a usar para reproducir efectos de sonido cuando el cavernícola salte, choque con un obstáculo o agarre un power-up:

jump.wav para el sonido de salto
hitHurt.wav para cuando te golpeas con algo
powerUp.wav para futuros power-ups

Los sonidos los puedes encontrar en mi repositorio. O puedes generar los tuyos en sfxr.me en 2 minutos. Es importante que los tengas listos antes de empezar porque en el primer prompt le vamos a decir a Kiro que los use.

Con eso listo, ya puedes empezar con los prompts.

1. El prompt inicial

Este fue el prompt más importante. Le expliqué a Kiro exactamente qué quería construir:

Quiero crear un videojuego en el navegador. El juego se trata de un clon del juego que tiene Chrome cuando te quedas sin internet.

Quiero hacer mi versión inspirada en ese juego. Quiero que el dinosaurio persiga a un cavernícola y que con cada obstáculo que no logre esquivar, el cavernícola se retrase por milisegundos para que al dinosaurio le dé tiempo de atraparlo.

Conforme vayas avanzando los obstáculos deben acercarse a ti más rápido pero siempre permitiéndole al jugador esquivarlos.

El diseño del juego es pixel art minimalista, usando solo tonos de gris. El juego usa la tecla espaciadora o las flechas del teclado.
Los obstáculos son infinitos: cactus en el suelo y pterodáctilos volando donde el cavernícola tenga que agacharse o saltarlos.

Consideraciones:
- Utiliza los sonidos que tengo en la carpeta public/game-assets/audio/
- Todo el trabajo debe ser hecho en la carpeta src/
- Utilizamos Vite
- Utilizamos pnpm
- Los sprites deben ser dibujados con canvas no usar imágenes externas

Kiro creó todo el proyecto. Corrí pnpm dev, abrí http://localhost:5173 y ya había algo funcionando.

¿Pero fue suficiente? No del todo.

2. Simplificar el fondo

El primer problema que encontré: el fondo tenía demasiados elementos. Volcanes, gradientes, parallax. Se veía laggeado y no se sentía como el juego original.

El fondo se ve laggeado con cada actualización. Mantenlo minimalista como el juego original de Chrome: fondo gris claro sólido, nubes simples, una línea de suelo. Sin volcanes ni parallax complejo.

3. Los obstáculos tardaban mucho en aparecer

El juego se sentía aburrido. Pasaban segundos sin que apareciera nada.

Necesito que los obstáculos no tarden tanto en aparecer. Que a veces haya que saltar obstáculos seguidos o agacharse para que sea un poco más difícil.

Con eso ya se sentía como un juego de verdad.

4. Obstáculos imposibles de esquivar

A veces aparecían dos obstáculos encimados, o uno aparecía justo cuando estaba cayendo de un salto. Imposible esquivarlos.

Tenemos un bug: cuando el cavernícola salta, a veces aparece un obstáculo tan cerca que ya no me permite saltar de nuevo y me cuenta como un golpe. Además dos obstáculos aparecen al mismo tiempo. Necesito que eso se arregle.

Kiro cambió el sistema de spawn para usar distancia mínima entre obstáculos en vez de tiempo. Mucho mejor.

Pero algo seguía sintiéndose raro. 🤔

5. Mejorar la respuesta de los controles

Este fue un momento clave. Presionaba saltar en el momento correcto, pero el juego no respondía porque el cavernícola todavía estaba en el aire del salto anterior.

Implementa un input buffer porque cuando aparecen combos parece que no logra saltar los obstáculos aunque yo le aplaste la tecla en el tiempo adecuado.

Kiro implementó dos técnicas clásicas de platformers:

Input Buffer (150ms): Si presionas saltar mientras estás en el aire, el juego recuerda ese input y salta automáticamente cuando aterrices.
Coyote Time (80ms): Tienes una ventana pequeña para saltar incluso después de empezar a caer.

Esto hizo que el juego se sintiera responsivo. Los combos de obstáculos ahora sí se podían esquivar.

Perfecto. La mecánica básica ya funcionaba. Pero faltaba algo para competir con amigos.

6. El contador y high score

Sin puntaje no hay competencia.

Implementa el counter del juego con high score guardado en localStorage. El formato debe ser de 5 dígitos como el juego original de Chrome.

Ahora sí podía retar a mis amigos.

7. El efecto dominó

Este fue el bug más difícil. Me tomó varias iteraciones resolverlo.

El problema era un ciclo vicioso:

Chocas con un obstáculo → el cavernícola se atrasa
Al atrasarte, el siguiente obstáculo ya está encima tuyo
Chocas de nuevo → te atrasas más
Se repite hasta game over

Era injugable. Le pedí esto a Kiro:

Si choco varias veces es imposible sortear los objetos siguientes porque queda muy cerca de ellos. Necesito que al colisionar se limpien los obstáculos cercanos y haya un periodo de inmunidad para recuperarse.

La solución combinó varias técnicas:

Inmunidad de 500ms después de cada colisión
Limpieza de obstáculos en un radio de 250px al colisionar
Recuperación de posición más rápida, proporcional a la velocidad del juego
Spawn basado en la posición del jugador, no del borde del canvas

Ahora tocaba preocuparme del dinosaurio.

8. Balancear al dinosaurio

El T-Rex alcanzaba al cavernícola demasiado rápido, incluso sin colisiones. La presión tenía que venir de mis errores, no del paso del tiempo.

El dinosaurio alcanza al cavernícola muy rápido. Haz que empiece más atrás y avance más lento. La presión debe venir de las colisiones, no del avance natural del dinosaurio.

Kiro redujo la velocidad de avance del dinosaurio de 0.2 a 0.08. Ahora la tensión viene de tus errores, no del reloj.

9. Pterodáctilos a dos alturas

Para darle más variedad, agregué pterodáctilos a diferentes alturas. Unos que hay que saltar y otros donde hay que agacharse.

Quiero que haya pterodáctilos a dos alturas: altos donde hay que agacharse y bajos donde hay que saltar. Asegúrate de que las figuras estén bien calibradas para que ambas acciones funcionen a cualquier velocidad del juego.

Estructura final del proyecto

Después de todas las iteraciones, la estructura quedó así:

├── src/
│   ├── main.js          # Entry point, pantallas inicio/game over
│   ├── game.js          # Game loop, colisiones, score, renderizado
│   ├── caveman.js       # Jugador: salto, agacharse, input buffer, inmunidad
│   ├── dinosaur.js      # Enemigo perseguidor
│   ├── obstacles.js     # Manager + CactusSmall, CactusBig, Pterodactyl
│   ├── background.js    # Nubes y decoraciones del suelo
│   ├── audio.js         # Gestión de sonidos
│   └── style.css        # Estilos de UI
├── public/game-assets/
│   └── audio/           # Archivos .wav
├── index.html
└── package.json

Lo que aprendí

No sabía hacer un videojuego. No sabía qué conceptos necesitaba ni por dónde empezar. Con ayuda de la IA logré construir algo que de otra forma me hubiera tomado semanas de investigación, y probablemente lo hubiera abandonado por frustración.

Pero aquí viene el detalle: la IA no lo hizo sola. Fueron 9 iteraciones. Cada una requirió que yo jugara, identificara problemas y supiera explicar qué estaba mal. La IA ejecuta, pero tú diriges.

Si estás estudiando programación y sientes que la IA viene a dejarte sin oportunidades, no pienses eso. Aprende a usarla. Empodérate con ella. Ahora puedes crear ideas más rápido y dedicarle tiempo a lo que realmente importa: entender los fundamentos.

Ojo, es importante que, aunque la IA escriba el código, tú seas capaz de leerlo y modificarlo cuando algo salga mal. Porque todavía no es perfecta.

Sigue aprendiendo y no le tengas miedo a la IA. Úsala como lo que es: una herramienta que amplifica lo que ya sabes y una aliada para aprender construyendo.

Si te animas a hacer tu propia versión, déjame el link a tu repositorio en los comentarios o puedes escribirme en LinkedIn si tienes alguna duda.

También te dejo el link al repositorio de mi juego 👉 Repositorio con juego

¿Qué es un encoding? Explicación sencilla: ASCII, UTF-8 y Unicode

Axel Espinosa — Thu, 19 Feb 2026 20:58:11 +0000

La forma en que nos comunicamos digitalmente ha cambiado muchísimo. Hoy nos comunicamos hasta con stickers, pero ¿alguna vez te has preguntado cómo llegamos hasta aquí?

Seguramente navegando por internet te has encontrado con textos que muestran caracteres extraños como este: M�xico
Eso tiene un nombre: Mojibake. Así se le llama al fenómeno de ver caracteres raros cuando hay un error en la codificación del texto.

En este artículo te explico a detalle qué es la codificación, con ejemplos claros y sencillos.

Encodings

El encoding (o en español, codificación) es el proceso de transformar la información de una representación a otra siguiendo reglas específicas. En este contexto, nos enfocaremos en la codificación de caracteres: cómo se representan letras, números y símbolos en formato digital.

Me imagino que has escuchado que las computadoras solamente entienden números binarios: 0 y 1. Esto es cierto, pero imagina si tuviéramos que usar únicamente esos números para comunicarnos con ellas todos los días. Por eso, los investigadores desarrollaron sistemas que nos facilitan esta comunicación.

Te muestro un ejemplo con mi nombre. Sería impráctico tener que escribirlo usando solo ceros y unos.

Son demasiados números, ¿cierto? ¿Cómo pasamos de letras a un montón de números?

Preguntas muy buenas, ser, joven Padawan

Retrocedamos un paso. Entendamos primero de dónde salieron esos números. Te presento a ASCII.

ASCII

ASCII son las siglas de American Standard Code for Information Interchange. Es un estándar que nos dice cómo deben representarse las letras como números para que las computadoras lo entiendan y nosotros también podamos entenderlo.

La primera versión de este estándar fue creada en 1963 y hasta hoy en día sigue siendo importante conocer que existe, porque es fácil de usar y los fabricantes de computadoras se encargan de que todas las PCs entiendan este formato.

Podemos encontrar la tabla ASCII que muestra cada letra del idioma inglés con un valor en decimal, hexadecimal y binario. Es por eso que pude transformar mi nombre a números binarios: porque cada letra cuenta con un valor que las computadoras pueden entender.

Te dejo los caracteres que usé:

La codificación ASCII solo nos provee de 127 caracteres, lo que equivale a 7 bits (2^7). Esto es importante porque la computadora utiliza 1 byte (8 bits) para poder almacenar un carácter, es decir, que se está desperdiciando un bit. Y precisamente de eso se dieron cuenta los investigadores, así que después decidieron extender esta tabla de caracteres a 256. Ahora un carácter podía utilizar hasta 8 bits, o lo que es igual a 1 byte completo.

Esta expansión fue clave para que otros países con idiomas y alfabetos diferentes al inglés pudieran usar la codificación sin problemas de compatibilidad.

Pero aquí viene el detalle: 256 caracteres no son suficientes cuando tienes que representar chino, árabe, cirílico y todos los demás alfabetos del mundo. Cada fabricante empezó a inventar su propia solución, y ahí es donde empezó el problema de M├®xico que viste arriba. La solución a este caos fue Unicode.

Unicode

Unicode se creó en los años 80 y se convirtió en un estándar hoy en día que define más de 1.1 millones de caracteres. Este estándar asigna a cada carácter un código que después, con ayuda de un encoding, se transforma a bits (lo que realmente la computadora entiende). Y no solamente se trata de letras: los emojis también están dentro de Unicode y por eso podemos utilizarlos en cualquier idioma.

La idea principal de Unicode es evitar que cada fabricante de hardware cree su propio encoding incompatible con los demás. Así, un fabricante en Europa que usa caracteres distintos al inglés puede compartir información con alguien en Asia o en América, evitando el caos de M├®xico que vimos antes.

Los códigos Unicode están definidos con un formato hexadecimal y se ven así:

Si ves esto y no sabes qué es hexadecimal, te dejo un link a un artículo: https://en.wikipedia.org/wiki/Hexadecimal

Listo. Ya conocemos Unicode y por qué es importante, pero esto solo nos da una pequeña porción del panorama completo. Recuerda que la computadora solo entiende bits, entonces, ¿cómo pasamos de estos códigos hexadecimales a bits? Aquí es donde entra UTF-8 🙌🏻

UTF-8 👾

UTF-8 es un encoding creado por el consorcio Unicode (los mismos que crearon el estándar Unicode) y se encarga de transformar los códigos hexadecimales a bits que la computadora pueda entender.

Algo muy inteligente de UTF-8 es que fue diseñado desde el inicio para ser compatible con ASCII. Los primeros 128 códigos tienen una traducción idéntica, es decir, se conservan los códigos ASCII. Por ejemplo, la letra A en ASCII es 65 (en decimal) y en UTF-8 también es 65.

Esto permitió que programas que ya usaban ASCII funcionaran automáticamente con UTF-8, lo que mejoró la adopción y ahora UTF-8 sea el encoding más popular en la web.

UTF-8 utiliza una transformación dinámica a bits: caracteres simples ocupan solo 1 byte, mientras que caracteres más complejos —con múltiples formas, diacríticos, etc.— pueden ocupar hasta 4 bytes.

Por ejemplo, este emoji 👾 ocupa 4 bytes completos, mientras que la letra A solo necesita 1 byte:

Charset y Encoding

Perfecto. Ya sabes cómo funcionan ASCII, Unicode y UTF-8. Pero hay una distinción importante que te ayudará a entender todo el panorama: charset vs encoding.

Cuando trabajas con bases de datos o creas un documento HTML, seguro has visto una etiqueta o configuración llamada charset. Esto se refiere al catálogo de caracteres que puedes usar en ese documento y que se mostrarán correctamente en pantalla. Es decir, qué caracteres están “permitidos” o “disponibles”.

El encoding, por otro lado, es la forma en que esos caracteres se transforman a bits para ser almacenados o transmitidos.

¿Por qué importa?

Si no trabajas con el mismo charset en documentos compartidos, terminas con el problema que vimos antes: caracteres rotos, símbolos raros y texto ilegible.

Ejemplo práctico

Imagina que creas un archivo de texto con este contenido:

México

Creamos el archivo en nuestra computadora y verificamos su encoding con el comando file:

~ echo "México" > test.txt
~ file -I test.txt
test.txt: text/plain; charset=utf-8

Perfecto, está en UTF-8. Ahora intentemos convertirlo a un encoding que no soporte acentos, como ISO-8859-10 (diseñado para idiomas nórdicos: sueco, noruego, danés).

Usamos la herramienta iconv para transformar el encoding:

~ iconv -f UTF-8 -t ISO-8859-10 test.txt > converted.txt

~ cat converted.txt
M�xico

¿Qué pasó? 😳 El archivo ahora contiene caracteres raros donde debería estar la “é”. La terminal no puede mostrarlo bien, pero un editor de texto sí revela el problema:

Nuestro archivo original estaba en UTF-8, donde la “é” tiene un código específico. Al convertirlo en ISO-8859-10, iconv intentó encontrar un equivalente... pero no es lo mismo, por eso se ve raro.

Ahora, si intentamos convertirlo a ASCII (que en teoría es compatible con UTF-8), vemos que directamente no puede manejar el acento porque en el charset ASCII no existen letras con acento como sí existen en Unicode:

~ iconv -f UTF-8 -t ASCII -c  test.txt > converted.txt
iconv: warning: invalid characters: 1
~ cat converted.txt
Mxico

Incluso si abres el editor, verás que no se logró transformar la segunda letra:

La letra “é” simplemente desapareció. Para verificar que el nuevo archivo tiene otro encoding, ejecutamos:

~ file -I converted.txt
converted.txt: text/plain; charset=us-ascii

Ahí está: ahora es us-ascii.

Ejemplo en programación

Listo. Ya entendemos la diferencia entre charset y encoding. ¿Pero cómo nos ayuda esto al programar?
Imagina este problema:

"Valida si una cadena de texto contiene únicamente caracteres A-Z y dígitos 0-9"

Para resolverlo, vamos a asumir que la cadena de texto es pequeña y trabajaremos con los códigos ASCII:

function containsOnlyLettersAndNumbers(s) {
    for (let i = 0; i < s.length; i++) {
        let char = s.charCodeAt(i);
        console.log(`Evaluating s[${i}]= ${s[i]} charcode=${char}`);

        if (char < 48 || char > 122) return false;
        if (char > 57 && char < 65) return false;
        if (char > 90 && char < 97) return false;
    }
    return true;
}

console.log(containsOnlyLettersAndNumbers("AUDID3222")) // TRUE
console.log(containsOnlyLettersAndNumbers("D444E##RUURUJ")) // FALSE
console.log(containsOnlyLettersAndNumbers("asbueu3$")) // FALSE
console.log(containsOnlyLettersAndNumbers("asbueu3")) // TRUE

Este código puedes probarlo con herramientas como RunJS o de una forma visual con un editor que te muestra el paso a paso que tiene soporte para Javascript: PythonTutor

Conclusión

Y así llegamos al final. En este artículo vimos cómo funcionan los encodings, por qué un emoji puede ocupar 4 bytes y ejemplos prácticos de transformaciones entre charsets.

Reacciona:
❤️ Sí, ya lo conocías
🔥 Si te sorprendió algo
💬 Y cuéntame qué fue lo que más te llamó la atención

Si crees que me faltó algo importante, déjamelo en los comentarios. Te estaré leyendo. 👇

Write better unit tests

Axel Espinosa — Wed, 28 May 2025 18:31:11 +0000

Hello, welcome to a new post!

Today I want to talk about a very important topic that should never be missing in serious software development: unit tests.

Unit tests are code we write to validate the logic of our program. These tests are characterized by evaluating small parts of the code, such as a function or a class.

Additionally, unit tests are very useful when refactoring code in the future, as they help ensure that what previously worked correctly continues to do so.

And really, I think we've all worked on a project where the team is afraid to change certain parts of the code, because we don't know if the changes will affect previously implemented business rules, causing strange behavior and those dreaded bugs.

The goal of these tests is to give you confidence in what you write and help you deliver as few bugs as possible. However, sometimes projects already have unit tests—maybe even an extensive suite—but simply having them doesn't guarantee you're covered. This happens when tests are outdated or have just been patched with each change, written only to make them pass and keep the CI process quiet, allowing work to continue without interruption.

This is a clear symptom that your unit tests have become a burden, and the whole team sees them that way. Writing tests becomes a tedious task with no reward. And in these cases, it's true: the tests just slow down development.

We can avoid this situation by changing our perspective: unit tests are a part of the system and must be treated with the same care as the main codebase.

Just because they don’t run in production doesn’t mean they should be forgotten after being written once. They must be maintained attentively, updated consciously—not just to keep the report green. For example, if you delete a method or class, you should remove the related tests. If a business rule changes, it's normal for tests to fail at first—but they must be updated to reflect the new logic. Don’t hide the real problem with hacks to make the test pass, and definitely don’t comment it out or delete it.

Since unit tests are so important, here are some tips I've learned that can help you improve them and feel more confident in your code.

Disclaimer: Unit tests alone don’t cover the whole system. It’s important to complement them with other types of tests like E2E, manual QA tests (if you have a QA team), and more. Still, unit tests are our first line of defense when making changes.

Tips

Tools
How to name your subject under test
Write a clear message for your test
How to avoid test fragility
What are mocks and when to use them
How much code coverage should I aim for?

Tools

In these examples, I'll use JavaScript, but the concepts are language-agnostic. JavaScript is just a tool to communicate the ideas.

JavaScript has popular libraries you can use to create tests. But first, it’s important to understand the difference between a Test Runner and an Assertion Library.

A Test Runner provides the infrastructure to execute tests in isolation (sometimes even in parallel), along with debugging utilities and more. Examples include:

Jest
Mocha

Assertion Libraries may be included with the test runner (as with Jest) or installed separately. Examples include:

Chai
Assert Module (built-in with Node.js ≥ v18)

These tools give you functions to validate whatever you need: an object’s content, a date, a string, etc.

Here’s an example:

const assert = require('node:assert/strict');

assert.deepEqual([[[1, 2, 3]], 4, 5], [[[1, 2, '3']], 4, 5]);
// AssertionError: Expected inputs to be strictly deep-equal:
// + actual - expected ...
// +     3
// -     '3'
// Example from Nodejs Docs https://nodejs.org/docs/latest-v22.x/api/assert.html#assert

In this example, we expect both arrays to have the same elements.

You might ask, "Do I really need these libraries if I can do it manually?" And the answer is: yes and no. You could write your own validation methods, or you could save time by using a library that works out of the box.

To get started, you’ll need to know how to configure these tools. It’s not difficult—the documentation is usually more than enough. Personally, I use Jest in my projects because it comes by default with NestJS, and it includes an assertion library.

How to Name Your Subject Under Test

The subject under test is often referred to as the SUT (System Under Test). I liked this naming convention when I read about it in the book Unit Testing, and I’ve adopted it ever since. It makes it clear what component is being tested and avoids confusion with other variables in the test.

Of course, this is just a personal preference. You’re free to name it however you like, but always try to make it obvious which part of the system you’re testing.

// sum.js
class Calculator {
  sum(x, y) {
    return x + y;
  }
}

// sum.spec.js
describe('Calculator', () => {
  let SUT; // System Under Test

  beforeEach(() => {
    SUT = new Calculator();
  });

  afterEach(() => {});
});

Write a Clear Message for Your Test

class EmailSender {
  send(to, content) {
    // validations
    this.provider.send(to, content);
  }
}

describe('EmailSender', () => {
  let SUT;

  beforeEach(() => {
    SUT = new EmailSender();
  });

  afterEach(() => {});

  // ❌ Not descriptive
  it('test method send()', () => {});

  // ✅ Clear descriptions
  it('send(): fails with invalid email', () => {});
  it('send(): fails with invalid content', () => {});
});

In the example above, we see that we can name our tests however we want, but in the end, we’re the ones affected by poorly described messages—either us or our teammates.

Imagine someone new joins the project, changes the EmailSender class, and a test fails. The only message shown is: test method send(). You’d pull your hair out trying to understand what it does and how to fix it.

On the other hand, if tests are clearly described—as in the later examples—you quickly get an idea of what might have failed, making the debugging experience much more pleasant.

How to Avoid Fragility in Your Tests

There’s an approach that can greatly improve your tests and help avoid fragility, false positives, and difficulties when refactoring.

Often, writing tests reveals how well we’ve applied best practices. This is because when we test our code, we should aim to isolate that unit as much as possible from the rest of the system.

What this means is: if your function or class relies on external resources like APIs or other classes—and you depend on concrete implementations instead of abstractions—you’re introducing fragility. Any updates to those dependencies might cause your tests to fail for reasons unrelated to the logic you’re actually testing. These false positives, if not addressed, make tests unsustainable.

If you depend on abstractions instead, testing a component with dependencies becomes much simpler. You can replace those dependencies easily and focus on what really matters: your business rules, algorithms, and logic.

// BAD: Depends on a concrete class
class EmailSender {
  constructor() {
    this.provider = new SNSAWSService(); // concrete class dependency
  }

  send(to, content) {
    // validations
    this.SNSServiceAws.send(to, content);
  }
}

// GOOD: Uses dependency inversion, easier to test
class EmailSender {
  constructor(provider) {
    this.provider = provider; // abstraction
  }

  send(to, content) {
    // validations
    this.provider.send(to, content);
  }
}

We can solve this by using dependency injection and applying the SOLID principle of Dependency Inversion, which tells us to depend on abstractions—in this case, an interface.

Another thing that helped me a lot is shifting my perspective: I now focus on testing what I want the code to do, the outcome, instead of worrying about how it’s done.

This change makes a big difference. It allows you to ignore implementation details (like exact algorithm steps) and focus on verifying that the desired result is correct. When you reflect that in your tests, you achieve greater robustness and resilience to change.

✅ Don’t waste time testing implementation details that may change. Your goal is to ensure the system behaves as expected from a functional perspective. This leads to more stable and meaningful tests in the long term.

What Are Mocks and When to Use Them?

Mocks are, colloquially, functions or classes that replace real dependencies in our tests. Their purpose is to help isolate the code and prevent the use of real services.

Imagine you need to send an email, an SMS, etc. A good practice would be to avoid using the real services for several reasons: cost, accidentally notifying real users, and because it’s much easier to replace them to have full control over what happens in your code.

Without mocks, tests would be too unpredictable, since they would depend on external components.

Jest provides built-in methods to create mocks and spies.

The difference between them is that spies allow you to track calls made to the mock—you can check what arguments were passed, how many times it was called, in what order, and so on.

One Important Note Before the Example:

You don’t always need to make assertions on your mocks.

This is because, in many cases, it's not relevant to the logic you're testing. Also, making unnecessary assertions can introduce fragility into your tests, since mocks simulate external dependencies that may change over time.

However, it does make sense to assert on mocks when they are relevant to business rules.

For example: if your application must send an email when a user is created, it's important to verify that the email service was called—and with the correct data.

This helps you confirm that your code is truly executing the key actions that matter to your business.

Now, let’s look at an example:

// notification.test.js
import * as emailService from './emailService.js';
import { notifyNewUser } from './notification.js';

beforeEach(() => {
  // Restore original behavior
  spy.mockRestore();
});

it('notifyNewUser: sends a welcome email', async () => {
  // Spy on sendEmail and prevent real call
  const spy = jest
    .spyOn(emailService, 'sendEmail')
    .mockResolvedValue('spy-ok');

  const user   = { email: 'u@e.com', name: 'Axel' };
  const SUT = await notifyNewUser(user);

  // Verify parameters and return value
  expect(spy).toHaveBeenCalledWith(
    'u@e.com',
    'Welcome!',
    'Hi Axel, thanks for joining.'
  );

  expect(result).toBe('spy-ok');
});

Code Coverage

Lastly, when it comes to code coverage, I believe having a test suite that covers around 80% of your code is a very good goal.

But we must keep in mind that setting a number shouldn't distract us from what truly matters: taking care of the quality of our tests.

It's not about hitting or exceeding a specific percentage—it's about writing meaningful tests. And as a natural consequence of doing so, you'll likely hit that coverage mark anyway, or get very close to it.

It’s also important to listen to the team, understand their perspective, and find a way for everyone to feel comfortable. Because when a strict percentage is enforced, the team may focus solely on reaching it, writing tests that add little to no value.

Conclusion

If you’ve made it this far, I hope you’ve taken something useful that you can start applying right away.

Writing good unit tests takes practice and consistency.

Personally, I’m still learning how to improve my own tests, but applying the principles I shared here has definitely helped me improve the quality of my code and avoid many false positives.

If you have any feedback or want to connect, feel free to reach out on LinkedIn, X (Twitter) as @im_not_ajscoder or in the comments 🙌🏻

Mejora tus pruebas unitarias 10x

Axel Espinosa — Tue, 27 May 2025 22:20:06 +0000

Hola, bienvenido a un nuevo post!

Hoy quiero hablar de un tema muy importante, que no puede faltar en un desarrollo serio de software: las pruebas unitarias.

Las pruebas unitarias son código que escribimos para validar la lógica de nuestro programa. Estas pruebas se caracterizan por evaluar partes pequeñas del código, como una función o una clase.

Además, las pruebas unitarias son muy útiles para realizar refactorizaciones a futuro sin temor a que, durante este proceso, deje de funcionar lo que ya teníamos correctamente.

Y es que, en realidad, creo que todos hemos trabajado en algún proyecto donde el equipo tiene miedo de modificar ciertas partes del código, porque no sabemos si lo que vamos a cambiar afectará reglas de negocio ya implementadas, provocando comportamientos extraños y los temidos bugs.

El objetivo de estas pruebas es que tengas confianza en lo que escribes y que entregues la menor cantidad posible de errores. Sin embargo, a veces los proyectos ya cuentan con pruebas unitarias, e incluso con una suite extensa, pero el simple hecho de tenerlas no garantiza que estés cubierto. Esto sucede porque las pruebas están desactualizadas o solo se han ido “parcheando” con cada cambio, buscando que pasen sin fallar y que el proceso de CI no se queje, lo que permite seguir con el flujo de trabajo sin más.

Esto es un claro síntoma de que tus pruebas unitarias se han convertido en una carga, y todo el equipo las percibe de esa manera. Hacer pruebas se ve como una tarea ardua sin recompensa. Y en estos casos, es cierto: las pruebas solo ralentizan el desarrollo.

Podemos evitar esta situación cambiando nuestra perspectiva: las pruebas unitarias son una parte más del sistema y deben recibir el mismo cuidado que el código principal.

El hecho de que no se ejecuten en producción no significa que deban quedar olvidadas después de haberlas escrito una vez. Deben mantenerse con atención, actualizarse de forma consciente y no solo para que el reporte salga “en verde”. Por ejemplo, si eliminamos un método o clase, hay que eliminar las pruebas relacionadas; si cambia una regla de negocio, es normal que las pruebas fallen al principio, pero debemos corregirlas según la nueva lógica. No debemos ocultar el problema real con trucos para que las pruebas pasen, o peor aún, borrarlas o comentarlas.

Y como las pruebas unitarias son importantes, aquí tengo algunos consejos que he aprendido y que pueden ayudarte a mejorarlas y a sentirte más seguro con tu código.

Disclaimer: Las pruebas unitarias por sí solas no prueban todo el sistema. Es importante complementar con otros métodos de prueba, como pruebas E2E, pruebas manuales con el equipo de QA (si cuentas con uno), entre otros. Sin embargo, las pruebas unitarias siempre serán nuestra primera red de protección ante los cambios.

Tips

Herramientas
¿Como nombrar nuestro sujeto de prueba?
Escribe un buen mensaje para tu prueba
¿Como evitar fragilidad en nuestros tests?
¿Que son los mocks y cuando usarlos?
¿Que porcentaje de cobertura debe tener mi código?

Herramientas

En estos ejemplos voy a utilizar JavaScript, pero los conceptos son agnósticos, ya que JavaScript es solo una herramienta para comunicar las ideas.

En JavaScript existen librerías populares con las que puedes crear pruebas para tu código. Sin embargo, es importante hacer una distinción entre un Test Runner y una Assertion Library.

Un Test Runner proporciona la infraestructura necesaria para ejecutar las pruebas de manera aislada, algunas incluso en paralelo. También incluye utilidades para hacer debugging, entre otras características. Algunos ejemplos son:

Jest
Mocha

Por otro lado, las librerías de assertions pueden venir integradas dentro del test runner (como ocurre con Jest) o ser externas, en cuyo caso deberás instalarlas por separado. Algunos ejemplos de estas son:

Chai
Assert Module (incluido en Node.js ≥ v18)

Estas herramientas te ofrecen un conjunto de funciones para validar lo que necesites: el contenido de un objeto, una fecha, una cadena de texto, etc.

Te dejo un ejemplo de código:

const assert = require('node:assert/strict');

assert.deepEqual([[[1, 2, 3]], 4, 5], [[[1, 2, '3']], 4, 5]);
// AssertionError: Expected inputs to be strictly deep-equal:
// + actual - expected ... Lines skipped
//
//   [
//     [
// ...
//       2,
// +     3
// -     '3'
//     ],
// ...
//     5
//   ]
/* Código tomado de la documentación de Nodejs https://nodejs.org/docs/latest-v22.x/api/assert.html#assert*/

En este ejemplo esperamos que el array de la izquierda tenga los mismos elementos que el de la derecha.

Y te preguntarás, realmente necesito estas librerías si puedo realizarlo manualmente. Y la respuesta es que si y no, podrías hacer tus propios métodos para validar inputs, etc. O ahorrar tiempo y tener algo que funciona con una librería.

Entonces, para iniciar necesitas conocer como configurar estas herramientas. No es difícil, con la documentación es más que suficiente para guiarte. Yo utilizó Jest en los proyectos que realizo porque es el que viene por defecto en NestJS y ya no tienes que instalar librerías de assertion.

¿Cómo nombrar nuestro sujeto de prueba?

Al sujeto de prueba también podemos llamarlo SUT (System Under Test). Es una forma de referirse a él que me gustó cuando leí el libro Unit Testing, y desde entonces la adopté. Me parece que así queda claro quién está siendo probado y se evita confusión con otros nombres que puedan surgir en el test.

Claro, esto es solo una preferencia personal. Tú eres libre de nombrarlo como prefieras, pero siempre trata de que sea evidente qué parte del sistema estás probando.

// sum.js
class Calculator {
    sum(x,y) {
        return x + y;
    }
}

// sum.spec.js
describe('Calculator', () => {
    let SUT // System under test

    beforeEach(() => {
        SUT = new Calculator()
    })

    afterEach(() => {})
})

Escribe un buen mensaje para tu prueba

class EmailSender {
    send(to, content) {
        // validations
        this.provider.send(to, content)
    }
}

describe('EmailSender', () => {
    let SUT // System under test

    beforeEach(() => {
        SUT = new EmailSender()
    })

    afterEach(() => {})

    // ❌ no muy descriptivo.
    it('test method send()', () => {})

    // ✅ Buena descripción
    it('send(): falla por email invalido', () => {})
    it('send(): falla por contenido invalido', () => {})
})

En el ejemplo anterior nos damos cuenta de que podemos nombrar nuestros tests de cualquier manera, pero al final, quienes terminamos afectados por mensajes con descripciones pobres somos nosotros o nuestros compañeros.

Imagina que alguien externo llega a trabajar en el proyecto y, al modificar la clase EmailSender, algo falla. Entonces aparece en la terminal un test con un mensaje como: test method send(). Yo me arrancaría el cabello tratando de entender, primero, para qué sirve ese test y, segundo, cómo arreglarlo.

En cambio, si los tests tienen una buena descripción —como en los ejemplos que siguen— te das una idea rápida de qué pudo haber fallado, y haces que la experiencia de debugging sea mucho más agradable.

¿Cómo evitar la fragilidad en nuestros tests?

Existe un enfoque que te ayudará a mejorar mucho tus pruebas y a evitar que estas sean frágiles, que aparezcan falsos positivos o que sea difícil hacer refactorizaciones.

Muchas veces, al escribir tests, nos damos cuenta de qué tan bien hemos aplicado buenas prácticas. Esto sucede porque, al probar nuestro código, debemos tratar de aislar lo más posible esa unidad de código del resto del sistema.

Con esto me refiero a que, si nuestra función o clase utiliza recursos externos como APIs u otras clases, y no dependemos de abstracciones sino de clases concretas, estaremos agregando fragilidad a las pruebas. En cualquier momento en que se actualicen esas dependencias, los tests pueden fallar por razones que no corresponden al alcance de la prueba unitaria. Esto introduce falsos positivos que, si no se abordan a tiempo, hacen que las pruebas se vuelvan insostenibles.

Cuando dependemos de abstracciones, escribir una prueba para un componente con dependencias se vuelve mucho más sencillo: podemos reemplazarlas fácilmente y enfocarnos en probar lo que realmente importa, como las reglas de negocio, la lógica o el algoritmo.

// EJEMPLO: Depende de clase concreta
class EmailSender {
    constructor() {
        this.provider = new SNSAWSService() // depende de clase concreta
    }

    send(to, content) {
        // validations
        this.SNSServiceAws.send(to, content)
    }
}

// EJEMPLO: Utiliza Principio SOLID, facil testear
class EmailSender {
    constructor(private provider: EmailProviderInterface) {}

    send(to, content) {
        // validations
        this.provider.send(to, content)
    }
}

Este detalle lo podemos resolver mediante inyección de dependencias y aplicando el principio SOLID de Inversión de Dependencias, el cual nos indica que debemos depender de abstracciones. En este caso, eso se traduce en utilizar una interfaz.

Además, algo que me ha servido mucho es cambiar la perspectiva de cómo escribo mis pruebas. Ahora me enfoco en probar lo que quiero que haga, en el resultado, y ya no me preocupo tanto por cómo tiene que hacerlo.

Existe una gran diferencia en este enfoque: al cambiar la perspectiva, dejamos de lado el detalle de la implementación —los pasos exactos del algoritmo— y nos centramos en que el resultado deseado sea correcto. Al reflejar esto en nuestras pruebas, logramos una mayor robustez y resistencia ante cambios en el código.

✅ No pierdas tiempo probando detalles de implementación que podrían cambiar con el tiempo. Tu objetivo debe ser asegurarte de que el sistema haga lo que se espera que haga desde el punto de vista funcional. Esto te permitirá mantener pruebas más estables y significativas a largo plazo.

¿Que son los mocks y cuando usarlos?

Los mocks son, de forma coloquial, funciones o clases que reemplazan las dependencias reales en nuestras pruebas. Su propósito es ayudar a aislar el código y evitar que se utilicen los servicios reales.

Imagina que necesitas enviar un correo electrónico, un SMS, etc. Una buena práctica sería no usar los servicios reales por varios motivos: costos, usuarios notificados erróneamente, y porque es mucho más sencillo reemplazarlos para tener control sobre lo que sucede con nuestro código.

Sin mocks, los tests serían demasiado impredecibles, ya que estarían dependiendo de componentes externos.

Jest cuenta con sus propios métodos para crear mocks y spies.

La diferencia entre ellos es que, con los spies, puedes hacer un seguimiento de las llamadas al mock: ver con qué datos se llamó, cuántas veces, en qué orden, etc.

Un detalle importante antes de pasar al ejemplo:

No siempre necesitas hacer asserts sobre los mocks.

Esto se debe a que, en muchos casos, no es relevante para la lógica que estás probando. Además, hacer asserts innecesarios puede introducir fragilidad en tus pruebas, ya que los mocks simulan dependencias externas que pueden cambiar con el tiempo.

Sin embargo, sí tiene sentido hacer asserts sobre los mocks cuando son relevantes para las reglas de negocio.

Por ejemplo: si tu aplicación debe enviar un correo electrónico cuando se crea un usuario, es importante verificar que el servicio de email se haya llamado, y con los datos correctos.

Esto te ayuda a confirmar que tu código realmente ejecuta las acciones clave para tu negocio.

Ahora sí, vamos con el ejemplo.

// notification.test.js
import * as emailService from './emailService.js';
import { notifyNewUser } from './notification.js';

beforeEach(() => {
  // Restauramos el comportamiento original
  spy.mockRestore();
})

it('notifyNewUser: envia un correo de bienvenida', async () => {
  // Espiamos sendEmail y evitamos la llamada real
  const spy = jest
    .spyOn(emailService, 'sendEmail')
    .mockResolvedValue('spy-ok');

  const user   = { email: 'u@e.com', name: 'Axel' };
  const result = await notifyNewUser(user);

  // Verificamos parámetros y valor de retorno
  expect(spy).toHaveBeenCalledWith(
    'u@e.com',
    '¡Bienvenido!',
    'Hola Axel, gracias por unirte.'
  );

  expect(result).toBe('spy-ok');
});

Cobertura de código

Por último, en cuanto a temas de cobertura de código, considero que tener una suite que cubra alrededor del 80 % del código es algo muy bueno.

Pero hay que tener en cuenta que, al imponer un número, no debemos olvidar lo más importante: cuidar la calidad de nuestros tests.

No se trata de apuntar a un porcentaje específico o de superarlo, sino de enfocarnos en tener buenas pruebas. Y como consecuencia de eso, de forma casi accidental, terminaremos alcanzando ese porcentaje o quedando muy cerca.

Siempre es importante escuchar al equipo, conocer su opinión y buscar una forma en la que todos se sientan cómodos. Porque puede suceder que, al imponer un porcentaje mínimo, el equipo empiece a enfocarse únicamente en cumplirlo, escribiendo pruebas que no aportan valor real.

Conclusión

Espero que, si llegaste hasta aquí, te hayas llevado algo útil que puedas poner en práctica de inmediato.

Crear buenas pruebas unitarias requiere práctica y constancia.

Yo mismo puedo decir que todavía sigo aprendiendo a mejorar las mías, pero aplicar estos puntos sin duda me ha ayudado a mejorar muchísimo la calidad de mis tests y a evitar muchos falsos positivos.

Si tienes algún comentario, con gusto podemos conectar en LinkedIn o en X (Twitter) como @im_not_ajscoder.

How to Type the '_id' Field in TypeScript with Mongoose

Axel Espinosa — Tue, 29 Apr 2025 03:13:54 +0000

Hi everyone, let me start by thanking you for reading this post.

I started this to practice my writing skills in English and to overcome my procrastination. Writing posts like this helps me gain a better understanding of things I'm learning. Let's dive into it.

I encountered an issue while writing code in typescript using the popular Mongoose library when I tried to convert the field _id to a string.

I have some example code here:

@Schema({ timestamps: true, collection: 'products' })
export class ProductModel {
  _id: mongoose.Schema.Types.ObjectId;

  @Prop({ required: true })
  name: string;

  @Prop()
  description: string;

  @Prop({ required: true })
  price: number;

  @Prop({ required: true, default: 0 })
  stock: number;
}

const product = new ProductModel(); // example of instance

product._id.toString(); // trying to convert my _id to a string

I'm using Nestjs and its Mongoose integration. Instead of writing plain schemas like we traditionally do, this library allow us to define models and their properties using Decorators (@prop) in a class, all within the same file. This class also serves as our model.

There are 2 lines I want us to focus on:

const product = new ProductModel();

product._id.toString();

Specifically to the second line where we call .toString(). It turns out that the way we declared the _id property in our class causes incorrect typing.

The library defines two types for ObjectId: the first is implemented under mongoose.Schema.Types.ObjectId , and the other is mongoose.Types.ObjectId.

The difference between these types is that they aren't interchangeable, the latter is the declaration of an object which has serializable methods like toString(), while the former doesn't.

So I'll show you the error from the typescript linter if you use the former.

Instead of writing something like this to silence the linter: (product._id as ObjectId).toString()

Try using the correct type for your class, which is mongoose.Types.ObjectId

@Schema({ timestamps: true, collection: 'products' })
export class ProductModel {
  _id: mongoose.Types.ObjectId;
}

It doesn't matter if you are not using NestJS and Decorators. The type you need to import is the same. The example below use an interface and plain Mongoose.

interface Product {
  _id: mongoose.Types.ObjectId;
}

const myProductModel = mongoose.Schema<Product>({ ... // props })

Bye

Well, that's a short post, just in case someone else needs this, and for me because after one week without using Mongoose, I forget it XD. I think it would be interesting to investigate more about these 2 types and why they are written in that way, under different objects.

In summary, we need to make sure we're typing our properties with the correct type before trying to bypass the Typescript compiler using type coercion or some other trick.

Thank you for reading ❤️

Password managers for developers

Axel Espinosa — Fri, 25 Aug 2023 01:44:13 +0000

Hello, #readers! I hope you're having a fantastic day and staying properly hydrated. Just a quick reminder, though: coffee doesn't count towards staying hydrated, so keep that in mind! 🧐

In today's post, I want to address a common issue that I think we've all experienced at some point: forgetting passwords and usernames for various websites, even our mobile banking apps!

The Facts

Did you know this is more common than you might think? According to a study conducted by ExpressVPN, 52% of respondents in the United States reset their passwords at least once a month. Moreover, 21% admitted to resetting passwords more than once a week, and a surprising 14% even do it once a day! These stats reveal a significant number of people frequently forget their passwords.

With this context, it's clear many of us have been through this situation, wasting valuable time trying to reset our passwords.
But don't worry, in the next segment of this post, I'll share an effective solution to avoid these problems and make your digital life much simpler. Keep reading!

The Issues

We've established the challenges of forgetting passwords, but have you realized the real consequences of these situations? Allow me to explain.

One major problem is resorting to opening our notepads and jotting down passwords. While it may seem practical at the moment, it puts our privacy and security at risk. Imagine if someone gains access to that notepad—your confidential data would be exposed!

But that's not all. Another common mistake is using the same password for all the apps and websites we use. This leads to a much bigger problem: the infamous data leaks. Unfortunately, we can't control the security of all the platforms we register on, and if any of them suffer a security breach, attackers can access our passwords and emails.

Imagine this scenario: a data leak occurs on one of the sites where you use that common password (onedirection1234!). Cybercriminals gain access to your personal info, and now you have a vulnerability across all other sites where you used the same password. It's a risk we shouldn't underestimate.
That's why it's crucial to take steps to protect our information.

The Solution

Did you know there are password managers that can greatly help with security and remembering passwords? They're essential for all your accounts! These managers generate automatic passwords and offer the option of using one-time codes, which is crucial nowadays.

Personally, I've tried several password managers like Bitwarden, Dashlane, and 1Password. Of them, 1Password has brought a remarkable change in how I handle my accounts. I no longer need to remember any passwords, as the manager takes care of that. Plus, it generates highly secure passwords, even over 32 characters if needed. Goodbye to using my birthdate as a password!

As a backend developer, a feature I find incredibly useful is the ability to securely store all my .env files and access them from my account. I no longer worry about copying and pasting files to an insecure location when switching computers. These files often contain database access info or external provider details. I simply store them in a secure note, and that's more than enough.

Furthermore, 1Password recently added a feature to manage SSH keys, although I haven't used it yet, I'm sure it'll be incredibly helpful. I've noticed this company truly has us, developers, in mind to make their tool genuinely useful. I wholeheartedly recommend it, even if there are more budget-friendly alternatives out there, this one's my favorite.

So, there you have it—use a password manager wherever possible! Don't forget to enable two-factor authentication on your accounts. If you use multiple AWS accounts, I promise it'll make your life so much easier.

Hope you enjoyed this new post about something that helps me in my day-to-day. Thanks for reading! I'll leave you with a cheems.

References:

P, M. (2022). Survey: How Much Time Do You Waste Resetting Passwords? Home of Internet Privacy. https://www.expressvpn.com/es/blog/encuesta-cuanto-tiempo-desperdicia-restableciendo-contrasenas/
Peru, E. C. (2021, May 6). World Password Day: 56% of users never change their access codes. El Comercio Peru. https://elcomercio.pe/tecnologia/actualidad/ciberseguridad-dia-mundial-de-las-contrasenas-el-56-de-usuarios-no-cambia-nunca-sus-claves-de-acceso-hackers-hackeo-noticia/
Biggest Data Breaches in US History [Updated 2023] | UpGuard. (n.d.). https://www.upguard.com/blog/biggest-data-breaches-us

Decoding Developer Challenges: Balancing Code, Clients, and User Experience

Axel Espinosa — Tue, 15 Aug 2023 19:22:14 +0000

Hello #readers! I hope you're doing well. I've just come out of some extremely busy weeks at work where we've been developing a core service for our mobile app. By the way, you can download it on the App Store or Google Play.

Today, I wanted to share some wild ideas that struck me as I was about to start a small freelance gig for a client. I think they might be helpful to you. These are little insights I've gathered that assist me in completing tasks or even tackling new projects without facing that ever-present dilemma: whether to use one technology over another, or wondering if database X is better than another. You know, those everyday conundrums.

Software Beyond Code.

It's not just about writing the most optimized lines or strictly adhering to standards. It's about how we can make a real difference in people's lives. Every time we write code, we're crafting solutions. Never forget that.

The User's Perspective.

While we're deep into design patterns, testing, and architectures, at the end of the day, our users just want something that works. So, if you ever find yourself torn between going for the latest tech or ensuring something simply works for the user, you know what to choose.

Finding Balance with Your Clients.

We know it can be tricky sometimes. But, you know what? Neither you nor they are always right. The key is to find a middle ground where both parties are content.

The Peaks and Valleys of Being a Developer.

There are days when everything flows, and others when you might feel like throwing your computer out of the window. It's all part of the journey, and it's what makes our profession both unique and exhilarating.

Well, I hope you enjoyed this short post. Do you have any other ideas that help you thrive? Catch me on Twitter(X) or in the comments 😃 @fromchiapasdev.

Reflexionando sobre el mundo del código

Axel Espinosa — Sat, 12 Aug 2023 00:25:38 +0000

Hola #readers, espero que estén muy bien, yo estoy saliendo de unas semanas muy atareadas del trabajo, en las que hemos estado creando un servicio core para nuestra aplicación móvil, por cierto pueden bajarla en la App Store o Google Play.

En esta ocasión vengo a escribir acerca de unas ideas locas que se me ocurrieron mientras estaba por empezar un pequeño freelance para un cliente y creo que te pueden ser útiles. Son pequeños puntos que recopilé que me ayudan a poder completar una tarea o incluso enfrentarme con un proyecto nuevo y no estar teniendo ese pequeño dilema de si usar una tecnología sobre otra, o que si la base de datos X es mejor que otra, ya saben dilemas de la vida.

Software más allá del código.

No es solo escribir las líneas más optimizadas o seguir los estándares al pie de la letra. Es sobre cómo podemos hacer una diferencia real en la vida de las personas. Cada vez que escribimos código, estamos creando soluciones. Nunca olvides eso.

La perspectiva del usuario.

Mientras estamos sumergidos en patrones de diseño, pruebas y arquitecturas, al final del día, nuestros usuarios solo quieren algo que funcione. Así que, si alguna vez te encuentras en el dilema de optar por la última versión de una tecnología o hacer que algo simplemente funcione para el usuario, ya sabes qué elegir.

Encuentra el balance con tus clientes.

Sabemos que a veces puede ser complicado. Pero, ¿sabes? Ni tú ni ellos tienen siempre la razón. La clave está en encontrar un término medio donde ambos se sientan satisfechos.

Las montañas y valles de ser programador.

Hay días en los que todo fluye, y hay otros en los que quisieras tirar tu computadora por la ventana. Es parte del viaje, y es lo que hace que nuestra profesión sea única y apasionante.

Pues bueno, espero te haya gustado este pequeño post, ¿tienes otras ideas que te ayudan a ser mejor? Te veo en Twitter(X) o en los comentarios 😃 @fromchiapasdev

Deja de olvidar las contraseñas

Axel Espinosa — Fri, 14 Jul 2023 19:12:38 +0000

¡Hola, #readers! Espero que estén teniendo un día genial y se estén hidratando adecuadamente. Recuerden que el café no cuenta para mantenernos hidratados, ojito 🧐

En el post de hoy, quiero abordar un problema común que creo que todos hemos experimentado en algún momento: ¡perder contraseñas y olvidarnos de los usuarios con los que nos registramos en diferentes sitios web, incluso en nuestra banca móvil!

Datos

¿Sabías que esto es más común de lo que te imaginas? Según un estudio realizado por la compañía ExpressVPN, el 52% de los encuestados en Estados Unidos restablecen sus contraseñas al menos una vez al mes. Además, un 21% admitió restablecerlas más de una vez a la semana, ¡y un 14% incluso lo hace al menos una vez al día! Estos datos nos revelan que un porcentaje significativo de personas olvida sus contraseñas con frecuencia.

Con este contexto, es evidente que muchos de nosotros hemos pasado por esta situación y perdemos un tiempo valioso tratando de restablecer nuestras contraseñas.
Pero no te preocupes, en el próximo segmento de este post compartiré contigo una solución efectiva para evitar estos problemas y hacer que tu vida digital sea mucho más sencilla. ¡Sigue leyendo!

Problemas

Ya hemos entendido los problemas que enfrentamos al perder nuestras contraseñas. Pero, ¿te has dado cuenta de cuáles son las consecuencias reales de estas situaciones? Permíteme explicarte.

Uno de los principales problemas es que solemos recurrir a abrir nuestro bloc de notas y anotar las contraseñas. Aunque parezca una solución práctica en el momento, puede poner en riesgo nuestra privacidad y seguridad. Imagina si alguien accede a ese bloc de notas, ¡todos tus datos confidenciales estarían al descubierto!

Pero eso no es todo. Otro error común es utilizar la misma contraseña para todas las aplicaciones y sitios web que utilizamos. Esto nos lleva a un problema mucho más preocupante: los famosos data leaks, es decir, la filtración de información. Desafortunadamente, no podemos controlar la seguridad de todas las plataformas en las que nos registramos, y si alguna de ellas sufre un fallo de seguridad, los atacantes pueden obtener acceso a nuestras contraseñas y correos electrónicos.

Imagina el escenario: un data leak ocurre en uno de los sitios en los que usas esa contraseña común (onedirection1234!). Los ciberdelincuentes obtienen acceso a tu información personal y ahora tienes una vulnerabilidad en todos los demás sitios en los que usaste esa misma contraseña. Es un riesgo que no debemos subestimar.
Por eso es fundamental tomar medidas para proteger nuestra información.

Solución

¿Sabías que existen gestores de contraseñas que pueden ser de gran ayuda para mantener la seguridad y recordar tus contraseñas? ¡Son imprescindibles en todas tus cuentas! Estos gestores generan contraseñas automáticas y te ofrecen la posibilidad de utilizar códigos de un solo uso, algo fundamental en la actualidad.

Personalmente, he probado varios gestores de contraseñas como Bitwarden, Dashlane y 1Password. De todos ellos, 1Password me ha brindado un cambio increíble en la forma en que manejo mis cuentas. Ya no tengo que recordar ninguna contraseña, ya que el gestor se encarga de ello. Además, genera contraseñas altamente seguras, incluso de más de 32 caracteres si es necesario. ¡Adiós al temor de utilizar mi fecha de cumpleaños como contraseña!

Como desarrollador backend, una función que me resulta extremadamente útil es poder almacenar todos mis archivos con extensión .env de forma segura y acceder a ellos desde mi cuenta. Ya no tengo que preocuparme por copiar y pegar los archivos en un lugar inseguro cuando cambio de computadora. Estos archivos suelen contener información de acceso a bases de datos o proveedores externos. Simplemente los almaceno en una nota segura y eso es más que suficiente.

Además, 1Password ha añadido recientemente una nueva función para gestionar llaves SSH, aunque aún no la he utilizado, estoy seguro de que será de gran utilidad. He observado que esta empresa realmente ha pensado en nosotros, los desarrolladores, para hacer de su herramienta algo realmente útil. La recomiendo al 100%, aunque existan alternativas más económicas en el mercado, esta es mi favorita.

Entonces, ya lo sabes, ¡utiliza un gestor de contraseñas para todo lo posible! No olvides activar la autenticación de dos factores en tus cuentas. Si utilizas varias cuentas de AWS, te aseguro que te ayudará enormemente.

Espero que les haya gustado este nuevo post sobre algo que me ayuda en mi día a día. ¡Gracias por leerme! Les dejo un cheems.

Referencias:

P, M. (2022). Encuesta: ¿Cuánto tiempo desperdicia restableciendo contraseñas? Home of Internet Privacy. https://www.expressvpn.com/es/blog/encuesta-cuanto-tiempo-desperdicia-restableciendo-contrasenas/
Perú, E. C. (2021, May 6). Día Mundial de las Contraseñas: El 56% de usuarios no cambia nunca sus claves de acceso. El Comercio Perú. https://elcomercio.pe/tecnologia/actualidad/ciberseguridad-dia-mundial-de-las-contrasenas-el-56-de-usuarios-no-cambia-nunca-sus-claves-de-acceso-hackers-hackeo-noticia/
Biggest Data Breaches in US History [Updated 2023] | UpGuard. (n.d.). https://www.upguard.com/blog/biggest-data-breaches-us

DEV Community: Axel Espinosa

Cómo proteger tu proyecto de paquetes maliciosos en npm

¿Qué es un "supply chain attack" o ataque a la cadena de suministro?

¿Cómo se infecta una librería?

¿Cómo funcionan los lifecycle scripts en npm?

¿Cómo proteger tu proyecto de paquetes maliciosos en npm?

No actualices versiones a lo loco

Bloquea los lifecycle scripts

Bloquea instalaciones desde Git

Fija la versión de tus dependencias

No instales la versión más reciente

Tu .npmrc defensivo mínimo

Considerar pnpm

Bloqueo de dependencias y builds

Tiempo de antigüedad

¿Cómo funciona trustPolicy?

Revisar antes de instalar

npq

Socket Firewall

Medidas adicionales

Evitar el uso de .env con información sensible

Usa devcontainers

Verifica tu ambiente

No estamos 100% seguros

npm install tips para la seguridad

¿Qué son los arrays y para qué sirven? Explicación sencilla

Cómo funciona la RAM

¿Qué es un array?

Arrays estáticos

Arrays dinámicos

Estáticos vs. Dinámicos

Operaciones comunes

Acceso por índice

Insertar al final

Eliminar el último elemento

Obtener longitud

Recorrer los elementos

Modificar el inicio del array

Costo de las operaciones

Construye tu propia implementación de un array

Conclusión

Cómo construí un videojuego usando Kiro

Vibecoding

La idea

Conceptos rápidos

POO (Programación Orientada a Objetos)

FPS (Frames Per Second)

Game Loop

El proceso

0. Preparar el proyecto

1. El prompt inicial

2. Simplificar el fondo

3. Los obstáculos tardaban mucho en aparecer

4. Obstáculos imposibles de esquivar

5. Mejorar la respuesta de los controles

6. El contador y high score

7. El efecto dominó

8. Balancear al dinosaurio

9. Pterodáctilos a dos alturas

Estructura final del proyecto

Lo que aprendí

¿Qué es un encoding? Explicación sencilla: ASCII, UTF-8 y Unicode

Encodings

ASCII

Unicode

UTF-8 👾

Charset y Encoding

¿Por qué importa?

Ejemplo práctico

Ejemplo en programación

Conclusión

Write better unit tests

Tips

Tools

How to Name Your Subject Under Test

Write a Clear Message for Your Test

How to Avoid Fragility in Your Tests

What Are Mocks and When to Use Them?

One Important Note Before the Example:

Code Coverage

Tu `.npmrc` defensivo mínimo

¿Cómo funciona `trustPolicy`?