¿Por Qué any Hace que Pierdas el Tipo que Pasaste? Tipa un parámetro como any y TypeScript deja de comprobar todo lo que sale de la función: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compila, falla en tiempo de ejecución Tú sabes que pasaste un array de números. El compilador no, porque any le dice que deje de mirar. n queda tipado como any, así que llamar a un método de string sobre un número compila sin problemas y lanza TypeError: n.toUpperCase is not a function cuando se ejecuta. ...

Abre un archivo que no existe en Python y open() lanza un FileNotFoundError que sube por la pila de llamadas hasta salir de tu función. Haz lo mismo en Go y os.ReadFile te devuelve un valor error junto a un slice de bytes nil. El mismo fallo, dos formas de código completamente distintas a su alrededor. La diferencia no es cosmética: decide si quien llama puede ignorar el fallo por accidente, y si el compilador se da cuenta cuando lo hace. ...

Llevas tres archivos editados en una rama de feature, sin nada confirmado, cuando un compañero te avisa de un null pointer en producción. El movimiento habitual es hacer git stash, cambiar a main, arreglarlo, hacer push, y luego git stash pop con la esperanza de que nada de tu feature a medias dependiera de los archivos que acabas de tocar. git worktree evita todo ese baile. Hace checkout de la rama del hotfix en una segunda carpeta, junto a la de tu feature, y ambas comparten el mismo repositorio. ...

Un cliente atascado en un retry loop sin backoff puede meterle más carga a tu API en un minuto que tus otros diez mil clientes juntos. Desde tu lado no parece un ataque. Parece un bug de su parte, y se convierte en un incidente del tuyo. Un rate limiter frena a ese cliente antes de que llegue a ese punto. ¿Qué decide realmente un rate limiter? En cada request, el limiter se hace una sola pregunta: ¿esta clave ha hecho demasiadas requests en la ventana actual? Tres decisiones convierten eso en algo que puedes implementar. ...

Qué hace realmente el function calling en un LLM Pregúntale a un modelo “qué tiempo hace ahora en Austin” sin ninguna conexión con el mundo exterior, y tiene dos opciones: decir que no lo sabe, o inventarse algo. El function calling le da una tercera opción: el modelo describe lo que necesita, se lo pasa a tu código y espera una respuesta real antes de contestar. El nombre es un poco engañoso. El modelo no llama a nada. Emite un bloque de datos estructurados que dice qué tool quiere y con qué argumentos, y tu aplicación decide si lo ejecuta y qué hace con el resultado. “Tool use” es el término más preciso, y es el que usa la documentación de Anthropic; OpenAI y Google suelen decir function calling. El mecanismo es el mismo bajo los dos nombres. El modelo solo produce una petición, nunca el efecto. ...

Un listener scroll en window puede dispararse cientos de veces durante un solo swipe. Si en cada uno de esos eventos ejecutas getBoundingClientRect() sobre todas las tarjetas de un feed, cincuenta imágenes bastan para que la página empiece a ir a tirones. La Intersection Observer API elimina esa comprobación del flujo del scroll: registras qué elementos observar y el navegador te avisa cuando su visibilidad cambia de verdad. Cómo funciona IntersectionObserver Un observer vigila uno o más elementos target respecto a un root (el viewport, por defecto) y llama a una callback cada vez que un target cruza un umbral de visibilidad. ...

Abre un archivo guardado en UTF-8 con una herramienta que asume otra codificación y café se convierte en café. Los bytes del disco no cambiaron. Lo que cambió es la regla usada para volver a convertirlos en caracteres, y las dos reglas no coinciden en qué significa el byte 0xC3. La mayoría de los bugs de “caracteres raros” vienen de la misma fuente: nombres de archivo rotos, formularios ilegibles, un emoji que hace fallar un insert en la base de datos, dos cadenas que se ven idénticas pero fallan al compararlas. Detrás de todos ellos hay la misma confusión entre dos cosas distintas: Unicode y UTF-8. ...

¿Qué Es una Closure en JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter se ejecuta una vez, devuelve una función, y ahí termina: su stack frame ya no existe. Aun así, cada llamada a counter() sigue leyendo y actualizando count, una variable declarada dentro de una función que ya terminó. count no vuelve a 0, y no se copia. Es la misma variable, todavía viva, tres llamadas después. ...

Un test escrito después del código tiende a comprobar lo que el código hace, no lo que debía hacer. El desarrollo guiado por pruebas (TDD) resuelve esto invirtiendo el orden: escribes el test, lo ves fallar, y luego escribes el código mínimo que lo hace pasar. El test existe antes que el código que examina, así que no puede limitarse a confirmar en silencio lo que ese código termine devolviendo. Kent Beck formalizó este ciclo como red, green, refactor en su libro de 2002 Test-Driven Development: By Example. El nombre se quedó. ...

Ejecuta npm install en un proyecto, luego pnpm install sobre el mismo package.json, y obtienes dos árboles node_modules distintos y dos lockfiles distintos. Añade un compañero que usa Yarn y el repositorio termina con tres lockfiles en su historial, cada uno describiendo un árbol de dependencias ligeramente diferente. Los tres leen el mismo package.json y descargan del mismo registro de npm. En lo que no se ponen de acuerdo es en qué escribir en disco. ...