DEV Community: Axel Espinosa

Qué es un hashmap y por qué es tan rápido

Axel Espinosa — Tue, 02 Jun 2026 17:19:59 +0000

Cuando escribes localStorage.getItem("token"), el navegador busca por clave de forma directa, sin recorrer todo. Esa idea de "dame el valor de esta clave" sin pasar por toda la estructura es lo que hace un hashmap.

En los artículos anteriores vimos arrays y strings. Ambos son secuencias: para encontrar algo, recorres elemento por elemento, y eso es O(n). Los hashmaps resuelven ese problema de una forma bastante elegante.

Lo que encontrarás en este artículo:

Qué es un hashmap y por qué importa

Qué hace una función hash y qué propiedades tiene

Cómo funciona por debajo: buckets, colisiones y cómo se resuelven

Load factor y rehashing

Big O y por qué el O(1) tiene un asterisco

1. ¿Qué es un hashmap?

Un hashmap almacena pares clave-valor. Tú le das una clave, él te devuelve el valor asociado.

Piénsalo como un casillero con etiquetas. Cada casillero tiene una etiqueta (la clave) y adentro hay algo guardado (el valor). Para abrir el casillero de "token", no revisas todos los casilleros uno por uno, vas directo al que tiene esa etiqueta.

Eso es lo que diferencia a un hashmap de un array. Los arrays buscan por índice numérico: array[0], array[5]. Los hashmaps buscan por cualquier clave: "nombre", "email", "token". Y el tiempo de búsqueda es prácticamente el mismo sin importar cuántos pares haya guardados.

En distintos lenguajes lo conoces con nombres diferentes, aunque todos hacen lo mismo:

Lenguaje	Nombre
Python	`dict`
JavaScript	`Map`
Java	`HashMap`
Go	`map`

En JavaScript se usa así:

const mapa = new Map();
mapa.set("token", "abc123");
mapa.set("userId", 42);

console.log(mapa.get("token")); // "abc123"

2. ¿Qué hace la función hash?

¿Cómo hace el hashmap para ir directo al valor sin recorrer todo? Por debajo, un hashmap vive sobre un array, y los arrays solo entienden índices numéricos. Entonces necesitamos convertir la clave "token" en un número. Eso pasa en dos pasos.

Primero, la función hash toma la clave y devuelve un hash code, que es un número (puede ser muy grande):

hash("token")  → 8472361
hash("nombre") → 23847
hash("email")  → 91234

Después, ese número se reduce al rango de buckets disponibles. Si el array tiene 8 buckets, lo más común es aplicar módulo:

8472361 % 8 = 1
23847   % 8 = 7
91234   % 8 = 3

Ese resultado sí es el índice del bucket donde se guarda el par. Por eso los tamaños del array casi siempre son potencias de 2.

Para que una función hash sea útil, necesita tres propiedades:

Determinista. La misma clave siempre produce el mismo número. Si hash("token") hoy devuelve 1, mañana también devuelve 1. Sin esto, nunca encontrarías lo que guardaste.

Distribución uniforme. Los resultados deben repartirse de forma pareja entre todos los buckets disponibles. Si todos los valores caen en el mismo índice, el hashmap pierde su ventaja.

Rápida de calcular. La función hash se ejecuta en cada lectura y escritura. Si fuera lenta, arruinaría el O(1).

Nota: la función hash de un hashmap no es lo mismo que el hashing criptográfico (SHA-256, bcrypt). El criptográfico está diseñado para ser difícil de revertir y resistente a ataques, mientras que el de un hashmap solo necesita ser rápido y distribuir bien.

3. ¿Cómo funciona un hashmap por debajo?

Ya sabemos que el hashmap vive sobre un array y que la función hash, junto con el módulo, convierte claves en índices. Veamos qué pasa en la práctica.

Buckets

Cada posición del array interno se llama bucket. El hashmap empieza con un tamaño fijo, generalmente una potencia de 2 (8, 16, 32...). Cuando guardas un par clave-valor, el índice resultante decide en qué bucket cae.

Colisiones

El espacio de claves posibles es enorme (cualquier string, número, objeto), pero el número de buckets es finito, así que tarde o temprano dos claves distintas van a caer en el mismo bucket. Puede pasar porque la función hash devolvió el mismo número, o porque devolvió números distintos que al aplicar el módulo cayeron en el mismo índice. Eso es una colisión, y manejarla bien es parte de cualquier implementación seria de hashmap.

hash("token") % 8 = 1
hash("rol")   % 8 = 1  ← colisión

Chaining (encadenamiento)

Una estrategia clásica es que cada bucket no guarde un solo par, sino una lista de todos los pares que cayeron ahí. Cuando hay colisión, el nuevo par se agrega a la lista del bucket.

Para buscar, vas al bucket correcto y recorres la lista hasta encontrar la clave exacta.

Open addressing (direccionamiento abierto)

La otra estrategia es que si el bucket está ocupado, buscas el siguiente disponible. No hay listas, todos los pares viven directamente en el array.

Hay varias formas de "buscar el siguiente":

Linear probing: revisa el siguiente bucket, luego el siguiente, y así.
Quadratic probing: salta de forma cuadrática (1, 4, 9, 16...) para evitar agrupar colisiones.
Double hashing: aplica una segunda función hash para calcular el salto.

