DEV Community: Axel Espinosa

Two Pointers en entrevistas técnicas: 3 problemas resueltos

Axel Espinosa — Wed, 22 Apr 2026 20:31:27 +0000

Si estás preparándote para entrevistas técnicas, tarde o temprano vas a encontrarte con problemas de arrays y strings. Y varios se resuelven con una misma familia de técnicas: two pointers.

En los artículos anteriores vimos cómo funcionan los arrays y los strings por debajo: memoria contigua, acceso por índice, operaciones y sus costos. Hoy toca usar todo eso para resolver problemas reales.

Lo que vas a encontrar en este artículo:

Qué son las entrevistas técnicas y por qué te piden resolver problemas

Qué es two pointers y qué técnicas incluye

Cómo identificar cuál técnica usar

Un problema resuelto paso a paso por cada técnica

¿Qué son los problemas de entrevistas técnicas?

Son ejercicios de programación que te ponen en entrevistas para puestos de desarrollo de software. Ojo, las entrevistas técnicas existen para muchos roles (arquitectura, DevOps, SRE, developer) y no todas se ven igual. Este artículo se enfoca en las entrevistas para roles de developer.

El objetivo no es que te sepas la respuesta de memoria. Lo que evalúan es cómo piensas: cómo descompones un problema, qué estructura de datos eliges y si tu solución es eficiente.

Y aquí viene lo interesante: existen técnicas que se crearon específicamente para resolver estos problemas de forma óptima. No es magia, es práctica y reconocimiento de patrones.

¿Qué es Two Pointers?

Two pointers es un paradigma general para resolver problemas con arrays y strings. La idea es simple: usas dos variables (los "punteros") que recorren la estructura de datos de formas específicas.

Ojo, cuando digo "punteros" no me refiero a punteros de memoria como en C. Aquí son simplemente variables que guardan índices para acceder a posiciones del array o string.

¿Por qué funciona? Porque con dos punteros moviéndose de forma inteligente, puedes evitar soluciones de fuerza bruta O(n²) y resolverlo en O(n). Eso es exactamente lo que buscan en una entrevista.

¿Qué técnicas incluye?

Two pointers incluye tres variantes principales:

Fast and slow pointers (lento y rápido): un puntero explora y otro se queda marcando una posición.
Opposite direction pointers (punteros convergentes): empiezan en los extremos y se acercan al centro.
Parallel pointers (punteros paralelos): cada puntero recorre un array diferente al mismo tiempo.

Lo que todas tienen en común: usan al menos 2 variables para recorrer un arreglo o string, y nos ayudan a pasar de O(n²) a O(n).

Vamos a usar los nombres en inglés porque así los encuentras en la mayoría de recursos, LeetCode y entrevistas.

¿Cómo saber cuál técnica usar?

Antes de entrar a los problemas, una guía rápida. Si en el enunciado ves algo de esto, probablemente necesitas two pointers:

Te dan uno o dos arreglos/strings.
Te piden espacio O(1) o modificar el array en su lugar.
La solución obvia sería O(n²) pero necesitas algo mejor.

Ahora, ¿cuál variante? Aquí va un resumen:

Técnica	Úsala cuando...
Fast and slow	Necesitas comparar o modificar elementos dentro del mismo array
Opposite direction	Necesitas verificar propiedades simétricas, encontrar pares, o trabajar desde los extremos
Parallel pointers	Tienes dos arrays y necesitas compararlos o fusionarlos

Sé que puede parecer mucho, pero conforme resolvamos los problemas vas a ver que es más intuitivo de lo que parece. Vamos a eso.

Opposite direction: Verificar un palíndromo

Empecemos con opposite direction porque es la más visual.

Tomemos el problema "Valid Palindrome" de LeetCode:

Problema:
Una frase es un palíndromo si, tras convertir todas las letras a minúsculas y eliminar los caracteres no alfanuméricos, se lee igual de izquierda a derecha que de derecha a izquierda.

Dada una cadena s, devuelve true si es un palíndromo, o false en caso contrario.

Ejemplos

Input:  s = "A man, a plan, a canal: Panama"
Output: true
// Porque "amanaplanacanalpanama" se lee igual en ambas direcciones

