Las 5 maneras en las que hago pruebas con ASP.NET

Al desarrollar aplicaciones en ASP.NET, tener un buen conjunto de pruebas es la diferencia entre encontrarte un fallo en desarrollo o en producción, así de sencillo. Las pruebas no evitan todos los errores, pero al menos nos permite que los caminos críticos se mantengan estables. Veamos de qué manera podemos probar nuestras aplicaciones ASP.net

1. Pruebas Unitarias

En una prueba unitaria probamos habitualmente los métodos y el comportamiento de una clase, aunque, por supuesto, no es necesario probar TODOS los métodos (getters y setters, por ejemplo, a menos que tengamos algun tipo de lógica de validación dentro de los mismos).

En una prueba unitaria, además, es importante que mantengamos aislada la clase a probar, de tal manera que todos los servicios o clases externas puedan ser simulados mediante mocks o clases de test específicas. Para estos mocks podemos recurrir a librerías como Moq.

Backend

Personalmente he utilizado tanto MSTest, NUnit como XUnit, estando más familiarizado con el primero ya que lo uso a diario. En general cada framework tiene sus características que lo hacen más interesante, aunque todo se reduce a encontar aquel con el que más cómodos nos sintamos.

Frontend

Si nuestra página contiene lógica de lado de cliente (por ejemplo, si estamos diseñando una SPA con Angular, Knockout o React) se hace prácticamente imprescindible el uso de tests. Para ello podemos recurrir a frameworks como QUnit, Jasmine o Mocha, herramientas que nos permiten establecer unas condiciones para crear tests, así como proporcionarnos un entorno de ejecución para ejecutar las mismas.

Estas herramientas, además, se pueden integrar con Visual Studio y también con Team Foundation Server/Visual Studio Online mediante la extensión Chutzpah que podemos agregar a nuestra solución.

2. Pruebas de integración

En una prueba de integración probamos la interacción entre diferentes módulos de nuestra aplicación, y en este caso el objetivo es asegurarnos que ciertos caminos funcionan correctamente entre las diferentes capas de la misma. Una prueba de aceptación no tiene por qué cubrir todo el sistema, sino que puede cubrir tan solo una parte del mismo.

Un ejemplo podría ser comprobar que el valor que llega a un controlador, pasa por la capa que valida la lógica de negocio de ese valor y finalmente devuelve una respuesta correcta, simulando la inserción en la base de datos.

Mientras más fuertes sean nuestras pruebas de integración entre componentes del sistema, más facilidad tendremos para encontrar y corregir posibles errores de regresión que no hayamos encontrado en pruebas unitarias, ya que, habitualmente, es en la interacción en donde pueden surgir más problemas inesperados.

3. Pruebas de UI

Una de las cosas que más problemas nos puede dar es no saber si los caminos críticos de nuestra web están funcionando correctamente, y para ello, la única manera de poder asegurarnos al 100% es mediante una prueba que simule un usuario navegando por la página. Para este cometido podemos utilizar Selenium, que nos permite grabar el comportamiento de un usuario en nuestra página y posteriormente reproducirlo, así como escribir este comportamiento en C# y ejecutarlo como si de un test de integración se tratara.

4. Pruebas de carga

¿Qué pasa cuando la aplicación recibe 1000 usuarios de golpe? ¿Soportará un «efecto menéame?. Benditos problemas, pero problemas al fin y al cabo. Si estamos trabajando en una solución que tenga que soportar cierta carga (prensa, bancos, redes sociales…) las pruebas de carga deben formar parte de nuestro plan de pruebas, ya que nos permitirán estresar el sistema y poder descubrir otro tipo de errores. Una de las herramientas para realizar estas pruebas de carga es JMeter del proyecto Apache, que nos permite además personalizar la salida de estas pruebas y poder ver los resultados como listas o como gráficas.

5. Tests exploratorios

Este tipo de pruebas resulta bastante interesante y ya hemos hablado de ellas en alguna ocasión ya que mezclan intuición y experiencia adquirida, para intentar encontrar nuevos fallos, errores o escenarios que se escapen del uso habitual del sistema (los denominados también «Corner cases»).

La ventaja de estos tests es que nos aportan un mayor conocimiento sobre el sistema, aunque pueden resultar difíciles de realizar o incluso tediosos, aunque hemos de pensar que no estamos haciendo el trabajo de la máquina, sino intentando ir un poco más allá.

Conclusiones

Aunque los test exploratorios pueden caer fuera del ciclo habitual de test de una tarea, no es conveniente dejarlos fuera, ya que nos pueden aportar mucho conocimiento sobre una herramienta, sobre todo si tenemos que trabajar con código heredado.

Estas son solo cinco opciones que personalmente uso o he usado en mi día a día, existen más sabores y tipos de tests, aunque el objetivo de todos es el mismo, asegurar la fiabilidad del código que estamos poniendo en producción.

¿Y tú, qué pruebas haces? Déjame un comentario o hablemos en @rlbisbe

Autenticación con Visual Studio Online desde Java usando OAuth

El protocolo OAuth nos proporciona una manera muy fiable de autenticación, así como la posibilidad de interconectar sistemas sin tener que ceder nuestras credenciales a un tercero.

Visual Studio Online es uno de los proveedores que lo soporta, aunque con ciertas peculiaridades. En este artículo veremos cómo podemos utilizar OAuth con Java para conectarnos y autenticarnos, así las peculiaridades de VSO.

Cómo funciona OAuth2.0

Oauth se basa en dos conjuntos de clave, conocidos como key y secret, que el cliente (Aplicación A) proporciona al sistema al que se quiere conectar (Aplicación B). Veamos un ejemplo del ciclo de vida de una petición OAuth:

  1. El usuario desde Aplicación A solicita autenticar con Aplicación B
  2. Aplicación A redirige a la página de Aplicación B con la Api_Key, la url de retorno y otros parámetros como parte de la redirección.
  3. El usuario introduce sus credenciales y autoriza (o no) la cesión de datos desde la Aplicación B a la Aplicación A.
  4. La Aplicación B redirige de vuelta a la Aplicación A con la url de retorno especificada anteriormente con un código de autenticación.
  5. De lado de servidor, la Aplicación A le envía a la Aplicación B el código de autenticación, el secret, y otros parámetros.
  6. La Aplicación B devuelve un Token a la Aplicación A que identifica al usuario y que se puede empezar a utilizar para realizar peticiones.

