Hay herramientas que aparecen y se hacen famosas casi que por arte de magia; fue ese el caso de OpenClaw, el hit del momento.

En tan solo 72 horas después de haberse lanzado, OpenClaw acumuló más de 60.000 estrellas en GitHub y, de hecho, hasta el mismo CEO de Nvidia, Jensen Huang, afirmó recientemente que será “el próximo ChatGPT”.

Pero en medio de tanta euforia por sus excelentes capacidades, también ha habido múltiples advertencias por parte de expertos en ciberseguridad que apuntan a que OpenClaw es altamente peligroso ☠️.

Imagina que estás construyendo una tienda online y quieres lanzar un nuevo sistema de pagos. Lo tienes listo en el código, pero aparece un sentimiento común… tienes miedo de que falle en producción.

Hace poco hablábamos en este episodio sobre los distintos métodos de despliegue que existen y cuáles ayudaban mejor a mitigar los fallos (en caso de que algo saliera mal).

En dicho episodio mencionábamos las feature flags que, si bien no son una estrategia de despliegue como tal, nos permiten habilitar/deshabilitar partes de nuestra aplicación dinámicamente, lo que tiene muuuchos beneficios en este contexto 😏.

Profundizaremos en qué son y de qué manera pueden servirte ⬇️.

No es lo mismo tener una aplicación pensada para que la usen 10 usuarios que para que la usen 10.000, y esa es precisamente la razón por la cual comprender el diseño de un sistema es tan importante.

💡 Entiéndase por diseño [de un sistema] la forma en que se estructuran y comunican sus componentes para que sea escalable, eficiente y mantenible.

Así que, en este episodio, te mostraremos cómo evolucionar de una aplicación tan básica como sea posible a un sistema complejo que sea capaz de soportar altas cargas de trabajo.

Para ello, nuestro punto de partida va a ser el siguiente:

Desplegar software en producción parece, a primera vista, una tarea técnica mundana. Uno pensaría que basta con subir el código, reiniciar el servidor y listo el pollo 😁.

Pero eso es solo hasta que vives un incidente real, y la realidad se torna bien diferente.

La forma en que desplegamos define, en gran medida:

• Cuánto riesgo asumimos

• Qué tan rápido podemos recuperarnos de un error

• Qué experiencia tendrán nuestros usuarios

¿Quieres cagarte de la risa? Escribe "PHP" en cualquier foro de programación y prepárate para el espectáculo.

Aparecerán memes, GIFs, los hilos de Reddit con dos mil upvotes, y todo tipo de formato que se preste para burlarse del lenguaje. Pero, por más que la gente hable de él, a la fecha, PHP es usado por el 72% de toda internet 🤯.

Nosotros aquí no vamos a defenderlo ni a terminarlo de hundir. Simplemente te vamos a dar un poco de contexto de por qué fue (o es) tan odiado y te daremos su ‘state of art’ en 2026.

¿Qué hizo PHP en el pasado?

Cuando hablamos de escalar una base de datos, buscamos distribuir la carga para optimizar la lectura y escritura de registros.

Como casi cualquier otro componente en un sistema, es posible escalarlo tanto vertical como horizontalmente. En este artículo, nos centraremos en el escalamiento horizontal de bases de datos, concretamente en el sharding. Hablaremos sobre las distintas estrategias y cuál ‘pagaría’ el precio más bajo para tu caso concreto.

¡Let’s go! 🙌

Hay ciertas aplicaciones que requieren un control fino de su modelo de concurrencia; hay que lidiar con hilos (threads), deadlocks, semáforos y un montón de cosas más.

Fue el caso de Netflix, que le confió esto a una nueva característica presente en Java 21 llamada Virtual Threads, que proponía una solución al clásico problema de la concurrencia en Java: demasiados hilos = demasiados costos del sistema operativo.

Pero la idea no fue tan buena, puesto que al desplegar a producción el sistema se detuvo 👉👈 (jeje).

Para entender qué fue lo que sucedió —y que no te pase a ti también— primero necesitamos darte algo de contexto.

Si despliegas APIs, microservicios, bases de datos o simplemente mantienes una VPS, entonces seguramente debas lidiar con servidores Linux.

Pero hay algo muy importante que necesitas saber: tu servidor está siendo escaneado constantemente 💀.

Así es; hay bots buscando puertos abiertos, intentos de fuerza bruta para acceder a él e incluso paquetes desactualizados que lo hacen vulnerable a todo tipo de ataques.

Reforzar la seguridad de los servidores no es algo que solo los equipos de infraestructura deban hacer. En realidad, debería ser parte de la base de conocimientos de cualquier desarrollador en 2026.

¿Conoces Claude Code? El famosísimo agente de IA capaz de escribir código. Bueno, adivina qué…

El 90% del código de Claude Code está escrito por el mismo Claude Code. Algo así como una auto-generación.

Pero eso no significa que ahora no debas aprender a programar y simplemente le pidas a tu asistente que trabaje por ti. De hecho, eso sería muy poco responsable de tu parte 😑.

A día de hoy, desarrollar software todavía requiere supervisión humana y, sobre todo, tener pensamiento crítico como nunca antes.

De los mismos creadores de: ¿Qué fue primero: el huevo o la gallina?

Presentamos…

¿Qué fue primero: el compilador o el lenguaje?

Bueno, cuando termines de leer este artículo lo tendrás más claro.

Hay problemas que son realmente difíciles de detectar, sobre todo cuando se dan en producción.

Fue el caso de una aplicación en la que trabajaba hace poco: un comercio electrónico que, solo en determinados momentos del día, respondía con latencias elevadas; algunas peticiones tardaban varios segundos en completarse y, en casos más graves, se devolvían errores HTTP 500.

