Visual Studio 2017: Nuevo formato de instalación

Muchos de nosotros hemos solicitado que la instalación e incluso el IDE de Microsoft fuera reducido y además, modular. Esto, en esta versión, ha sucedido y ahora tenemos una instalación que ocupará más o menos a nuestra elección al igual que el propio entorno. Para que os hagáis una idea, la instalación mínima de VS, ocupa 10 veces menos que las anteriores versiones.

Actualmente tenemos una experiencia de instalación mejorada pudiendo seleccionar en todo momento lo que queremos instalar y lo que no, evidentemente, modificable a posterior. Además, nuestra instalación será mucho más rápida que las anteriores versiones.

Al ejecutar el instalador de la nueva versión de VS nos aparecerá una ventana, clasificada por Workloads, dónde pondremos seleccionar que queremos instalar:

Visual Studio

Además de los Workloads, podemos seleccionar componentes individuales de cada uno de los entornos de trabajo e instalar componentes individuales que necesitemos o, por lo contrarios, que no nos sirvan en nuestro entorno de desarrollo.

VS Installation

Tan fácil cómo seleccionar que queremos instalar, su ruta y el alias (nickname) de la instalación. A parte de estas novedades, el alias en sí es otra de las novedades que nos trae Microsoft. ¡Ahora podemos instalar diferentes entornos de desarrollo con sus componentes usando el alias! Es decir, podemos tener una instalación para “web”, “mobile”, “cloud”, etc… y tener los diferentes sandboxs de desarrollo de forma independiente. Por último, y no menos importante, podemos instalar idiomas adicionales al IDE

Si quieres empezar a trabajar con él, aquí lo puedes descargar aunque recuerda que está cómo RC.

Happy new version!! :)

La evolución de las PCL con .NET Standard para Xamarin

En un anterior post hablé sobre la unificación de las librerías .NET a través de .NET Standard para desarrollos cross-platform.

Muchas de ellas, recientemente, han añadido soporte a la librería de .NET estándar. La virtud de esta librería es que agrupa un conjunto de API’s básicas y versiones construidas de forma agnóstica a la plataforma que las va a usar. Por este motivo, las librerías construidas con este subconjunto de dotnet se consideran una evolución a las librerías portables (PCL). Estas no tienen un Profile asignado si no que tienen un alias único que permite una comptaibilidad transversal de forma que las nuevas versiones de esta son compatibles con otras más antiguas.

Para entenderlo mejor, podemos ver un diagrama especifico que muestra el interior de la librería,netstandard

Y otro, de cómo esta organizado por dentro y como la capa de contratos hace posible esta compatibilidad lineal, 

.NET Standard contracts

Tenemos que tener en cuenta que la librería no puede tener todas las APIs que tenemos en .NET debido a que muchas de ellas están atadas a versiones especificas de Microsoft Windows y la totalidad del .NET Framework tradicional no es compatible con el enfoque cross-platform y por lo tanto, algunas API, dejan de tener sentido con este.

Cuantas más frameworks tenga que soportar la versión de .netstandard, menos APIs tendrá disponibles. Por ejemplo, netstandard1.0 es compatible con la mayoría de las plataformas pero con menos APIs y, por otro lado, netstandard1.6 soporta únicamente .NET Core 1.0 y .NET Framework 4.6.3 pero con disponibilidad de todas las APIs recientes de .NET. Para que tengáis una idea en cifras de lo que comento, .netstandard 1.0 tiene 7.949 APIs y 2.0, 32.638.

Xamarin, actualmente, soporta esta librería para los diferentes tipos de aplicaciones. Para ello nos debemos asegurar que estamos usando Visual Studio 2015 Update 3 y tener actualizado Xamarin a la versión 4.1.2.

Para hacer uso de ellas es muy sencillo y no conlleva ninguna complicación; nos vamos a VS > Nuevo Proyecto y seleccionamos la plantilla estándar de creación de PCL tal y como se muestra en la imagen,VS Standard Library

Una vez creado el proyecto, vamos a las propiedades del mismo y cambiamos el target,

propiedades_proyecto

Y ya tenemos nuestra librería cross-platform trabajando con un modelo más modular y portable que las propias PCL con una abstracción completa sin conocimiento de cuál será el destino en el que se va a usar.

Finalmente, tan solo necesitamos agregar nuestra lib a nuestro proyecto Xamarin como una referencia más y ya podemos seguir!

.NET Standard como unificación de .NET Framework, .NET Core & Xamarin