Cliente Oauth

Vamos a crear un ejemplo de Aplicación A, es decir, un cliente OAuth. Para ello utilizaremos scribe, un componente OAuth para Java muy sencillo y muy fácil de extender para adaptar a nuestras necesidades:

OAuthService service = new ServiceBuilder()
                                  .provider(LinkedInApi.class)
                                  .apiKey(YOUR_API_KEY)
                                  .apiSecret(YOUR_API_SECRET)
                                  .build();

A partir de ese código podemos generar la URL de redirección o capturar el Token. Como Visual Studio Online no forma parte de los proveedores por defecto, crearemos nuestro propio proveedor:

@Override
public class VSOnlineApi extends DefaultApi20 {

    @Override
    public String getAccessTokenEndpoint() {
        return "https://app.vssps.visualstudio.com/oauth2/token";
    }

    @Override
    public String getAuthorizationUrl(OAuthConfig oac) {
        return String.format("https://app.vssps.visualstudio.com/oauth2/authorize?mkt=es&client_id=%s&response_type=Assertion&state=sample&scope=vso.profile&redirect_uri=%s", 
                oac.getApiKey(), oac.getCallback());
    }

    @Override
    public Verb getAccessTokenVerb() {
        return Verb.POST;
    }

    
    @Override
    public OAuthService createService(OAuthConfig config) {
        return new VSOOauthService(this, config);
    }

    @Override
    public AccessTokenExtractor getAccessTokenExtractor() {
        return new VSOTokenExtractor();
    }
}

