Si alguna vez te ha pasado esto:

“¿Quién desplegó esto a prod?”

“En mi máquina sí funcionaba”

“¿Por qué el cluster no está igual que ayer?”

“Me da miedo tocar Kubernetes”

…entonces GitOps te va a caer como agua fría en día de calor 🧊

🤔 ¿Qué es GitOps?

Dicho simple:

GitOps es usar Git como el botón oficial de deploy.

Si no está en Git, no existe.
Si está en Git, se despliega solo.

Nada de:

kubectl apply helm upgrade

Solo:

git commit git push

Y alguien más (spoiler: Argo CD) hace la magia 🪄

🧠 El problema antes de GitOps

Antes, el flujo típico era algo así:

Jenkins corre

Jenkins hace kubectl

Jenkins hace helm

Jenkins toca el cluster

Nadie sabe qué pasó

Nadie sabe cómo volver atrás

Resultado:
😵 caos
😵 miedo a prod
😵 “no toques eso que se rompe”

✅ La idea clave de GitOps

GitOps cambia el juego con una regla muy clara:

Git es la fuente de la verdad

No Jenkins
No Kubernetes
No tu laptop

👉 Git

🔁 Cómo se ve el flujo real

Así, sin drama:

Haces cambios en el código

CI (Jenkins, GitHub Actions, etc):

corre tests

construye imagen Docker

la sube al registry

CI clona otro repo (el repo GitOps)

CI genera un values.yaml

CI hace commit y push

Argo CD ve el cambio

Argo CD despliega en Kubernetes

👉 El CI no toca el cluster
👉 Argo CD sí toca el cluster

📦 ¿Por qué dos repos?

Porque cada uno tiene una responsabilidad clara:

Repo 1 – Código

Código fuente

Dockerfile

Tests

Jenkinsfile

Repo 2 – GitOps

Configuración de despliegue

values.yaml

Ambientes (dev, preview, prod)

Esto hace que:

Todo sea auditable

Los deploys sean repetibles

El rollback sea trivial

🔥 Rollback en GitOps (lo bonito)

Algo se rompió en prod 😬

Antes:

logs

estrés

parches a mano

Con GitOps:

git revert git push

Y listo. Argo CD vuelve al estado anterior solo.

🌱 Ambientes efímeros (lo más cool)

Con GitOps puedes hacer esto:

PR abierto → ambiente nuevo

PR cerrado → ambiente eliminado

Cada PR tiene:

su namespace

su URL

su config

Y cuando ya no sirve:
💥 se borra solo

Sin limpiar basura después.

🧠 ¿GitOps es solo para seniors?

❌ No.

De hecho, GitOps ayuda mucho a la gente no senior, porque:

Reduce errores humanos

Evita tocar prod “a mano”

Te obliga a documentar cambios

Hace el sistema más predecible

GitOps no te pide ser crack, te ayuda a no romper cosas.

🎯 Ventajas reales (sin marketing)

✔ Menos miedo a desplegar
✔ Todo queda en Git
✔ Rollback fácil
✔ Auditoría automática
✔ Kubernetes más ordenado
✔ CI más simple

🧩 Frase para llevarte

Jenkins construye
Git decide
Argo CD ejecuta
Kubernetes mantiene

Si estás empezando con Kubernetes y CI/CD, GitOps es una de las mejores decisiones que puedes tomar temprano. Te ahorra errores, estrés y discusiones futuras.

Hace unas semanas me encontré en una situación bastante común en el mundo digital: necesitaba mover un backup enorme de una plataforma a otra. Específicamente, tenía una exportación de datos de Google Workspace y mi objetivo era llevarla a mi espacio de almacenamiento en la nube de AWS.

El problema es que mis archivos eran gigantes. No quería (y mi disco duro tampoco) tener que descargar gigabytes de información para luego subirlos de nuevo a AWS. Era un proceso lento, tedioso y totalmente ineficiente.

Así que me puse a buscar. Necesitaba una herramienta que hiciera la magia: una que pudiera transferir archivos directamente entre servicios en la nube, sin pasar por mi computadora. Fue entonces cuando descubrí rclone.

El superhéroe de los backups: ¿Qué es rclone?

Imaginen una navaja suiza, pero para la nube. Eso es rclone. Es una herramienta de línea de comandos gratuita y de código abierto que se conecta con más de 70 servicios de almacenamiento en la nube. Su caso de uso principal es exactamente lo que yo necesitaba: copiar, sincronizar y mover archivos de una nube a otra, de manera eficiente y segura. Es ideal para automatizar tareas, hacer backups o simplemente gestionar tus archivos sin tener que tocar el disco duro.

Mi viaje de implementación: De la confusión al "¡Eureka!"

Mi experiencia no fue perfecta desde el inicio, y si me pasó a mí, seguro le pasa a otros. El primer obstáculo que encontré fue que rclone me decía que no podía ver mis archivos sin un "project number". Busqué por todas partes en la consola de Google Cloud, pero no encontraba el número.

El truco, al final, estaba en entender que mi backup no venía de un proyecto de Google Cloud normal, sino de una exportación de Google Workspace. Es un servicio diferente y el bucket se gestiona de forma distinta.

El proceso para lograrlo fue un poco largo, pero el resultado valió la pena:

1. La configuración mágica: Usé el comando rclone config y, en lugar de ingresar IDs de proyecto, elegí la opción de autenticación interactiva. Esto hizo que rclone me abriera una página web en el navegador.
2. El momento "¡Eureka!": Me autentiqué con mi cuenta de Google, acepté los permisos y rclone hizo el resto. En cuestión de segundos, la terminal me confirmó que la conexión estaba lista. Había sorteado el mayor obstáculo.
3. Los tropiezos finales: Aunque la conexión estaba hecha, el comando no funcionaba. Me di cuenta de que el nombre del bucket y el directorio eran muy específicos y largos. A veces me equivocaba en un número, y rclone simplemente no encontraba nada.
4. El éxito: Una vez que puse la ruta exacta (rclone copy gcp:nombre_del_bucket/nombre_de_la_carpeta/ aws:mi_destino/ --progress), la transferencia se inició. Vi cómo mis archivos se movían directamente de Google a AWS sin un solo segundo de descarga en mi computadora. ¡Fue una victoria total!

La lección aprendida

Implementar rclone me enseñó que no necesitas descargar todo para gestionar tus archivos en la nube. Con la herramienta correcta, el proceso se vuelve simple, rápido y mucho más eficiente. Si tienes que mover grandes volúmenes de datos entre servicios en la nube, rclone es, sin duda, la mejor opción. Es una herramienta poderosa que te da el control total sobre tus datos.

Si quieres empezar tu propio proyecto, te dejo la liga oficial para que la descargues y empieces a explorar:

• Página oficial de rclone: https://rclone.org/
• Repositorio en GitHub: https://github.com/rclone/rclone