Input:  s = "race a car"
Output: false
// Porque "raceacar" no es palíndromo

Input:  s = " "
Output: true
// Un string vacío se lee igual al derecho y al revés

¿Cómo lo pensamos?

La solución de fuerza bruta sería limpiar el string, invertirlo y comparar. Funciona, pero crea strings nuevos en memoria (recuerda que los strings son inmutables, así que cada operación crea uno nuevo).

Con opposite direction pointers hacemos algo más elegante: ponemos un puntero al inicio y otro al final. Los vamos acercando al centro comparando los caracteres. Si en algún momento no coinciden, no es palíndromo. Si los punteros se cruzan sin encontrar diferencias, sí lo es.

Solución paso a paso

/**
 * @param {string} s
 * @return {boolean}
 */
var isPalindrome = function (s) {
  let l = 0;
  let r = s.length - 1;

  while (l < r) {
    if (!isAlphanumeric(s[l])) {
      l++;
    } else if (!isAlphanumeric(s[r])) {
      r--;
    } else if (s[l].toLowerCase() !== s[r].toLowerCase()) {
      return false;
    } else {
      l++;
      r--;
    }
  }
  return true;
};

// función auxiliar: ¿es letra o número?
function isAlphanumeric(char) {
  const code = char.charCodeAt(0);
  return (
    (code >= 48 && code <= 57) || // 0-9
    (code >= 65 && code <= 90) || // A-Z
    (code >= 97 && code <= 122) // a-z
  );
}

Vamos línea por línea:

l arranca en 0 (inicio del string) y r en s.length - 1 (final). Son nuestros dos punteros que se van a acercar al centro.
El while (l < r) se ejecuta mientras los punteros no se hayan cruzado.
Dentro del loop hay cuatro casos:
- Si s[l] no es alfanumérico (un espacio, coma, dos puntos...), lo saltamos moviendo l a la derecha.
- Si s[r] no es alfanumérico, lo saltamos moviendo r a la izquierda.
- Si ambos son alfanuméricos pero no coinciden (comparando en minúsculas), no es palíndromo. Retornamos false.
- Si coinciden, avanzamos ambos punteros hacia el centro (l++, r--).
Si el loop termina sin retornar false, los punteros se cruzaron sin encontrar diferencias. Es palíndromo, retornamos true.

La función auxiliar isAlphanumeric revisa el código ASCII del carácter: 48-57 son dígitos, 65-90 letras mayúsculas, 97-122 letras minúsculas. Todo lo demás (espacios, puntuación, etc.) retorna false.

💡 Complejidad: O(n) en tiempo, O(1) en espacio. Un solo recorrido del string, sin crear copias ni estructuras extra.

Veamos cómo se ve con s = "A man, a plan, a canal: Panama":

Fast and slow: Remove Duplicates

Ahora veamos fast and slow con el clásico "Remove Duplicates from Sorted Array" de LeetCode:

Problema:
Te dan una lista de números nums ya ordenada de menor a mayor, pero con algunos repetidos. Tienes que dejar cada número una sola vez, moviendo los únicos al inicio de la misma lista (sin crear otra lista nueva).
Por ejemplo, si te dan [1, 1, 2, 3, 3], la lista debe quedar así: [1, 2, 3, ?, ?]. Los primeros tres espacios tienen los números únicos en orden, y los últimos dos espacios no importan (pueden quedar con cualquier valor, por eso los marcamos con ?).
Además, tu función debe devolver cuántos números únicos quedaron al inicio. En el ejemplo anterior, devolverías 3 porque hay tres números únicos (1, 2, 3). A ese número lo llaman k en el enunciado.

Ejemplos

Ejemplo 1

Entrada: nums = [1,1,2]
Salida: 2, nums = [1,2,_]

Explicación: Tu función debe devolver k = 2, y los primeros dos elementos de nums deben ser 1 y 2 respectivamente. No importa qué quede después de los primeros k espacios (por eso aparecen como guiones bajos).

Ejemplo 2

Entrada: nums = [0,0,1,1,1,2,2,3,3,4]
Salida: 5, nums = [0,1,2,3,4,_,_,_,_,_]