4. ¿Cuándo crece un hashmap? Load factor y rehashing

Hay un número que el hashmap monitorea constantemente: el load factor.

load factor = elementos guardados / número de buckets

Si tienes 8 buckets y 6 elementos guardados, tu load factor es 0.75. Cuando ese número supera cierto umbral (0.75 es el valor típico), el hashmap sabe que está demasiado lleno y que las colisiones van a empezar a afectar el rendimiento.

Cuando eso pasa, hace rehashing: crea un array interno más grande (generalmente el doble) y redistribuye los pares existentes. Como numBuckets cambió, el mismo hash code aplicado al módulo cae en un índice distinto, así que cada par puede terminar en otro bucket.

5. ¿Cuál es el Big O de un hashmap?

Operación	Caso promedio	Peor caso
`set(k, v)`	O(1)*	O(n)
`get(k)`	O(1)	O(n)
`delete(k)`	O(1)	O(n)
`has(k)`	O(1)	O(n)

* Amortizado. Ocasionalmente O(n) cuando ocurre un rehashing.

El peor caso O(n) existe, pero es teórico en la práctica. Ocurre cuando todas las claves caen en el mismo bucket, y como dentro de ese bucket toca recorrer todos los pares para encontrar el correcto, la búsqueda termina siendo lineal. Con una buena función hash y un load factor controlado, eso no pasa.

Con implementaciones modernas estás casi siempre en O(1), y esa es la razón por la que los hashmaps son la primera herramienta que buscas cuando necesitas búsquedas rápidas. Buscar en un array es O(n) porque tienes que recorrerlo, buscar en un hashmap con la clave es O(1), y esa diferencia se vuelve enorme cuando tienes miles o millones de elementos.

La próxima vez que uses localStorage.getItem("token"), ya sabes qué está pasando por debajo.

Si el artículo te sirvió, deja un ❤️ y nos vemos en el siguiente. 🙌🏻

Cómo empezar a usar Node.js

Axel Espinosa — Mon, 01 Jun 2026 22:16:20 +0000

Empezar con Node.js es muy sencillo. No necesitas aprender un lenguaje de programación nuevo, utilizas JavaScript. Vamos a ver qué necesitas para comenzar con Node.js.

¿Si ya sé JavaScript puedo usar Node?

Me acuerdo la primera vez que vi a alguien utilizando Node.js en el 2015 y se me hizo súper complicado entenderlo pero eso fue porque no sabía mucho de JavaScript. Lo mínimo que debes saber es esto:

Callbacks
Promesas (debes entender qué son y lo básico. No necesitas comprender todo lo que pasa por debajo)
Async/Await
Timers (setTimeout, setInterval)
Fundamentos de JavaScript (arrays, strings, loops, entre otros)

Como ves, necesitas únicamente saber JavaScript porque trabajar con Node.js no significa que vas a utilizar un lenguaje nuevo.

Usar Node.js es como si escribieras JavaScript en la consola del DevTools de Chrome, la diferencia es que al usar Node.js nosotros podemos aprovechar la máquina donde va a ejecutarse nuestro JavaScript.

Obtendremos acceso al sistema de archivos, a la red, a los procesos del sistema operativo, entre otras cosas.

Por supuesto, Node.js tiene diferencias al momento de ejecutar el código que escribes pero eso se presta para un tema avanzado que podemos cubrir más adelante.

¿Cómo instalar Node.js?

Perfecto, espero que ya estés emocionad@ después de saber que no necesitas aprender un lenguaje nuevo y que puedes utilizar el JavaScript que ya aprendiste. Pero antes debemos instalar Node.js.

¿Cómo que instalar? Así es, necesitamos instalar el ambiente de ejecución. Piensa en esto como si estuvieras descargando un navegador nuevo, la diferencia es que en vez de navegar en páginas, esta plataforma te da acceso a controlar la computadora con JavaScript.

Un dato interesante es que Chrome utiliza algo llamado V8, es el sistema que hace posible que JavaScript se ejecute y Node.js también utiliza ese sistema.

Para instalar Node.js, dependiendo del sistema operativo que utilices necesitarás descargar el instalador o usar la línea de comandos.

Vamos a cubrir la instalación usando la línea de comandos, si no te sientes cómod@ puedes usar el instalador pero yo te invito a que le pierdas el miedo a la terminal ya que te ayuda a ser más versátil.

Instalar NVM

Al querer instalar Node.js vas a darte cuenta que existen muchas versiones y quizás cuando ya tengas varios proyectos con Node.js vas a tener que usar diferentes versiones en cada uno de ellos. Y ese es un problema porque sería muy incómodo instalar la versión que necesitas y después desinstalarla para usar otra.

Por eso se crearon los manejadores de versiones de Node.js. NVM es una herramienta que te permite cambiar entre versiones de Node.js sin tener que eliminar la que ya tenías y así poder trabajar en proyectos que requieran distintas versiones.

Para instalar NVM es muy sencillo, únicamente necesitamos seguir los pasos del readme.

Este es un ejemplo de lo que encuentras en el readme. Abres la terminal y ejecutas el comando, después necesitas reiniciar la terminal. Puedes abrir y cerrarla si se te hace más fácil.