En medio del auge de la inteligencia artificial, donde cada semana una nueva startup promete revolucionar el mundo, hemos sido testigos de una historia que parece sacada de una serie de ficción: una empresa que se hizo pasar por pionera en IA, cuando en realidad dependía de cientos de ingenieros humanos para simular el funcionamiento de sus algoritmos.

El caso: 700 ingenieros disfrazados de IA

La startup en cuestión, Builder.ai, se presentó ante gigantes tecnológicos como Microsoft como una empresa que había desarrollado una solución de inteligencia artificial capaz de optimizar procesos en tiempo real. Pero lo que parecía una proeza tecnológica era en realidad un montaje sostenido por 700 ingenieros indios que realizaban las tareas de manera manual, simulando la eficiencia de una IA inexistente.

Durante meses, estos trabajadores operaban desde centros de trabajo disfrazados de sistemas automatizados, respondiendo solicitudes y procesando datos con la precisión y velocidad que uno esperaría de un algoritmo sofisticado.

¿Engaño o prototipo en evolución?

Este escándalo pone sobre la mesa una discusión ética compleja. ¿Fue simplemente un fraude bien ejecutado? ¿O era una estrategia de "IA humana" usada como un puente temporal mientras la tecnología se desarrollaba?

No es la primera vez que sucede algo así. En el mundo de las startups, el concepto de "Wizard of Oz prototyping" —donde humanos simulan funciones que eventualmente serán automatizadas— no es nuevo. Sin embargo, la diferencia clave aquí es la transparencia. Microsoft y otros inversores fueron convencidos de que la tecnología ya existía y era funcional.

Las consecuencias

La revelación ha sido devastadora. Builder.ai ha entrado en quiebra, y su reputación está destruida. Microsoft, por su parte, ha comenzado una revisión de sus procesos de due diligence para evitar caer nuevamente en trampas similares.

Y mientras tanto, la historia deja una pregunta latente: ¿qué tan preparado está el mundo para diferenciar entre una verdadera IA y una operación humana disfrazada?

Reflexiones finales

Este caso no solo es una advertencia para inversores y grandes corporaciones tecnológicas, sino también una llamada de atención para la industria en general. En la carrera por la automatización y la innovación, la ética y la honestidad deben ser innegociables.

Además, pone sobre la mesa otro dilema: si 700 humanos pueden hacer el trabajo de una IA durante meses sin que nadie lo note, ¿realmente entendemos qué es lo que hace a una inteligencia artificial… artificial?

Entrar al universo de la ingeniería de datos puede ser abrumador al principio, porque hay un montón de términos técnicos y conceptos que vuelan por todos lados. Si estás empezando, lo más importante es entender que un ingeniero de datos es como un arquitecto que diseña y construye los sistemas que mueven, transforman y organizan los datos. Estos datos son el combustible que impulsa a las empresas modernas, ya sea para tomar decisiones, generar reportes, o entrenar modelos de inteligencia artificial.

Este post es tu brújula inicial. Te explico los términos esenciales de forma práctica, sin tanto rodeo, para que no te sientas perdido cuando escuches cosas como "Data Lake", "ETL", o "Data Pipeline". Una vez que los entiendas, verás que todo empieza a conectar.

Así que prepárate porque aquí te dejo el glosario básico que todo ingeniero de datos debe conocer. ¡Vamos a construir juntos ese mapa mental!

1. ETL (Extract, Transform, Load)

Este es el pan de cada día en ingeniería de datos. Es el proceso de:

• Extraer datos de diferentes fuentes (bases de datos, APIs, archivos CSV, etc.).
• Transformar los datos para limpiarlos, normalizarlos o adaptarlos según las necesidades del negocio.
• Cargar los datos transformados en un destino como un Data Warehouse o un Data Lake.

Esencialmente, ETL es el flujo que lleva los datos crudos a un formato útil para análisis.

2. ELT (Extract, Load, Transform)

Es como ETL, pero cambia el orden:

• Primero extraes los datos y los cargas sin procesar a un Data Warehouse o Data Lake.
• Luego haces las transformaciones directamente en el destino.

Este enfoque se usa mucho cuando trabajas con herramientas como Snowflake o BigQuery, que permiten procesar los datos directamente en su infraestructura.

3. Data Warehouse

Es un almacén centralizado donde guardas datos estructurados y organizados para análisis.
Ejemplo: Snowflake, Amazon Redshift, Google BigQuery.

La diferencia clave con un Data Lake es que aquí los datos ya están procesados y listos para usarse, mientras que en un Data Lake los datos suelen estar crudos.

4. Data Lake

Un Data Lake es un repositorio gigante donde puedes almacenar todos tus datos, estructurados o no, sin preocuparte mucho por organizarlos de inmediato. Es ideal para almacenar datos históricos o grandes volúmenes de datos en su forma más pura.

Ejemplo: Amazon S3, Azure Data Lake Storage, Google Cloud Storage.

5. Data Pipeline

Es el flujo automatizado que mueve datos desde una fuente (o múltiples fuentes) a un destino. Incluye tareas como extracción, transformación, validación y carga.
Herramientas populares para esto: Apache Airflow, AWS Glue, Dagster, Luigi.

6. Schema

El schema es la estructura de tus datos. Por ejemplo, en una base de datos, define las tablas, columnas, tipos de datos, etc.
En el mundo de los Data Lakes, puedes escuchar términos como schema-on-read (los datos se estructuran al leerlos) o schema-on-write (los datos se estructuran al guardarlos).

7. Batch Processing

Procesamiento de datos en lotes. Tomas un gran conjunto de datos, lo procesas todo junto y produces un resultado. Es útil para tareas como generación de reportes diarios o cargas masivas de datos.
Ejemplo: Procesar logs de todo el día al final de la jornada.

Herramientas: Apache Spark, Hadoop, AWS Glue.

8. Stream Processing

Procesamiento de datos en tiempo real o casi real. Aquí no esperas a acumular datos; los procesas a medida que llegan.
Ejemplo: Analizar clicks en una página web para hacer recomendaciones al instante.

Herramientas: Apache Kafka, Apache Flink, Kinesis, Spark Streaming.

9. Data Governance

Esto es todo lo relacionado con políticas y prácticas para asegurar que los datos estén gestionados correctamente. Incluye cosas como:

• Controlar el acceso a los datos.
• Mantener la calidad de los datos.
• Garantizar la privacidad y cumplimiento con regulaciones (GDPR, CCPA, etc.).

10. Data Lakehouse

Es un híbrido entre un Data Lake y un Data Warehouse. Combina lo mejor de ambos mundos: puedes almacenar datos crudos (como en un Data Lake), pero también tener datos estructurados y listos para análisis (como en un Data Warehouse).
Ejemplo: Databricks, Delta Lake, Google BigLake.

11. Data Partitioning

