En un vídeo del canal de Nick Chapsas, al que por cierto os recomiendo suscribiros, he descubierto que .NET 7 introducirá un mecanismo para "decorar" parámetros, propiedades y miembros de tipo string de forma que podamos aportar información sobre el tipo de contenido que esperan almacenar.
Para que lo entendáis mejor, observad el siguiente ejemplo, una función que recibe un mensaje y un formato de fecha, y que escribe por consola la fecha actual en el formato indicado seguido del mensaje.
void Log(string message, string dateFormat)
{
Console.WriteLine(DateTime.UtcNow.ToString(dateFormat) + " - " + message);
}
Log("Hello!", "dd/MM/yyyy hh:mm");
Desde el punto de vista del consumidor de la función Log(), gracias a las ayudas del IDE podremos deducir que el segundo parámetro de tipo string, llamado dateFormat, debería ser un formato de fecha válido en .NET. Sin embargo, el entorno de desarrollo no podrá ofrecer ningún tipo de ayuda a la hora de codificar la llamada ni detectar si se producen errores, pues no dispone de información suficiente sobre el tipo de contenido esperado en la cadena de texto que se le suministra.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Cómo conseguir uniones en .Net
José María Aguilar - Blazor Server + Entity Framework Core = InvalidOperationException (si no tienes cuidado)
José María Aguilar
.NET Core / .NET
- C# 11 - Top 5 Features in the new C# Version
Nikola M. Zivkovic - Counting the leading zeroes in a binary number with C#
Andrew Lock - AutoMapper vs Mapster in .NET
Code Maze - Memory is complicated
Steven Giesel - Default interface members and missing “public” in implementation
Jiří Činčura - How to log Correlation IDs in .NET APIs with Serilog
Davide Bellone - Writing unsafe .NET code without the unsafe keyword
Gérald Barré - Enumeration class in C# using records
Josef Ottosson
En algunas ocasiones me he topado con escenarios en los que necesitaba contar, o incluso enumerar, las claves de los elementos presentes en una caché en memoria, inyectada en mis servicios en forma de objeto IMemoryCache.
Aunque a priori pueda parecer sencillo, esta interfaz no proporciona métodos o propiedades que permitan acceder a la colección que actúa como almacén de los mismos, por lo que nos veremos obligados a usar una estructura de datos adicional (normalmente algún tipo de diccionario o hashset paralelo) para almacenar estos elementos.
¿O quizás tenemos otras fórmulas?
Tras varias semanas de parada, estamos de nuevo al pie del cañón y listos para iniciar la nueva temporada en el blog. Por detrás quedan algunas semanas de descanso, ya totalmente olvidadas, algunos objetivos incumplidos, como mover el blog a WordPress, y otros completados como la actualización de los cursos de ASP.NET Core y Blazor en CampusMVP a las últimas previews de .NET 7, que me ha tenido bastante ocupado.
Y qué mejor forma de volver que publicando la colección de enlaces que he ido recopilando durante la semana pasada, ¿verdad? Pues aquí los tenéis; como siempre, espero que os resulten interesantes.
Por si te lo perdiste...
- Diez años de enlaces interesantes: lo que siempre habéis querido saber sobre esta serie
José María Aguilar - Comentar porciones de código en un archivo .ASPX
José María Aguilar
.NET Core / .NET
- Announcing .NET 7 Release Candidate 1
Jeremy Likness - Working with System.Random and threads safely in .NET Core and .NET Framework
Andrew Lock - Referencing a Local Private NuGet Package in your Solution
Rick Strahl - Performance Improvements in .NET 7
Stephen Toub - .NET now on Windows Package Manager
Ashita Nagar - Serializing asynchronous operations in C#
Raymond Chen - C# Lambda Discards
Ian Griffiths - Improving Unit Tests with Fluent Assertions
Alvaro Montoya - Arm64 Performance Improvements in .NET 7
Kunal Pathak - AutoMapper Madness - Nuances in Self-Mapping
Scott DePouw - .NET One-line Scoped Initializers with Dependency Injection
Khalid Abuhakmeh - C# Tip: use Miniprofiler instead of Stopwatch to profile code performance
Davide Bellone - Microsoft Teams Assignments Service's Journey to .NET 6
Kevin Halverson - How to turn an ASP.NET Core appsettings.json file into a fast-read database
Jon P Smith
Como todos los mediados de Julio, poco más o menos, os informo de que el blog entrará en modo de bajo consumo de energía (de mi energía, básicamente 😉) hasta el próximo mes de septiembre, cuando volveremos a retomar el ritmo habitual de publicaciones.
Mientras tanto, espero descansar un poco, renovar fuerzas y disfrutar de la familia y la buena compañía, que durante el año no siempre es posible prestarles la atención que merecen.
Nos vemos a la vuelta, con las baterías bien cargadas y listos para comenzar la nueva temporada. ¡Que disfrutéis de las vacaciones!
Imagen: Puesta de sol en Cádiz (Costa Ballena)
Autor: Guillermo Martínez
Publicado en Variable not found.
Como sabemos, la respuesta a todas las peticiones HTTP comienzan por un código de estado que indica el resultado de la operación. Ahí encontramos desde los códigos más célebres, como HTTP 200 (Ok) o HTTP 404 (Not found) hasta otras joyas menos conocidas como HTTP 429 (Too many requests) o HTTP 418 (I'm a teapot).
Sin embargo, pocas veces nos fijamos en el texto que acompaña al código de respuesta, denominado reason phrase (en los ejemplos anteriores va entre paréntesis, como "Ok" o "Not found"). Según se define en la RFC 7230 sección 3.1.2, la reason phrase...
"... existe con el único propósito de proporcionar una descripción textual asociada con el código de estado numérico, principalmente como una deferencia a los protocolos iniciales de Internet, que eran utilizados frecuentemente por clientes de texto interactivos. Un cliente DEBERÍA ignorar su contenido"
Por tanto, dado que se trata de un texto arbitrario y puramente informativo, deberíamos poder modificarlo a nuestro antojo, más allá de los textos estándar proporcionados por el framework.