Antes de copiar y pegar revisa cual es la ultima versión en el Readme. Si tiene menos de 1 día es preferible instalar la versión anterior a esa.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

Instalar Node.js

Ya que tienes NVM deberías de tener acceso a un comando en tu terminal llamado nvm.

Una vez que logres instalar NVM podemos instalar Node.js.

Si te gustaría que haga un blog acerca de nvm déjalo en los comentarios.

Con el siguiente comando instalarás la versión LTS (Long Term Support), es decir, la versión activa de Node.js que está recibiendo actualizaciones de seguridad, features, etc.

nvm install --lts

En mi terminal al ejecutar el comando puedo ver esto:

Ejecuta tu primer hola mundo

¡Listo! Ya tenemos Node.js descargado, usamos NVM para manejar las versiones de Node.js. Entonces, si quisieras utilizar una versión distinta únicamente instalas la versión y utilizas el comando nvm use <version> y nvm se encarga de cambiar de versión por ti.

Ahora si ejecutas node -v deberías ver la versión que estás ejecutando:

Después puedes ejecutar esto para ver el primer hola mundo usando Node.js:

node -p 'console.log("hello world")'

Debería verse algo así:

Cierre

Listo, ya tenemos instalado Node.js y estás list@ para comenzar con tus proyectos. En los siguientes artículos seguiremos con más temas de Node.js para que te conviertas en expert@.

Déjame en los comentarios qué fue lo que más te gustó o si tienes alguna pregunta escríbeme en instagram @fromchiapasdev.

Stacks en entrevistas técnicas: 3 problemas resueltos paso a paso

Axel Espinosa — Wed, 27 May 2026 17:53:28 +0000

Cuando empecé a resolver problemas de LeetCode cada uno se sentía como un mundo nuevo. Me costó un rato darme cuenta de que la mayoría se agrupan por estructura, y que si reconoces el patrón el problema se desarma solo. Hoy le toca a los stacks.

En el artículo anterior vimos cómo funcionan los stacks por debajo. Hoy usamos esa base para resolver tres problemas clásicos.

Lo que vas a encontrar:

Tres problemas resueltos paso a paso: balanced parentheses, reverse string y simplify path

Dónde aparecen los stacks fuera de las entrevistas

Recordatorio rápido

LIFO: el último que entra es el primero que sale. push agrega al tope, pop saca del tope. En JavaScript un array ya funciona como stack. Si necesitas el detalle completo, está en el artículo anterior.

Vamos a los problemas.

Problema 1: Balanced Parentheses

"Valid Parentheses" de LeetCode.

Problema: dado un string s con solo ()[]{}, determina si es válido. Cada apertura debe tener su cierre correspondiente y en el orden correcto.

Ejemplos

Input:  "()[]{}"   → true
Input:  "([)]"     → false
Input:  "{[]}"     → true

¿Cómo lo pensamos?

"El último que abrió es el primero que debe cerrarse." Justo eso es lo que un stack hace bien.

Recorremos el string. Cada apertura va al stack. Cada cierre debe coincidir con el tope. Si al final el stack queda vacío, todo cerró bien.

Solución

function validParentheses(s) {
  const stack = [];
  const pairs = { ")": "(", "}": "{", "]": "[" };

  for (const char of s) {
    if (char === "(" || char === "{" || char === "[") {
      stack.push(char);
    } else if (stack.pop() !== pairs[char]) {
      return false;
    }
  }

  return stack.length === 0;
}

Lo importante:

pairs mapea cada cierre con su apertura.
Aperturas van al stack. Cierres hacen pop y validan.
Si el stack está vacío al hacer pop, devuelve undefined y la comparación falla. Cómodo, así no necesitamos un chequeo extra.
Al final, el stack debe estar vacío.

Complejidad: O(n) tiempo y O(n) espacio.

Problema 2: Reverse String (easy)

Adaptación de "Reverse String" de LeetCode. Vamos a invertir una palabra usando stack.

Problema: dado un string s, devuelve el string invertido.

Ejemplos

Input:  "stack"   → "kcats"
Input:  "hello"   → "olleh"

¿Cómo lo pensamos?

"Invertir" es la pista. Metes los elementos en orden y los sacas en orden inverso. Eso es exactamente lo que hace un stack.

En la vida real usarías s.split("").reverse().join("") y listo. Aquí lo hacemos con stack para ver el patrón en acción.

Solución

var reverseString = function (s) {
  const stack = [...s]; // crea un stack con los caracteres
  let reversed = "";

  while (stack.length > 0) {
    reversed += stack.pop();
  }

  return reversed;
};

Metemos todos los caracteres al stack y los vamos sacando uno por uno. Como pop devuelve el último que entró, los caracteres salen al revés.

Complejidad: O(n) tiempo y O(n) espacio.

Problema 3: Simplify Path (medium)

"Simplify Path" de LeetCode.

Problema: dada una ruta absoluta de Unix, conviértela a su forma canónica.

Reglas:

. es el directorio actual.
.. sube un nivel.
// se trata como /.
El resultado no termina en /, salvo la raíz.

Ejemplos

Input:  "/home//foo/"       → "/home/foo"
Input:  "/../"              → "/"
Input:  "/a/./b/../../c/"   → "/c"

¿Cómo lo pensamos?