Dividir grandes conjuntos de datos en partes más pequeñas y manejables. Esto ayuda a optimizar el rendimiento, especialmente cuando trabajas con grandes volúmenes de datos en herramientas como Apache Hive, Presto o Spark.

12. Orquestación de Datos

Es el proceso de coordinar las tareas en un pipeline de datos para que se ejecuten en el orden correcto y con los recursos necesarios.
Herramientas: Apache Airflow, Prefect, Dagster.

13. OLTP vs OLAP

• OLTP (Online Transaction Processing): Bases de datos optimizadas para operaciones transaccionales. Piensa en registros de ventas o actualizaciones de inventarios.
  Ejemplo: MySQL, PostgreSQL.
• OLAP (Online Analytical Processing): Bases de datos optimizadas para análisis de datos, como crear reportes o dashboards.
  Ejemplo: Snowflake, Redshift.

14. CDC (Change Data Capture)

Es una técnica para detectar y capturar cambios en una base de datos (como actualizaciones o nuevas filas). Es útil para mantener actualizados los datos en un pipeline sin necesidad de procesarlo todo de nuevo.
Ejemplo: Herramientas como Debezium o AWS DMS.

15. SQL vs NoSQL

• SQL: Bases de datos relacionales, con datos estructurados en tablas. Ejemplo: MySQL, PostgreSQL.
• NoSQL: Bases de datos no relacionales, ideales para datos semiestructurados o no estructurados. Ejemplo: MongoDB, DynamoDB.vb 9

16. Sharding

Es dividir una base de datos grande en fragmentos más pequeños (o shards) que se distribuyen entre varios servidores para mejorar el rendimiento y la escalabilidad.

17. Metadata

Los datos sobre los datos. Ejemplo: Información sobre cuándo se creó un archivo, quién lo modificó por última vez, o qué columnas tiene una tabla. Esto es clave para gestionar grandes volúmenes de datos.

18. Data Mesh

Es un enfoque moderno para gestionar datos descentralizándolos en dominios específicos. En lugar de tener un equipo centralizado manejando todos los datos, cada dominio es responsable de sus propios datos como si fueran un producto.

Con estos conceptos claros, ya tienes una buena base para moverte en el mundo de la ingeniería de dato    s.

Si eres programador o trabajas en tecnología, seguro has escuchado hablar del "Ingeniero de Datos". Pero ¿qué hace exactamente esta figura y cómo encaja dentro del ecosistema tech? Aquí te lo explico sin rodeos ni tecnicismos innecesarios.

La columna vertebral de los datos

Un Ingeniero de Datos es como el constructor de carreteras de la información. Su trabajo principal es asegurarse de que los datos fluyan desde donde se generan (bases de datos, APIs, sensores, etc.) hasta donde se necesitan (dashboards, modelos de machine learning, reportes, etc.). Pero no solo es "mover datos", es hacerlo de manera eficiente, confiable y escalable. En otras palabras, prepara el terreno para que los científicos de datos, analistas y otros roles puedan hacer magia con los datos.

Principales responsabilidades

Aquí van las tareas más comunes de un Ingeniero de Datos:

1. Diseñar pipelines de datos: Un pipeline de datos es como una línea de producción. Desde que los datos se generan hasta que llegan a su destino final, hay procesos intermedios como transformaciones, limpieza y almacenamiento. El ingeniero diseña y construye estos procesos.
2. Gestionar infraestructuras: Esto incluye trabajar con bases de datos (SQL y NoSQL), sistemas de almacenamiento distribuido (como S3 o HDFS) y herramientas de procesamiento masivo (Spark, Hadoop, etc.). Además, suelen trabajar en la nube (AWS, GCP, Azure) para escalar estas soluciones.
3. Asegurar la calidad de los datos: Los datos "sucios" son el peor enemigo de cualquier proyecto. El ingeniero se encarga de implementar validaciones, eliminar duplicados y garantizar que los datos sean consistentes y útiles.
4. Optimizar el rendimiento: Trabajar con grandes volúmenes de datos puede ser costoso y lento si no se hace bien. Parte del trabajo es optimizar consultas, elegir los formatos de almacenamiento adecuados y minimizar el costo en la nube.
5. Monitorear y mantener sistemas: Una vez que todo está en marcha, el trabajo no termina. Hay que asegurarse de que los pipelines no fallen, que las bases de datos no se queden sin espacio y que los tiempos de respuesta sigan siendo rápidos.

Tecnologías clave

Un Ingeniero de Datos suele usar un stack variado, dependiendo de la empresa y los proyectos. Algunas herramientas y lenguajes comunes son:

• Lenguajes: Python, SQL, Scala, Java.
• Bases de datos: PostgreSQL, MySQL, MongoDB, Cassandra.
• Procesamiento: Apache Spark, Apache Kafka, Airflow.
• Nube: AWS (Redshift, Glue), Google Cloud (BigQuery, Dataflow), Azure (Data Factory, Synapse).
• Versionado y CI/CD: Git, Jenkins, Docker, Kubernetes.

¿Cómo es un día típico?

El trabajo varía mucho, pero aquí hay una idea general:

1. Revisar logs y monitorear pipelines para detectar fallas.
2. Diseñar o mejorar procesos ETL (Extract, Transform, Load).
3. Colaborar con científicos de datos o analistas para entender qué datos necesitan.
4. Implementar una nueva integración de datos desde una API o fuente externa.
5. Optimizar consultas o procesos que están tardando demasiado.

¿Por qué es importante este rol?

Sin ingenieros de datos, las organizaciones simplemente no podrían manejar ni aprovechar sus datos. Los científicos de datos y analistas tendrían que invertir la mayor parte de su tiempo limpiando y organizando datos, en lugar de crear modelos y generar insights. Este rol permite que todo el ecosistema de datos funcione.

Reflexión final

El Ingeniero de Datos es el puente entre el caos y el orden en el mundo de los datos. Es un rol que mezcla programación, infraestructura y resolución de problemas a gran escala. Si te gusta construir sistemas que funcionen como relojes suizos y tienes paciencia para lidiar con los "problemas del mundo real" de los datos, este camino puede ser para ti.

En el ámbito de DevOps, es muy común encontrarse con la necesidad de gestionar múltiples cuentas o perfiles en la nube. Hoy vamos a explorar una de las mejores herramientas con las que he trabajado personalmente para manejar esta situación de manera eficiente.

Para comenzar, es fundamental contar con el AWS CLI instalado en nuestro sistema, independientemente de si utilizamos Windows, Linux o iOS. Este es el primer paso crítico para asegurarnos de que podemos interactuar adecuadamente con los servicios de Amazon Web Services desde nuestra línea de comandos.

El segundo paso implica la instalación de una dependencia que utiliza Node.js. Por lo tanto, es esencial tener instalado npm, el gestor de paquetes de Node.js. En mi experiencia, la versión 10.2.3 de npm ha funcionado sin problemas, pero puedes utilizar la versión que mejor se adapte a tu configuración actual.