Pero lo más desconcertante era que el consumo de CPU y memoria en los servidores de aplicación se mantenía dentro de rangos normales.

Lo primero que uno se imagina es: “Pues algún cuello de botella debe de haber…”. La pregunta del millón es dónde.

MCP se ha convertido rápidamente en un estándar de la industria; su utilidad se basa en poder brindar herramientas y recursos a los agentes de IA para que lleven a cabo acciones en servicios externos.

Pero, ¿qué sucede cuando un servidor MCP remoto (al que pueden acceder múltiples clientes) otorga acceso a un servicio donde cada usuario tiene una cuenta distinta?

Para que te quede más claro, pongamos de ejemplo un servidor MCP que sirva como puente entre Claude y Google Drive. Es importante tener en cuenta que dicho servidor está alojado remotamente, y es consumido por Claude vía HTTP.

Por ahí se dice que, en el desarrollo de software, solo existen dos cosas verdaderamente difíciles: la invalidación de caché y el nombramiento de variables. Pero quizás debamos incluir una tercera, que es, el manejo de fechas, horas, marcas temporales, zonas horarias, y todos los demás conceptos asociados a esto.

Y es que, el mero hecho de entender cómo se distribuyen los husos horarios a lo largo y ancho del planeta ya supone un serio dolor de cabeza (de verdad, es más loco de lo que piensas).

Pero el hecho de que entender el tema sea difícil, no significa que sea imposible, y un buen ingeniero debería tener una comprensión suficiente de este.

Así que prepárate, porque en este episodio aprenderás todo lo que debes saber al respecto y, créeme, que gracias a lo que estás a punto de leer, podrás evitar muchos errores graves que podrían romper tu sistema.

Hablar del problema del ‘Dual Write’ puede sonar como un edge case raro, pero, en realidad, es más común de lo que podrías pensar.

De hecho, es más común en arquitecturas orientadas a eventos y microservicios. Pero eso no significa que solo se presente en estos escenarios: lo único que se necesita para que un problema de escritura dual explote es que se deban hacer dos o más escrituras en sistemas distintos.

A continuación, te explicaremos de qué se trata y lo que puedes hacer para solucionarlo.

Comencemos… 🤓

Hoy vamos a hablar de uno de esos temas que todo programador senior domina, pero que muchos solemos pasar por alto: cómo gestionan la memoria los lenguajes de programación.

Es muy probable que, en el fondo, siempre hayas sabido que este era un concepto importante, pero que nadie te lo había explicado de forma directa y ordenada.

La buena noticia es que, una vez lo entiendes, muchas piezas encajan de golpe.

Sin más que decir, empecemos ⬇️

Seamos sinceros:

¿Te sientes seguro de ti mismo usando Git?

Si la respuesta es un rotundo “sí”, pues felicitaciones. Pero si, por el contrario, sientes que se te va a salir el corazón cada vez que ejecutas un comando de Git —y esperas cualquier respuesta al azar como si de lanzar un dado se tratase—, quizás te haga falta agarrar un poquito más de confianza.

Tampoco te sientas culpable. En algún punto, todos estuvimos ahí.

¿Te ha pasado que, cuando estás implementando un proyecto, te toca escribir un condicional con tres o más caminos? Algo tipo:

function procesarPedido(pedido) {
  if (pedido.estado === "nuevo") {
    validarStock(pedido);
  } else if (pedido.estado === "pagado" || pedido.esUrgente) {
    generarFactura(pedido);
    enviarExpress(pedido);
  } else if (pedido.estado === "pagado") {
    generarFactura(pedido);
  } else if (pedido.estado === "cancelado") {
    revertirPago(pedido);
  }
}

Bien, pues podemos asumir que un bloque como estos es inofensivo, pero de una vez te advierto que puede convertirse en una de las partes más frágiles de tu sistema.

El if/else no es malo por sí solo (tampoco el switch). Sin embargo, puede volverse difícil de manejar cuando:

Las Functions-as-a-Service (FaaS), o más conocidas como Lambdas —en el contexto de Amazon Web Services— te permiten ejecutar código del lado del servidor sin tener que preocuparte por la infraestructura; es decir, los servidores, el espacio, la memoria, y un largo etcétera.

En general, las funciones sin servidor son uno de los pilares más importantes del enfoque ‘serverless’, en el que no tienes que provisionar máquinas, instalar runtimes ni preocuparte por escalar. Eso se lo delegamos al proveedor cloud.

Sin embargo, solemos estar tan acostumbrados a trabajar con backends ‘comunes’ y autogestionados, que las tratamos como si fueran uno.

Y la verdad es que no.

El caching es un arma de doble filo. Puede ser muy poderoso si se sabe aprovechar, pues hace que la web sea más rápida, estable y barata de mantener, pero también puede ser la causa de aplicaciones lentas, frágiles y costosas.

Hoy, analizaremos cómo opera la caché de HTTP más allá de las reglas básicas que todos conocemos (Cache-Control, Expires, etc.), además de cómo interactúan estas bajo los criterios adicionales que los navegadores imponen.

Iniciemos 👊

Nada más esta semana estabamos hablando en nuestra cuenta de Instagram sobre cómo JSON podía convertirse en un cuello de botella silencioso. En él, te mostramos algunas alternativas más ligeras como Protobuf o MessagePack.

Aun así, muchos de ustedes comentaron que estos formatos eran ilegibles para humanos (y tienen toda la razón 🙂‍↕️). Por ello dejamos claro que se trata de opciones que deben emplearse solo cuando la eficiencia es crítica, tanto temporal como espacialmente.

Ahora, con el auge de los LLMs, ha surgido una nueva problemática, y es que las empresas que los mantienen suelen cobrar el uso por token.