Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• Cancelación de peticiones en ASP.NET Core y MVC
  José María Aguilar
• Componentes con cuerpo en Blazor
  José María Aguilar

.NET Core / .NET

• Todo sobre los archivos .PDB: qué son y por qué se generan siempre al compilar una aplicación .NET
  José Manuel Alarcón
• .NET Worker Service: Working Hard So You Don’t Have To
  Richard Reedy
• Capitalize First Letter Of Words With C#
  Khalid Abuhakmeh
• Blank Zero Values in .NET Number Format Strings
  Rick Strahl
• .NET 5 Networking Improvements
  Máňa Píchová
• Migrating RealProxy Usage to DispatchProxy
  Mike Rousos
• Diagnostics improvements in .NET 5
  Sourabh Shirhatti
• Go (golang) Multiple Return Values
  Jeremy Clark
• Azure Active Directory's gateway is on .NET Core 3.1!
  Avanindra Paruchuri
• Happy 10th Birthday, NuGet!
  Christopher Gill
• Here's a One-Stop Shop for .NET 5 Improvements
  David Ramel
• How to configure your custom roslyn analyzer using an .editorconfig file
  Carlos Pons
• Taking the new Chromium WebView2 Control for a Spin in .NET
  Rick Strahl
• My preferred .NET console stack
  Mattias Karlsson
• Quick tip: listing global dev tools and extensions
  Mark Heath

Pues parece que por fin hemos conseguido quitarnos de encima el nefasto 2020, y afrontamos un nuevo año con la esperanza de que sea, al menos, algo mejor que el anterior. Os deseo a todos que así sea; sobre todo que la salud os acompañe a vosotros y los que os rodean, y que esto permita que seáis felices tanto en lo personal como en lo profesional.

Y dicho esto, llega la hora de acudir a las tradiciones: el repaso de los posts más visitados durante el año que acabamos de dejar atrás, donde, como podemos ver, Blazor ha entrado con bastante fuerza :)

Top ten 2020 en Variable not found

Comenzando por el décimo puesto, encontramos el post cómo mostrar el número de usuarios conectados a una aplicación Blazor Server, en tiempo real, un interesante ejercicio que nos ayudaba a comprender cómo funcionan los circuitos de Blazor Server y cómo sacar partido a los componentes internos que nos permiten introducirnos en su ciclo de vida.

La novena posición la ocupa nuestro amigo Mario, protagonista del post incluir recursos estáticos en una Biblioteca de Clases Razor (RCL), donde lo usábamos para crear un componente Razor reutilizable que mostraba al simpático personaje correteando por la pantalla.

Continuamos con Blazor gracias a la serie sobre los mecanismos de interoperación con Javascript de este framework. En concreto, el post Cómo invocar métodos de instancia C# desde Javascript con Blazor es el que más vistas ha tenido, probablemente por su atractiva propuesta ;)

La posibilidad de publicar aplicaciones .NET Core en modo auto-contenido y en un único archivo no ha pasado desapercibida para los lectores del blog. Por ello, el post publicación self-contained y single-file en .NET Core, aparece ocupando la séptima posición del ranking anual.

Muy cerca del anterior en número de visitas, encontramos la respuesta a una pregunta relativamente frecuente a la hora de desarrollar aplicaciones .NET: ¿Usar try/catch es malo para el rendimiento?. Una respuesta con demostración incluida, gracias al imprescindible BenchmarkDotnet.

La basura que va dejando en vuestro equipo las distintas versiones y revisiones de .NET Core conforme evoluciona el producto también parece haberos preocupado o, al menos, os ha llamado la atención. La aparición de una herramienta para limpiarlas fácilmente fue el detonante para escribir el post desinstala fácilmente versiones antiguas de .NET Core con "dotnet-core-uninstall".

AddMvc(), AddControllers(), AddControllersWithViews(), AddRazorPages()... ¿qué es todo eso?, ya en quinta posición de la lista, intentaba aclarar qué eran esos nuevos métodos que aparecían en el intellisense a la hora de registrar los servicios de MVC o Razor Pages a partir de la llegada de ASP.NET 3.0.

En tercera y cuarta posición respectivamente encontramos dos post muy relacionados. En el primero de ellos, describiendo APIs ASP.NET Core con Swagger, veíamos los conceptos básicos de OpenAPI y el uso de Swashbuckle para describir nuestras APIs creadas con ASP.NET Core. En el segundo, cómo documentar y generar código cliente de nuestras APIs utilizando Swagger/OpenAPI, revisábamos cómo sacar partido de dicha descripción, generando automáticamente la documentación de la API e incluso código cliente para acceder a ella.

A cierta distancia de los anteriores, ya en segundo puesto, tenemos la solución a un error que frecuentemente encontramos al desarrollar aplicaciones ASP.NET Core con Visual Studio e IIS Express. El post cómo solucionar el error "Unable to connect to web server 'IIS Express'" en Visual Studio describe paso a paso qué hacer cuando nos topamos con este incómodo inconveniente al ejecutar las aplicaciones.