Explicación: Tu función debe devolver k = 5, y los primeros cinco elementos de nums deben ser 0, 1, 2, 3 y 4 respectivamente. No importa qué quede después de los primeros k espacios (por eso aparecen como guiones bajos).

¿Cómo lo pensamos?

La fuerza bruta sería crear un nuevo array y copiar solo los valores que no se repiten. Pero el problema dice explícitamente que lo hagas "in-place", o sea, modificando el mismo array sin crear otro. Ahí es donde entra fast and slow.

La idea es esta: usamos dos punteros que arrancan casi juntos. slow marca la posición donde va el siguiente número único. fast se adelanta recorriendo todo el array buscando valores nuevos.

Como el array ya está ordenado, los duplicados siempre están juntos. Entonces fast solo necesita comparar su valor con el de slow. Si son diferentes, encontramos un número nuevo: avanzamos slow una posición y copiamos ahí el valor de fast. Si son iguales, fast simplemente sigue avanzando.

Piénsalo así: slow es el que construye la respuesta, y fast es el explorador que le dice "oye, encontré uno nuevo".

Solución paso a paso

/**
 * @param {number[]} nums
 * @return {number}
 */
var removeDuplicates = function (nums) {
  let slow = 0;
  for (let fast = 1; fast < nums.length; fast++) {
    if (nums[fast] !== nums[slow]) {
      slow++;
      nums[slow] = nums[fast];
    }
  }
  return slow + 1;
};

Vamos línea por línea:

slow arranca en 0, apuntando al primer elemento. Ese siempre es único porque no hay nada antes con qué comparar.
fast arranca en 1 y recorre el array completo con el for.
En cada paso, comparamos nums[fast] con nums[slow]:
- Si son iguales, es un duplicado. fast avanza y slow se queda donde está. No hacemos nada.
- Si son diferentes, encontramos un valor nuevo. Avanzamos slow una posición (slow++) y copiamos el valor de fast ahí (nums[slow] = nums[fast]).
Al final, slow queda apuntando al último elemento único. Como los índices empiezan en 0, el total de únicos es slow + 1.

Veamos cómo se ve con nums = [0, 0, 1, 1, 1, 2, 2, 3, 3, 4]:

Los primeros 5 elementos son [0, 1, 2, 3, 4], exactamente los valores únicos en orden. Lo que queda después del índice 4 no importa.

¿Ves el patrón? fast recorre todo el array una sola vez, y slow solo avanza cuando encuentra algo nuevo. Eso nos da O(n) en tiempo y O(1) en espacio, porque no creamos ninguna estructura extra.

💡 Complejidad: O(n) en tiempo, O(1) en espacio. Un solo recorrido, sin estructuras extra.

Parallel pointers: Intersección de dos arrays

Por último, parallel pointers con "Intersection of Two Arrays" de LeetCode:

Problema:
Dados dos arreglos de enteros, devuelve un arreglo con su intersección. Cada elemento del resultado debe ser único y puede estar en cualquier orden.

Ejemplos

Input:  nums1 = [1, 2, 2, 1], nums2 = [2, 2]
Output: [2]

Input:  nums1 = [4, 9, 5], nums2 = [9, 4, 9, 8, 4]
Output: [9, 4]  // el orden no importa

¿Cómo lo pensamos?

La fuerza bruta sería usar dos loops anidados: por cada elemento de nums1, recorrer todo nums2 buscando coincidencias.

Con parallel pointers hacemos algo más inteligente: primero ordenamos ambos arrays y después los recorremos una sola vez con dos punteros. Como están ordenados, podemos comparar los valores y decidir cuál puntero mover:

Si los valores son iguales, encontramos una intersección. Avanzamos ambos.
Si el valor de p1 es menor, lo avanzamos porque no puede haber coincidencia más atrás en nums2.
Si el valor de p2 es menor, lo avanzamos por la misma razón.

Es como hacer merge de dos listas ordenadas, pero solo nos quedamos con los valores que aparecen en ambas.

Solución paso a paso

/**
 * @param {number[]} nums1
 * @param {number[]} nums2
 * @return {number[]}
 */
