Entendiendo tu aplicación con Visual Studio Code Maps

Cuando requieres de entender las dependencias que tienen los proyectos de tu solución, ya sea entre ellos o con archivos externos, hacerlo por cada uno puede ser bastante engorroso.  Afortunadamente Visual Studio cuenta con una herramienta bastante interesante: Code Maps.

La primera opción que tenemos es ver el panorama general de la solución. Para ello hay que ir al Menú Architecture > Generate Code Map for Solution

Dependiendo del tamaño de la solución tardará más o menos, pero al finalizar deberás ver algo  como esto

Y listo, tenemos una representación visual de los proyectos y sus dependencias. Una de las cosas que más me gustaron es que el mapa incluye hasta los Solution Folders, que muchos usamos para organizar los proyectos, comúnmente en “capas”. Pero en este caso, no nos es de mucha utilidad tenerlo. Lo que vamos a hacer ahora es …. quitarlo. Para ello vamos a la parte derecha en la seccion Filters, y desactivamos la casilla de Solution Folder en la seccion de Code Elements. El resultado debe ser algo parecido a esto

 

Este ejemplo es de un proyecto demo de la implementación de IdentityServer4. Como se puede apreciar, los proyectos no tienen dependencia entre sí, solamente externas. Dependiendo de tu situación actual podrías tener algo como spaghetti (honestamente espero que no sea tu caso)

 

Otro de los atractivos (a mi parecer) de la heramienta es que te muestra el tipo de relación que hay entre los elementos. Para este otro proyecto podemos ver múltiples ejemplos

El código de colores y tipos de línea se encuentra al lado derecho, en el panel “Legend”. Si no esta visible puede mostrarse presionando el botón del mismo nombre en la parte superior del diagrama.

Relaciones

El diagrama actual muestra dos escenarios de relaciones, uno es entre mis “capas” (los Solution Folders) y el otro entre los elementos dentro de ellos. Curiosamente en este ejemplo, si observamos en la esquina inferior izquerda de Auth, encontramos un elemento tan antisocial como el autor, que parece no relacionarse con nadie. ¿Es realmente el caso? Si le damos clic a uno de los elementos del diagrama (en este caso, Hermes.Auth.B2C.dll), podemos notar que nos da la información de sus relaciones con el resto del mundo binario.

Dependencias externas

Adicional a las relaciones, tenemos la opción de ver las dependencias externas.  Siguiendo el ejemplo anterior, al dar click en el elemento Externals, se muestran las lineas de las relaciones específicas que cada proyecto tiene. Pero ¿y si quiero saber cuáles son? En este caso, al acercar el cursor a Externals, aparece una pequeña flecha del lado superior izquierdo. Si la presionas, podrás ver la lista completa de referencias de la solución

Ahora bien, el punto de más utilidad es el siguiente: aquí podemos darnos cuenta, entre otras cosas si en la solución estamos utilizando dos versiones diferentes de un mismo ensamblado, como en este caso:

 

Esto es obviamente posible gracias a la magia negra del GAC, pero no necesariamente quiere decir que sea lo que yo quiero ni la mejor opción. Al poner el cursor sobre el nombre del ensamblado, puedo darme cuenta que estoy usando Microsoft.Owin version 3.1.0 y versión 3.0.1. Puede parecer algo sin importancia, pero cuando salen los errores es uno de los detalles que nos pueden causar más dolores de cabeza.

Y como ya vimos anteriormente, dar clic al elemento nos muestra que proyecto está usando cada dll.

 

Moraleja

Esta herramienta está disponible desde Visual Studio 2015 (los ejemplos aquí son con 2017), en las versiones Pro y Enterprise. Y como moraleja de esta historia tenemos “No confíes en las versiones que los paquetes de nuget descargan”.

 

 

Meetup GDL Connect 18/Oct

El día de ayer tuve la oportunidad de hablar acerca de tácticas de arquitectura de software en el meetup de la comunidad GDL Connect.

 

Pueden ver el video aquí (gracias a César por la grabación)


y la presentación en mi perfil de Speaker Deck.

 

 

Gracias a EPAM por su apoyo.

Meetup GDL Connect 16/Ago

