Desarrollo

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.

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?

Azure Durable Functions es una gran extensión de las Azure Functions que nos permite generar «recetas» o definir procesos que involucren diferentes Azure Functions para llevar a cabo una tarea cuyo resultado conjunto no pueda ser resuelto por una de ellas debido a su complejidad. De esta forma, una Durable Function comienza con un «Orquestador» que definirá las reglas o el flujo que deben seguir en la actuación de las diferentes Azure Functions involucradas . Hasta aquí todo es relativamente sencillo pero, ¿qué ocurre cuando el proceso incluye a su vez subprocesos complejos? Es aquí donde aparecen las Suborquestaciones y os lo enseño en este artículo con código y en el vídeo incluído al final.

En un artículo reciente os hablé de cómo unir dos listas de elementos en C# con Linq eliminando los duplicados y en este artículo os traigo una pequeño tip muy simple que es cómo reemplazar un elemento de una lista.

En muchas ocasiones es necesario combinar dos listas de elementos del mismo tipo de objeto sin tener la certeza de que puedan o no existir duplicados. Realizar esta combinación es, a priori, una tarea sencilla puesto que podemos resolverla usando un bucle y realizando todas las comprobaciones pertinentes pero, ¿es la forma más elegante y legible? Gracias a Linq podemos resolver esta tarea, y otras muchas, sin necesidad de escribir grandes cantidades de código y haciéndolo mucho más legible y mantenible.

Mientras desarrollaba la aplicación Torch8 me encontré con estas dos formas de controlar el flash de la cámara pero, ¿cuál es la adecuada para qué momento y cómo debo usarla?

Si vamos a la documentación podemos observar que la ayuda para tomar esta decisión es mínima y que depende en gran medida de la interpretación que hagamos sobre la descripción.

• TorchControl : Provides functionality for controlling the torch LED settings on a capture device.
• FlashControl : Provides functionality for controlling the flash settings on a capture device.

Y os preguntaréis… WTF!! Pero si es análogo!! Pues no exactamente. Digamos que la diferencia es que Torch está pensado simplemente para alumbrar porque sí y Flash está pensando para realizar la acción de flash durante una captura de una foto o un vídeo aunque en definitiva, sea prácticamente lo mismo. De hecho, FlashControl contiene alguans propiedades más como RedEyeReduction y RedEyeReductionSupported que nos dan esa misma idea.

Un año más, Codemotion ha sido uno de los mayores eventos sobre tecnolgías de desarrollo de software de España y, este año, me ha tocado el privilegio de participar por partida doble con sesiones sobre Branding en SharePoint (Online y OnPremises) y sobre Aspectos útiles de Machine Learning en Universal Windows Platform Apps. Además, como siempre, Microsoft ha participado muy activamente arropando a los que íbamos a hablar sobre tecnologías .NET y relacionadas así como ofreciendo a todos los asistentes la posibilidad de pasarse por una amplia zona de entretenimiento y networking en la que se podía contactar con cualquiera de los miembros de DX e informarse de todas las ventajas que se ofrecen.

Migration note: the original event poster from the legacy blog was removed after a targeted retry confirmed the source files still return 404.

El próximo viernes 4 de diciembre, gracias a la iniciativa de Josué Yeray, se celebrará el primer Talks4Kids en las instalaciones de Microsoft Ibérica (Urbanización La Finca en Pozuelo de Alarcón, Madrid) y tendré el enorme placer de poder impartir una sesión con un título atópico “Por qué los espartanos molan y Gerges debe morir”, pero no os asustéis, que no va a haber lanceros, ni persas, ni espartanos… ¿o sí? jjjj

Escenario

Supongamos que tenemos un formulario en una vista de una aplicación web realizada con ASP.MVC y necesitamos enviar los datos, que corresponden a un modelo de la aplicación, a nuestra acción del controlador. ¿Cómo realizamos esta tarea? Seguro que se nos ocurren ideas «liosas» para realizar esta operación pero generalmente optamos por lo más obvio que, además, no es óptimo ni flexible o no aprovechamos las facilidades que nos ofrece el ModelBinding.