Microsoft está haciendo un gran trabajo para abrirse y exponer sus dotes tecnológicas a través de Frameworks abiertos, modulares y cross-platform con el fin de reutilizar el código al máximo.

En las primeras versiones de .NET Core, ASP.NET Core, Entity Core, etc… teníamos marcos de trabajo independientes, con un entorno aislado al .NET tradicional a diferencia de ahora.

Para huir de este entorno aislado, es dónde .NET Standard Library cómo eje de unión, entra en acción. Esta librería es una especificación de las APIs del framework que está destinada a estar disponible en todos los runtimes de .NET. ECMA355 establece una uniformidad para el comportamiento del runtime a diferencia de las antiguas .NET Base Class (BCL).

Esta librería nos permite trabajar con una API unificada para todas las plataformas de dotnet abstrayéndonos de cual es la plataforma y, además, nos permite que podamos desarrollar librerías portables sin políticas de compilación.

¡Vamos a ver esto un poco más gráfico! Así es cómo quedará el stack,.NET Tomorrow

Para nosotros, cómo técnicos, significa que tan solo tendremos que tener un knowledge de una única biblioteca. Las bibliotecas nuevas cómo .NET Core o el recién incorporado en Microsoft, Xamarin, podrán ser ejecutadas sobre esta librería sin tener que preocuparnos que  librería debemos consumir.

Para resumir este primer post nos tenemos que quedar con dos importantes mensajes; consistencia y cross-plarform en todos los desarrollos realizados con esta nueva librería.

Un saludo!!! :)

Principios SOLID – Principio de Abierto/Cerrado (OCP)

En una anterior entrada, explicaba los principios SOLID y, además, hice un vídeo del primero de ellos con varios ejemplos.

En esta entrada, quiero explicar el segundo de ellos y dar a conocer la importancia de entenderlo y saberlo aplicar. Este, dice así,

Principio de Abierto – Cerrado (OCP)  toda clase debe ser extensible sin requerir modificación en la implementación de sus métodos internos. Esto se consigue mediante la abstracción.

Es decir, que una entidad (clase) en nuestro desarrollo debería estar abierta a extensión pero cerrada a modificación.
Para ver esto más claro y entender OCP más rápidamente, primero, veremos una violación del principio OCP. Dentro de un entorno profesional académico dónde tenemos diferentes perfiles y cada uno de ellos tiene variables salariales en función de su antigüedad. En un inicio, lo que haremos, será implementar este conjunto de clases,

public class Teaching {
      public double VariableSalary { get; set; }
      public double Antiquity { get; set; }
}

public class VariableSalaryCalculator {
      public double VariableSalary(IList<Teaching> personal)
      {
          double salary = 0;
          foreach(Teaching p in personal)
              salary = p.Antiquity * 1.2d;
          return salary;
      }
}

Cómo podemos observar, tenemos la clase Teacher con sus propiedades y posteriormente otra para calcular el salario variable.

Aparentemente, esto, parece correcto. El problema viene, cuando pasado un tiempo, nos solicitan que el salario variable ahora es aplicable para todo el personal relacionado con la enseñanza y no únicamente para los profesores, y que además, es diferente en función de ese rol.

Si no tenemos en cuenta este principio, nuestro código sería modificado con un resultado similar al siguiente,

public class VariableSalaryCalculator
{
    public double VariableSalary(IList<Object> teachers)
    {
        double salary = 0;
        foreach (var p in teachers)
        {
            if (p is Teacher)
            {
                Teacher pItem = (Teacher)p;
                salary = pItem.Antiquity * 1.2d;
            }
            else
            {
                Administrative pItem = (Administrative)p;
                salary = pItem.Antiquity * 1.1d;
            }
        }
        return salary;
    }
}

Cómo podemos observar, esto es incorrecto. No únicamente por el principio OCP si no porque estamos escribiendo un código altamente acoplado y una cohesión baja teniendo que modificar la clase para cada rol que tengamos.

Siguiendo el ejemplo, y para aplicar el principio OCP, tenemos una solución muy sencilla; crear una clase base que represente al personal docente y extenderlo mediante nuevas clases que sobrescriban el método según el rol del personal.

public class Teaching {
      public abstract double VariableSalary { get; set; }
      public double Antiquity { get; set; }
}

public class Teacher : Teaching {
      public override double VariableSalary {
      	salary = this.Antiquity * 1.2d;
      }
}

public class Administrative : Teaching {
      public override double VariableSalary { 
	salary = this.Antiquity * 1.1d;
      }
}

Sencillo, ¿Verdad?

