The lost reference

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?

Al desarrollar un proyecto siempre es necesario disponer de diferentes entornos para poder desarrollar y testear antes de pasar a producción. Así, es habitual tener entornos de Desarrollo, Pre-Producción y Producción aunque también podemos encontrarnos con escenarios con más (o menos) entornos. Por ello, es necesario disponer de variables de entorno que puedan ser configurables de forma automática a la hora de compilar/ejecutar nuestras aplicaciones react, tales como URLs de Apis, Client Ids, etc.

Los pasados días 23, 24 y 25 tuve la fortuna de participar, un año más, en el Global Azure como Organizador y ponente. En esta nueva edición además, participé en el track global con dos sesiones junto a mi gran amigo Diego Zapico, además de participar en el track español en formato entrevista junto a muchísimos cracks en las tecnologías que forman parte de Azure.

Cuando creamos una aplicación o un sitio web es necesario que le instalemos un certificado SSL para permitir una comunicación segura entre los usuarios que accedan y el servidor. Además, hacerlo generará confianza en los usuarios evitando que los navegadores les muestren un mensaje indicando que nuestro sitio web es inseguro y, los buscadores le otorgarán un mejor posicionamiento premiando así la seguridad. Si desplegamos nuestro sitio web en Azure App Service, es posible crear y añadir este certificado de forma sencilla y gratuita usando los Certificados administrados para App Service.

Cuando desarrollamos una Azure Function y la depuramos en local, poco se puede ver en la consola que se levanta y nos muestra la traza dada la cantidad y la velocidad con la que se muestra la información. Gracias al archivo de configuración de la function «host.json» podemos gestionar el nivel de logging que deseamos mostrar y así poder ver nuestros propios mensajes.

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.