Penúltima entrega de enlaces interesantes antes del parón vacacional, con más de cincuenta referencias a contenidos a los que vale la pena echar un vistazo.
Por destacar, en esta entrega, encontramos a Marc Rubiño hablando sobre cómo aplicar el enfoque ágil de las startups (probar pronto, equivocarse rápido y adaptarse), no sólo en el mundo de la tecnología. Y sobre todo, perder el miedo a equivocarnos.
Ricardo Peres hace una recopilación de tipos de colecciones presentes en la BCL de ,NET, y muestra las mejores prácticas a la hora de utilizarlas.
Chris Pietschmann nos recuerda la importancia de escribir código testeable, independientemente de que escribamos o no pruebas unitarias.
Y por último, echamos un vistazo en profundidad a las diferencias entre las funciones ordinarias y las funciones flecha en JavaScript, de la mano de James Sinclair.
El resto de enlaces, a continuación.
Por si te lo perdiste...
- El operador 'with': mutaciones no destructivas en C#
José M. Aguilar - Redirecciones HTTP 303, 307 y 308: ¿las conoces?
José M. Aguilar
.NET
- Monitor your A/B test in .NET
Bart Wullems - Design Patterns Guide in .NET Using C# -Part II: Real-Time Project-Enterprise Notification System
Bhargava Koya - Testcontainers Best Practices for .NET Integration Testing
Milan Jovanović - Adding test description for data-driven tests in xUnit
Steven Giesel - Exploring the features of dotnet run app.cs
Andrew Lock - How to Find Public Symbols That Can Be Internal Using Roslyn
Gérald Barré - Evolving Text: Solving the “Hello World” Puzzle with a C# Genetic Algorithm
Chris Woodruff - .NET Collections
Ricardo Peres
El compilador de C# es listo, muy listo. Es capaz de analizar en tiempo real nuestro código para comprender lo que estamos haciendo y su contexto y, en muchas ocasiones, advertirnos de posibles errores antes de que seamos conscientes de que están ahí.
Pero lamentablemente aún no es adivino, y en algunas ocasiones tenemos que ayudarlo a que conozca nuestras intenciones. Para estos casos, existen una serie de atributos que añaden metadatos al código y que el compilador puede utilizar para realizar un análisis más preciso.
Hoy vamos a hablar de uno de estos atributos, MemberNotNullWhenAttribute, que nos permite dar pistas al compilador sobre la nulabilidad de un miembro de una clase en función del valor de otro miembro, algo que puede resultarnos muy útil en ciertos escenarios, como veremos a continuación.
De alguna forma, los desarrolladores somos como relojeros: construimos sistemas complejos utilizando piezas diminutas que van encajando armoniosamente unas con otras para formar una máquina que funciona como un todo y aporta valor a nuestros usuarios. Quizás por eso me ha llamado la atención un precioso y trabajado artículo interactivo de Bartosz Ciechanowski, al que he llegado a través de MicroSiervos, sobre cómo funcionan los relojes mecánicos.
Continuando con la serie "cómo funcionan las cosas", Mia Koring nos explica cómo funciona la compresión de texto usando el algoritmo de codificación Huffman, uno de los muchos que existen para que nuestros datos ocupen menos espacio.
También esta semana, Martin Fowler ha publicado una reflexión, que comparto totalmente, sobre cómo los LLMs tienen la capacidad de redefinir lo que entendemos como "programación". De la misma forma que el ensamblador nos alejó de los ceros y unos, o los lenguajes de alto nivel nos fueron aislando cada vez más de la máquina permitiéndonos jugar con abstracciones superiores, los LLMs son una capa de abstracción aún mayor, que incluso nos permite alejarnos de los detalles de implementación y centrarnos más en la lógica y el diseño de alto nivel... eso sí, a costa de la indeterminación. Un artículo muy interesante que no te puedes perder.
Por último, me ha alegrado leer en el post de David Ortinau que .NET 10 va a reducir la verbosidad del XAML usado en páginas y componentes MAUI, algo que siempre me ha parecido más farragoso de la cuenta... sobre todo cuando vienes de la web y usas sintaxis superconcisas como Razor.
El resto de contenidos interesantes recopilados la semana pasada, a continuación.
Por si te lo perdiste...
- Un ejemplo de uso elegante del operador "null coalescing assignment" de C#
José M. Aguilar - Extendiendo claims de usuarios en ASP.NET Core
José M. Aguilar
.NET
- Wire Up XUnit Logging for Crazy Integration Testing
Jeremy D. Miller - Legacy Code Survival Guide: Visual Basic and .NET in 2025
DeeDee Walsh - Task.WhenAll or Parallel.ForEach?
Fati Iseni - Day 11: Implementing a C# Mutation Operator for Genetic Algorithms
Chris Woodruff - Managing Secrets in .NET Applications with Azure Key Vault & Managed Identities
Sudhir Mangla - .NET 8.0.17 Upgrades, Forwarded Headers, and Unknown Proxy Issues
Khalid Abuhakmeh & Wesley Cabus - .NET Channels as a In-Memory Message Bus – Beware!
Derek Comartin
Estamos acostumbrados a usar el operador await de C# para esperar la finalización de tareas asíncronas representadas por objetos de tipo Task, Task<T>, ValueTask o ValueTask<T>, pero, ¿sabíais que en realidad podemos usarlo con cualquier tipo de objeto?.
En este artículo vamos a ver que es bastante sencillo, y lo ilustraremos con un ejemplo muy simple: cómo esperar un segundo usando la expresión await 1000 o await TimeSpan.FromSeconds(1) en lugar del clásico await Task.Delay(1000).
Una vez más, vamos con los contenidos interesantes recopilados durante la semana pasada 🙂
En esta ocasión, me vais a permitir a destacar un post propio que, aunque tiene más de un año de vida y es bastante básico, creo sigue siendo muy válido y puede ser de ayuda para algunos desarrolladores que siguen malgastando recursos. En "¡No uses ContainsKey() en un diccionario .NET para ver si existe un elemento antes de obtenerlo!" demostramos de forma empírica lo absurdo de realizar una comprobación de existencia de un elemento en un diccionario .NET antes de obtenerlo, un detalle en los que a veces no caemos.
También destacaremos algunos contenidos relacionados con MCP, que sin duda es la palabra de moda de los últimos tiempos. Primero, Aaron Stannard nos cuenta en qué consiste este estándar y para qué podamos usarlo en la práctica, eliminando el hype que le rodea.
Juan Luis Guerrero continúa explorando la implementación y uso de servidores MCP, esta vez usando como modelo Google Gemini 2.5.
Rhea Patel nos cuenta que el modo agente ya está disponible de forma general en Visual Studio.
Y el equipo de Visual Studio Code ha publicado un catálogo de servidores MCP listos para usar en el modo agente del editor, instalables con un único click.
El resto de enlaces, a continuación.
Por si te lo perdiste...
- ¡No uses ContainsKey() en un diccionario .NET para ver si existe un elemento antes de obtenerlo!
José M. Aguilar - Renderizar una vista Razor a un string en ASP.NET Core MVC
José M. Aguilar
.NET
- .NET 10 Performance Edition
Steven Giesel - Song recommendations from C# combinators
Mark Seemann - Getting started with Open Telemetry in .NET with Jaeger and Seq
Anton Martyniuk - 16 common mistakes C#/.NET developers make (and how to avoid them)
Ali Hamza Ansari - Temporal.IO in .NET
Marek Sirkovský - RunJS: An MCP server that lets LLMs generate and execute JavaScript safely in an embedded .NET runtime sandbox using the Jint library.
Charles Chen - 7 Underrated C# 12 and C# 13 Features Every Developer Should Know!
Saravanan Madheswaran - Kickstarting your libraries with the .NET Library Starter Kit Dennis Doomen
Dennis Doomen - How to use frozen collections in C#
Joydip Kanjilal - Unpacking Zip Folders into Windows Long File Paths
Rick Strahl
Si os gusta trastear con las previews de .NET en el mismo equipo en el que estáis desarrollando proyectos que usan versiones estables, es posible que al compilar encontréis en la consola o ventana Output de vuestro IDE favorito un mensaje de error parecido al siguiente:
NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
Básicamente, el sistema nos está informando de que estamos usando un SDK que aún está en fase de pruebas, o preview. Aunque esto no debería ser un problema porque el SDK debería ser totalmente compatible hacia atrás, simplemente es un recordatorio de que no es la versión estable y siempre podríamos encontrarnos algún problema.
Esto ocurre porque los comandos del SDK utilizan la última versión instalada en el equipo, por lo que, si hemos instalado una versión preliminar, será ésta la que se utilice. Podemos comprobarlo fácilmente ejecutando el siguiente comando en consola, que nos mostrará la versión del SDK que se está utilizando por defecto:
C:\> dotnet --version
10.0.100-preview.5.25277.14
Normalmente, el mensaje NETSDK1057 podemos ignorarlo sin problema, pero si por cualquier motivo queremos eliminarlo o simplemente queremos forzar el uso de una versión determinada del SDK de .NET en algún proyecto o de forma global, podremos hacerlo usando un archivo llamado global.json.