Esto nos asegura que nuestro sistema se podrá extender, será fácil de mantener, de hacer Unit Testing en él… y además, cumpliremos con el principio OCP.

Happy clean code :)

Usando Windows Azure Content Delivery Network (CDN)

El Azure Content Delivery Network (CDN) esta diseñado para enviar audio, vídeo, imágenes y otros contenidos rápidamente a los usuarios en función de la proximidad del usuario a un nodo de su red global. Esto aumenta la velocidad y la disponibilidad haciendo su uso indispensable para ofrecer una gran experiencia de usuario dentro de nuestra aplicación web.

cdn

El CDN o Red de entrega de contenidos nos ofrece una red de servidores distribuidos que es fundamental para escalar cualquier aplicación HTTP en Azure. En la actualidad cuándo diseñamos una aplicación web que recibirá mucho trafico generado por miles de usuarios mediante llamadas concurrentes proporcionando diferente tipo de contenidos desde archivos CSS a imágenes, entre otros, sería un error plantear que un único nodo sea el responsable de ofrecer el contenido.

En este tipo  de escenarios y mediante el CDN conseguimos distribuir todos nuestros contenidos en servidores distribuidos de forma geográfica para que cuando un usuario de USA este conectado a nuestra aplicación web, el CDN le proporcione el contenido de nuestras páginas desde el nodo geográficamente más cercano.

Razones para usar un CDN

Una de las razones obvias es la distribución global y la caché de contenidos de cada uno de los nodos de la red global ofreciendo una menor latencia en la carga de la página a los usuarios de nuestra aplicación.

Con el uso de esta red ofreceremos un mejor rendimiento a nuestras aplicaciones y servicios, tendremos una aplicación escalable, reduciremos la posibilidad de failover de nuestra aplicación y además, ofreceremos contenido seguro en todo momento a través de la distribución del contenido mediante HTTPS.

Configurar Windows Azure CDN

Para configurar nuestro CDN en Azure debemos ir al portal y de ahí a Nuevo > Medios + CDN > CDN y configurar el nombre de nuestro CDN, la ubicación principal y el grupo de recursos dónde almacenaremos todo nuestro contenido. Es importante establecer el nodo principal cercano a nuestro mercado principal pues es del que se replicará a los otros nodos del CDN global de Azure.

cdn_azure

Una vez tenemos el CDN creado debemos crear un Endpoint o punto de conexión desde el mismo portal,

cdn_azure_endpoint

Para crear el endpoint necesitaremos especificar un nombre, el tipo de origen, y el host de origen. Si en el tipo de origen seleccionamos un origen personalizado deberemos escribir nosotros el host de origen, cómo por ejemplo, www.francescjaumot.net que será el dominio autorizado a consumir de nuestro CDN.

Una vez configurado nuestro endpoint este tendrá un nombre *.azureedge.net siendo * el nombre de nuestro dominio CDN y empezaremos a cargar contenido en él indicándole la ubicación del contenido mediante una ruta relativa. En mi caso el origen es un sitio web pero este puede ser el almacenamiento, un servicio en la nube, una WebApp o cómo en mi caso un dominio personalizado.

Lo más lógico para un entorno de producción es que tengamos un BLOB de Azure dónde subamos todo el contenido que queremos distribuir a través de un CDN y desde ahí administremos el contenido que cargaremos a nuestro endpoint.

cdn_azure_endpoint_load

Una vez tenemos nuestro contenido cargada podemos acceder a él y hacer referencia de el desde nuestra aplicación web mediante la URL que nos da el CDN, en nuestro caso, http://cdn4demo.azureedge.net/sliderAZURE_1.jpg.

Si nuestra aplicación ya esta desplegada en un entorno de producción y tenemos configurada la misma en un servidor IIS, podemos agregar una norma rewrite en el servidor web para que sobrescriba la URL de un grupo de contenidos directamente a nuestro CDN sin aplicar ningún cambio en nuestro código y con tan solo modificar nuestro web.config,

<rewrite>
  <rules>
    <rule name="Rewrite hacia el CDN">
      <match url="^wp-content/(.+)$" />
      <action type="Rewrite" url="http://cdn4demo.azureedge.net/{R:0}" />
    </rule>
   </rules>
</rewrite>

Tener en cuenta que el endpoint y su contenido no están disponibles de forma inmediata. De hecho puede tardar hasta 90 minutos para que sea registrado y distribuido en la red global de azure. Mientras no esté distribuido recibiremos un fantástico error 404 :) .