¿Qué hace ..? Nos regresa al directorio anterior. Ahí está la señal, necesitamos recordar por dónde pasamos y poder retroceder.

Partimos la ruta por / y recorremos cada componente:

"" o ".", ignora.
"..", saca el tope del stack.
Cualquier otra cosa es un directorio y va al stack.

Al final, el stack contiene los directorios de la ruta simplificada.

Solución

var simplifyPath = function (path) {
  const stack = [];

  for (const part of path.split("/")) {
    if (part === "" || part === ".") continue;
    if (part === "..") stack.pop();
    else stack.push(part);
  }

  return "/" + stack.join("/");
};

Tip: en JavaScript, pop sobre un stack vacío no rompe nada, solo devuelve undefined. Así que si la ruta intenta subir más allá de la raíz, no hace falta validación extra.

Complejidad: O(n) tiempo y O(n) espacio.

El patrón detrás de los tres

Si los lees seguidos vas a notar lo mismo. Los tres resuelven el mismo problema de fondo, poder regresar a algo anterior.

Balanced parentheses: recordar la última apertura para validar el cierre.
Reverse string: regresar al orden opuesto.
Simplify path: .. regresa un nivel.

Ese es el superpoder del stack. Cuando un problema te pide recordar lo último, deshacer algo o procesar de atrás hacia adelante, casi siempre la respuesta es stack.

Stacks más allá de las entrevistas

Los stacks no son trivia de entrevistas. El patrón de "regresar" aparece por todos lados:

El botón de regresar del navegador es un stack.
El undo/redo de tu editor también.
Los call stacks de los lenguajes (por eso existen los stack overflow errors).
Pipelines de datos que necesitan mantener contexto de lo último visto.

Para seguir practicando

Problemas de LeetCode ordenados por dificultad:

Min Stack, easy.
Baseball Game, easy.
Evaluate Reverse Polish Notation, medium.
Daily Temperatures, medium. Es la intro al patrón de monotonic stack.

¿Cuál te costó más? Déjamelo en los comentarios. A mí Simplify Path me hizo dar más vueltas para resolverlo.

Cómo destacar como JR DEV en tu equipo

Axel Espinosa — Tue, 26 May 2026 19:33:38 +0000

Cuando entré a mi primer trabajo de desarrollador venía con una idea muy clara de lo que iba a hacer. Patrones de diseño, arquitectura, UML, escribir código limpio desde cero. Llegué con la mochila llena de cosas que aprendí en la escuela y en cursos.

A los pocos días me di cuenta de que la realidad era otra.

No estoy diciendo que lo que aprendí no sirviera. Sirve, y mucho. Pero el trabajo del día a día no se parecía a los proyectos personales ni a los ejercicios de clase. Era otra cosa.

Lo que te comparto aquí está basado en mi experiencia. Son cosas que viví, errores que cometí, y aprendizajes que fui agarrando con el tiempo. Si vas entrando a tu primer trabajo o llevas pocos meses, espero que te sirva para no chocar con los mismos muros que yo y para crecer más rápido de lo que yo lo hice.

Resumen rápido: aprende a leer código ajeno, propón cambios con argumentos, escribe pruebas útiles, documenta lo que aprendes, pregunta antes de programar, entiende el negocio, pide ayuda rápido, habla en los meetings, lleva registro de lo que haces y únete a comunidades. Suena obvio, pero nadie te lo dice antes.

1. Aprende a leer código ajeno

Cuando entré a mi primer trabajo pensé que iba a diseñar sistemas desde cero. Arquitectura hexagonal, Clean Code, patrones de diseño. Pasé semanas leyendo código que escribió alguien que ya ni trabaja en la empresa, intentando entender por qué tal función hacía lo que hacía.

Al principio me frustré. Después entendí que eso era el trabajo.

La mayor parte del tiempo vas a mejorar lo que otras personas ya hicieron. Agregar un pedacito, arreglar lo que está roto sin romper lo que sí funciona. Y mientras más rápido aprendas a leer código ajeno, más rápido vas a entender el sistema completo y más valor vas a aportar.

Esa habilidad, leer código, es lo que te diferencia en los primeros meses. No el framework que conoces ni los patrones que estudiaste.

Acción: cuando entres a un proyecto nuevo, dale dos o tres días solo a leer. Sin tocar nada. Toma notas, dibuja diagramas a mano, anota dudas. Vas a avanzar más rápido cuando empieces a programar.

2. Aprende a proponer cambios con argumentos, no con opiniones

Cuando llegué a una empresa me encontré con proyectos legacy enormes. Monolitos de los que dependían muchas otras cosas y muchos otros equipos. Yo quería proponer migrar a microservicios, actualizar el framework, modernizar todo.

Nadie me hizo caso. Y tenían razón.

Mover un sistema así puede tomar meses. A veces años. Y mientras tanto el negocio sigue corriendo, los clientes siguen pagando. Nadie va a detener eso para esperar a que termines de migrar.

Lo que aprendí es que la diferencia entre un JR que propone cosas y uno que las ve implementadas es cómo las presenta. Una opinión es "deberíamos actualizar esto". Un argumento es "esta versión tiene una vulnerabilidad de seguridad conocida, migrar nos tomaría dos sprints, y si no lo hacemos corremos este riesgo".

