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.

Si hay algo que todo programador descubre tarde o temprano, es que las estructuras de datos están en todas partes. Matrices, listas, grafos y muchas otras nos permiten modelar problemas del mundo real de forma eficiente, convirtiendo información compleja en algo que nuestras aplicaciones pueden procesar rápido y con precisión.

Sin embargo, hay estructuras de datos que han sido ‘olvidadas’, o que, al menos, no se les ha dado la importancia que merecen.

Una de ellas son los heaps (o montones). ¿Los has escuchado? 🧐

Hoy te explicaremos qué son, por qué son tan útiles y cuándo deberías aplicarlos.

¿Te ha pasado que un gran artista se va a presentar en tu ciudad y conseguir los tiquetes es literalmente un infierno 😵?

Bueno, ya te imaginarás los grandes retos a los que se enfrentan quienes desarrollan sistemas de ticketing: el cuello de botella inicial para ingresar al sitio, la escalabilidad de los recursos del sitio y la resiliencia para no caerse.

Pero hoy nos centraremos en hablar de un escenario muy específico.

Condiciones de carrera

Si trabajas en equipo o has contribuido a proyectos open-source, probablemente sepas lo intimidante que es leer por primera vez el código que otros escribieron.

No estás solo, de hecho, me atrevería a decir que esa sensación siempre existirá 😁, sin importar la experiencia que tengas.

Y, es que claro, nadie dijo que eso tenía que ser una tarea fácil. De hecho, depende en gran medida de las habilidades de redacción de la otra persona. Si su código es malo, leerlo será difícil.

Pero, como muchas otras cosas, estos son gajes del oficio.

Cuando se trata de escalar un sistema y, a su vez, asegurar una alta disponibilidad, entra en juego la replicación de la base de datos.

Y es que, así como replicamos servicios —para que en caso de que uno falle, el otro siga atendiendo las solicitudes—, así mismo es posible hacerlo con las bases de datos, manteniendo una o más copias actualizadas.

¿Has escuchado alguna vez hablar de “read replicas”, “multi-primary clusters” o “failover automático”? Pues todas son caras de la misma moneda.

Hoy, entraremos en detalle en cada una de estas técnicas de replicación y en cuándo conviene aplicar cada una.

…bueno, asumiendo que ya lo usas.

Terraform es una herramienta de código abierto que sirve para provisionar y gestionar infraestructura en la nube mediante código, en lugar de hacerlo manualmente, llendo a cada su sitio web y luego… 😴.

💡 La infraestructura son los recursos físicos y virtuales que ejecutan las aplicaciones; servidores, redes, bases de datos, etc.

La idea tras Terraform es muy simple: tú escribes archivos .tf en los que especificas cómo quieres que sea tu infraestructura: cuántas máquinas, qué redes, qué bases de datos, en qué proveedor de nube, etc.

Si eres developer desde hace un tiempo, seguramente ya estés acostumbrado a la siguiente pregunta:

“¿Para cuándo lo puedes tener listo?“

Bien sabemos que definir los plazos de entrega para un proyecto no es una tarea fácil. De hecho, el mismo Douglas Hofstadter tenía razón cuando dijo:

“Siempre toma más tiempo de lo esperado, incluso cuando tienes en cuenta la Ley de Hofstadter“.

Cuando un sistema empieza a crecer, nos vemos en la necesidad de escalar y, en la mayoría de casos, la mejor opción es hacerlo horizontalmente; es decir, añadiendo más nodos.

❗ Con un nodo, nos referimos a:

• Un servidor físico

• Una máquina virtual

• Un contenedor

• O incluso un pod de Kubernetes

Escalar horizontalmente no solamente es bueno en términos de rendimiento, sino también en cuando a disponibilidad.

En realidad, cuando distribuimos la carga entre varios nodos, nos aseguramos de que nuestros usuarios puedan acceder más fácilmente a una instancia de la aplicación y que obtengan la menor latencia posible.

Cuando alguien nos explica qué son los contenedores, la definición más común suele ser algo como:

“Una cajita que aisla tu aplicación junto con todo lo que necesita para funcionar para que se pueda ejecutar en cualquier lado“.

Y aunque la definición es correcta, en realidad, un contenedor no se encuentra completamente aislado del mundo que lo rodea, sino que se conecta a una red que es internamente gestionada por Docker.

¿Recuerdas los switches?

¿Te has preguntado cómo programan los seniors?

Aunque no hay una fórmula exacta que podamos seguir al pie de la letra, sí existen principios que todo buen informático debería seguir.

Nuestro propósito hoy será explicarte 3 de estos principios que, aunque no son los únicos, sí son esenciales si quieres que tu código sea mucho mejor (al final verás por qué 🤭).

Puede que ya los conozcas, pero muchos de ellos han sido malinterpretados con el paso del tiempo, así que nos tomaremos el tiempo de aclararte las cosas tal y como son.

Parte de nuestra filosofía como comunidad de divulgación para informáticos es que, un buen sistema no se construye solo con código limpio, sino que también necesita bases sólidas que lo sostengan.

Así que puedes haber escrito el código más elegante y sofisticado del mundo, pero sin un buen diseño, difícilmente sea óptimo para producción.

Y cuando hablo de diseño no me refiero a la interfaz gráfica.

💡 El diseño de un sistema es la forma en que están organizados sus componentes y cómo interactúan entre sí.

¿Cuántas veces has utilizado localhost? Seguro has escrito miles de veces 127.0.0.1 para conectarte a servicios y aplicaciones localmente. Y aunque siempre nos han enseñado que no hay ninguna diferencia entre estos 2, puede que estemos pasando algunos detalles por alto.

Alguna vez mentoramos a alguien (que sí, que también ofrecemos mentorías personalizadas 😉) que llevaba horas intentando conectarse a una base de datos MySQL que tenía levantada en su máquina.

MySQL escuchaba todas las llamadas de 127.0.0.1, pero el cliente intentaba conectarse a localhost. Nuestro amigo no pudo conectarse hasta que se dio cuenta de lo que te contaremos a continuación.

¿Qué es localhost?

JavaScript nació en 1995, cuando los navegadores necesitaban un lenguaje ligero y fácil de aprender para añadir interacción a las páginas web. Para ese entonces, el HTML todavía era estático.

El lenguaje parecía casi una creación divina, pues la primera versión de JavaScript fue construida en tan solo 10 días.

Desde un principio JavaScript fue un lenguaje pensado:

• Para ser interpretado, por lo que se ejecuta línea por línea a través de un intérprete, sin necesidad de compilarse previamente a código máquina.

• Con un sistema de tipos dinámico. Es decir, no declaras explícitamente el tipo de las variables, sino que este se asigna en tipo de ejecución.

• Carente de módulos y otras herramientas. Eso vino después cuando se introdujo ECMAScript.