var intersection = function (nums1, nums2) {
  let p1 = 0,
    p2 = 0;

  // ordenar arreglos
  nums1.sort((a, b) => a - b);
  nums2.sort((a, b) => a - b);
  const intersection = [];

  while (p1 < nums1.length && p2 < nums2.length) {
    if (nums1[p1] === nums2[p2]) {
      // Evita duplicados en el resultado
      if (
        intersection.length === 0 ||
        intersection[intersection.length - 1] !== nums1[p1]
      ) {
        intersection.push(nums1[p1]);
      }
      p1++;
      p2++;
    } else if (nums1[p1] < nums2[p2]) {
      p1++;
    } else {
      p2++;
    }
  }

  return intersection;
};

Vamos línea por línea:

Ordenamos ambos arrays con .sort(). Esto es clave: sin el orden, no podríamos saber hacia dónde mover los punteros.
p1 y p2 arrancan en 0, cada uno apuntando al inicio de su array.
El while se ejecuta mientras ambos punteros estén dentro de sus arrays.
Dentro del loop hay tres casos:
- Si nums1[p1] === nums2[p2], encontramos un valor en común. Antes de agregarlo, verificamos que no sea un duplicado (comparando con el último elemento del resultado). Avanzamos ambos punteros.
- Si nums1[p1] < nums2[p2], el valor de p1 es más chico. Como ambos arrays están ordenados, ese valor no puede existir más adelante en nums2. Avanzamos p1.
- Si nums1[p1] > nums2[p2], misma lógica pero al revés. Avanzamos p2.
Cuando alguno de los dos punteros llega al final de su array, el loop termina. Ya no puede haber más intersecciones.

Veamos con nums1 = [4, 9, 5], nums2 = [9, 4, 9, 8, 4]:

¿Ves cómo cada puntero solo avanza hacia adelante? Nunca retroceden. El recorrido en sí es O(n + m), pero el ordenamiento inicial domina: O(n log n + m log m) en total.

💡 Complejidad: O(n log n + m log m) en tiempo por el ordenamiento. O(n) en espacio para el resultado.

Resumen

Estas tres técnicas son variantes de un mismo concepto: usar dos punteros para recorrer arrays o strings de forma eficiente.

Técnica	Movimiento de punteros	Problema resuelto
Opposite direction	De los extremos al centro	Valid Palindrome
Fast and slow	Uno explora, otro referencia	Remove Duplicates
Parallel pointers	Cada uno en su array	Intersection of Two Arrays

La clave no es memorizar las soluciones. Es reconocer el patrón en el enunciado y saber qué técnica aplicar. Con práctica, vas a leer un problema y saber qué variante de two pointers usar antes de escribir una línea de código.

Si quieres seguir practicando, aquí te dejo más problemas de LeetCode:

¿Cuál técnica te costó más entender? ¿Hay algún problema que quieras que resolvamos juntos? Déjamelo en los comentarios. 🙌🏻

No olvides revisar estos consejos para disminuir la probabilidad de infectar tu computadora con un troyano al instalar un paquete de npm.

Axel Espinosa — Thu, 16 Apr 2026 18:03:35 +0000

Axel Espinosa

Apr 4

npm install puede infectar tu máquina: cómo protegerte

#discuss #security #npm #node

Comments 1

7 min read

🙌🏻

Axel Espinosa — Wed, 15 Apr 2026 16:25:01 +0000

Hazel Saenz for AWS

Apr 15

Cómo crear un agente de IA desde cero. Open source, local y gratis.

#agents #ai #opensource #tutorial

Comments

14 min read

¿Qué es un String y para qué sirven?

Axel Espinosa — Mon, 13 Apr 2026 21:19:53 +0000

Los strings son probablemente la estructura de datos que más usas sin pensar. Pero, ¿sabes cómo se almacenan en memoria? ¿Por qué no puedes modificarlos directamente? ¿Cuánto cuesta concatenarlos en un loop?

En el artículo anterior vimos cómo funcionan los arrays por debajo: memoria contigua, acceso por índice, operaciones y sus costos. Si aún no lo has leído, te recomiendo empezar por ahí. Hoy toca hablar de sus primos: los strings.

En estos ejemplos usaremos JavaScript como lenguaje principal. Si usas otro lenguaje, te invito a buscar los métodos equivalentes. Los conceptos son los mismos.

Lo que encontrarás en este artículo:

Qué es un string y cómo se almacena en memoria

Qué significa que sean inmutables

En qué se parecen y en qué se diferencian de los arrays

Operaciones comunes con strings y cuánto cuestan (Big O)

Una tabla de complejidad para que la tengas de referencia

1. ¿Qué es un string?

Un string (o cadena de caracteres) es una secuencia de caracteres almacenados de forma contigua en memoria. Suena familiar, ¿verdad? Es básicamente lo que vimos con los arrays, pero en lugar de números o emojis, almacenamos caracteres.

Índice:    0   1   2   3   4
         ┌───┬───┬───┬───┬───┐
String:  │ H │ o │ l │ a │ ! │
         └───┴───┴───┴───┴───┘

Para empezar, puedes pensar en un string como un array de caracteres — es un buen modelo mental. Más adelante verás que los motores modernos implementan strings con estructuras más sofisticadas, pero conceptualmente esta idea te va a servir para entender cómo se comportan.

Pero aquí viene el detalle: ¿qué es realmente un "carácter" para la computadora? No es una letra. Es un número. La "H" es el 72, la "o" es el 111. Cada carácter tiene un código numérico asignado por un estándar (como ASCII o Unicode), y un encoding (como UTF-8) convierte ese código a bits. Así que cuando digo "array de caracteres", por debajo es un array de números.

Si quieres entender a fondo cómo funciona eso, lo cubrimos en el artículo de encodings. Ahí explicamos por qué un emoji ocupa 4 bytes y una letra solo 1. 😉

Cada carácter ocupa una posición y tiene un índice, exactamente como en un array. Y al igual que con los arrays, acceder a un carácter por su índice es instantáneo: O(1).

const saludo = "Hola!";
console.log(saludo[0]); // "H"
console.log(saludo[4]); // "!"

Una advertencia importante: este modelo funciona perfectamente con caracteres del alfabeto latino básico, pero se complica con emojis y algunos caracteres especiales. En JavaScript, un emoji como 😀 ocupa dos posiciones en el string, no una:
const s = "😀";
console.log(s.length); // 2, no 1
Esto es por cómo JavaScript representa internamente el texto (UTF-16). Lo vemos a detalle en el artículo de encodings. Por ahora, si trabajas con caracteres simples, el modelo de "array de caracteres" te sirve bien.

2. ¿Por qué los strings son inmutables?

Porque una vez que creas un string, su contenido no puede cambiar. Si necesitas una versión diferente, se crea uno nuevo en memoria. Esto aplica en JavaScript, Python y la mayoría de lenguajes modernos. Aquí es donde los strings empiezan a diferenciarse de los arrays.

¿Qué significa inmutable?

Inmutable quiere decir que algo no puede cambiar después de creado. En programación, cuando decimos que un valor es inmutable, significa que no puedes modificar su contenido directamente. Si necesitas una versión diferente, tienes que crear una nueva.

¿Qué pasa cuando modificas un string?

En lenguajes como JavaScript y Python, los strings son inmutables. Esto quiere decir que cuando "modificas" un string, en realidad se está creando uno nuevo en memoria. El original no se toca.

Veamos un ejemplo:

let palabra = "Hola";
palabra[0] = "J"; // Intentamos cambiar la "H" por "J"
console.log(palabra); // "Hola" — no cambió nada

¿Ves? JavaScript simplemente ignora el intento. No lanza un error, pero tampoco hace el cambio.

Si tu código está en strict mode (lo cual pasa automáticamente dentro de módulos ES y clases), este intento sí lanza un TypeError. Es el comportamiento más común en código moderno.

En Python es más explícito:

palabra = "Hola"
palabra[0] = "J"  # TypeError: 'str' object does not support item assignment

Python directamente te dice: "no puedes hacer eso".

¿Cuánto cuesta concatenar strings?

Cuando concatenas strings con +=, no estás "agregando" al final como harías con push() en un array. Conceptualmente, se crea un string nuevo que contiene todo el contenido anterior más lo que agregaste.

let resultado = "";
resultado += "Hola"; // Se crea un nuevo string "Hola"
resultado += " "; // Se crea un nuevo string "Hola "
resultado += "Mundo"; // Se crea un nuevo string "Hola Mundo"