Una vez asegurado que npm está operativo en nuestro sistema, procederemos a instalar globalmente la librería necesaria. Para ello, ejecutamos el siguiente comando en nuestra terminal:

npm install -g awsp

Una vez realizado, procedemos a modificar un nuestro archivo .bashrc or .zshrc config dependiendo de cual uses y agregamos lo siguiente:

alias awsp="source _awsp"

Despues de eso, para que agarre los cambios, hay que reiniciar el bash sin tener que reiniciar la computadora con el siguiente comando:

source ~/.bashrc

En mi caso fue bashrc, una vez realizado esto, vamos a proceder a agregar un perfil de nuestras multiples cuentas gestionadas con el siguiente comando:

aws configure --profile PROFILE_NAME

Se te solicitara un access y secret y procedes a llenar con esa informacion.

Una vez relizado eso, ejecutamos este comando para poder swichear entre diferentes accounts o profiles:

awsp

Y nos aparecera el pequenio menu.

Imagina que estás construyendo una ciudad con bloques de Lego, y cada vez que haces cambios en la ciudad, necesitas actualizarla sin que los ciudadanos se vean afectados.

1. Blue-Green Deployment con Legos:

En el enfoque de Blue-Green Deployment, tienes dos áreas separadas de la ciudad: una es la "Zona Azul" y la otra es la "Zona Verde". Actualmente, todos los ciudadanos viven en la Zona Azul, que es la versión de la ciudad que ya está en producción.

Cuando tienes una nueva versión de la ciudad que deseas implementar, comienzas a construir esa nueva versión en la Zona Verde, que está completamente separada de la Zona Azul. En la Zona Verde, puedes hacer todas las pruebas y ajustes necesarios para asegurarte de que todo funcione correctamente.

Una vez que estás satisfecho con la nueva versión en la Zona Verde, cambias rápidamente la señal de tráfico, dirigiendo a los ciudadanos hacia la Zona Verde. Ahora, la nueva versión se convierte en la versión principal en producción, mientras que la Zona Azul queda desocupada temporalmente.

La ventaja de este enfoque es que no hay tiempo de inactividad para los ciudadanos durante el cambio. Además, si surge algún problema inesperado en la Zona Verde, siempre puedes cambiar rápidamente la señal de tráfico de regreso a la Zona Azul, deshaciendo el despliegue y manteniendo la ciudad funcionando sin interrupciones.

1. Canonical Deployment con Legos:

Ahora, imagina que en lugar de tener dos áreas separadas de la ciudad, tienes dos edificios idénticos, uno al lado del otro. Cada edificio representa una versión diferente de la ciudad.

En este caso, todos los ciudadanos todavía están viviendo en el primer edificio (Versión A), que es la versión canónica actual de la ciudad en producción. Pero, también estás construyendo la nueva versión (Versión B) en el segundo edificio, que representa la versión no canónica.

En lugar de cambiar repentinamente todo el tráfico hacia el segundo edificio, diriges solo un pequeño grupo de ciudadanos (quizás algunos voluntarios) hacia el segundo edificio para probar la nueva versión. Esto te permite comparar el rendimiento y la reacción de los ciudadanos entre ambas versiones en tiempo real.

Si la nueva versión (Versión B) es estable y funciona bien, gradualmente puedes aumentar el número de ciudadanos que se mudan al segundo edificio. Esto permite una transición suave y progresiva de la versión anterior a la nueva versión.

Sin embargo, si en algún momento surge un problema en el segundo edificio (Versión B), siempre puedes redirigir rápidamente a todos los ciudadanos hacia el primer edificio (Versión A) para mantener la estabilidad de la ciudad.

En resumen, Blue-Green Deployment tiene dos zonas completamente separadas y cambia todo el tráfico de una vez, mientras que Canonical Deployment utiliza dos versiones en funcionamiento simultáneamente y permite una transición gradual entre ellas.

Ambos enfoques son valiosos en diferentes situaciones, y elegir uno u otro dependerá de los objetivos y requisitos específicos de tu proyecto.

El event loop de Node.js es como un gran juego de bloques de lego. En este juego, cada bloque representa una tarea o evento que se debe ejecutar en la aplicación. Cuando un bloque es activado, se agrega a una pila de tareas pendientes, similar a como se agregan bloques a una torre de legos.

Una vez que la tarea actual se ha completado, se retira el bloque superior de la pila de tareas y se ejecuta la siguiente tarea en la cola. De esta manera, el event loop de Node.js maneja múltiples tareas simultáneamente y de forma asíncrona, lo que lo hace muy eficiente en la gestión de tareas y eventos en aplicaciones de Node.js.

El event loop es fundamental en Node.js ya que permite que la aplicación siga ejecutándose de forma asíncrona mientras espera la finalización de tareas, como la lectura de archivos o solicitudes de red. Esto significa que Node.js puede manejar múltiples solicitudes simultáneamente y no bloquear el proceso de ejecución de la aplicación, lo que mejora el rendimiento y la escalabilidad de la misma. En resumen, el event loop es una herramienta vital en Node.js para permitir una programación asíncrona y eficiente.

Evitar el bloqueo del event loop

Para evitar bloquear el event loop en Node.js, debemos evitar ciertas prácticas que pueden afectar su rendimiento y eficiencia. Algunas de estas prácticas son:

1. Operaciones de E/S síncronas: Las operaciones de E/S síncronas pueden bloquear el event loop, ya que esperan a que se complete la operación antes de continuar con otras tareas. En su lugar, debemos utilizar operaciones de E/S asíncronas para evitar bloquear el event loop.
2. Bucles infinitos: Los bucles infinitos pueden bloquear el event loop y hacer que la aplicación se vuelva no responsable. Debemos evitar los bucles infinitos y en su lugar utilizar métodos de iteración como map, filter o reduce.
3. Tareas de larga duración: Las tareas que tardan mucho tiempo en completarse pueden bloquear el event loop y hacer que la aplicación sea no responsiva. Debemos evitar realizar tareas de larga duración en el hilo principal y utilizar procesos secundarios o hilos para realizar tareas pesadas.
4. Funciones recursivas infinitas: Las funciones recursivas infinitas pueden causar un desbordamiento de la pila de llamadas y bloquear el event loop. Debemos evitar funciones recursivas infinitas y utilizar iteraciones o funciones de cola en su lugar.

En resumen, para evitar bloquear el event loop en Node.js, debemos evitar operaciones de E/S síncronas, bucles infinitos, tareas de larga duración y funciones recursivas infinitas. Al seguir estas prácticas, podemos mejorar el rendimiento y la eficiencia de nuestra aplicación en Node.js.

Un agente de logs es una herramienta de software que se encarga de recolectar, procesar y enviar logs de diferentes fuentes a un sistema centralizado. Los logs son registros de actividad generados por diferentes aplicaciones y sistemas, y su análisis puede ser muy útil para detectar problemas, identificar tendencias y mejorar el rendimiento.