Acción: antes de proponer una actualización o migración, prepara tres cosas: el problema concreto que resuelve, el costo estimado en tiempo, y el riesgo de no hacerlo. Con eso tienes una conversación real con tu equipo.

3. Escribe pruebas que de verdad prueben algo

Yo venía con la idea de que las pruebas unitarias eran sagradas. Llegué pensando que iba a encontrar suites de tests bien hechas, con cobertura útil, validando edge cases.

Lo que me encontré fue otra cosa. Pruebas que validan cosas obvias. Pruebas con mocks tan cargados que terminan probando el mock y no el código. Pruebas escritas únicamente para llegar al 80% de cobertura que pide el pipeline. Y nadie las entiende porque las escribió alguien que ya se fue.

Aquí está la oportunidad. Cuando el equipo tiene esa cultura, tú puedes destacar haciendo lo contrario. Escribe pruebas que cubran los casos donde el código se puede romper. Que un compañero pueda leerlas y entender qué están validando.

Va a tomar más tiempo que copiar el patrón malo del repo. Pero te va a salvar de bugs en producción, y poco a poco la gente del equipo se da cuenta y empieza a hacer lo mismo.

Acción: la próxima vez que escribas una prueba, hazte esta pregunta antes de terminar: "¿si alguien rompe esta función, mi prueba lo detecta?" Si la respuesta es no, reescríbela.

4. Documenta lo que aprendes, aunque nadie te lo pida

He trabajado en proyectos donde el README dice cosas que dejaron de ser ciertas hace dos años. En otros, el README es solo el comando de instalación. Y en algunos, no hay nada.

Eso es una oportunidad.

Cuando eres el nuevo y te toca entender el sistema desde cero, cada cosa que descubres tiene valor. Por qué tal servicio hace lo que hace, cómo se conecta con el otro, qué pasa si falla. Escríbelo. En una wiki interna, Confluence, Notion, donde sea, pero que todo el equipo pueda verlo.

Esto te sirve a ti porque dentro de seis meses no te vas a acordar. Le sirve a la persona nueva que va a entrar. Y cuando la gente ve que tú escribes documentación, algunos empiezan a hacer lo mismo.

No te desanimes si al principio nadie la lee. La vas a usar tú primero, y eso ya justifica el esfuerzo.

Acción: esta semana, cuando resuelvas algo que no estaba documentado, escríbelo. Una sola entrada. Dónde está, qué hace, por qué funciona así. Cinco minutos. Eso es todo.

5. Pregunta antes de programar

A mí me pasó muchas veces que recibí un ticket con pasos detallados, lo hice al pie de la letra, y al final el usuario decía "no, eso no era lo que necesitaba". Es frustrante para los dos.

El problema no era el código. Era que nunca pregunté para qué servía lo que estaba construyendo.

Los tickets ambiguos son normales. "Agregar botón de exportar" sin decir qué exporta, en qué formato, quién lo va a usar. Una lista de pasos sin contexto del problema que están tratando de resolver. Eso va a pasar siempre. La diferencia está en si arrancas a programar de inmediato o si primero entiendes qué estás resolviendo.

Cuando un ticket no tiene contexto suficiente, pregunta. ¿Para qué se va a usar esto? ¿Qué problema resuelve? ¿Qué pasa si no lo hacemos? Muchas veces salen detalles que el ticket no decía, y a veces descubres que la solución que pedían no era la que necesitaban.

Acción: la próxima vez que recibas un ticket, antes de abrir el editor, escribe en dos oraciones qué problema resuelve y para quién. Si no puedes, el ticket está incompleto y hay que preguntar.

6. Entiende el negocio detrás del software

Esto está conectado con el punto anterior, pero va más allá.

Conocer el negocio te hace mejor desarrollador. Suena raro, pero es cierto. Cuando entiendes para qué se va a usar lo que estás construyendo, qué clientes lo van a tocar, cuánto vale para la empresa, tomas mejores decisiones técnicas.

Te pongo el caso del ticket. Si el ticket sí tiene una definición completa, igual vale la pena cuestionar. ¿Esto es bueno para el usuario final? ¿Hay otra parte del sistema que se va a ver afectada con este cambio? ¿Existe una solución más simple que la que están proponiendo?

Cuando haces estas preguntas dejas de ser solo el que ejecuta tickets y empiezas a aportar al producto. Eso es lo que te diferencia. Tu manager se va a dar cuenta. Tu equipo también.

Y para entender el negocio no tienes que meterte en cursos de business ni leer libros de estrategia. Solo platica con la gente de producto, con soporte, con ventas. Pregúntales qué problemas tienen los clientes. Mete la nariz en las métricas del producto si tienes acceso. En poco tiempo vas a ver resultados.

Acción: agenda una llamada de 30 minutos con alguien de producto o soporte. Solo para escuchar. Pregúntales qué es lo que más les reportan los clientes. Esa conversación te va a cambiar cómo ves tu trabajo.

7. Pide ayuda rápido

Este es el punto que a mí me hubiera gustado escuchar más temprano.

Yo soy bastante necio con los problemas. Me encanta resolverlos por mi cuenta, sentir el placer de cerrar las 45 pestañas de Stack Overflow después de horas peleando con un bug. Pero esto a veces juega en contra.

