Tooling para presentar Charlas/Eventos/Demos

Durante estos días está teniendo lugar la #dotNETConf en la que no solo estamos viento novedades de .NET, también es momento para compartir todo tipo de experiencias. En concreto en este post, quiero hacer mención a dos de las herramientas que usan los Presentadores, y que ademas @shanselman contaba ayer en una de sus charlas.

ZoomIt

ZoomIt es la herramienta de Sysinternals, para anotaciones y zoom de pantalla.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-4.png

La siguiente imagen muestra un rectangulo y una flecha señalando la caja de texto de “Power Toys Run” :

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-6.png

Aunque con 5 min de dedicación es facil entenderla al completo, los paso seguidos son estos para este ejemplo en concreto son los siguientes:

  • Ctrl + 1. Realiza el zoom de la pantalla. ¡Si pulsamos Ctrl + 2 en su lugar evitamos hacer el zoom, si no lo necesitamos!
  • Mouse Left Click. Fijamos el zoom en el punto en el que poner el foco.
  • [Opcional]. En este punto, al pulsar la tecla, r, g, b, y, el color del rectangulo o la flecha cambiará por Red, Gree, Blue o Yellow, respectivamente.
  • Ctrl + Mouse Left Click. Pintamos el rectangulo.
  • Shift + Ctrl + Mouse Left Click. Pintamos la flecha.

Nota: Las combinaciones de teclas indicadas son las predetermindas, si bien, estas pueden ser adecuadas a nuestro antojo.

Azure Mask

Azure Mask (Az Mask). Es una extensión de Chrome / Edge (Chromium) que permite enmascarara (o hacer “blur“) de todas los textos de caracter sensible al navegar a lo largo del Portal de Azure.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image.png
Extesión de Chrome
La imagen tiene un atributo ALT vacío; su nombre de archivo es image-3.png
Habilitar / Deshabilitar el enmascarado

A continuación podemos ver un ejemplo de su uso:

La imagen tiene un atributo ALT vacío; su nombre de archivo es azmask-1.gif

Nota: Como excepción, la parte de la url correspondiente a la subscripción no es ofuscada por la herramienta.

Creo que voy a comenzar a sustituir a “Magnifier” y, por supuesto, a dejar enmascarar manualmente cada pantallazo de Azure que incluyo en mis posts 🙂

Saludos/regards and enjoy #dotNETConf days !

Gran momento en el Podcast: NTN con @elbruno y @jc_quijano

Partiendo de no tener un guión inicial, durante 1h, (que me han parecido minutos), he compartido con @elbruno y @jc_quijano una gran momento. Momento tan cercano y familiar, que hasta me ha llegado a suponer un empujón emocional y motivacional. ¡Pilas cargadas para seguir al pie del cañón tecnológico otros tantos años más!

Hemos hablado de temas como: Blazor, Arquitectura de Software, generación de código, usuarios de Windows que usan Mac (:D), Angular por todos lados (y en especial para un “.NET-tero” como yo), consumición de contenidos online, Microsoft Ignite, NetCoreConf y mucho, mucho más.

Un repaso general y cambios de impresiones, que creo que merece la pena escuchar. ¡Nos faltó la cervecita!

Aquí os dejo el link: https://www.ivoox.com/ntn-66-sobre-exceso-eventos-audios-mp3_rf_57486368_1.html

Un placer estar de este otro lado/canal y espero que lo disfrutéis como yo lo he disfrutado.

Un saludo
Juanlu.

Improving the Code Quality in .Net and .Net Core projects using NDepends

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-7.png

Continuando con el análisis de código, la cobertura y los tests como ya viemos en este post (“Runing Tests and Code Coverage without Visual Studio. OpenCover con coverlet y ReportGenerator“), seguiremos profundizando en el “Code Quality”, y conoceremos otra buena herramienta, también extensión de Visual Studio e integración con Azure DevOps, NDepends:

NDepend es la única extensión de Visual Studio que puede decirnos que durante la última hora, el código recién escrito ha introducido una deuda técnica que costaría, por ejemplo, de 30 minutos. Sabiendo esto, podemos arreglar el código, incluso antes de comprometerlo con el control de código fuente.
Con NDepend, las reglas son consultas C# LINQ que se pueden crear y personalizar en cuestión de segundos. Estas consultas contienen fórmulas de C# para calcular estimaciones técnicas de la deuda.
El conjunto de reglas predeterminado ofrece más de cien reglas de código que detectan una amplia gama de Code Smell que incluyen código espagueti, código muerto, breaking changes, y mal uso de POO.

