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.
Otro año más ya llevamos 5 ediciones, un poco este año es como pasar la reválida. Primer año en el que ya no se habló de covid, de medidas sanitarias… un poco la vuelta a la normalidad. Esta edición la organización en la que yo pertenezco decidimos unos pequeños cambios, queremos potenciar lo que para nosotros tiene que ser un evento de comunidad: que los asistentes se lo pasen pipa, que los speakers tengan ganas de venir a nuestros eventos y tengan implicación con el evento y por último y no menos importante que los partners nos vean un evento atractivo y quieran participar. Eso es un poco la esencia de la NetCoreConf ser un poco diferentes al resto y no queríamos perder se sello. Si todos los asistentes/speakers/partner os habéis sentido bien, eso significa que hemos conseguido nuestro objetivo.