Construir un string de tamaño N con concatenaciones repetidas tiene un costo total de O(N) — el tamaño del resultado final.

Los motores de JavaScript modernos optimizan este caso con estructuras internas que evitan copiar el string completo en cada paso, así que en la práctica += en un loop es bastante eficiente. Pero la regla general sigue siendo útil: si vas a construir texto pieza por pieza, piensa en el tamaño del resultado final, no solo en cuántas piezas tienes.

3. ¿Cuál es la diferencia entre strings y arrays?

Ambos son secuencias contiguas con acceso por índice O(1), pero los arrays son mutables y los strings no. Esa diferencia cambia todo: los arrays tienen push y pop, los strings tienen métodos de texto como slice, split y replace.

Primos, no gemelos. Los arrays te permiten modificar su contenido directamente: cambiar un elemento por índice, agregar al final, quitar del inicio. Los strings no. Son inmutables, así que no puedes hacer push o pop sobre un string.

Lo que sí tienen los strings son métodos especializados para operaciones comunes con texto: buscar, acortar, dividir, reemplazar. Implementar estos métodos de strings manualmente sería tedioso (y propenso a errores). Por eso los lenguajes nos dan estos métodos listos para usar.

Característica	Array (dinámico)	String
Secuencia contigua	✅	✅
Acceso por índice	✅ O(1)	✅ O(1)
Mutable	✅	❌
push / pop	✅	❌
Métodos de texto	❌	✅ (search, slice, split, etc.)
Redimensionable	✅ (crece automáticamente)	❌ (se crea uno nuevo)

4. Operaciones comunes con strings y su complejidad

Vamos a las operaciones que más vas a usar con strings. Cada una con un ejemplo en JavaScript y su complejidad.

Obtener longitud

Igual que con los arrays, podemos saber cuántos caracteres tiene un string con .length.

const texto = "Hola Mundo";
console.log(texto.length); // 10

Complejidad: O(1) — el acceso es inmediato

Acceso por índice

Ya lo vimos, pero vale la pena repetirlo: puedes acceder a cualquier carácter directamente por su posición.

const texto = "JavaScript";
console.log(texto[0]); // "J"
console.log(texto[4]); // "S"

Complejidad: O(1) — acceso directo, como el elevador del artículo de arrays.

Buscar dentro de un string

Podemos verificar si un string contiene cierto texto con includes(), o encontrar la posición exacta con indexOf().

const frase = "Los arrays son geniales";

console.log(frase.includes("arrays")); // true
console.log(frase.includes("strings")); // false

console.log(frase.indexOf("arrays")); // 4
console.log(frase.indexOf("strings")); // -1 (no lo encontró)

Complejidad: O(n·m) en el peor caso — donde n es la longitud del string y m la longitud del texto que buscas. En la práctica, los motores modernos usan algoritmos de búsqueda optimizados que son mucho más rápidos en la mayoría de los casos.

Extraer una porción (slice / substring)

slice() te permite extraer una parte del string sin modificar el original (recuerda: inmutabilidad).

const texto = "JavaScript";
console.log(texto.slice(0, 4)); // "Java"
console.log(texto.slice(4)); // "Script"
console.log(texto); // string original

Complejidad: O(n) en el peor caso — donde n es el tamaño de la porción extraída. Algunos motores optimizan esta operación para evitar copiar cuando es posible.

Dividir un string (split)

split() divide un string en un array de substrings usando un separador.

const csv = "nombre,edad,ciudad";
const campos = csv.split(",");
console.log(campos); // ["nombre", "edad", "ciudad"]

Complejidad: O(n) — recorre todo el string para encontrar los separadores y crear los substrings.

Concatenar strings

Ya hablamos de esto, pero aquí va el resumen con código:

const nombre = "Hola";
const saludo = nombre + " Mundo";
console.log(saludo); // "Hola Mundo"

Complejidad: O(n) — donde n es el tamaño del resultado final. Recuerda que los motores modernos optimizan esta operación por debajo.

Si quieres explorar todos los métodos de strings disponibles en JavaScript, la referencia de String en MDN es un excelente recurso.

5. ¿Cuál es la complejidad Big O de las operaciones con strings?