Y por último, el indiscutible vencedor del año: ¿qué es Blazor, eso de lo que todo el mundo habla?. Este post intentaba despejar dudas en un momento en el que la palabra "Blazor" empezaba a sonar más de la cuenta y a despertar el interés de muchos desarrolladores, entre los que, por supuesto, me incluyo.

Para acabar, me gustaría también hacer una mención especial a ¡Toma las riendas! ¡Conviértete en Desarrollador 10x Certificado!, el post publicado el 28 de diciembre que, si bien no ha conseguido entrar en el ranking, se ha quedado bien cerca a pesar de haber tenido pocos días para acumular visitas. Me he divertido mucho escribiéndolo, leyendo las respuestas y comentarios que me han llegado por diversas vías, y comprobando que algunos incluso habéis traducido los textos en japonés para ver qué ponía :D

¡Vamos a por 2021!

Publicado en Variable not found.

Si nos dedicásemos a enroscar tapones de botellas probablemente podríamos medir nuestra productividad en términos del número de botellas cerradas por hora. Si cargásemos sacos en un muelle, quizás en kilos transportados por jornada... Hay muchos trabajos en los que es relativamente sencillo establecer una medida para conocer el grado de productividad con el que desempeñamos nuestras obligaciones.

Lamentablemente, esto no es así en la industria del software, que durante años ha ido dando tumbos, probando y descartando sucesivamente diversas métricas para intentar medir la productividad de los desarrolladores, como el cómputo de líneas de código por día, puntos función, puntos de historia o el grado de completitud de sprints, pero siempre sin éxito. En el desarrollo de software todo es demasiado etéreo: dado que no creamos ni manipulamos productos tangibles, no hay nada que poder pesar o contar, salvo las horas pegados a nuestra silla.

Sin embargo, todos tenemos una idea intuitiva de lo que es un desarrollador productivo, e incluso se ha hablado bastante de los desarrolladores 10x: programadores que son al menos diez veces más productivos que los que se encuentran en el lado opuesto del espectro. Esta idea parte de estudios científicos contrastados, y algunos destacados gurús incluso suben la apuesta llegando a estimar que determinados desarrolladores pueden producir entre diez y veintiocho veces más que sus compañeros. Casi nada.

Sin duda, un desarrollador 10x es todo un lujazo para las empresas, que lucharán para atraerlos, normalmente a base de ofrecer unas condiciones espectaculares, porque es mucho más rentable ofrecer a un desarrollador 10x el triple de sueldo que tener a diez desarrolladores para conseguir el mismo resultado.

Nuestro objetivo profesional, por tanto, debería ser dar el salto y convertirnos en uno de ellos.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• ¿Dónde está Server.MapPath() en ASP.NET Core?
  José María Aguilar
• Cómo mostrar el número de usuarios conectados a una aplicación Blazor Server, en tiempo real
  José María Aguilar

.NET Core / .NET

• Mejorar la legibilidad de números en tu código C# con separadores de dígitos
  José Manuel Alarcón
• What's next for System.Text.Json?
  Layomi Akinrinade
• Building a Code Analyzer for .NET
  Tim Heuer
• Batch.Parallel
  Marc Clifton
• C# in Simple Terms - Indexers
  Matthew Jones
• Implementing a Text Templating Language and Engine for .NET
  Alexandre Mutel
• Thinking With Properties: Examining Where
  Cameron Presley
• Implementing the page object pattern in UI tests
  James Croft
• Never forget a #if when multi-targeting .NET libraries or applications
  Gérald Barré
• Creating a game art asset pipeline in .NET
  Sam Eddy
• From .NET Standard to .NET 5
  Immo Landwerth
• How to add User-Agent header to HttpClient in .NET
  Kristoffer Strube
• .NET 5.0 on Google Cloud
  Mete Atamel
• Playing with C#9 Top-level Programs, Records and Elasticsearch.NET - Steve Gordon
  Steve Gordon
• The proper usages of Exceptions in C#
  Patrick Smacchia
• Overloading Vs. Overriding in C#
  Sam Walpole
• .NET 5 Source Generators - MediatR - CQRS
  Tore Nestenius
• C# vs. F#
  Urs Enzler
• C# 9 Covariant Return Types
  Khalid Abuhakmeh

En Blazor, es habitual implementar la interfaz de nuestros componentes de forma declarativa, mezclando etiquetas que:

• Pueden ser HTML, y cuyo resultado irá textualmente al navegador
• Pueden ser instancias de otros componentes, por lo que al navegador irá el resultado de la renderización de éstos.

Por ejemplo, el siguiente código envía al navegador la etiqueta <h1> y luego el resultado de renderizar el componente Blazor <MyComponent>, en cuyo interior podrán existir a su vez otras etiquetas o componentes:

@page "/home"
<h1>Welcome!<h1>
<MyComponent />

Fijaos que, aunque es la fórmula que emplearemos en la mayoría de ocasiones, es una estructura totalmente rígida: podemos tener la total certeza de que el componente que será instanciado en la página anterior es MyComponent, pero, ¿qué ocurre si queremos poder decidir en tiempo de ejecución qué componente instanciaremos en la página?