En el mundo del desarrollo de software moderno, la seguridad y el rendimiento no deben ser una ocurrencia tardía, sino pilares fundamentales desde el inicio del proyecto. Ignorar estos aspectos puede llevar a vulnerabilidades críticas y a un deterioro del rendimiento que afecte directamente la experiencia del usuario y, en última instancia, la viabilidad de un producto. Una de las estrategias más efectivas y sencillas para mitigar estos riesgos es la implementación de Rate Limiting.
Recientemente se ha lanzado .NET 9, que no es una versión de soporte extendido (LTS). Ya compartí mi opinión sobre el tema del versionado y cómo lo gestionamos en ocasiones en el artículo que escribí para CompartiMOSS hace un tiempo. Si me preguntáis si en los proyectos en los que trabajamos vamos a migrar a .NET 9, mi respuesta es un rotundo SÍ.
¡La NetCoreConf 2024 en Madrid fue todo un éxito! Este evento, celebrado en las oficinas de Microsoft en Pozuelo de Alarcón, destacó por ser un espacio donde la comunidad tecnológica se reunió para aprender, compartir y conectar. Con una agenda variada que incluyó temas como Power BI & Fabric, .NET Aspire, Inteligencia Artificial, Big Data, y Unity Catalog, el evento combinó charlas inspiradoras con talleres prácticos.
A lo largo de mi trayectoria profesional, siempre he sido y sigo siendo un firme defensor de las buenas prácticas de programación, esforzándome para que los proyectos en los que participo sean motivo de orgullo. Sin embargo, quienes llevamos tiempo en proyectos sabemos que, por muy bueno que sea alguien o por mucho conocimiento que tenga, no puede hacer que un proyecto sea excelente por sí solo. Todo ese conocimiento debe compartirse entre los miembros del equipo para que puedan aplicarlo y así evitar cometer errores. ¿Cómo se puede lograr esto? Hace tiempo, era un firme defensor de herramientas de análisis estático de código, como SonarQube o Kiwan. Estas herramientas analizaban el código una vez que lo subías a la rama y te mostraban sugerencias/recomendaciones para mejorarlo. No obstante, hay aspectos que no terminan de encajar en los equipos. El primero es el tiempo: tienes que subir tu código y luego consultar qué cosas puedes mejorar. ¿Qué ocurría la mayoría de las veces? Que, al final, los últimos días del proyecto se dedicaban a “solucionar” lo que, según estas herramientas, estaba mal, pero el objetivo no es solo corregir, sino aprender. Y cuando el equipo lo hace de esta manera en el último día, no se aprende realmente (es como cuando estudiabas todo la noche antes de un examen, ¿sinceramente, te acordabas de lo que habías estudiado una semana después?). Además, hay otro motivo por el cual actualmente tampoco confío tanto en estas herramientas: además de ser un análisis sintáctico, el código tiene un contexto, un “por qué”. A veces, haces las cosas de cierta forma porque lo consideras necesario. Un ejemplo trivial: si hacemos un proyecto con una arquitectura Vertical Slice, independientemente de si el equipo lo hace mejor o peor, la herramienta probablemente señalará que hay código repetido o que se podría refactorizar. Pero, según Vertical Slice, cada “feature” debe tener todo lo necesario para ser independiente de las otras, y no podemos reutilizar una clase modelo (DTO), aunque la base sea la misma (se podría, pero entonces no lo llamaríamos Vertical Slice aunque esa conversación daría para otro post). Está claro que este es un ejemplo muy obvio, pero puede haber decisiones que se toman debido a la casuística de ese desarrollo, y aunque no sean la mejor opción desde el punto de vista estático, sí lo son para cumplir con los requisitos de la aplicación. Además, he visto proyectos con una puntuación “A” en Sonar que eran, sinceramente, de los más chapuceros que he visto, mientras que otros con una “C” mostraban un rendimiento espectacular gracias a las decisiones que se tomaron.
Quizás uno de los servicios más caros que ofrece Azure sea Cosmos DB, un servicio que reúne diversas bases de datos no relacionales con una multitud de características que la convierten en una de las mejores del mercado. Sin embargo, ¿realmente es tan caro para implementarlo en todos los proyectos, o quizás no lo es tanto? En este artículo, intentaremos ofrecer una serie de consejos para comprender mejor todo lo que Azure nos ofrece y así poder pagar lo necesario en nuestro desarrollo.