Aquí te dejo la tabla de complejidad, en el mismo formato que usamos en el artículo de arrays para que puedas compararlas:

Operación	Complejidad
Acceso por índice	O(1)
Obtener longitud	O(1)
Buscar un substring	O(n·m)
Concatenar (resultado total)	O(n)
Slice / Substring	O(n)
Split	O(n)

Nota: las complejidades de búsqueda y concatenación representan el peor caso. Los motores modernos de JavaScript implementan optimizaciones que hacen que en la práctica sean más rápidas de lo que sugiere la teoría.

Compara esta tabla con la del artículo de arrays. Vas a notar que el acceso por índice es igual de rápido en ambos. La diferencia está en que los strings no tienen operaciones como push o pop porque son inmutables. Cada vez que necesitas un string "modificado", estás pagando el costo de crear uno nuevo.

Algo importante: en esta tabla y a lo largo del artículo usamos Big O para describir el costo de las operaciones. Big O es una notación que nos dice cómo crece el tiempo de una operación conforme crece el tamaño de la entrada. O(1) significa tiempo constante (siempre tarda lo mismo sin importar el tamaño), y O(n) significa tiempo lineal (entre más grande la entrada, más tarda, proporcionalmente).

No es el foco de este artículo, pero es importante que tengas el contexto. Si quieres que hagamos un artículo dedicado a Big O, dime en los comentarios.

Conclusión

Los strings son como los primos de los arrays: comparten la misma base (secuencia contigua, acceso por índice) pero juegan con reglas diferentes gracias a la inmutabilidad. Eso los hace predecibles y seguros, pero también significa que operaciones que parecen simples, como concatenar en un loop, pueden ser más costosas de lo que esperabas.

Si leíste con atención, quizá notaste que dije varias veces "en el peor caso". Eso es porque los motores de JavaScript modernos hacen optimizaciones que a veces rompen el modelo mental simple que vimos aquí.

En el siguiente artículo de la serie vamos a poner en práctica todo lo que hemos visto de arrays y strings con problemas y patrones comunes de entrevistas técnicas. Ahí es donde todo se conecta. 💪

Si quieres avanzar con el siguiente tema intenta resolver esto: dado un string, ¿cómo lo invertirías sin usar .reverse()? Piensa en lo que vimos de inmutabilidad. En el siguiente artículo vamos a resolver este tipo de problemas.

Gracias por llegar hasta el final. Estaré pendiente de tus comentarios 🙌🏻

npm install puede infectar tu máquina: cómo protegerte

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 construir 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 ❤️

DEV Community: Axel Espinosa

Two Pointers en entrevistas técnicas: 3 problemas resueltos

¿Qué son los problemas de entrevistas técnicas?

¿Qué es Two Pointers?

¿Qué técnicas incluye?

¿Cómo saber cuál técnica usar?

Opposite direction: Verificar un palíndromo

¿Cómo lo pensamos?

Solución paso a paso

Fast and slow: Remove Duplicates

¿Cómo lo pensamos?

Solución paso a paso

Parallel pointers: Intersección de dos arrays

¿Cómo lo pensamos?

Solución paso a paso

Resumen

No olvides revisar estos consejos para disminuir la probabilidad de infectar tu computadora con un troyano al instalar un paquete de npm.

npm install puede infectar tu máquina: cómo protegerte

🙌🏻

Cómo crear un agente de IA desde cero. Open source, local y gratis.

¿Qué es un String y para qué sirven?

1. ¿Qué es un string?

2. ¿Por qué los strings son inmutables?

¿Qué significa inmutable?

¿Qué pasa cuando modificas un string?

¿Cuánto cuesta concatenar strings?

3. ¿Cuál es la diferencia entre strings y arrays?

4. Operaciones comunes con strings y su complejidad

Obtener longitud

Acceso por índice

Buscar dentro de un string

Extraer una porción (slice / substring)

Dividir un string (split)

Concatenar strings

5. ¿Cuál es la complejidad Big O de las operaciones con strings?

Conclusión

npm install puede infectar tu máquina: cómo protegerte

¿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 construir un videojuego usando Kiro

Vibecoding

La idea

Conceptos rápidos

Tu `.npmrc` defensivo mínimo

¿Cómo funciona `trustPolicy`?