El día de ayer tuve la oportunidad de compartir acerca de desarrollo de software seguro en el meetup de este mes de la comunidad GDL Connect.

Pueden ver la grabación aquí

y la presentación aqui

Muchas gracias a Unosquare por el patrocinio.

Hacer copy-paste es maligno

Hace poco, hablando con algunos de los desarrolladores de un equipo al que me tocó apoyar por un tiempo, le decía qué hacer copy-paste al momento de estar desarrollando era “del diablo”.

Estuvimos discutiendo un rato al respecto, y me preguntaban si yo nunca lo hacía: mi respuesta fue que la mayoría de las veces no, y las razones son las siguientes:

Estimaciones: La precisión construye credibilidad

Cuando hablamos del desarrollo de software, una de las cosas que al parecer resultan más complicadas es estimar el esfuerzo y tiempo que una tarea va a tardar en completarse, no se diga un proyecto completo. La ambigüedad de los requerimientos iniciales, la experiencia de los involucrados, las herramientas potenciales y la curva de aprendizaje son siempre factores que hacen que los números varíen de persona a persona.

Adicionalmente al momento de discutirlo con otras personas, muchas veces alguna de las partes involucradas caemos en la maldición del conocimiento (no recordar lo que implica desconocer un tema en el que tenemos ya algo de experiencia) lo cual conlleva el desestimar o no comprender las razones para la diferencia de estimación contra las expectativas.

Crear una llave pública de OpenSSH para una VM Ubuntu en Azure usando PuttyGen

En días pasados publiqué como crear una llave pública de OpenSSH para una VM Ubuntu en Azure usando macOS. Esta vez vamos a hacerlo para Windows usando PuttyGen. El proceso de crear la VM en el portal de Azure es exactamente igual, debes ver una pantalla como esta

¿Cuántos nueves? Entendiendo el concepto de disponibilidad

Es muy probable que hayas experimentado un sistema caído, ya sea una aplicación en la que has trabajado o algún servicio que consumes. Le ha pasado a Amazon, Netflix, Microsoft, Salesforce, etc. ¿Cuánto tuviste que esperar? o ¿cuánto tus usuarios?

Si al estar construyendo una aplicación le preguntas a tu jefe (o cliente) qué porcentaje de tiempo la aplicación debe estar disponible, lo más seguro es que recibas respuestas como “siempre” o “100% (o más)”.

Aunque no queremos que pasen cosas malas, pasarán: bugs, ataques, fallas de corriente, desastres naturales, etc., son escenarios que pueden afectar un sistema. Esperar que no pases es ingenuo; es mejor pensar en y planear para los fallos, ya que son inevitables.

Disponibilidad (availability) es la capacidad de una aplicación de estar disponible después y a pesar de que un problema ocurre. Repito, no estamos diciendo que no habrá problemas, sino que tan efectivamente podrá recuperarse. Esto significa que tenemos que a) identificar los puntos de falla potenciales y b) crear una estrategia para prevenir que el error se convierta en una falla afectando al usuario (un árbol que cae en el bosque cuando no hay nadie, no hace ruido).

Meetup GDL Connect 22/Mar

Ayer estuve platicando acerca de Azure Functions en el meetup de la comunidad .NET en Guadalajara

La presentación la pueden ver en mi perfil de Speaker Deck.


Pueden encontrar el código del demo en mi perfil de Github, y en este post la descripción completa de como se realiza.

Muchas gracias a EPAM por el apoyo.

Define primero el tamaño del monstruo

Muchas veces he escuchado a clientes o compañeros desarrolladores decir “Vamos a usar x framework” o “necesitamos x tecnología para el proyecto. El problema es que la mayoría de las veces no existe un análisis previo de la decisión propuesta. Es sólo porque algo está de moda (o es cool) y ya. Como uno de mis anteriores managers decía frecuentemente “Hype and buzzwords are dangerous friends”.

La pregunta principal que debemos hacer es “¿Cuál es el problema que estoy tratando de resolver?”. Es sorprendente la frecuencia en que proponemos soluciones para problemas que apenas conocemos. Estamos ansiosos de brincar a la pelea sin conocer de antemano el tamaño del oponente. ¿Que tal que es un mounstro en lugar de la cosita que habíamos pensado? ¿O lo contrario?