Pasa así. Te trabas en algo, te das cuenta de que no avanzas, pero te sientes mal pidiendo ayuda. Entonces sigues intentando. Pasan dos horas. Cuatro. Un día. Y al final pides ayuda y resulta que alguien del equipo lo había visto antes y te lo resolvía en quince minutos.

Lo que hago ahora es ponerme un timebox. Una o dos horas máximo intentándolo solo. Si no resuelvo, pido ayuda. Eso le ahorra tiempo al equipo y a mí.

Y cuando pidas ayuda, hazlo bien. No llegues con "no me funciona". Llega con "estoy intentando hacer X, probé Y y Z, esperaba que pasara A pero pasa B, aquí está el error". Eso le ahorra tiempo a quien te ayuda y aprendes a estructurar problemas.

Acción: pon un timer de una hora la próxima vez que te trabes. Si suena y no resolviste, para y pide ayuda. Sin culpa.

8. No tengas miedo de hablar en los meetings

Cuando entré a trabajar me quedaba callado en las llamadas. Esperaba a que alguien con más experiencia hablara y yo solo asentía. Tenía miedo de equivocarme, de decir algo tonto, de que la gente pensara que no sabía.

Después de un tiempo le pregunté al senior del equipo qué me hacía falta para crecer. Una persona con la misma experiencia que yo había sido promovida y yo no. Me dijo: "casi no hablas en las llamadas".

Me explicó que no se trataba de hablar por hablar. Era dar mi opinión, cuestionar cuando no estaba de acuerdo, proponer ideas. No solo aceptar todo lo que decían los demás.

Esto fue duro de aceptar. Pero tenía razón.

Empecé a forzarme a hablar. Aunque tuviera miedo. Aunque pensara que mi idea no era tan buena. Y la verdad es que muchas veces me equivoqué. Pero también muchas veces aporté algo útil que nadie había considerado.

Hoy en día sigo sintiendo nervios antes de hablar en juntas grandes. Sigue ahí ese miedo. Pero también recuerdo que cada vez que aporto, construyo confianza con mi equipo. Y eso es lo que hace que la gente te tome en serio.

Acción: en tu próxima junta, di una cosa. Una opinión, una pregunta, una duda. Solo una. No tienes que resolver todo, solo participar.

9. Lleva un registro de tus contribuciones

Este punto no me lo enseñaron nunca y es probablemente el más importante para destacar.

Tu equipo y tu manager necesitan saber qué haces. Suena obvio, pero no lo es. Por más que pensemos que los demás se acuerdan de lo que hicimos, no es así. La gente tiene su propio trabajo, sus propios problemas, sus propias prioridades.

Lleva un documento, en Word, Notion, Notes, donde sea, y anota tus contribuciones cada semana. No tiene que ser elegante, solo tiene que existir.

La forma en que lo escribas importa. Si solo anotas tareas, te sirve poco. Si lo enfocas en impacto, te sirve mucho.

Compara estos dos:

- Llamada con Juan

- Apoyé a Juan a resolver un error en el sistema de pagos.
  Esto desbloqueó el proceso de cobros que llevaba 2 semanas
  fallando para 200 clientes.

Las dos describen la misma reunión. Pero la segunda te ayuda en performance reviews, en conversaciones con tu manager, en negociaciones de aumento. Cuando llega el momento de demostrar tu valor, este documento es oro.

Cuando te llamen para una entrevista futura, vas a tener un registro real de lo que hiciste. Sin tener que pensar "¿qué hice los últimos dos años?".

Acción: abre un documento ahora y escribe tres cosas que hiciste esta semana, enfocadas en impacto. Si no recuerdas tres, escribe una. El hábito empieza con una entrada.

10. Únete a comunidades

Todo lo anterior pasa dentro de tu equipo. Pero crecer rápido también pasa por la gente que conoces fuera de él.

Las comunidades son ese espacio donde aprendes cosas que en tu empresa nadie usa, ves cómo otras personas resuelven los mismos problemas que tú, y conoces gente que después se convierte en tu red. Esa red te abre puertas que un CV nunca te va a abrir. Recomendaciones, oportunidades de trabajo, mentores, amigos que la pasaron mal con el mismo bug que tú.

¿Pero dónde encuentro comunidades? Una opción es AWS Builder Center. Ahí encuentras grupos de usuarios por ciudad, student builder groups que son comunidades lideradas por estudiantes, y eventos donde puedes ir a aprender o presentar.

No tienes que llegar a hablar en un meetup el primer día. Empieza yendo a escuchar. Después haz una pregunta. Después platica con alguien al final del evento. Y un día te das cuenta de que ya conoces a varias personas y aprendiste cosas que ni en el trabajo ni en cursos ibas a aprender.

Acción: entra a AWS Builder Center, busca un grupo en tu ciudad o un student builder group, y anótate al próximo evento. Solo ir ya cuenta.

Cierre

Si tuviera que resumir todo en una idea, sería esta. Ser un buen JR no es saber más que los demás. Es leer código con paciencia, hablar con la gente, escribir lo que aprendes y llevar cuenta de lo que haces.

Lo demás llega con el tiempo.