Existen muchas herramientas de agentes de logs en el mercado, pero aquí te presento tres de ellas:

1. Fluentd: Es una herramienta de recolección y procesamiento de logs que permite recopilar logs de diferentes fuentes y enviarlos a múltiples destinos, como bases de datos, sistemas de almacenamiento en la nube, y herramientas de análisis de logs. Fluentd es muy flexible y personalizable, lo que la hace muy adecuada para entornos complejos con múltiples fuentes de logs.
2. Logstash: Es una herramienta de procesamiento de logs que se integra muy bien con el stack ELK (Elasticsearch, Logstash, Kibana) y que permite recopilar, transformar y enviar logs a un servidor centralizado para su análisis. Logstash admite una gran variedad de fuentes de logs y se puede configurar para enviar los logs a múltiples destinos, incluyendo bases de datos y herramientas de análisis de logs.
3. Syslog-ng: Es una herramienta de recolección y procesamiento de logs que se enfoca en los logs de sistemas Unix y Linux. Syslog-ng permite la recopilación y el filtrado de logs de diferentes fuentes y la posibilidad de enviarlos a diferentes destinos, incluyendo sistemas de almacenamiento en la nube y herramientas de análisis de logs. Syslog-ng es muy flexible y escalable, lo que la hace muy adecuada para entornos de TI empresariales.

En resumen, los agentes de logs son herramientas esenciales para la gestión de logs en entornos empresariales. Fluentd, Logstash y Syslog-ng son solo algunas de las herramientas disponibles en el mercado, cada una con sus propias características y ventajas. La elección de la herramienta adecuada dependerá de las necesidades específicas de cada organización.

En el mundo de la tecnología, especialmente en el ámbito de la informática y las aplicaciones en línea, el término "contenedores" ha ido ganando popularidad en los últimos años. Pero, ¿cómo debemos tratar a nuestros contenedores? ¿Como mascotas o como ganado?

En primer lugar, es importante entender que un contenedor es una herramienta de virtualización ligera que permite ejecutar aplicaciones de manera aislada en un mismo sistema operativo. A diferencia de las máquinas virtuales, los contenedores comparten el mismo kernel y recursos del host, lo que los hace más eficientes y rápidos.

Ahora bien, ¿por qué debemos tratar a los contenedores como ganado y no como mascotas? La respuesta es simple: escalabilidad y automatización. Los contenedores están diseñados para ser desechables y reemplazables, es decir, podemos crear y eliminar contenedores de manera rápida y sencilla según nuestras necesidades. Además, los contenedores son altamente escalables, lo que significa que podemos replicarlos y distribuirlos en diferentes nodos para mejorar la disponibilidad y el rendimiento de nuestras aplicaciones.

En resumen, tratar a nuestros contenedores como ganado significa que estamos adoptando una mentalidad de automatización y escalabilidad, lo que nos permite gestionar y desplegar aplicaciones de manera más eficiente y rápida. En lugar de preocuparnos por cada contenedor individual, debemos enfocarnos en la automatización y la gestión a gran escala, lo que nos permitirá aprovechar al máximo el potencial de los contenedores y obtener los mejores resultados para nuestras aplicaciones y proyectos.

¿Sabes como optimizar este bloque de código a mitad del tiempo?

async function getPageData() {
  const user = await fetchUser()
  const product = await fetchProduct()
}

Como puedes observar en el bloque de código, esperamos a que se obtengan los datos del usuario para poder obtener los datos del producto de una forma secuencial.

Pero uno no depende del otro, por lo tanto, no deberíamos esperar una petición que termine para continuar con la otra.

En vez de eso, podemos hacer las dos peticiones juntas y esperar ambas por concurrencia.

Usando Promise All

Una manera para solucionar eso, es utilizar promise all

async function getPageData() {
  const [user, product] = await Promise.all([
    fetchUser(), fetchProduct()
  ])
}

Y ahora imagínate que cada petición dura 1 segundo en responder, mientras que en nuestra función original esperaríamos ambos en una fila totalizando 2 segundos para que se complete nuestra función, en esta nueva función esperamos ambos simultáneamente para que nuestra función se complete en 1 segundo, ¡la mitad del tiempo!

Pero, hay un problema

Here is the problem...

Primero, no estamos capturando ningun tipo de error.

Asi que puedes decir, pondre un gran bloque de try y catch

async function getPageData() {
  try {
    const [user, product] = await Promise.all([
      fetchUser(), fetchProduct()
    ])
  } catch (err) {
    // 🚩 this has a big problem...
  }
}

Pero esto tiene un gran problema.

Supongamos que el método fechUser() marca un error, eso nos llevara un error en tiempo de ejecución y se pasara al catch y bloqueara el flujo continuo de la aplicación.

Pero aquí está el truco: si fetchProducts luego se equivoca, esto no activará el bloque de captura. Esto se debe a que nuestra función ya ha continuado. El código de captura se ha ejecutado, la función se ha completado, hemos seguido adelante.

Así que esto resultará en un rechazo de la promesa no manejado. Ack.

Entonces, si tenemos algún tipo de lógica de manejo, eso le pregunta al usuario o guarda en un servicio de registro de errores, así:

// ...
} catch (err) {
  handle(err)
}
// ...

function handle(err) {
  alertToUser(err)
  saveToLoggingService(err)
}

Lamentablemente, solo seremos conscientes del primer error. El segundo error se perderá en el éter, sin comentarios de los usuarios, sin ser capturado en nuestros registros de errores, es efectivamente invisible (además de un poco de ruido en la consola del navegador).

Resolviendo con Catch

Una solución a nuestro problema anterior es pasar una función a .catch(), por ejemplo así:

function onReject(err) {
  handle(err)
  return err
}

async function getPageData() {
  const [user, product] = await Promise.all([
    fetchUser().catch(onReject), // ⬅️
    fetchProduct().catch(onReject) // ⬅️
  ])

  if (user instanceof Error) {
    handle(user) // ✅
  }
  if (product instanceof Error) {
    handle(product) // ✅
  }
}

En este caso, si nos sale un error, volvemos a manejar el error y lo devolvemos. Así que ahora nuestros objetos de usuario y producto resultantes son un error, que podemos verificar con instanceof, o de lo contrario nuestro buen resultado real.

Esto no es tan malo, y resuelve nuestros problemas anteriores.

Pero, el principal inconveniente aquí es que debemos asegurarnos de que siempre estamos proporcionando ese .catch(onReject), religiosamente, en todo nuestro código. Lamentablemente, esto es bastante fácil de pasar por alto, y tampoco es el más fácil de escribir una regla de eslint a prueba de balas.

Cachando errores por separado

Como nota al margen, es útil tener en cuenta que no siempre necesitamos esperar inmediatamente una promesa después de crearla. Otra técnica que podemos utilizar aquí que es prácticamente la misma es esta:

async function getPageData() {
  // Fire both requests together
  const userPromise = fetchUser().catch(onReject)
  const productPromise = fetchProduct().catch(onReject)

  // Await together
  const user = await userPromise
  const product = await productPromise

  // Handle individually 
  if (user instanceof Error) {
    handle(user)
  }
  if (product instanceof Error) {
    handle(product)
  }
}

Debido a que disparamos cada búsqueda antes de esperar a cualquiera de ellas, esta versión tiene los mismos beneficios de rendimiento que nuestros ejemplos anteriores que usan Promise.all .

Además, en este formato, podemos usar de forma segura try/catch si lo deseamos sin los problemas que tuvimos anteriormente:

async function getPageData() {
  const userPromise = fetchUser().catch(onReject)
  const productPromise = fetchProduct().catch(onReject)

  // Try/catch each
  try {
    const user = await userPromise
  } catch (err) {
    handle(err)
  }
  try {
    const product = await productPromise
  } catch (err) {
    handle(err)
  }
}

Entre estos tres, personalmente me gusta la versión de Promise.all, ya que se siente más idiomático decir "espera estas dos cosas juntas". Pero dicho esto, creo que esto se reduce a la preferencia personal.

Resolviendo con Promise.allSettled

Otra solución, que está integrada en JavaScript, es usar Promise.allSettled.

Con Promise.allSettled, en lugar de recuperar el usuario y el producto directamente, obtenemos un objeto de resultado que contiene el valor o error de cada resultado de la promesa.

async function getPageData() {
  const [userResult, productResult] = await Promise.allSettled([
    fetchUser(), fetchProduct()
  ])
}

Los objetos resultantes tienen 3 propiedades:

• status: "fulfilled" or "rejected"
• value: Solo está presente si el estado se "cumple". El valor con el que se cumplió la promesa
• reason: Solo está presente si el estado es "rechazado". La razón por la que la promesa fue rechazada con.

Así que ahora podemos leer cuál era el estado de cada promesa y procesar cada error individualmente, sin perder nada de esta información crítica:

async function getPageData() {
  // Fire and await together
  const [userResult, productResult] = await Promise.allSettled([
    fetchUser(), fetchProduct()
  ])

  // Process user
  if (userResult.status === 'rejected') {
    const err = userResult.reason
    handle(err)
  } else {
    const user = userResult.value
  }

  // Process product
  if (productResult.status === 'rejected') {
    const err = productResult.reason
    handle(err)
  } else {
    const product = productResult.value
  }
}

Pero, eso es un poco repetitivo. Así que vamos a abstraer esto:

async function getPageData() {
  const results = await Promise.allSettled([
    fetchUser(), fetchProduct()
  ])

  // Nicer on the eyes
  const [user, product] = handleResults(results)
}

Y podemos implementar una función simple handleResults así:

// Generic function to throw if any errors occured, or return the responses
// if no errors happened
function handleResults(results) {
  const errors = results
    .filter(result => result.status === 'rejected')
    .map(result => result.reason)

  if (errors.length) {
    // Aggregate all errors into one
    throw new AggregateError(errors)
  }

  return results.map(result => result.value)
}

Podemos usar un truco ingenioso aquí, la clase AggergateError, para lanzar un error que puede contener múltiples dentro. De esta manera, cuando se detecta, obtenemos un solo error con todos los detalles, a través de la propiedad .errors en un AggregateError que incluye todos los errores incluidos:

async function getPageData() {
  const results = await Promise.allSettled([
    fetchUser(), fetchProduct()
  ])

  try {
    const [user, product] = handleResults(results)
  } catch (err) {
    for (const error of err.errors) {
      handle(error)
    }
  }
}

Y oye, esto es bastante simple, agradable y genérico. Me gusta.

Cuando empezamos a realizar nuestra aplicación del lado del servidor, es muy normal que se inicie como una Arquitectura Monolítica. ¿Y que significa Arquitectura Monolítica? Pues es aquel proyecto que trabaja con un solo lenguaje de programación y una única base de datos. Esta arquitectura es ideal cuando se trabaja un proyecto pequeño, pero ¿Que pasa cuando nuestro proyecto esta creciendo a gran escala? Bueno es debido decir, que una arquitectura monolítica se vuelve una limitante cuando acceden a la aplicación muchos usuarios, pues la aplicación debe ser capaz de soportar a esa gran cantidad de usuarios que acceden, así como la consulta rápida y respuesta inmediata del servidor, y es ahí donde entra el concepto de Microservicios.

¿Qué es Microservicios?

Es una arquitectura de microservicios que unifica a una aplicación como un conjunto de pequeños servicios. Lo que admite esta arquitectura es la variedad de clientes (navegadores de escritorio, móviles y aplicaciones móviles y nativas). La aplicación es capaz de manejar las solicitudes y mensajes HTTP durante la ejecución de la lógica y retorna una respuesta HTML/JSON/XML.

Algunas de sus características son

• Los servicios se despliegan de manera independiente.
• Cada servicio se enfoca en realizar una tarea en específico.
  • Cada servicio es soportado por un equipo y el equipo puede evolucionar su servicio, independientemente de los demás microservicios.
• Código entendible.
  • Los servicios son pequeños, lo que vuelve su código entendible para los desarrolladores.
• Puede utilizar varios lenguajes de programación y cada servicio cuenta con su propia base de datos.
• Cuando un servicio se cae, la aplicación no se derriba sino que continua trabajando recibiendo y enviando solicitudes, con la diferencia de que tiene un servicio menos.

Los microservicios permiten a una empresa poder evolucionar su tecnología. La imagen muestra un ejemplo de Aplicación de comercio electrónico ficticia.

Entonces ... ¿Cuando debemos utilizar los microservicios?

En primera instancia cuando apenas hemos desarrollado la primera versión de nuestra aplicación, es poco probable que tenga problemas que puedan ser resueltas con microservicios, pues las nuevas empresas lo que buscan es iniciar con su lógica de negocios, sin embargo, cuando se a trabajado durante un tiempo considerable con el código, y la evolución de este es enorme, puede que empiecen los problemas, ya que, mantener una aplicación de gran tamaño y utilizando una arquitectura monolítica se vuelve complicado.

A pesar de ellos es importante tener en cuenta que no podemos migrar de una arquitectura monolítica a microservicios de un solo jalón, la transcisión a una nueva arquitectura se empieza de poco en poco. Y lo verdaderamente desafiante es ¿Cómo descomponer la aplicación en microservios?. Las siguientes estrategias pueden ser de mucha ayuda:

• Descomponer por capacidad empresarial
• Descomponer por subdominio de diseño impulsado por dominio
• Descomponer por verbo o caso de uso y definir los servicios encargados de realizar cosas particulares, por ejemplo, un carrito de compra, pago por tarjeta, etcétera.
• Descomponer por sustantivos o recursos y definir los servicios que son responsables de entidades/recursos. Por ejemplo, un servicio responsable de la gestión de cuentas de usuario.