Antes de nada, quiero aprovechar la oportunidad y dar las gracias a Patrick Smacchia, quien me a invitado a probarla y a sacar mis propias conclusiones, que sin duda, me adelanto a decir que han sido satisfactorias.

Así mismo quiero hacer referencia a este post de Variable Not found, donde @jmaguilar, comentaba las bondades de esta herramienta. Profundizaré comentando nuevas características y mejoras que han seguido llegando. Como podemos ver, directamente al abrir la herramienta nos encontramos ya con nuevas integraciones: AppVeryor, Bamboo, VSCoverage, OpenCover, DotCover, NCover además delas ya conocidas: VSTS, TeamCity, Sonarqube, Jenkins y Reflector:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-6.png

Par probarla, instalaremos la extensión para Visual Studio y utilizaremos este ejemplo (https://github.com/juanluelguerre/DotNet.ApiRest.BasicTemplate) .

En Visual Studio 2019, tenemos una nueva opción de menú (Extensions – NDepend) con multitud de opciones:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image.png

Para añadir la solución , proyectos y/o ensamblados y así asociar NDepend para su ejecución, ejecutamos “NDepend Project Properties” y a continuación, el análisis (Run Analysis) tras el cual se muestra un Dashboard. Dashboard que representa un resumen general del estado de nuestra aplicación. A partir del mismo podemos acceder a cada uno de sus detalles que iran siendo mostrados en la ventana de la derecha y nos irán facilitando la posibilidad de navegar por el código e incluso ejecutar acciones sobre propio código.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-2.png

Uno de los puntos interesantes es la facilidad para hacer consultas sobre el código o incluso definir nuevas reglas, usando un lenguaje muy similar a “Linq” . Para ello bastará con editar las mismas o bien crear una nueva.

En lo que respecta, por ejemplo, a la deuda técnica, podemos verla detallada por método e incluso acceder y/o modificar el código “Linq” equivalente.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-3.png

Asi mismo, para nuevas personalizaciones tenemos varias alternativas mediante el menu: “Tools – NDepend – new y sub-menu: Code query… | Code Rule… \ Quality Gate… | Tend Metric…\ Trend Chart… \ Rule File… \ Project …“.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-5.png

Donde, para la creación de una nueva consulta (“Tools – NDepend – new – Code Query“), navegamos a la ventana de edición que incluso incorpora Intellisense, lo que nos facilita mucho más el trabajo.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-6.png

En cuanto a la covertura de código, NDepends proporciona el siguiente detalle de manera totalmente gráfica en proporción al número de lineas de código (LOC), e incluso, en la ventana de la derecha, el % de cobertura, a nivel de namespace, clase, método, etc..

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-7.png

La matriz de dependencias no cambia mucho con respecto a la que ya conocíamos,

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-9.png

sin embargo, el gráfico/diagrama de dependencias si que lo hace, con un diseño mucho más moderno y una navegación mucho más amigable e intuitiva y, nuevamente con posibilidad de edición:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-11.png

Por otro lado, en la esquina inferior derecha de Visual Studio, encontramos también una opción, en la que, además de algunos accesos directos, vemos a modo de resumen datos significativos sobre el estado de nuestro código.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-1.png

Que también cuenta con una opción “Run Analysis and Build Report“, que, además de mostrar el Dashboard, como hemos visto anteriormente, genera un report local (en formato html), totalmente navegable y accesible a todos los detalles. Como podemos imaginar, su consumo, va a permitirnos no depender directamente de Visual Studio.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-4.png

Por ultimo, NDepend cuenta con una herramienta de línea de comando avanzada (NDepend Power Tools), que hace uso del API de NDepends y proporciona una amplia variedad de características, desde la búsqueda de código duplicado, facilidad para la revisión de código y, hasta la detección de cambios de API públicas:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-5.png

Como conclusión, y coincidiendo con @jmaguilar, NDepend:

  • No requiere la edición “Enterprise” de Visual Studio y tenemos la posibilidad de usar su versión stand alone.
  • Es una herramienta, en mi opinión muy potentente, que además resulta casi imprescindible en grandes proyectos y de alto y constante mantenimiento.
  • Esencial al adquirir/heredar proyectos de terceros, donde de un primer vistazo vamos a poder tener una amplia visión sobre el estado del mismo. Va a permitirno poder hacer una valoración y saber a que nos enfrentamos desde un primer momento.
  • Añadir, que se trata de una herramienta de pago con su versión trial que puedes descargar aquí.

Espero que sirva de utilidad y que ayude a seguir creciendo como programadores además de a continuar mejorando y aprendiendo de las buenas practicas.

Happy Coding and good Quality !

Referencias:

[Event] Inteligencia Artificial, Bots, VUIs, Cognitive Services y Azure

[Disponible Material Everis CodeFest 2019] – Sessión: Bots, asistentes de voz y otras interfaces del futuro .

Espero que además de esta sessión, el evento en general haya sido intereante, entretenido, divertido, además de productivo, etc. 😉

Github

Nos vemos en el próximo evento
Un saludo
Juanlu

PD: Mas información sobre el evento: http://codefest.everis.com/

Code Analysis and Code Coverage using NetCore + VS Code & publishing to Sonarqube (sonarcloud.io)

En el post anterior (Runing Tests and Code Coverage without Visual Studio. OpenCover con coverlet y ReportGenerator), hablamos sobre la ejecución de Test Unitarios y de la cobertura de código e incluso de la generación de reports desde línea de comandos. En este Post y continuando con la línea de comandos (CLI) y con el foco/roadmap en DevOps (Jenkins, Azure DevOps, Travis, etc.), veremos como realizar un análisis estático de código y publicarlo en Sonarqube junto a la cobertura de código.

Para este caso usaremos https://SonarCloud.io como servidor gratuito y publico de SonarQube donde crearemos una organización, por ejemplo “juanluelguerre-github” y generaremos un token, que usaremos para la publicación

Partiremos del siguiente Script (Shell y Cmd) similar al del post anterior, al que hemos añadadio algunas sentencias adicionales. En concreto, y las que merecen especial atención para la publicación en Sonarqube, son las que hacen referencia a “dotnet sonarScanner”, es decir, las líneas: 15, 18 y 25.

En el parámetro “/d:sonar.exclusions”, podremos incluir todas aquellas exclusiones

Recuerda que en este post, puedes encontrar mas detalle sobre el resto de líneas de estos scrips

En post sucesivos, continuaremos trasladando todo esto a Jenkins, Azure DevOps, Travis, etc. ¡Espero una vez más que sea de ayuda!

Happy testing and good Coverage
Juanlu

Runing Tests and Code Coverage without Visual Studio. OpenCover con coverlet y ReportGenerator.

imageMuy buenas,

Llevo ya un tiempo con ganas de escribir sobre este tema y, principalmente por el impacto que causa en DevOps, en donde últimamente estoy un poco más inmerso de lo habitual.

En primer lugar, me gustaría hacer mención a este post del compañero @snavarropino, donde nos habla de la Cobertura de Código y Azure DevOps (anteriormente conocido como VSTS).

Y, en segundo lugar quiero hacer mención también a esta reseña de Wikipedia:

La cobertura de código es una medida (porcentual) en las pruebas de software que mide el grado en que el código fuente de un programa ha sido comprobado. Sirve para determinar la calidad del test que se lleve a cabo y para determinar las partes críticas del código que no han sido comprobadas y las partes que ya lo fueron.

Cuando desarrollamos con Visual Studio, y ejecutamos tests, en la mayoría de las ocasiones hacemos uso del tooling integrado en Visual Studio, si bien, tenemos que reconocer que para poder lanzar la cobertura de código entre otras acciones que brinda, necesitamos disponer de la edición Enterprise, lo que supone un coste adicional, que en muchas ocasiones es tal que da lugar a evaluar y analizar el mismo frente al beneficio que aporta.

A continuación veremos como ejecutar los Tests y la Cobertura de código desde Visual Studio, tal y como estamos acostumbrados y también, desde la línea de comandos, con .Net Core.

Desde Visual Studio (Enterprise Edition)

Lanzamos la cobertura de código bien desde la opción de menú “Test – Analyze Code Coverage” o bien, desde el Test Explorer, “Analyze Code Coverage for Selected Tests”:

image

El resultado es el siguiente:

image

Donde, por ejemplo, para la clase ProjectService.cs, podemos ver que parte del código está cubierto (en azul) por los tests y que partes no.

image

Teniendo en cuenta esto, podemos ir afinando nuestros tests para cubrir más y más código. Existen indicadores referentes a este dato que sirven de orientación para medir la calidad de nuestros desarrollos, si bien, no olvidemos que la cobertura determina la calidad del test, (no la del código). Eso si, podremos conocer el porcentaje de código que es cubierto y en consecuencia asegurar que tal %, al menos está “testeado”, lo que supone una garantía de calidad.

Conseguir un 100% de cobertura, evidentemente supone un esfuerzo y un coste, y es aquí donde debemos poner especial atención. Tenemos que valorar el porcentaje a cubrir en base a este coste y tiempo. Un valor de este porcentaje orientativo puede estar entre el 60% y el 70%, pero va a depender de cada caso en particular.  Dejo aquí una referencia de Wikipedia, a: El Triangulo de Hierro (o Iron Triangle), para profundizar en este tema, al que quizás, otro día le dedique un post.

Desde Línea de Comandos (Sin Visual Studio)

Antes de continuar, es importante recordar que los tests han de ser excluidos de la cobertura indicándolo mediante el atributo [ExcludeFromCodeCoverage] a nivel de clase en los tests.  De igual forma, podemos también excluirlos haciendo uso del fichero “.runsettings”. Visitar este enlace, para más detalle.

Adicionalmente, añadir el paquete Nuget: “coverlet.msbuild”.

image

A continuación, en el siguiente fragmento de código, (“coverage.cmd”) contamos con todas las instrucciones para ejecutar los tests y visualizar la cobertura de código de forma similar a como lo hace Visual Studio.

Las líneas [19-24, se corresponden con el comando “dotnet test” que ejecuta los tests unitarios. Habilitan la cobertura de código, especifican el formato en el que generar la cobertura (“Open Cover”) y la ruta en la que se generará el fichero “.xml” con el resultado de la cobertura.

Si ejecutamos este comando, obtendremos la siguiente salida en relación a la cobertura de código:

image

Donde, podemos ver la cobertura para cada módulo y diferenciada por:

  • Línea. Número de líneas de código que son cubiertas.
  • Branch. Número de caminos diferentes que toma el código (para instrucciones, if, switch, etc.), que son cubiertos.
  • Método. Número de métodos que son invocados desde los tests.

Adicionalmente, podríamos utilizar el parámetro /p:Exclude=\”[].Models.*\”, para excluir del análisis, cualquier clase cuyo namespace coincida con el filtro indicado. Mas detalle aquí: coverlet.msbuild.

La línea 27. Instala la herramienta Report Generator, que va a permitirnos generar un informe similar al utilizado por Visual Studio.

La línea 28.  Ejecuta la herramienta, tomando como entrada uno o más ficheros (en formato .xml) generado tras la ejecución de los tests, indicado por el parámetro “p:/CoverletOutput” y como salida, –targetdir, la ruta en la que se generan los ficheros de informes en el formato especificado por el parámetro –reporttypes (Html y HtmlSummary).

Finalmente, la línea 30, lanza el navegador y muestra el fichero “index.htm” tal y como podemos ver en la siguiente imagen, con el resumen y el detalle de la cobertura.

image

¡Ahora ya no hay argumentos para no “cubrir” bien el código!

En siguientes posts, veremos como aplica todo esto a la Integración Continua dentro del mundo de DevOps, tanto en Jenkins, como en Travis, como en Azure DevOps.

Happy testing and good Coverage
Juanlu

Logging/Traces in NetCore projects with Serilog

imageBuenas,

Como en cualquier desarrollo, un buen sistema de Logging o Trazas para diagnósticos y detección de problemas, es una buena práctica que va a salvarnos de un aprieto más de una vez. En La mayoría de los casos, creamos un ApplicationBlock, un Helper, o similar para trabajar con un sistema de estas características, cuyo objetivo es escribir trazas en un repositorio: Consola, fichero y/o base de datos entre otros, con la intención de poder consultarlo a posteriori, ante cualquier problema, que como sabemos, siempre recurrimos a el en entornos Productivos.

Con NetCore, podemos hacer lo mismo como no podía ser de otra manera, si bien, una peculiaridad y gran ventaja, es la posibilidad de usar el Interfaz ILogger (Microsoft.Extensions.Logging), tanto en nuestro controladores como en nuestros servicios o cualquier clase, mediante Injección de dependencias, lo que nos permitirá codificar sin pensar el framework o factoría encargada de escribir trazas en un repositorio: consola, fichero, base de datos, etc.

Existen muchos frameworks, que nos permiten llevar a cabo esta tarea de manera muy facil: Serilog, NLog y Log4Net, entre otros. ¡Atrás quedo Enterprise Libray  ! Cada uno tiene sus particularidades, si bien, Serilog, es considerado como uno de los mejores, además, cuenta con un elevado número de extensiones para el guardo de trazas en diferentes repositorios: consola, fichero, RollingFile, base de datos, Azure ApplicationInsight, Azure App Service, etc., lo que lo hacen aun más potente.

Por tanto, veamos como trabajar con Serilog:

Por ejemplo, podríamos tener el siguiente código en nuestro Controller:

Donde “_logger”, dejará dos trazas en nuestro/s repositorio/s.  Podríamos codificar de esta misma forma todas aquellas de nuestras clases: Servicios, Repositories, etc., sin preocupación adicional, por el momento.

A continuación, en el fichero Program.cs, incluiremos la siguiente configuración:

Como buena práctica, dejaremos en manos del fichero “appSettings.json”, la configuración de el/los repositorio/s.

Otra ventaja de Serilog, como puede verse en el código anterior, es la capacidad de ejecución en modo “asíncrono”. Es decir, la escritura de trazas en un hilo adicional para no afectar a la ejecución normal del programa.

ver-github

Y ahora, veamos todo esto en ejecución:

Referencias:

Un saludo & Happy Logging
Juanlu

 

[Material] Evento Blazor (C# en el Browser)

image

Buenas,

Ayer 28 de Junio he vuelto a poder compartir conocimiento y muy buenos momentos con los compañeros de SVQDotNet, hablando de #Blazor en el evento: BLAZOR: Browser + Razor (C# en el Navegador) ¿Adios a JavaScript?

Dejo aquí el material empleado en la misma:

ver-github

En esta otra entrada puedes continuar profundizando.

Un saludo
Juanlu

Blazor 0.3.0/0.4.0-preview1-10286 ready!

image

El pasado 2 de mayo Blazor aparecía con su versión 0.3.0, y hoy, ya tenemos la versión 0.4.0-preview1-10286 lista para ser probada. Como ya sabemos, (según post anterior) al tratarse de un proyecto experimental requiere cambios constantes en nuestros proyectos (aun no recomendados para entornos de Producción).

Estos cambios, por tanto, nos obligan a realizar modificaciones en nuestra aplicación Taskin, que ya vimos en el post anterior (“¿Javascript ha muerto? .NET Web Assembly con Blazor”).

Según la release 0.3.0 e incluso para la 0.4.0-preview1, estas son las novedades:

    1. Project templates updated to use Bootstrap 4
    2. Async event handlers
    3. New component lifecycle events: OnAfterRender / OnAfterRenderAsync
    4. Component and element refs
    5. Better encapsulation of component parameters
    6. Simplified layouts

Y para hacer el Upgrade de 0.2.0 a 0.3.0:

  1. Instalar .NET Core 2.1 SDK (2.1.300-preview2-008533 o superior).
  2. instalar Visual Studio 2017 (15.7 Preview 5 or superior) con ASP.NET and web development workload selected.
  3. Instalar la última versión de la extensión “Blazor Language Services” del Marketplace de Visual Studio
  4. Actualizar el paquete Blazor y la Tool CLI a 0.3.0.
  5. Eliminar cualquier referencia al paquete: “Microsoft.AspNetCore.Razor.Design” asi como cualquier dependendencia.
  6. Actaulizar los proyectos a C# 7.3.
  7. Actualizar los parámetros usado en os componentes para que incluyan el atributo [Parameter].
  8. Actualizar los layouts para que hereden de “BlazorLayoutComponent” y eliminar la implementación de ILayoutComponent incluso la propiedad Body.

Tras la actualización, a continuación podemos una muestra de ello:

image

Y aquí, el código en Github: https://github.com/juanluelguerre/Taskin

Un saludo and happy Blazor coding
Juanlu

[Material] “.Net LOVE Open Source”

imageDurante el día de hoy ha tenido lugar l “I Jornada de conocimiento abierto“, en Huelva.

Ha sido un día interesante en lo que respecta al Software y Hardware libre así como en lo referente al Open Source, donde he tenido la oportunidad de participar, y, como no podía ser de otra manera con esta presentación “.Net LOVE Open Source“, en la que he tratado los siguientes puntos:

  • Free Software VS Open Source
  • Microsoft y el Open Source
  • .NET Open source
  • .NET Core
  • Azure, Dockery más…

A continuación dejo la presentación.

 

Un saludo & happy Open weekend

Juanlu