Cada punto de este artículo tiene una acción concreta. No tienes que hacer las diez esta semana. Elige una, aplícala, y cuando ya sea hábito agrega otra. Si me preguntas por dónde empezar, empieza por el registro de contribuciones. Es el de menor fricción y el que más rendimiento te va a dar a largo plazo.

¿Cuál de estos puntos te resuena más? ¿O hay algo que tú hayas aprendido en tu primer trabajo que no está aquí? Déjamelo en los comentarios, me interesa leerlo.

Y si quieres seguir la conversación, me encuentras en Instagram como @fromchiapasdev.

Why you keep attacking npm?

Axel Espinosa — Tue, 12 May 2026 22:39:43 +0000

Honestly, it's exhausting to wake up and find out there's yet another attack on the npm ecosystem.

Socket shared via social media that they identified compromised packages — some of them were TanStack.

Why are attackers so obsessed with npm? Seriously, can you stop already?

If you still use npm and haven't disabled post-scripts, you're in serious danger.

Go and disable that right now.

Start using pnpm. Version 11 disables this functionality by default. Of course, some packages still need post-scripts, and in those cases you should manually review and authorize them.

Also, there are tools you can use before installing a package: Socket's sfw and npq.

Hope this helps.

Can you stop attacking #npm packages? I'm scared of installing packages. Now it's time to switch 100% to PNPM...

Axel Espinosa — Tue, 12 May 2026 22:21:32 +0000

¿Qué son los Stacks (LIFO)?

Axel Espinosa — Fri, 08 May 2026 21:22:09 +0000

¿Alguna vez te has preguntado qué pasa cuando presionas el botón "atrás" en tu navegador? ¿O cómo Ctrl + Z sabe exactamente qué acción deshacer? Detrás de esas funciones hay una estructura de datos que llevas años usando sin darte cuenta: el stack.

En los artículos anteriores vimos los arrays y los strings. Hoy toca hablar de la siguiente pieza: los stacks. Si los arrays son el almacén general, el stack es una pila de platos. Ya lo vas a ver.

Lo que encontrarás en este artículo:

Qué es un stack y qué significa LIFO

Las operaciones básicas: push, pop, peek, size, isEmpty

Cómo implementar tu propio stack en JavaScript

La complejidad Big O de cada operación

Dónde se usan los stacks en la vida real

¿Qué es un stack?

Un stack (o pila) es una estructura de datos que sigue el principio LIFO: Last In, First Out. En español: el último que entra es el primero que sale.

Imagina una pila de libros sobre tu escritorio. Vas apilándolos uno sobre otro. Cuando quieres leer uno, ¿por cuál empiezas? Por el de arriba, no por el de abajo. El último libro que pusiste es el primero que vas a tomar.

Esa es la esencia de un stack. No puedes sacar un elemento del medio o del fondo. Solo trabajas con el que está hasta arriba.

Pero aquí viene el detalle interesante: aunque suene restrictivo, esta limitación es justo lo que hace al stack útil. Cuando solo te importa el último elemento agregado, un stack es la herramienta perfecta.

Operaciones básicas de un stack

Un stack tiene cinco operaciones fundamentales. Estas son las que aparecen en el ADT (Abstract Data Type) de un stack:

push(item): agrega un elemento a la parte superior
pop(): elimina el elemento de arriba y lo devuelve
peek(): mira el elemento de arriba sin eliminarlo
size(): devuelve cuántos elementos hay en el stack
isEmpty(): dice si el stack está vacío o no

Las dos estrellas son push y pop. Con ellas agregas y quitas elementos, siempre desde la misma puerta: la de arriba.

Fíjate en cómo pop() siempre saca el último que entró. En el paso 3 agregamos 🐱, y en el paso 4 pop() nos devuelve 🐱. Si hubiéramos hecho pop() otra vez, nos devolvería 🐶.

Cómo implementar un stack en JavaScript

Dato curioso antes de empezar: los arrays en JavaScript ya se comportan como un stack. Si haces miArray.push(x) y miArray.pop(), estás trabajando como si fuera un stack..

Pero un array te deja hacer cosas que un stack no debería permitir: acceder por cualquier índice, unshift, splice, lo que quieras. Y esa libertad de más es justo lo que queremos esconder.

Así que vamos a implementarlo desde cero. Sin usar .push() ni .pop() del array. Solo lo vamos a usar como almacenamiento indexado y el control lo lleva nosotros. Así se ve qué pasa por debajo.

class Stack {
  constructor() {
    this.items = [];
    this.count = 0; // posición donde iría el próximo elemento
  }

  push(item) {
    this.items[this.count] = item;
    this.count++;
  }

  pop() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    this.count--;
    const item = this.items[this.count];
    this.items.length = this.count; // recortamos el array
    return item;
  }

  peek() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    return this.items[this.count - 1];
  }

  size() {
    return this.count;
  }

  isEmpty() {
    return this.count === 0;
  }
}

Probemos cómo se usa:

const miStack = new Stack();

miStack.push("🐶");
miStack.push("🐱");
miStack.push("👻");

console.log(miStack.size()); // 3
console.log(miStack.peek()); // "👻" (solo mira, no elimina)
console.log(miStack.pop()); // "👻" (lo elimina y devuelve)
console.log(miStack.size()); // 2
console.log(miStack.isEmpty()); // false

Así se ve el stack en cada paso:

Puedes probar este código en RunJS o verlo paso a paso en PythonTutor, que también soporta JavaScript.

Vamos a desarmar lo que está pasando:

count lleva la cuenta de cuántos elementos hay. También indica la siguiente posición libre del array. Recuerda que los arrays empiezan en el índice 0, así que cuando el stack está vacío count vale 0 y ese es justo el lugar donde va a caer el primer elemento.
push() coloca el nuevo elemento en la posición count y luego incrementa el contador.
pop() hace lo contrario: decrementa count primero (ahora apunta al último elemento), lee ese valor y recorta el array.
peek() lee la posición count - 1 (el último elemento) sin mover nada.

Por ejemplo, si hacemos push("🐶"), push("🐱"), push("👻"), el array queda así:

Cuando hacemos pop(), el contador baja de 3 a 2 y leemos items[2] que es 👻. Luego hacemos this.items.length = 2 para recortar el array, y listo.

Un truco de los arrays en JavaScript

Fíjate en esta línea: this.items.length = this.count. Podría parecer que solo estamos "cambiando un número", pero en realidad estamos modificando el array. En JavaScript, asignarle un valor menor a .length recorta el array y elimina los elementos que sobran.

Míralo por fuera de la clase:

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

console.log(numbers.length); // 5

// Definir la longitud
numbers.length = 3;

console.log(numbers); // [1, 2, 3]
console.log(numbers.length); // 3
console.log(numbers[3]); // undefined (los elementos extra se eliminan)

Este es un detalle que muchos desarrolladores desconocen y te abre posibilidades interesantes. En nuestra clase lo usamos para asegurarnos de que el array y el contador count siempre estén sincronizados.

Si te fijas, no usamos los métodos push y pop del array nativo de JavaScript. Solo lo usamos como almacenamiento indexado. Todo el control lo lleva nuestra variable count.

Complejidad Big O de las operaciones

Ya vimos qué hace cada operación. Ahora, ¿cuánto cuestan? Aquí es donde entra Big O, la notación que nos dice cómo crece el tiempo de una operación conforme crece el stack.

Operación	Complejidad en tiempo	Complejidad en espacio
`push()`	O(1)*	O(1)
`pop()`	O(1)	O(1)
`peek()`	O(1)	O(1)
`size()`	O(1)	O(1)
`isEmpty()`	O(1)	O(1)

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

Todas las operaciones de un stack son O(1). ¿Por qué? Porque siempre trabajamos con un solo elemento: el de arriba. No importa si el stack tiene 10 o 10 millones de elementos, push y pop tardan lo mismo.

Compara esto con un array, donde insertar al inicio es O(n) porque hay que mover todos los elementos. En un stack no tenemos ese problema porque solo tocamos la punta.

Esta es la razón principal por la que los stacks se usan tanto: son rápidos y predecibles. Si tu problema solo necesita trabajar con el último elemento agregado, un stack te da esa operación en tiempo constante.

Eso sí, rápido no quiere decir infinito. Un stack vive en memoria, así que si crece demasiado va a depender por completo de los recursos del dispositivo donde corra. En celulares, tablets y computadoras con poca RAM esto importa más de lo que crees: un stack que crece sin control puede tronar la app. Los lenguajes hasta tienen un límite específico para el call stack, y si lo rebasas te topas con el famoso stack overflow.

¿Dónde se usan los stacks en la vida real?

Antes de ver ejemplos, quédate con esto:

Regla de oro: cuando lo único que te importa es el último elemento, un stack es la respuesta.

Todo lo que viene a continuación es una variante del mismo patrón. Una vez que lo ves, empiezas a reconocer stacks en todos lados.

Navegador web: botón de "atrás"

Cada vez que visitas una página nueva, el navegador hace push() con la URL. Cuando presionas "atrás", hace pop() y te lleva a la página anterior.

Funciona perfecto porque siempre quieres volver a la última página que visitaste, no a una del medio.

Ctrl + Z: deshacer acciones

Cuando escribes en un editor de texto, cada acción (escribir una letra, borrar, pegar) se agrega a un stack. Cuando presionas Ctrl + Z, la última acción se hace pop() y se deshace. Presionas Ctrl + Z otra vez y la penúltima se deshace.

Mismo patrón: siempre deshaces la acción más reciente.

Call stack de tu programa

Cuando una función llama a otra, que a su vez llama a otra, tu programa va apilando cada llamada en un "call stack". Cuando una función termina, se hace pop() y el control vuelve a la función anterior.

Por eso cuando ves un error con "stack trace" en la consola, estás viendo exactamente eso: el estado del stack de llamadas en el momento del error.

Validación de paréntesis balanceados

Un problema clásico de entrevistas. ¿Cómo verificas que en ((a + b) * (c - d)) todos los paréntesis estén correctamente balanceados? Con un stack. Cada ( hace push, cada ) hace pop. Si al final el stack está vacío, los paréntesis están balanceados.

Cierre

Los stacks son simples: cinco métodos, todos O(1), un solo principio (LIFO). Y justo por eso los encuentras en tantos lugares, desde el botón de atrás hasta el call stack de tu lenguaje de programación.

Si te sirvió el artículo, dale ❤️ y sígueme para no perderte el siguiente. Nos leemos pronto. 🙌🏻

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

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

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.