La siguiente imagen muestra la variedad de patrones que podemos toparnos al implementar una arquitectura de microservicios.

Conclusión

Algunas empresas de gran escala como lo son Netflix, Amazon, eBay han evolucionado, pues pasaron de tener una arquitectura monolítica a microservicios.

Netflix responsable de un 30% del tráficos de internet, recibe más de mil millones de llamadas a su API por día desde diferentes tipos de dispositivos.

Usar microservicios es una ópción que quizás debamos considerar cuando contamos con una aplicación gigantesca que reciba muchas peticiones al día, pues los microservicios nos brindan una arquitectura estructurada y ordenada, aunque no debemos de olvidar que la transición a microservicios no es nada fácil, lo que si es seguro que los servicios nos permitirán escalar y evolucionar nuestra aplicación conforme nuestra lógica de negocios así lo requiera.

Tal vez si eres un principiante como yo, mientras navegas por el amplio universo del Internet, te has topado con conceptos que no entiendes, o si eres pro activo, los has investigado y esto solo complica mas las cosas porque te topas con otros términos que tampoco entiendes.

Uno de esos términos puede que sea el de "Clean Architecture" ó "Arquitectura Limpia". El día de hoy te quiero presentar y tratar de aclarar de forma general este concepto así como sus características, OJO este articulo no pretende explicarte a profundidad para eso te dejare al final unos enlaces donde podrás encontrar información mas detallada sobre este tema, comencemos...

¿Que es la Arquitectura Limpia?

Cuando vamos desarrollando un proyecto que podrá crecer eventualmente, al principio tal vez no le demos mucha importancia al como debe estar segmentado, pero a medida de que este crece nos vamos a dar cuenta de que probablemente es difícil de leer y peor aun, es difícil de mantener, es aquí donde pensamos que quizás y solo quizás debimos investigar si existe alguna manera de organizar nuestro código para no tener estos problemas.

Pues bien es esto lo que hace una arquitectura limpia la cual nos va guiando en la construcción de nuestro proyecto y nos indica como es que debemos organizarlo y que reglas se deben cumplir, mas adelante se abordara esto, mientras tanto es importante mencionar que el termino viene del libro titulado "Clean Code" escrito por Robert C. Martin, un libro que si quieres puedes comprarlo solo debes buscarlo en Google.

¿Que conforma una Arquitectura limpia?

Bien tenemos 2 tipos de principios los de Cohesión y los de Acoplamiento ademas de 5 características

Principios de Cohesión

• The Reuse/Release Equivalence Principle En síntesis nos dice que los componentes se deben ejecutar de manera independiente sin afectar a otros.
• The common closure principle Si algunas clases deben cambiar por la misma razón, estas deben ser agrupadas.
• The common reuse principle Si un componente depende de otro debemos intentar que se usen la mayoría de las clases del componente del cual se esta dependiendo.

Principios de Acoplamiento

• The Acyclic Dependencies Principle Si llegamos a cambiar una dependencia este cambio no debe afectar el resto del proyecto.
• The stable dependencies Principle Si un componente cambia constantemente no debe depender de alguno que sea complejo de modificar.
• The stable Abstractions Principle Si un componente es difícil de modificar debemos cuidar que este compuesto por interfaces y clases abstractas para así hacerlo extensible y mantener la arquitectura.

Caracteristicas

1. Independiente de los framework Esto debido a que si en algún momento cambiamos de Framework no debemos tener inconvenientes de compatibilidad
2. Testable Debemos poder realizar las pruebas necesarias sin necesidad de componentes externos como por ejemplo la base de datos.
3. Independiente de la UI El proyecto no debe verse afectado si la UI llega a cambiar.
4. Independiente de la base de datos Si en algún momento requerimos el cambio de proveedor de base de datos no debe afectar el proyecto.
5. Independiente de cualquier entidad externa Los componentes deben desconocer que sucede afuera de ellos.

Muchas reglas y eso pero en sí que nos dice todo esto, bueno como puedes ver en la imagen esta arquitectura nos presenta un diseño de capas donde en el centro se encuentra nuestra lógica de negocios y todos los componentes externos, o dependencias, van en las capas siguientes esto es así para que si en algún momento debemos cambiar incluso todos los componentes podamos de alguna manera desacoplar nuestra lógica de negocio y acoplarla en otro ambiente conformado por otras dependencias y con los ajustes necesarios esta siga funcionando con normalidad, , por esto la importancia en que no dependamos de Frameworks, bases de datos etc.

Es importante mencionar que es muy difícil llegar a cumplir todas estas reglas, muchas veces se debe hacer un análisis para ajustar el diseño y tratar de cumplirlo en su totalidad, ademas de que no existe una sola arquitectura limpia, pues cualquiera que cumpla con las características anteriormente mencionadas podrá ser considerada.

Como prometí aquí te dejo 3 recursos si quieres profundizar en el tema:

• Principios de una arquitectura limpia: mantenible y testeable
• Clean Architecture: La mejor forma de escalar y mantener tu código
• Introducción a Arquitectura Limpia

En esta ocasión, recomendaremos un conjunto de herramientas de monitoreo; estas son las mas utilizadas actualmente. Para esto tengamos en cuenta que despues de desplegar un servicio o una aplicación, debemos de saber todo lo que sucede en este mismo, pues si llegase a fallar por situaciones desconocidas, tenemos que estar informados y estar conscientes de que hay un error para posteriormente solucionarlo cuanto antes y asi evitar que los usuarios que consumen esta aplicación tengan dificultades para acceder a ella.

Para monitorear nuestros servicios utilizaremos Prometheus con Grafana, tambien utilizaremos Node Exporter y CAdvisor.

Prometheus es una base de series de tiempo y un sistema de monitoreo y alertas,

Grafana es la plataforma de análisis para métricas, que le permite consultar, visualizar, alertar y comprender los datos, sin importar dónde estén almacenadas. Le permite crear, explorar y compartir tableros con su equipo.

Node Exporter y CAdvisor nos servirán para obtener las métricas que queremos visualizar, Node Exporter nos expondrá las métricas con respecto a CPU, Memoria, Disco duro, etc del servidor, y CAdvisor nos dará las métricas de nuestros contenedores, los recursos que consumen, entre otros valores.

version: '3'

