Articulos

Con la evolución de herramientas de desarrollo que hacen uso de la IA como GitHub Copilot, Claude Code, Cursor y compañía, es natural preguntarse si el rol del developer está en peligro de extinción.

Desde luego, ya no desarrollamos, o no deberíamos desarrollar, código a mano como antes. Ahora nos apoyamos en estas herramientas para generar código de manera más eficiente y mucho más rápida. Y en este contexto he visto multitud de artículos, posts y reflexiones donde hay quien afirma que el rol del developer está muerto, o que va a morir, o que va a ser sustituido por la IA; y, contrariamente, hay quien afirma que no, que todo es puro alarmismo.

Como todos tienen su propia opinión y, ya sabéis, las opiniones son como los culos, con perdón, todos tenemos una, voy a compartir la mía. Y lo haré desde mi experiencia actual: la de un developer que lleva más de 20 años desarrollando en equipo y que ha vivido la evolución desde los editores de texto hasta las modernas herramientas de IA.

La mayoría de demos con agentes funcionan muy bien hasta que aparece el primer problema real: hay que persistir contexto, exponer capacidades por HTTP, desacoplar eventos, aguantar reinicios y, además, mantener el sistema operable por un equipo backend normal.

Ahí es donde Dapr Agents resulta interesante. No tanto por la palabra “agent”, sino porque aterriza el problema sobre piezas de plataforma que ya conocemos: state stores, pub/sub, workflows, APIs y sidecars.

En este artículo voy a contar cómo encaja esa idea en un proyecto real: D&D Copilot, un juego conversacional con backend en ASP.NET Core, frontend en React y una capa de NPCs que ya adopta varios conceptos de Dapr Agents aunque la aplicación esté implementada en .NET.

Como ya conté en un artículo anterior, .NET 6 no incluye fichero Startup.cs para apoyar los procesos de inicialización de una solución, sino que se implementa todo desde el propio Program.cs. Esto resulta beneficioso en proyectos simples pero, cuando aumentamos la complejidad, es posible que ese Program.cs comience a tener una cantidad de líneas poco manejable y se convierta en un fichero de «código espaguetti». ¿Qué soluciones tenemos para crear un fichero Startup.cs en .NET 6?

Aunque hay muchas formas de escribir estilos cuando trabajamos con React.js, es bastante habitual usar Sass, que no es más que CSS con superpoderes, para escribir las hojas de estilos pero que requieren de una pequeña librería para compilar lo que hemos escrito en reglas CSS puras. Es aquí donde entraba el archiconocido node-sass que tantos quebraderos de cabeza solía dar, pero…

Aunque el concepto de React.JS y Web Components es muy parecido en el fondo, crear componentes reutilizables, resuelven problemas diferentes porque se aplican a contextos muy distinto ya que, Web Components se basa en crear mini-componentes que puedan ser incrustados en cualquier desarrollo web y en React.JS se crean componentes que pueden ser reutilizados dentro de cualquier desarrollo con React. Pero ¿es posible mezclar ambos mundos? La respuesta es sí, y además de una forma muy sencilla.

¿Problemas con los pipelines de compilación de proyectos React/Node? Si la respuesta es sí y esos problemas se vienen produciendo desde el 1 de diciembre… esta puede ser la solución.

En ocasiones, al desarrollar aplicaciones web es necesario realizar un diseño que acepte el cambio de Tema para adaptarlo a las necesidades del cliente de forma dinámica y que pueda personalizar su experiencia. Si estamos usando React.JS junto con JSS para aplicar los estilos, podemos hacerlo de forma manual añadiendo el código necesario o, usar la característica de Theming de JSS.

En mayo de este año 2021, Microsoft anunció la llegada de nuevos proveedores de almacenamiento (Storage Providers) para mejorar el rendimiento de Azure Durable Functions ya que, en algunos casos, se requiere de mayor rendimiento, fiabilidad o flexibilidad. En este artículo veremos cómo cambiar el Storage Provider a Netherite, cómo funciona y qué ventajas nos aporta.

Ahora que tenemos .Net 6 disponible para desarrollar, es necesario que nos acostumbremos a ciertos cambios en cuanto a la configuración y ubicación de determinados fragmentos de código así como a nueva nomenclatura y significativos cambios que tienen el fin de simplificar el desarrollo. Entre estos cambios, se encuentra especificar los ficheros y otros orígenes de configuración de nuestras aplicaciones, es decir, de dónde se tomarán los valores de las variables de entorno y configuración a la hora de ejecutar las aplicaciones.

Para los desarrolladores de .Net, es habitual usar el archivo Startup.cs, que viene por defecto en ciertas plantillas de proyecto, entre ellas las de proyectos de Web y de Api, para realizar determinadas tareas que deben ejecutarse al inicio, como determinar los orígenes de las variables de entorno/configuración, añadir servicios al contenedor de dependencias, etc. e incluso aprendimos a añadirlo en proyectos de consola donde no viene por defecto. Pero, al crear un proyecto de Web y de Api con .Net 6, podemos apreciar que ya no existe este fichero Startup.cs. ¿Y ahora dónde ponemos nuestra configuración?