Este proveedor consta de dos urls, la de token y la de autorización, el verbo que utilizaremos para solicitar el access token, y dos componentes, un servicio que crearemos a continuación y el extractor para procesar el código resultado de la autenticación. Con este proveedor podemos generar la URL para realizar la redirección:


 OAuthService service = new ServiceBuilder()
                           .provider(VSOnlineApi.class)
                           .apiKey("KEY")
                           .apiSecret("SECRET)
                           .callback("https://rlbisbe.dev:4567/callback")
                           .signatureType(SignatureType.QueryString)
                           .build();

Por otra parte, para poder hacer la llamada del lado de servidor y validar el token necesitaremos implementar el servicio VSOOauthService, ya que la implementación OAuth de Visual Studio Online tiene ciertas peculiaridades.

public class VSOOauthService extends OAuth20ServiceImpl {

    private final DefaultApi20 api;
    private final OAuthConfig config;
    
    public VSOOauthService(DefaultApi20 api, OAuthConfig config) {
        super(api, config);
        
        this.api = api;
        this.config = config;
    }
    
    @Override
    public Token getAccessToken(Token requestToken, Verifier verifier)
    {
      OAuthRequest request = new OAuthRequest(api.getAccessTokenVerb(), api.getAccessTokenEndpoint());
      request.addBodyParameter(VSOConstants.CLIENT_ASSERTION_TYPE, "urn:ietf:params:oauth:client-assertion-type:jwt-bearer");
      request.addBodyParameter(VSOConstants.GRANT_TYPE, "urn:ietf:params:oauth:grant-type:jwt-bearer");
      request.addBodyParameter(VSOConstants.CLIENT_ASSERTION, config.getApiSecret());
      request.addBodyParameter(VSOConstants.ASSERTION, verifier.getValue());
      request.addBodyParameter(OAuthConstants.REDIRECT_URI, config.getCallback());
      request.addHeader("Content-type", "application/x-www-form-urlencoded");
      config.log(request.getCompleteUrl());
      Response response = request.send();
      return api.getAccessTokenExtractor().extract(response.getBody());
    }
}

Esta clase nos permite construir una petición POST (que hemos visto antes en que nos permitirá validar el código que hemos recibido desde Visual Studio Online utilizando el secret de nuestra aplicación y las claves específicas que nos solicita la aplicación, enviar la petición y convertir el resultado en un Token para futuras peticiones.

Creando la web para conectarnos al servicio

Una vez que tenemos el servicio creado para obtener el token, vamos a crear una pequeña página para poder hacer el proceso completo. Para ello utilizaremos spark, un proyecto inspirado en Sinatra que nos permite crear aplicaciones web de una manera rápida y sencilla:


        OAuthService service = new ServiceBuilder()
                           .provider(VSOnlineApi.class)
                           .apiKey("KEY")
                           .apiSecret("SECRET")
                           .callback("https://rlbisbe.dev:4567/callback")
                           .signatureType(SignatureType.QueryString)
                           .debugStream(System.out)
                           .debug()
                           .build();
        
        get("/auth", (req, res) -> {
            res.redirect(service.getAuthorizationUrl(EMPTY_TOKEN));
            return null;
        });
        
         get("/callback", (req, res) -> {

             String code = req.queryParams("code");
             Verifier verifier = new Verifier(code);
             Token token = service.getAccessToken(EMPTY_TOKEN, verifier);
             return token;
        });

Con el sódigo anterior podemos ver dos puntos de entrada, /auth, que realiza la redirección al servicio, y /callback, que recoge el resultado de la redirección, parsea el código del resultado, solicita el token utilizando el servicio que hemos creado anteriormente y muestra el token como resultado:

Token[CODIFICADOENHEXADECIMAL, ]

Consideraciones adicionales: SSL

Visual Studio Online requiere que la url de retorno esté bajo el protocolo SSL y no admite localhost, con lo cual para pruebas lo que podemos hacer es crear un certificado autofirmado utilizando la utilidad Keytool de Java:

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

Además deberemos importar dicha keytool dentro de nuestro proyecto para poder utilizar HTTPS:

        SparkBase.setSecure("C:\\Users\\Roberto\\Documents\\NetBeansProjects\\OauthClientTest\\keystore.jks", "password", null, null);

Finalmente, como no admite localhost, una solución puede ser utilizar el nombre DNS de nuestro ordenador de pruebas, o bien mediante el fichero hosts crear una entrada para 127.0.0.1, en mi caso rlbisbe.dev

Documentación

Creando una VM de Azure desde línea de comandos (Primera parte)

Hoy tenía la necesidad de configurar una máquina virtual de Azure. Podía haber optado por la manera simple, que es conectarme al portal y configurarla, pero ya que tenía el SDK de Azure instalado, he decidido probar a ver cuanto puedo hacer desde línea de comandos.

Creando un grupo de afinidad y una storage account

El primer paso es crear un grupo de afinidad que es, básicamente, una sub-región donde podemos tener varios servicios. En mi caso lo configuraremos en la región del oeste de Europa:

New-AzureAffinityGroup -Name Sample -Location "West Europe"

El siguiente paso es crear una storage account, una cuenta en la que almacenaremos la máquina virtual, en el grupo de afinidad que hemos creado antes

New-AzureStorageAccount -StorageAccountName "NAME" -Label "sqlServer" -AffinityGroup "Sample"

Una vez la hemos creado, la podemos almacenar en una variable para su posterior uso:

$storage = (Get-AzureStorageAccount | where {$_.StorageAccountName -Contains "NAME"})

Finalmente fijamos esta cuenta de almacenamiento como la cuenta por defecto de nuestra suscripción.

Para ello necesitamos el nombre de nuestra suscripción, que lo podemos obtener con este comando:

Get-AzureSubscription

Con el nombre de la suscripción podemos fijar la cuenta de storage actual, usando la variable obtenida anteriormente:

Set-AzureSubscription -SubscriptionName $subscription.SubscriptionName -CurrentStorageAccountName $storage.StorageAccountName

Buscando la máquina que necesitamos desplegar

El primer paso es conseguir la máquina virtual que queremos agregar, para lo cual podemos filtrar y seleccionar solamente las máquinas que cumplen ciertos requisitos:

Get-AzureVMImage | where {$_.Label -match "SQL Server 2014"} | Select Label

Una vez que hemos seleccionado una imagen base, la podemos asignar a una variable para su posterior uso:

$vm = (Get-AzureVMImage | where {$_.Label -match "SQL Server 2014"})[6]

Finalmente podemos crear nuestra máquina virtual, con los comandos New-AzureVMConfig, Add-AzureProvisioningConfig y New-AzureVM:

New-AzureVMConfig -Name "VM-NAME" -InstanceSize Small -ImageName $vm.ImageName | Add-AzureProvisioningConfig -Windows -AdminUsername "USER" -Password "PASSWORD" | New-AzureVM -ServiceName 'SERVICENAME' -AffinityGroup "Sample"

Si todo ha ido bien, podremos ver que, tras ejecutar el siguiente comando:

Get-AzureVM 

Se muestra nuestra máquina virtual en estado de «Provisioning».

Conclusiones

Ha sido cuanto menos curioso (y más difícil de lo que imaginaba en un principio) no solo por la sintaxis de los comandos, sino porque a veces no somos conscientes de todos los procesos que se ejecutan cuando creamos una máquina virtual.

El hecho de que esto sea un script, es que lo podemos meter en un bucle for y crear 20-50-100 máquinas de la misma manera, según nuestras necesidades.

En el siguiente artículo veremos qué podemos hacer una vez que el provisionamiento está completo. Nos podremos conectar por Powershell como si de SSH se tratara? Podremos descargar el perfil de RDP desde la línea de comandos? La respuesta a esta y más preguntas en el próximo artículo de la serie.

8 cosas aprendidas de Android en el Codemotion 2014

En el pasado Codemotion 2014 pude asistir a varias charlas relacionadas con el desarrollo de aplicaciones para Android, en las que pude aprender y recordar algunos conceptos y herramientas que resumo en este pequeño artículo:

1. Model-View-Presenter

Fuente: Wikipedia DE
Fuente: Wikipedia DE

El patrón Model View Presenter es muy similar a Model View ViewModel en la base, ya que tanto el ViewModel como el Presenter notifican a la vista de los cambios, y reciben los comandos de la misma.

En el caso de Android, se propone el uso de Interfaces entre Presenter y la Vista, de manera que trabajamos, con clases abstractas, consiguiendo cierta independencia con las implementaciones.

2. Arquitecturas hexagonales

El uso de las clases abstractas con los MVP es lo que deriva en una arquitectura hexagonal, en la que mediante puertos (que es como se denominan estas interfaces) nuestra lógica de negocio se comunica con las diferentes abstracciones de la vista y diferentes servicios como comunicaciones o almacenamiento.

Fuente: VICTOR SAVKIN
Fuente: VICTOR SAVKIN

En el caso concreto de Android, la lógica de negocio puede estar completamente aislada en un módulo Java puro, lo que da una mayor independencia de la plataforma.

3. Documentación de calidad mantenida por la comunidad

android-guides

Los manuales de android guides, creados por los chicos de codepath, contienen (a fecha de hoy) más de 100 artículos con guías prácticas de desarrollo, cubriendo temas como fragments, persistencia, o guías completas como cómo empezar con gradle. Resultan verdaderamente interesantes y desde luego es un lugar a añadir a mi lista de favoritos.

4. Motores de Inyección de dependencias

De la misma manera que tenemos ninject en .NET o bien podemos crear nuestro propio motor, para Android tenemos Dagger (para inyección de dependencias en general) y Butterknife (para inyectar vistas), que nos permiten gestionar las dependencias de nuestros objetos (para implementar una arquitectura hexagonal como la que hemos definido anteriormente, por ejemplo).

5. Bases de datos y almacenamiento

url

En función de las necesidades que tengamos, hay dos proyectos que deberíamos tener en cuenta:

  • SugarORM, permite tener una base de datos local de manera extremadamente simple y manejable.
  • ORMLite compatible con cualquier proyecto de Java y permite una mayor personalización y estructuras un poco más complejas, además de estar más extendido en la comunidad.

Además, podemos o bien utilizar la clase ContentProvider para almacenar datos, o bien usar los adaptadores propios del sistema operativo, aunque se recomiendan las dos opciones anteriores.

Web: SugarORM (no confundir con SugarCRM): http://satyan.github.io/sugar/
Web: ORMLite: http://ormlite.com/

6. Testing

Para desarrollo Android tenemos muchas herramientas para hacer testing, desde JUnit que nos permite además de código Java estándar probar código específico para la plataforma, pasando por Mockito para crear artefactos para nuestros tests, y acabando con Espresso, para probar la UI de nuestra aplicación.

7. Programación reactiva

La programación reactiva o Reactive Programming es un paradigma que se basa en el flujo de datos, actualizando la visualización de los mismos a través del envío y recepción de mensajes. Es un tema verdaderamente interesante, ya que mezcla conceptos de programación funcional con patrones de lenguajes orientados a objetos como observer.

8. Otros lenguajes

Uno de los puntos fuertes de la JVM es la capacidad para ejecutar otros lenguajes más allá de Java, de esta manera podemos usar lenguajes como Kotlin (creado por Jetbrains), Groovy o incluso Clojure para hacer aplicaciones Android. El soporte para otros lenguajes es algo que está en proceso, pero que podemos tener en cuenta (Android Studio se lleva bastante bien con Kotlin, por ejemplo). Si nos vamos fuera de la JVM tenemos opciones como Xamarin que nos permite desarrollar apps para Android usando C#.

Conclusiones

Esta lista es solamente un resumen de varias charlas y conversaciones tenidas durante el evento. El ecosistema Android es muy interesante, no solo por todas las herramientas y técnicas disponibles, que una vez aplicadas se pueden llevar a otras plataformas, sino además por la comunidad que tiene, no solamente Android sino el lenguaje Java y los lenguajes basados en la JVM.

Nos vemos en la siguiente, aquí te dejo un recopilación de todas las charlas del Codemotion: https://docs.google.com/spreadsheets/d/14ZjJQ_VeT8mKmO8MANA1Os5zwRA3Pu_rpFdfyFtBZ4A/edit#gid=0

Resumen de atajos de teclado de Visual Studio

Una de las sesiones que me resultaron más interesantes en el pasado TechEd 2014 fue la de Tips and Tricks de Visual Studio con Tarek Madkur.

En ella, comentaba un montón de atajos de teclado que nos proporciona Visual Studio para mejorar nuestra productividad. En este artículo resumo brevemente las que más me han llamado la atención:

Ctrl + Q: Quick Launch

Este menú nos permite acceder, desde el teclado, a todas las ventanas auxiliares, opciones de configuración y elementos del menú del IDE. Ventanas como por ejemplo el «Package Manager Console» de Nuget, o ventanas como el Test Explorer, sin tener que estar buceando por las opciones del IDE.

Ctrl + K, X: Insertar snippet

Una herramienta muy útil cuando queremos reutilizar trozos de código llamados snipets. Este atajo nos muestra la lista de snipets instalados en nuestro sistema, y nos permite insertarlos de manera inmediata.

Alt + Shift + Enter: Pantalla completa

La pantalla completa es una vista que nos permite centrarnos en una (o varias) secciones de código, o cuando queremos mostrar código a alguien (por ejemplo, en una charla).

Ctrl + F4: Cerrar documento

Nos permite cerrar los documentos abiertos dentro del entorno de visual studio.

Shift + Esc: Ocultar ventanas

Nos permite cerrar otras ventanas como Output o Search Results, sin que ello afecte al layout actual.

Ctrl + Alt + O: Convertir en documento normal

Convierte un documento cargado en modo «preview» (el que se activa cuando hacemos click en un documento o cuando estamos navegando usando F12) en un documento normal.

Alt + F12: Peak navigation

El comando F12 nos permite navegar a la definición de un método o una clase, pero podemos perder el contexto, así que con esta opción podemos mantener el contexto y poder navegar a la definición. Lo más curioso es que podemos, dentro del menú de Peak navigation, continuar navegando

Extra! Más atajos de teclado!

El ilustre Gorka Madariaga (@Gk_8) aporta estos tres atajos:

Ctrl+C

En una linea sin seleccionar nada te la copia entera, idem para Ctrl+X o Ctrl+V (te la pega completa en la linea de arriba).

Ctrl+K, C

Comenta la linea en la que estas entera si no seleccionas nada o lo que tengas seleccionado, Ctrl+K, U hace lo inverso del anterior.

Ctrl+K, D

Para dar formato a todo el archivo o a lo que tengas seleccionado.

Conclusiones

Esta es una lista bastante corta de atajos de teclado, Visual Studio cuenta con una opción en el menú para poder listar todos los atajos, las opciones a las que están asignados, y asignarnos nuestros propios atajos (Por ejemplo, yo tengo configurado Ctrl + < para ejecutar mis test de Javascript)

Más información

Si quieres ver estas y más, te recomiendo la charla de Tarek Madkour en el TechEd 2014: https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B348

Adding multiple languages to a Windows Store app with Javascript and Angular

Leer este artículo en castellano aqui

Last thursday I could attend a debate organized by MSCoders Madrid user group, related with localization of apps in a web enfironment.

After the event I got interested in frontend localization with Javascript. As Karmacracy for Windows is a Javascript app, I decided to do some experimentation on localizing the user interface in the context of a Windows Store app, to be able to distribute it for other markets.

Detecting the system language

For a Windows Store app the first thing to do is to detect the sustem language. This can be archieved with the following piece of code:

var culture = Windows.System.UserProfile.GlobalizationPreferences.languages[0];
var language = culture.substr(0, 2);

The culture is the language that is currently being used for the UI, in culture format. For example for Spanish of Spain would be es-ES, for US English would be en-US, and for British English would be en-GB. To be able to change this order and deploy our app, we must go to the control panel:

Captura de pantalla 2014-09-15 00.29.43

In this example we only need the language, not the culture, so we are going to get a substring of the culture getting en, es, de, etc.

Adding angular-translate

Angular-translate is a module that allows us to define key-value pairs for each language and perform the translation according to the configuration. For installing it, if we don’t use a package manager such as bower, we must download the last package from github and add it to our project.

Once installed, we must add it to the configuration of our app, in the section we define external modules (in this case the module is pascalprechtr.translate).

var karmacracyApp = angular.module('karmacracyApp', [
    'ngRoute',
    'karmacracyControllers',
    'pascalprecht.translate'
]);

Finally, we configure the different languages by using the code we defined previously for getting the OS display language:

karmacracyApp.config(['$translateProvider', function ($translateProvider) {
    $translateProvider.translations('en', {
        'LOGIN': 'Log in',
        'LOGIN_USERNAME': 'User name',
        'LOGIN_PASSWORD': 'Password'
    });

    $translateProvider.translations('es', {
        'LOGIN': 'Inicia sesión',
        'LOGIN_USERNAME': 'Nombre de usuario',
        'LOGIN_PASSWORD': 'Contraseña'
    });

    var culture = Windows.System.UserProfile.GlobalizationPreferences.languages[0];
    var language = culture.substr(0, 2);

     $translateProvider.preferredLanguage(language).fallbackLanguage('en');
}]);

Also, in case the current language is not available, we set English by default

#Usage

For accessing our keys we don’t need any aditional configuration on our controllers, we just need to modify our views so they can access the localized information

<span class="loginMessage">{{ 'LOGIN' | translate }}</span>

If the language is set to English or other language not controlled, the result will be the following:

en

If the language is set to spanish, the result will be the following:

es

As it shows, is an easy way to localize our javascript apps for the Windows Store.

Recap and next steps

Angular-translate provides a simple way of localizing texts in our views and Windows provides the information we need for setting the current language of an app.

As an aditional step, we may try to localize winjs controls such as buttons, which work in a very different way. Angular-translate also supports loading the translations from a json files, an option that may be useful if we want to distribute those files for translation by 3rd parties.

Links

Creando un motor de inyección de dependencias con C#

Read this article in English: Creating a Dependency Injection in C#

De acuerdo con la Wikipedia, la inyección de dependencias es un patrón de diseño de software que nos permite seguir el principio de inversión de dependencias mediante inversión de control, es decir, definir las dependencias de una clase desde fuera de la misma. En el caso de C# tenemos a nuestra disposición varios proyectos que generan todas las dependencias necesarias para nuestros objetos. Uno de estos es Ninject, un motor open-source con una sintaxis simple y plugins para ASP.net MVC y SignalR.

En este artículo veremos cómo funciona un motor de inyección de dependencias creando uno propio, basado en la sintaxis y la filosofía de Ninject.

Introducción

La inyección de dependencias nos ayuda a separar las responsabilidades entre las diferentes capas de nuestro código, así como mejorar la encapsulación y la facilidad de crear pruebas en nuestro código. Comencemos por un ejemplo simple, una lista de notas que nos permiten agregar una nota y guardarla llamando a _dataStorage, un objeto inicializado en el constructor:

public class NoteList
{
    private DataStorage _dataStorage;
    public NoteList()
    {
        _dataStorage = new DataStorage();
    }
    public void Add(string note)
    {
        if (string.IsNullOrEmpty(note))
        {
            throw new ArgumentException("Note cannot be empty");
        }

        _dataStorage.Save(note);
    }
}

DataStorage es una clase que escribe el contenido de una nota en disco, y que tiene el siguiente código para el método Save:

internal void Save(string note)
{
    using (StreamWriter writer = new StreamWriter("db.txt"))
    {
        writer.WriteLine(note);   
    }
}

El código de test se muestra a continuación:

//Arrange
var noteList = new NoteList();
var noteText = "myCustomNote";

//Act
noteList.Add(noteText);

//Assert
using (StreamReader reader = new StreamReader("db.txt"))
{
    var all = reader.ReadToEnd();
    Assert.IsTrue(all.Contains(noteText));
}

Como se puede ver, generamos un acoplamiento con DataStorage, esto significa que no podemos probar NoteList a menos que también probemos el comportamiento de DataStorage.

Eliminando el acoplamiento

El primer cambio que podemos hacer es abstraer DataStorage en una interfaz llamada IDataStorage. Seguidamente pasamos dicha interfaz como argumento en el constructor, en vez de inicializarla dentro de nuestra clase:

...
private IDataStorage _dataStorage;
public NoteList(IDataStorage dataStorage)
{
    _dataStorage = dataStorage;
}
...

El código de test cambia también, ya que pasamos a definir las dependencias fuera de la clase:

...
var dataStorage = new DataStorage();
var noteList = new NoteList(dataStorage);
var noteText = "myCustomNote";
...

Construyendo nuestro inyector

Una vez que tenemos una clase que recibe los parámetros como argumentos. Estos parámetros deben ser definidos e inicializados manualmente antes de llamar a nuestro constructor, con lo cual, el primer paso es generar dichos parámetros solicitando un tipo específico a nuestro Iniector. La primera versión es una clase estática con dos métodos y un diccionario interno para almacenar los mapeos, que tiene este aspecto:

private static Dictionary<Type, object> mappings
    = new Dictionary<Type, object>(); 

public static T Get<T>()
{
    return (T)mappings[typeof(T)];
}

public static void Map<T>(object o)
{
    mappings.Add(typeof(T), o);
}

Ahora podemos solicitar un objeto para la interfaz de nuestro test:

Injector.Map<IDataStorage>(new DataStorage());
var dataStorage = Injector.Get<IDataStorage>();

Este código presenta un problema, y es que siempre devolveremos el mismo objeto, y seguimos especificando el inyector en el constructor. Sería mucho más sencillo si el inyector devolviera una nueva copia de nuestro objeto, y si adicionalmente pudiéramos pedir nuestro objeto directamente desde el inyector:

Injector.Map<IDataStorage>(new DataStorage());
var noteList = Injector.Get<NoteList>();

Para poder llegar a estos resultados necesitamos una serie de mejoras importantes en nuestro inyector. El primer paso consiste en dividir el método Get en un método no genérico, de tal manera que podamos realizar llamadas recursivas como veremos más adelante:

public static T Get<T>()
{
    var type = typeof(T);
    return (T)Get(type);
}

El segundo paso consiste en cambiar la manera de almacenar los objetos, ya que en vez de una instancia, almacenaremos un tipo. De esta manera cambiamos el método Map para asegurarnos que no estamos almacenando un objeto específico, y que el tipo a almacenar hereda o implementa el tipo que se usará de clave:

public static void Map<T, V>() where V : T
{
    mappings.Add(typeof(T), typeof(V));
}

Finalmente, cambiamos nuestro método Get para invocar al constructor del tipo requerido, tras algunas comprobaciones adicionales:

private static object Get(Type type)
{
    var target = ResolveType(type);
    var constructor = target.GetConstructors()[0];
    var parameters = constructor.GetParameters();

    List<object> resolvedParameters = new List<object>();

    foreach (var item in parameters)
    {
        resolvedParameters.Add(Get(item.ParameterType));
    }

    return constructor.Invoke(resolvedParameters.ToArray());
}

Veamos este código paso a paso: En primer lugar se resuelve el tipo, es decir, se comprueba si hay algún mapping disponible para el tipo especificado, en caso contrario se devuelve el mismo tipo:

private static Type ResolveType(Type type)
{
    if (mappings.Keys.Contains(type))
    {
        return mappings[type];
    }

    return type;
}

Una vez nos hemos asegurado de estar usando el tipo de dato correcto, el siguiente paso es recuperar el constructor, y su lista de parámetros (si existe).

...
    var target = ResolveType(type);
    var constructor = target.GetConstructors()[0];
    var parameters = constructor.GetParameters();
...

Si el constructor tiene parámetros, para cada uno de ellos se intentará resolver (es decir, se repetirá el proceso de manera recursiva), y si la resolución tiene éxito, se agregará a una lista de parámetros resueltos. En este caso el orden es muy importante ya que debe coincidir con el orden en el que se especifican los parámetros en el constructor**.

    foreach (var item in parameters)
    {
        resolvedParameters.Add(Get(item.ParameterType));
    }

Finalmente se invoca el constructor con la lista de parámetros y se devuelve el objeto que se acaba de crear.

    return constructor.Invoke(resolvedParameters.ToArray());

La sintaxis final para obtener un nuevo objeto de nuestro inyector de dependencias es la siguiente:

Injector.Map<IDataStorage, DataStorage>();
var noteList = Injector.Get<NoteList>();

El resultado es una manera muy conveniente de generar un objeto sin preocuparnos de sus dependencias, que pueden estar definidas a un nivel mucho mayor.

Resumen

La inyección de dependencias no es un término oscuro ni mucho menos, nos permite crear arquitecturas desacopladas, y motores como el que acabamos de crear nos permiten crear la infraestructura necesaria a un nivel más alto, con lo cual el resto de las clases pueden tener solamente la lógica relacionada con su propio comportamiento (principio de responsabilidad simple) con un conjunto mínimo de dependencias. Por otro lado no es una pieza de software muy complicada, aunque en este caso es un ejemplo y el conjunto de casos cubiertos es mínimo.

Finalmente, las características de C# nos permiten hacer algo de metaprogramación al obtener tipos y parámetros de una función en tiempo de ejecución, así como crear objetos de manera dinámica, lo cual no está mal para un lenguaje fuertemente tipado. Sería interesante comprobar cómo podríamos crear una versión de este inyector en un entorno más dinámico y débilmente tipado.

Descarga el código!

Kata UpperCounter con Software Craftsmanship Madrid

El pasado martes 5 de agosto tuve la oportunidad de acudir a mi primer meetup de Software Craftsmanship Madrid, en el que se celebaba un coding dojo facilitado por Carlos Ble @carlosble. El objetivo de la sesión era hacer uso de un patrón diseñado por Robert «Uncle Bob» Martin llamado «Transformation Priority Premise» que nos lleva a una programación más genérica y funcional.

Tras sentarnos por parejas y escoger el entorno y el lenguaje de programación (En mi caso, C# con Visual Studio 2013 y XUnit como motor de pruebas) se desveló el objetivo de la kata:

Dada una cadena, devolver, en forma de array, las posiciones de dicha cadena cuyos caracteres sean la letra mayúscula

Ejemplos:
– A: {0}
– bA: {1}
– aBcdE: {1, 4}

Primera iteración, sin restricciones

Para esta primera iteración no teníamos ninguna limitación más allá de intentar resolver la kata. El resultado es el que se muestra en el vídeo:

El código completo, tanto del test como de la implementación se puede ver a continuación:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Sample
{
public class UppercaseSearcher
{
internal int[] Search(string source)
{
var result = new List<int>();
if (source.Length > 0)
{
for (int i = 0; i < source.Length; i++)
{
var current = source[i];
if (char.IsUpper(source, i))
{
result.Add(i);
}
}
}
return result.ToArray();
}
private bool IsUpperCase(char current)
{
return current.ToString().ToUpper()
== current.ToString();
}
}
}

view raw

Source.cs

hosted with ❤ by GitHub


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;
using Xunit.Extensions;
namespace Sample
{
public class Test
{
[Fact]
public void ShouldReturnEmptyArrayIfEmptyString()
{
//Arrange
var source = "";
var searcher = new UppercaseSearcher();
//Act
var result = searcher.Search(source);
//Assert
Assert.Empty(result);
}
[Fact]
public void ShouldReturnValidUppercaseLocation()
{
//Arrange
var source = "A";
var searcher = new UppercaseSearcher();
//Act
var result = searcher.Search(source);
//Assert
Assert.Equal(1, result.Length);
Assert.Equal(0, result[0]);
}
[Fact]
public void ShouldReturnValidUppercaseInSecondPlace()
{
//Arrange
var source = "bA";
var searcher = new UppercaseSearcher();
var expected = new int[] { 1 };
//Act
var result = searcher.Search(source);
//Assert
Assert.Equal(expected, result);
}
[Theory]
[InlineData("A", new int[] { 0 })]
[InlineData("bA", new int[] { 1 })]
[InlineData("bbAab", new int[] { 2 })]
[InlineData("babC", new int[] { 3 })]
//Multiple uppercases
[InlineData("bCbC", new int[] {1,3})]
//No uppercase
[InlineData("qwerty", new int[] { })]
public void ShouldBeValidInDifferentSituations(string source, int[] expected)
{
//Arrange
var searcher = new UppercaseSearcher();
//Act
var result = searcher.Search(source);
//Assert
Assert.Equal(expected, result);
}
}
}

view raw

Test.cs

hosted with ❤ by GitHub

El enfoque es iterativo, utilizando un bucle para recorrer los caracteres de la cadena y la comprobación es bastante artesanal (a mejorar en la segunda iteración) y además, como teníamos tiempo, pudimos probar las Theories de XUnit, que nos permiten utilizar, en el mismo test, diferentes conjuntos de entrada y esperar diferentes resultados.

Segunda iteración, con restricciones

En esta segunda iteración teníamos una limitación importante: No podíamos asignar variables, ni modificar valores existentes. Esto nos deja sin la posibilidad de usar bucles (ya que vamos actualizando la posición del iterador) y forzando nuestro código a que sea más funcional. El resultado es el que se muestra:

El código completo es el siguiente, con el que intentamos seguir a rajatabla la indicación de no asignar o modificar los valores de las variables. En este caso el tiempo no permitió pasar de unos pocos test, pero se aprecia una diferencia notable por una parte en el test y por otra en el código de implementación:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Sample.WithLimits
{
class UppercaseSearcher
{
internal static int[] Search(string source)
{
return Search(source, 0);
}
internal static int[] Search(string source, int index)
{
if (IsOutOfBounds(source, index))
{
return new int[0];
}
if (char.IsUpper(source, index))
{
return new int[] { index }
.Concat(Search(source, index + 1))
.ToArray();
}
else
{
return Search(source, index + 1)
.ToArray();
}
}
private static bool IsOutOfBounds(string source, int index)
{
return source.Length == 0 || index >= source.Length;
}
}
}

view raw

Searcher.cs

hosted with ❤ by GitHub


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;
namespace Sample.WithLimits
{
public class TestClass
{
[Fact]
public void ShouldReturnEmptyArray()
{
//Arrange, act, assert
Assert.Equal(new int[0], UppercaseSearcher.Search(""));
}
[Fact]
public void ShouldReturn0IfOneLetterIsUppercase()
{
//Arrange, act, assert
Assert.Equal(new int[] {0}, UppercaseSearcher.Search("A"));
}
[Fact]
public void ShouldReturn1IfSecondLetterIsUppercase()
{
//Arrange, act, assert
Assert.Equal(new int[] { 1 }, UppercaseSearcher.Search("bA"));
}
}
}

view raw

Test.cs

hosted with ❤ by GitHub

Como nota adicional, gracias a @DanielRoz0 que me ha estado ayudando con la edición del vídeo, se pudo simplificar la comparación de una letra con su correspondiente mayúscula mediante el uso de la función char.IsUpper(source, index).

Información y enlaces:

Creating a Dependency Injection Engine with C#

According to the Wikipedia, dependency injection is a software design pattern that implements inversion of control and allows a program design to follow the dependency inversion principle. This patttern is implemented in C# with engines that generate all the required dependencies for our objects like Ninject, an open-source engine with a simple syntax and plugins for ASP.net MVC and SignalR.

In this article, we will see how does a dependency injection engine works by creating our own, based on Ninject’s syntax and philosophy.

Introduction

Dependency injection helps us to separate the concerns between the different layers of our code, and improve the encapsulation and testability of our code. Let’s start with a simple code, a list of notes that allows us to add a note, and saves it by calling _dataStorage, an object initialized in the constructor:

public class NoteList
{
    private DataStorage _dataStorage;
    public NoteList()
    {
        _dataStorage = new DataStorage();
    }
    public void Add(string note)
    {
        if (string.IsNullOrEmpty(note))
        {
            throw new ArgumentException("Note cannot be empty");
        }

        _dataStorage.Save(note);
    }
}

DataStorage is a class that writes the content of the note to disk, and has the following code for the Save method:

internal void Save(string note)
{
    using (StreamWriter writer = new StreamWriter("db.txt"))
    {
        writer.WriteLine(note);   
    }
}

The test code is the following:

//Arrange
var noteList = new NoteList();
var noteText = "myCustomNote";

//Act
noteList.Add(noteText);

//Assert
using (StreamReader reader = new StreamReader("db.txt"))
{
    var all = reader.ReadToEnd();
    Assert.IsTrue(all.Contains(noteText));
}

As we can see, we are generating a dependency on DataStorage (they are coupled), so this means that we cannot test NoteList unless we also test the behavior of DataStorage.

Removing coupling

The first thing we can do is to abstract DataStorage in an interface called IDataStorage. The following step is passing it as an argument, instead of initializing on the constructor:

...
private IDataStorage _dataStorage;
public NoteList(IDataStorage dataStorage)
{
    _dataStorage = dataStorage;
}
...

The test code also changes, so we define the dependencies from outside the class:

...
var dataStorage = new DataStorage();
var noteList = new NoteList(dataStorage);
var noteText = "myCustomNote";
...

Building our injector

Now we have a class that receives the parameters as arguments. These parameters must be defined and initialized manually before calling our constructor, so the first step is generating the parameters by asking our Injector for a specific type. The first version of our injector is a static class with two methods and an internal dictionary to hold the mappings, and it looks like this:

private static Dictionary<Type, object> mappings
    = new Dictionary<Type, object>(); 

public static T Get<T>()
{
    return (T)mappings[typeof(T)];
}

public static void Map<T>(object o)
{
    mappings.Add(typeof(T), o);
}

Now we can request an object for the interface in our test:

Injector.Map<IDataStorage>(new DataStorage());
var dataStorage = Injector.Get<IDataStorage>();

This code has an issue, that is that we always return the same object, and we are still specifying the injector in the constructor. It would be easier if the injector returns a new copy of the object and if we could also request our object directly from the injector:

Injector.Map<IDataStorage>(new DataStorage());
var noteList = Injector.Get<NoteList>();

For having these results we need to do some heavy improvements to our Injector. The first thing we are going to do is to divide the Get method into a non-generic one, so we can use recursion someway later:

public static T Get<T>()
{
    var type = typeof(T);
    return (T)Get(type);
}

The second thing we are going to do, instead of storing the object in our dictionary, is store the type, so we change also the Map method, this way we make sure of not storing a specific object:

public static void Map<T, V>() where V : T
{
    mappings.Add(typeof(T), typeof(V));
}

And finally, we are going to change our Get method to invoke the constructor of the requested type, after some extra checks:

private static object Get(Type type)
{
    var target = ResolveType(type);
    var constructor = target.GetConstructors()[0];
    var parameters = constructor.GetParameters();

    List<object> resolvedParameters = new List<object>();

    foreach (var item in parameters)
    {
        resolvedParameters.Add(Get(item.ParameterType));
    }

    return constructor.Invoke(resolvedParameters.ToArray());
}

Let’s review this code step by step: The first thing it does is resolving the type, this means checking if we have any mapping available for the specific type, if not, it returns the same type:

private static Type ResolveType(Type type)
{
    if (mappings.Keys.Contains(type))
    {
        return mappings[type];
    }

    return type;
}

After being sure about using the correct type, the next step is retrieving the constructor for the specified type, and the list of its parameters (if any).

...
    var target = ResolveType(type);
    var constructor = target.GetConstructors()[0];
    var parameters = constructor.GetParameters();
...

If the constructor has parameters, then each parameter type it will try to resolve it individually, and if the resolution was successful, it is added to a list of resolved parameters (the order here is very important, as it must match the order of the constructor signature).

    foreach (var item in parameters)
    {
        resolvedParameters.Add(Get(item.ParameterType));
    }

Finally, the constructor is invoked with the parameter list and returns the created object.

    return constructor.Invoke(resolvedParameters.ToArray());

The final syntax for getting a new object from our dependency injector is the following:

Injector.Map<IDataStorage, DataStorage>();
var noteList = Injector.Get<NoteList>();

The result is a very convenient way of generating an object without caring about its dependencies, that may be defined at a way higher level.

Recap

Dependency injection is not an obscure term, it allows us to create uncoupled architectures, and engines like the one we just created allow us to create the required infrastructure at a higer level, so the rest of the classes have only the logic related to its own behavior, with the minimum set of dependencies. It’s also not a very complicated piece of software, although ninject has a way more features and is far more robust that what we have seen here, but this is just step one.

Also, C#’s language features allow us to do some metaprogramming by getting types, parameters of a constructor and invoking it at runtime, which is not bad for a strongly typed language. It would be interesting to see how we could create a version of this injector in a more dynamic, loosely typed environment.

Get the code and play with it!

Y esto son las Interactive Rooms

En las últimas semanas he estado trabajando junto con el resto del equipo de VS Anywhere en una funcionalidad completamente nueva para nuestro Web Workspace, que hemos denominado Interactive Rooms.

Con ella, y aprovechando la recientemente presentada API de Visual Studio Online, podemos iniciar sesiones de colaboración directamente desde el navegador conectados con un repositorio Git o TFSVC, algo que, hasta ahora, resultaba imposible.

En este artículo veremos qué tecnologías y servicios hemos empleado para poder hacer posible este producto.

Obteniendo la información de Visual Studio Online

La API REST de Visual Studio Online, presentada en el pasado TechEd, permite acceder a la información de los ficheros almacenados en un repositorio, para poder comenzar una sesión en un punto específico de la historia del proyecto. Entre la información a la que podemos acceder están:

  • Team projects del portal de Visual Studio
  • Commits de un team project específico
  • Estado del repositorio en un commit específico, es decir, acceso a los ficheros.
  • Acceso a la Team Room del Team Project, para poder emitir mensajes.

Con esto, mostramos esta pantalla para que el usuario seleccione los datos antes de comenzar la sesión:

session

La autenticación está basada en OAuth2, lo que permite, una vez autorizado, poder realizar llamadas a la API sin tener que solicitar el usuario y la contraseña una y otra vez. El funcionamiento de OAuth va asociado a dos tokens, de autorización y de refresco, para asegurar la integridad de la cuenta en caso de que alguno de ellos se vea comprometido.

connectToVSO

Estos tokens, en nuestro caso, se asocian a la cuenta de usuario de VS Anywhere.

Almacenamiento y caché

Cuando creamos una sesión guardamos un snapshot de esta primera versión, que no contiene cambios. Esta snapshot se almacena dentro de Windows Azure Storage, concretamente dentro de un blob, que tiene esta estructura:

  • 123456789
    • 123456789000
    • 235123789021
    • 563473568561

Si accedemos desde el Azure Storage Explorer podemos ver qué se está almacenando:

blobs

Esta estructura de árbol nos permite obtener el histórico de una sesión y poder agregar nuevos items usando los ticks como clave. De esta manera podemos mostrar la fecha de creación sin necesidad de acceder al contenido del blob.

El resto de información almacenada (serializada como JSON) está relacionada con el tipo de autenticación, el team project, el commit o la lista de ficheros que se ha usado para poder re-crear la sesión en el futuro.

Para mantener una caché de sesiones activas usamos Redis, que nos permite un almacenamiento clave-valor con un acceso increíblemente rápido.

Descargando los datos

De la misma manera que podemos crear un snapshot, también podemos descargar el estado actual del proyecto, para integrarlo en nuestro workspace de git o TFS local, descargando un fichero que contiene solamente los documentos abiertos y los editados, siendo el resultado el que se muestra:

download

El fichero .zip se genera sobre la marcha, usando la información actual de la sesión y las opciones de compresión de .net 4.5 (ver más en MSDN).

Conclusiones

Mediante el uso de Azure Storage, Redis, y las API de Visual Studio Online hemos podido crear una funcionalidad adicional que complementa, por una parte el Web Workspace, y por otra el propio Visual Studio Online, dando nuevas opciones de colaboración.

La API, aún en estado beta, está bastante avanzada y productos como UserVoice o Zapier la están integrando dentro de sus propias soluciones.

¿Cómo empiezo?

Para poder empezar a usar las Interactive Rooms, solamente necesitas VS Anywhere 3.0.0.157 y una cuenta en Visual Studio Online. Puedes comenzar desde el propio Visual Studio siempre que:

  • Estés conectado a Visual Studio Online
  • El proyecto sea C# y esté en control de versiones
  • El team project esté conectado a visualstudio.com

Si se cumplen esos dos requisitos, las opciones se mostrarán al hacer click derecho sobre un proyecto:

options

Información y registro

Puedes encontrar más información (y registrarte) en la web de Interactive Rooms