services:
  # monitoring linux host metrics
  node-exporter:
    image: prom/node-exporter:latest
    container_name: monitoring_node_exporter
    restart: unless-stopped
    ports:
      - 9100:9100

  # monitoring metrics for the running containers
  cadvisor:
    image: google/cadvisor:latest
    container_name: monitoring_cadvisor
    restart: unless-stopped
    ports:
    - '8080:8080'
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:rw
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

  # event monitoring and alerting
  prometheus:
    image: prom/prometheus:latest
    container_name: monitoring_prometheus
    restart: unless-stopped
    ports:
      - '9090:9090'
    volumes:
      - ./prometheus/config:/etc/prometheus/
      - prometheus-data:/var/lib/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    links:
      - node-exporter:node-exporter
      - cadvisor:cadvisor

  # database for analytics & monitoring solution
  grafana:
    image: grafana/grafana:latest
    container_name: monitoring_grafana
    restart: unless-stopped
    user: "1000" # grafana needs permisions
    ports:
      - '3000:3000'
    volumes:
      - grafana-data:/var/lib/grafana
    links:
      - prometheus:prometheus
    depends_on: 
      - prometheus
      
volumes:
  grafana-data:
  prometheus-data:

Este será el docker-compose.yaml que nos servirá para levantar nuestro conjunto de contenedores los cuales nos ayudaran con el monitoreo de nuestro servidor y de los contenedores que se estén ejecutando dentro de este mismo.

Para practicidad podemos encontrar este repositorio en https://github.com/paulspartan14/prometheus-grafana

despues de analizar el docker-compose.yaml, vemos que en los volumenes hacemos referencia a la ruta 'prometheus/config' la cual nos brinda un archivo de configuración de prometheus.yml en el cual le indicaremos que servicios son los que vamos a configurar, en este caso seria el mismo prometheus, node-exporter y cadvisor, para esto aplicaremos la siguente configuración:

global:
  scrape_interval: 5s # By default, scrape targets every 15 seconds.
  external_labels:
    monitor: 'Monitoring'
scrape_configs:
  - job_name: 'prometheus' 
    static_configs: 
      - targets: ['localhost:9090']
  - job_name: 'node-exporter' 
    static_configs: 
      - targets: ['node-exporter:9100']
  - job_name: 'cAdvisor' 
    static_configs:
     - targets: ['cadvisor:8080']

despues ejecutaremos el comando "docker-compose up -d" el cual levantará nuestros servicios, despues de esto veremos que nos despliega diferentes contenedores, pero el que nos ayudará a visualizar las métricas será el contenedor que esta corriendo en el http://localhost:3000

despues de entrar y asignarle las credenciales correspondientes al prometheus y anclar grafana podemos utilizar el panel con el id "10566"

y posterior a esto nos devolverá una cómoda interfaz en la cual podemos ver nuestros servicios corriendo.

Muchas personas saben programar, pero pocas saben “desarrollar”. Desarrollar no sólo es escribir código, es hacerlo bien y TDD, el tema de hoy, es una herramienta para lograr ese objetivo.

Manteniendo todo en orden

Al hacer un producto de software, una web API, por ejemplo, siempre hay sistemas que mantienen todo bajo control: Git y GitHub nos ayudan a mantener el código versionado y guardado, las metologías ágiles mantienen al equipo y el trabajo en un ritmo de trabajo controlado y, como estas, hay más herramientas que evitan que nuestro producto se convierta en un development hell. Pero, no hay un sistema que nos diga en qué orden hacer el código. Aquí es donde entra al espectáculo el panorama de TDD.

¿Qué es el TDD?

TDD o Test Driven Development (desarrollo basado en tests, por su traducción al español), es una pespectiva de desarrollo donde, como su nombre lo dice, predominan los tests o pruebas del sistema. Estas pruebas pueden ser unitarias, de integración, punto a punto, etcétera. La gracia del TDD es que, antes de programar y desarrollar la plataforma, tengamos instrumentos a través de los cuáles medir los avances que hagamos. Sólo hagámonos las siguinetes preguntas: ¿Cuántas veces no ha pasado que hacemos algo del software, para darnos cuenta al final que obviamos algo, y tenemos que volver a programarlo? Incluso si no te confundes y eres un desarrollador experimentado ¿Cómo te aseguras que las especificaciones para terminar una funconalidad o feature del sistema no van a ser interpretados de diferente manera por diferentes programadores? Sin duda, tener las pruebas desde un principio nos ayuda a solucionar estos problemas y mejorar la eficiencia de nuestro trabajo.

Vamos directo al grano...

Bueno, ¿cómo implementamos TDD? Veremos un pequeño ejemplo con Node JS, el framework Hapi.js y la librería de pruebas Jest. Para este ejemplo se considera que el lector posee conocimiento básicos para desarrollar un web API con Hapi.js y crear pruebas unitarias con Jest.

Primero que nada, antes de desarrollar algo, siempre tenemos que generar una historia de usuario, una épica o algún issue que defina la funcionalidad que queremos crear. Para nuestro ejemplo, estaremos desarrollando una plataforma de cursos en línea, por lo que una de sus tareas es poder registrar cursos:

Como administrador quiero registrar un curso a la plataforma:

Al hacer una petición POST a la web API en el endpoint “/courses”, con un payload que representen los datos del curso a ingresar, se debe crear en la base de datos un registro que contenga tales datos.

Ejemplo de payload:

nombreCurso: “Curso de Node js”

sesiones: 5

dificultad: “Fácil”

Genial. Ahora nos toca escribir los tests para que el desarrollador pueda comprobar si el código que escriba en un futuro estará bien.

En código anterior es una prueba unitaria que hace una petición POST a la web API para crear un curso, devolviendo un código HTTP 200, tal como queríamos. Sin embargo, hay ciertos comportamientos que no definimos explícitamente. Por ejemplo, se espera que la API devuelva el identificador de curso, aunque no estaba en la descripción de la tarea.

Este tipo de discrepancias suelen suceder, pero no por que sea un error, sino por convenciones del equipo de trabajo. Muchos desarrolladores suelen retornar el ID del registro creado después de un POST, y sería muy engorroso anotarlo como requisito en todas las descripciones de features de creación. Sin embargo, ya que tenemos el código de la prueba unitaria, fácilmente nos podemos dar cuenta de qué es lo que en realidad se necesita que realice el programador. De esta manera mantenemos limpias las descripciones de tareas que nuestro equipo tenga en GitHub, obviando todo aquello que se haya acordado generalizar, dando más enfoque a los detalles propios de la tarea y, en caso de que un desarrollador tenga dudas sobre qué exactamente se debe realizar, puede dar un vistazo a las pruebas unitarias.

Siguiendo con el ejemplo, desarrollamos la parte correspondiente a la creación de cursos en la web API y, durante este tiempo se pueden ejecutar las pruebas para saber cuándo una tarea está completada. De igual forma, TDD nos tiene varias ventajas, no sólo al crear nuevas funcionalidades, sino al trabajar sobre código ya escrito. Los tests dirán si, de manera accidental, estropeamos algo que otra persona hizo, haciendo del proceso de debugging algo más fácil y sencillo.

Conclusión

TDD hace el desarrollo más fácil y ordenado, de eso o hay duda. De hecho, TDD sólo es uno de los muchos paradigmas para desarrollar, existen otros como BDD, y te lo contaremos en el siguiente post.