martes, 21 de enero de 2020
Recuerdo que la primera vez que, en una de mis visitas a Redmond, vi a Steve Sanderson haciendo una demo de Blazor "en vivo" me pareció casi magia: una aplicación web SPA cuya lógica de presentación y UI se implementaba exclusivamente en C#, eliminando por completo de la ecuación a Javascript. ¡Uau!En aquellos tiempos era aún poco más que un prototipo y no se podía saber si aquella línea de investigación llevaría a alguna parte, pero era tan prometedor que, algún tiempo después, a primeros de 2018, Blazor pasó a ser un proyecto experimental del equipo ASP.NET de Microsoft.
A partir de ese momento se fueron despejando las incógnitas que quedaban en cuanto a la viabilidad real de convertir aquello en un producto y se continuaron implementando funcionalidades, hasta que, en abril de 2019, Daniel Roth anunció que daban por concluida la fase experimental y Blazor entraba oficialmente a formar parte del stack de tecnologías para la web.
A día de hoy, Blazor es un framework completo para el desarrollo de aplicaciones web SPA, como lo pueden ser Angular, React o Vue. Dispone de sistema de bindings, routing, componentes, ciclo de vida, validaciones, plantillas, gestión de errores, inyección de dependencias, etc. Todo lo que podemos necesitar para crear aplicaciones web profesionales de calidad.
La primera versión de Blazor se lanzó acompañando a .NET Core 3.0 en Septiembre de 2019, aunque sólo en uno de sus modelos de hospedado: el denominado server-side o Blazor Server.
Pero no era ese el único plan...
lunes, 20 de enero de 2020
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)Por si te lo perdiste...
- Antipatrones de asincronía en C#
José María Aguilar - El archivo _ViewImports en ASP.NET Core MVC
José María Aguilar
.NET Core / .NET
-
Digest Authentication en .NET Core 3.x
Jorge Serrano
-
Type.GetType Functionality Has Not Changed in .NET Core
Jeremy Clark
-
The Reunification of .NET 5
Matthew MacDonald
-
Implementing State in .NET Core gRPC Messages with oneof
Peter Vogel
-
C# 8.0: Understanding Using Declarations
Steve Gordon
-
C# 9 Proposals: Module Initializers
Jonathan Allen
-
Collecting and analyzing memory dumps
Sourabh Shirhatti
-
C# Futures: Simplified Parameter Null Validation
Jonathan Allen
-
SelfServe: A Self-hosting Self-installing Windows Service
Honey the codewitch
-
UTF-8 BOM adventures in C#
Daniel Wertheim
-
Not planning now to migrate your .NET 4.8 legacy, is certainly a mistake
Patrick Smacchia
martes, 14 de enero de 2020
Las Razor Class Libraries (RCL) constituyen una interesante fórmula para crear componentes redistribuibles de interfaz de usuario para aplicaciones basadas en ASP.NET Core MVC o Razor Pages. En las bibliotecas de clases de este tipo podemos incluir controladores, view components, tag helpers o vistas y páginas Razor, elementos que estarán disponibles en las aplicaciones que las referencien, bien directamente o bien a través del paquete NuGet en el que las distribuyamos.Sin embargo, es menos conocido el hecho de que estas bibliotecas pueden incluir también recursos estáticos como imágenes, hojas de estilo o scripts, lo que resulta bastante interesante a la hora de crear componentes totalmente autosuficientes y muy reutilizables.
En este post vamos a ver cómo crear una RCL redistribuible que definirá el tag helper
<mario>, cuya inclusión en una página hará que ésta muestre el conocido personaje correteando por la pantalla, como se muestra en la siguiente captura:
lunes, 13 de enero de 2020
Ahí van un buen puñado de enlaces recopilados durante las semanas anteriores. Como siempre, espero que os resulten interesantes. :-)Por si te lo perdiste...
- ¿Cómo se llama el operador "-->" de C#?
José María Aguilar - ¿Se pueden asociar varias interfaces a la misma instancia en el contenedor de servicios de ASP.NET Core?
José María Aguilar
.NET Core / .NET
- Trabajando con documentos JSON en .NET Core 3.x, Parte I y Parte II
Jorge Serrano - Utilizando la librería BenchmarkDotNet
Jorge Serrano - Controversial extension methods: CastTo<T> and As<T>
Raymond Chen - C# 8 is old news. Onward, to C# 9!
Calvin A. Allen - Abusing Extension Methods and Null Continuation
Marc Clifton - Tracing .NET Core applications
Tom Deseyn - Commenting out Code in C# (Oldie but Goldie Tip) & Quick #if … #endif in Visual Studio
Roland Weigelt - Check for Breaking Changes with ApiCompat
Stuart Lang - Happy New ... C# 9 Features!
Rion Williams - MediatR 8.0 Released
Jimmy Bogard - What dotnet new Could Be
Muhammad Rehan Saeed - Chaos Engineering your .NET applications using Simmy
Joseph Woodward - Building a self-contained game in C# under 8 kilobytes
Michal Strehovský - Multiplatform Desktop HTML Editor with .NET Core 3 and Electron.NET
Erik Engineer - C# Channels - Async Data Pipelines
Denis Kyashif - .NET Core, .NET 5; the exodus of .NET Framework?
Marc Gravell - Building a Windows service with Worker Services and .NET Core 3.1, part 1: Introduction
Anthony Giretti - The case of the unbalanced brackets
Mark Seemann - C# boxing with string concatenation and interpolation
Fons Sonnemans - Using Type.GetType with .NET Core / Dynamically Loading .NET Standard Assemblies in .NET Core
Jeremy Clark - How to Design Messages for gRPC Services in .NET Core
Peter Vogel - Static Initializers in C#: A Cautionary Tale
Edin Kapić - .NET Core: Writing Really Obvious Code with Enumerated Values in gRPC Web Services & Reusing and Recycling Data Structures in gRPC Services in .NET Core
Peter Vogel
martes, 7 de enero de 2020
Estrenamos este nuevo año y década (aunque esto último es bastante más discutible) siguiendo una de las grandes tradiciones de este blog: dedicar el primer post a repasar cuál fue el contenido publicado durante los doce meses anteriores que más os llamó la atención.
Pero antes, abusando de este pequeño slice de atención que me estáis prestando en este momento, quería aprovechar para desearos un 2020 repleto de salud y alegría, tanto en el plano personal como en el profesional.
Y ahora, al turrón...
sábado, 28 de diciembre de 2019
Un reciente estudio de la consultora Garner indica que durante el desarrollo de una aplicación dedicamos más del 80% de nuestro tiempo a implementar controles de posibles fallos.
Además, este otro informe de StackOverflow obtenido tras analizar el código fuente de miles de proyectos open source, el control y tratamiento de excepciones y problemas supone más del 60% de nuestra base de código y, por tanto, aporta gran parte de la complejidad interna de las aplicaciones.
Pero, adicionalmente, estos estudios ponen al descubierto otros tres aspectos bastante interesantes:
¿No estaría bien poder ignorar esos problemas y centrar nuestro código en aportar valor a nuestros clientes?
Además, este otro informe de StackOverflow obtenido tras analizar el código fuente de miles de proyectos open source, el control y tratamiento de excepciones y problemas supone más del 60% de nuestra base de código y, por tanto, aporta gran parte de la complejidad interna de las aplicaciones.
Pero, adicionalmente, estos estudios ponen al descubierto otros tres aspectos bastante interesantes:
- Primero, que la mayoría de errores que intentamos controlar no se van a producir nunca. Son posibles a nivel de flujo de código, pero en la operativa de la aplicación no ocurrirán, por lo que podríamos decir que son problemas creados artificialmente durante el proceso de desarrollo.
-
Segundo, las líneas de control de errores no están exentas de problemas, por lo que muy a menudo encontraremos en ellas nuevo código de control (¿quién no ha visto
try/catchanidados a varios niveles?), por lo que la bola de nieve no para nunca de crecer: código de tratamiento de errores que a su vez contiene código de tratamiento de errores, y así hasta el infinito.
-
Y por último, también nos encontramos con que en muchas ocasiones el código de control no hace nada. Por ejemplo, se cuentan por millones las líneas de código detectadas en Github cuyo tratamiento de excepciones consiste simplemente en la aplicación a rajatabla del Swallow Design Pattern, por ejemplo, implementando bloques
catch()vacíos.
¿No estaría bien poder ignorar esos problemas y centrar nuestro código en aportar valor a nuestros clientes?
