Artículo Invitado: ECMAScript 6 y la nueva era de JavaScript por @CKGrafico

Comenzamos con este artículo una nueva sección llamada “Artículos Invitados”, en este caso tengo la suerte de contar con Quique Fernandez Guerra, Microsoft Student Partner y desarrollador Javascript:

Quique Fdez GuerraQuique Fdez. Guerra
Desarrollador y amante de JavaScript
Twitter: @CKGrafico
Web: CKGrafico.com

Quique es un usuario muy activo de comunidades de desarrollo frontend, y le hemos visto en varios hangouts mostrando su experiencia, así que le he pedido que nos cuente sus impresiones de lo que está por venir en la nueva versión del estandar ECMAScript 6, en el cual se basarán las próximas versiones de Javascript. A continuación sus impresiones


Desde siempre se ha considerado a JavaScript cómo un lenguaje simplón, es seguramente uno de los lenguajes actuales más sencillos de aprender, pero además es conocido por no ser muy completo (ya sea por la manera de trabajar con las clases, o los artículos sobre ‘JavaScript the weird parts’).

Por otro lado, en los últimos años JavaScript a empezado a tener más importancia hasta el punto que se ha vuelto el único lenguaje universal, es decir, lo encontramos en web, servidor, hardware, móvil, etc, cómo ya comenté en un artículo hace un tiempo.

Aún así el lenguaje sigue igual, de hecho ha llegado un momento en que la gente sabe mucho más sobre frameworks del lenguaje que del propio lenguaje. Está lleno de ofertas de trabajo en las que se pide conocimientos en jQuery y Backbone o Angular y por supuesto hay mucha gente aprendiendo directamente estos frameworks (Aprender un framework antes de saber el propio lenguaje…).

Por suerte, parece que con la nueva versión del estándar ECMAScript vamos a poder tomar más en serio JavaScript, aunque cómo siempre vamos a tener que esperar que todos los navegadores lo soporten. A continuación voy a explicar las partes que considero más importantes de esta nueva versión.

Declaración let

Ahora podemos declarar variables que existan solo en un bloque de código, entendiendo por bloque de código desde una función hasta un bucle o una condición.


if(1) {
var a = 5;
let b = 6;
console.log(a,b); // 5 6
}

console.log(a,b); // b is not defined

Constantes, ¡¡Sí constantes!!

Ya era hora de poder utilizar constantes en nuestro apreciado JavaScript, muy sencillas de utilizar igual que en otros lenguajes.

const PI = 3.14;
console.log(PI); // 3.14

function test() {
 console.log('test', PI); // test 3.14
}

test();

PI = 6; // Error!!

Arrow functions

Si trabajas con lenguajes cómo C# que tienen lambda verás que es algo parecido, que se ha traído a JavaScript.

let simple = a => a / 2;
console.log(simple(8)); // 4

let complex = (a, b) => {
 if (a < b) {
 return a;
 }
 return b;
}

console.log(complex(3,6)); // 3

Valores por defecto en parámetros

Otro ejemplo más de algo que tienen casi todos los lenguajes y JavaScript aún no lo tenía, pero ya está aquí.

function test(a, b = 10) {
 return a + b;
}

console.log(test(1)); // 11
console.log(test(1,2)); // 3

Rest parameters

Nos va a ser muy útil cuando no sepamos el número de parámetros exactos, muchas veces usábamos arguments para eso, pero ahora vamos a tenerlo mucho más fácil.

function test(a, b = 1, ...c) {
 return a + b + c.length || 0;
}

console.log(test(1)); // 2
console.log(test(1,10,1,1,1,1)); // 15

Pero no solo eso, también lo vamos a poder utilizar en un array o al llamar a una función.

let arr = [4, 5, 6];
let numbers = [1, 2, 3, ...arr, 7, 8];

console.log(numbers); // [1, 2, 3, 4, 5, 6, 7, 8]

Object literals

Simplificaremos los objetos, de manera que no haya que poner información irrelevante.

// ECMA 5
var world = 'world';
var obj = {
 world: world,
 hello: function() {
 console.log('hello', this.world);
 }
};

obj.hello(); // hello world

// ECMA 6
let world6 = 'world';
let obj6 = {
 world6,
 hello() {
 console.log('hello6', this.world6);
 }
};

obj6.hello(); // hello6 world

for..of

La evolución lógica del for..in

// ECMA 5
var arr = ['a', 'b', 'c'];
for(var i in arr) {
 console.log(arr[i]); // a, b, c
}

// ECMA 6
let arr6 = ['a', 'b', 'c'];
for(let i of arr6) {
 console.log(i); // a, b, c
}

Generadores

Un nuevo tipo de función que nos ayuda a crear un iterador de manera fácil, utilizan yield en vez de return que es una nueva palabra reservada.

function* range(start, end) {
 for (let i = start; i <= end; i++) {
 yield i;
 }
}

var ranger = range(1,10);

var res = {
 value: null,
 done: false
};

while(!res.done){
 res = ranger.next();
 console.log(res.value, res.done);
}

Symbol

symbol es un nuevo tipo de dato y Symbol() nos devuelve un objeto único de tipo symbol, pensado para tener objetos o métodos que son distintos de los demás, sería un sustituto a usar cadenas para los nombres de los métodos por ejemplo.

let myMethod = Symbol();
let obj = {
 [myMethod]() {
 console.log('Soy único e irrepetible');
 }
};

obj[myMethod](); // Soy único e irrepetible
console.log(typeof myMethod); // symbol

Map

El objeto Map  es un objeto de clave / valor, la mejor manera de entenderlo es ver un ejemplo.

let map = new Map();
let arr = [];
map.set('string', 'Ola k ase');
map.set(arr, [1, 2, 3, 4]);
map.set(typeof 8, 'I\'m a number');

console.log(map.size); // 4

console.log(map.get('string')); // Ola k ase
console.log(map.get(typeof 1)); // I'm a number
console.log(map.get([])); // undefined -> arr !== []
console.log(map.get(arr)); // [1, 2, 3, 4]

Set

Sirve para poder crear algo parecido a las listas en otros lenguajes, aunque aún bastante simple.

let set = new Set();
set.add('test');
set.add(8);
set.add('Quique');

console.log(set.size); // 3
console.log(set.has(8)); // true

set.delete('Quique');

set.forEach(function(value) {
 console.log(value); // test 8
});

Clases

Vamos a tener clases en condiciones, más o menos van a hacer lo mismo que hasta ahora pero vamos a tener una sintaxis más sencilla para implementarlas.

class Human {
 constructor(name = 'anonymous') {
 this.name = name;
 }

 hello() {
 console.log('Welcome to the world ' + this.name);
 }
}

class Male extends Human {
 constructor(name) {
 super(name);
 this.sex = 'male';
 }

 get age() {
 return this._age;
 }

 set age(age) {
 this._age = age;
 }
}

let me = new Male('Quique');
me.hello();
me.age = 1;
console.log(me.age); // 1

Módulos

Ha llegado la hora de poder crear partes de nuestro código por separado e importarlas cuando nos sea conveniente, para no cargarlo todo de golpe y trabajar de una manera ordenada.

// number.js
module 'number' {
 let num = 8;
 export class Number {
     constructor() {
         console.log('The number is: ' + num);
     }
 }

}

// app.js
module number from '/number.js';
import Number from 'number';

var n = new Number(); // The number is 8

Templates

Una de las cosas que más he usado este último año en JavaScript han sido los templates, sobretodo trabajando Handlebars, pues ahora mismo se convierten en algo propio de este lenguaje.

let name = 'Quique', twitter = 'CKGrafico';
let template = `Hello, this is ${name}, find my on ${twitter}`;
// Nota, fíjate en las ` que no es lo mismo que '
console.log(template); // Hello, this is Quique, find my on CKGrafico

Estas son las cosas más destacables que trae la nueva versión, puedes encontrar la lista entera en su especificación.

Mientras esperas a que sea compatible en los navegadores puedes trabajar con ECMA6 en ES6 fiddle (un sandbox) o utilizar un pequeño transpiler llamado Traceur que te permite trabajar en ECMA6 y compilar a ECMA5

 


Si tienes preguntas o comentarios no dudes en dejarlas en la sección de comentarios, y si tienes más información sobre Quique, aquí tienes algunos datos de contacto:

Quique Fdez GuerraQuique Fdez. Guerra
Desarrollador y amante de JavaScript
Twitter: @CKGrafico
Web: CKGrafico.com

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:

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:

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!

First contact with AppNow, an awesome tool for generating and deploying code on the cloud

Disclaimer: Although I know personally members of the AppNow team, I don’t have any relationship with the company and with the products it develops.

TL; DR The creators of the Radarc tool have just launched a free preview of AppNow, an online cloud based service that allows us to generate a MEAN backend for our apps. In this article we will see how to create our solution, the generated result, and finally some notes about what can we find under the hood.

contents

Some context

If you don’t know what is Icinetic, it is a company based in Seville, Spain dedicated to the development of products and mobile applications. Its flagship product, Radarc, is a solution that generate native mobile and web applications from a class based model (model-driven design).

This operation is carried out through various modules called formulas and is integrated into Visual Studio through an extension. I could see it in action a few months ago and I was very impressed with the quality of the generated code.

In the last /Build event, they announced Radarc Online, which is independent from Visual Studio, and today have gone one step further with AppNow, a tool to create and deploy custom backends in the cloud.

Technical features and limitations

The beta version is limited to a MEAN stack:

  • Cloud server: Heroku
  • Database: MongoDB
  • Backend: Node.js + Express.js
  • Frontend: Angular.js

First contact

When we reach the web the first thing we can do is login by using our favourite social network account:

appnow_home

The next step is configuring our data model, for this example I opted to load the default sample set:

datamodel

Once configured the data model, we continue with our Heroku credentials. At this point, it is very important that our Heroku account is validated (read more…) and that we have added our SSH key to Heroku to continue.

heroku

If all goes well you will see a screen like the one shown, that it will be updating while the solution is generating.

generated

Thus we have generated code from our class model, and we have deployed it in the cloud with a single step. The result of this deployment is this site:

result

From here we can list created models, as well as add, edit and delete them.

Under the hood

contents

In the list of files we can see different views, drivers and services that are part of an angular application inside the public directory, and on the other hand we can see the backend on the app directory.

If we take a look at the code we can see some details:

  • Access to MongoDB occurs by mongoose, which is an ORM that gives us validation and strict data types for working with MongoDB.
  • The API (Generated using Express.js) is compatible with swagger, which if you don’t know it, is a tool that allows us to generate documentation as well as static and dynamic clients automatically from the API comments and endpoints.
  • Angular app is a SPA, with a controller for each entity we have specified at the beginning, and different actions for adding, editing and deleting each entity.
  • Supports, in addition, authentication and session services for Angular.

Recap

An interesting point here is that it offers the full package, not only the generation of code but it also deployment. Being based on git means that we can, from that moment, gain control of the code and continue to develop. It is a simple and elegant way of creating a service backend, which once generated, does not have any additional dependency to Radarc services.

Although it is only a demo, it is an interesting test of the power behind this tool. It generates clean, well commented code so we can continue developing it (nothing to do with the generated code that we have seen in some tools). My recommendation is to try it with patience, and tell the guys from Icinetic if you find something wrong. Without a doubt, a project to follow closely!

Links

Probando AppNow, lo nuevo de los chicos de Icinetic

Disclaimer: Aunque conozco personalmente a miembros del equipo de AppNow (unos auténticos cracks) no tengo ninguna relación con la empresa ni con los productos que ella desarrolla.

TL; DR Los creadores de Radarc acaban de lanzar la preview gratuita de AppNow, una herramienta en la nube para generar un backend para nuestras aplicaciones. En este artículo veremos cómo generar nuestro backend, el resultado, y qué nos podemos encontrar en el código generado.

contents

Un poco de contexto

Si no sabes qué es Icinetic, es una empresa con sede en Sevilla que se dedica al desarrollo de productos y aplicaciones móviles. Su producto estrella, Radarc, es una una solución para generar modelos de aplicaciones nativas a partir de un modelo de clases (model-driven design).

Su funcionamiento se realiza a través de diversos módulos llamados fórmulas y se integran en Visual Studio a través de una extensión. Pude verlo en acción hace unos meses y me quedé muy impresionado con la calidad del código generado.

En el pasado /Build, saltaron a la nube presentando Radarc Online, lo que supone una independencia de Visual Studio, y hoy han ido un paso más allá con AppNow, una herramienta para crear y desplegar backends personalizados en la nube.

Características técnicas y limitaciones

La versión beta nos permite probar un stack MEAN, es decir:

  • Servidor: Heroku
  • Base de datos: MongoDB
  • Backend: Node.js + Express.js
  • Frontend: Angular.js

Primer contacto

Cuando entramos a la web lo primero que podemos hacer es iniciar sesión con nuestra cuenta de nuestra red social favorita:

appnow_home

El siguiente paso es configurar nuestro modelo de datos, que para este ejemplo he optado por cargar el conjunto que ofrecen por defecto:

datamodel

Una vez configurado el modelo de datos, continuamos con nuestras credenciales de heroku. En este punto es muy importante que nuestra credencial esté validada (ver más..) y que agreguemos nuestra clave SSH a Heroku para poder continuar.

heroku

Si todo ha ido bien podremos ver una pantalla como la que se muestra, que se irá actualizando mientras se va generando la solución.

generated

Con ello hemos generado código a partir de nuestro modelo de clases, y lo hemos desplegado en la nube con un solo paso. El resultado de dicho despliegue es este sitio:

result

Desde él podemos listar los modelos creados, así como agregar, editar y borrar los mismos.

Bajo el capó

contents

En la lista de ficheros podemos ver, dentro del directorio public las diferentes vistas, controladores y servicios que forman parte de una aplicación angular, y por otro el backend dentro del directorio app.

Si echamos un vistazo al código podremos ver algunos detalles:

  • El acceso a MongoDB se realiza mediante mongoose, que es un ORM que nos aporta validación y tipos estrictos de datos para trabajar con MongoDB,
  • La API (generada usando Express.js) es compatible con swagger, que si no lo conoces, es una herramienta que nos permite generar documentación así como clientes estáticos y dinámicos de manera automática a partir de los comentarios de la API
  • La aplicación Angular es una SPA, con un controlador por cada entidad que hemos especificado al principio, y diferentes acciones de edición, agregación, listado o borrado para cada uno de ellos.
  • Soporta, adicionalmente, autenticación y sesiones a través de servicios de Angular.

Conclusiones

Un punto interesante en este aspecto es que ofrece el paquete completo, no solamente la generación de código sino que también el despliegue, y, al estar basado en git, podemos, a partir de ese momento, obtener el control del código y continuar el desarrollo. Es una manera simple y elegante de crear un servicio de backend, que, una vez generado, no tiene ninguna dependencia adicional a servicios de Radarc.

Aunque no es más que una demo, es una prueba interesante de la potencia tras esta herramienta. El código que genera es limpio, bien comentado, a partir del cual se podría continuar el desarrollo (nada que ver con el código auto-generado que hemos visto en algunas herramientas). Mi recomendación es probarlo con paciencia, y avisar a los chicos de Icinetic si encontramos algún fallo. Sin duda, un proyecto a seguir de cerca!

Enlaces

Cacheando con Varnish un proyecto ASP.net MVC5

Una caché, por definición, es un almacenamiento a corto plazo de información y con una altísima velocidad de acceso, permitiéndonos mejorar el rendimiento de nuestros sistemas. En el caso de la web podemos diferenciar dos tipos:

  • Caché de cliente, que se hace en el navegador y que nos permite no tener que traer de internet imágenes o ficheros de estilo una vez hemos obtenido una copia.
  • Caché de servidor, que guarda una copia de manera temporal para evitar sobrecarga de nuestro servidor de aplicaciones.

Esto último tiene una justificación, y es que el acceso a las aplicaciones (PHP, ASP.net, Ruby) es un proceso relativamente lento que suele estar acompañado de un acceso a una base de datos, una aplicación de la lógica de negocio y la composición final de la página.

Existen diferentes sistemas y tipos de caché, como Memcached o Redis. En este artículo hablaremos de Varnish, un proyecto open-source que se instala sobre sistemas UNIX (aunque tiene soporte para Windows mediante Cygwin).

La principal peculiaridad que tiene este sistema, además de sus casi-infinitas opciones de configuración, es que permite dividir nuestra página en trozos y cachearlos de manera independiente, en función del intervalo de actualización de los mismos, un proceso conocido como Edge Side Includes (ESI) y que veremos a lo largo del artículo.

Instalación y configuración

La instalación de Varnish es un proceso tan simple como brew install varnish si usamos homebrew en mac. Una vez instalado, para ejecutarlo usamos el siguiente comando:

sudo /usr/local/opt/varnish/sbin/varnishd -n /usr/local/var/varnish -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8082

pasando como parámetros las siguientes opciones:

  • Ruta del fichero de configuración
  • Puerto de registro de log
  • Máximo consumo de RAM
  • Puerto de escucha (en nuestro caso el 8082)

El fichero de configuración default.vcl, para nuestro ejemplo, contiene las siguientes directivas:

backend default {
    .host = "127.0.0.1";
    .port = "8087";
}

sub vcl_recv {
	if (req.http.cookie) {
		unset req.http.cookie;
	}
}

sub vcl_fetch {
	
	if (req.url == "/layout/*") {
       set beresp.ttl = 2m;      /* Sets a one minute TTL on        */
    } else {
       set beresp.do_esi = true; /* Do ESI processing               */
       set beresp.ttl = 30s;     /* Sets the TTL on the HTML above  */
    }
    unset beresp.http.set-cookie;
}

sub vcl_deliver {

    if (obj.hits > 0) {
            set resp.http.X-Cache = "HIT";
    } else {
            set resp.http.X-Cache = "MISS";
    }
}

Los comandos que hemos implementado son:

  • backend: Permite especificar qué servidores estarán funcionando al otro lado, se puede especificar una IP o un nombre DNS.

  • vcl_recv: En el caso de ASP.net, se genera una cookie de sesión al acceder al sitio, lo cual no siempre es lo deseable. En este ejemplo se borran todas las que provienen del servidor, de manera que se pueda cachear la página.

  • vcl_fetch: Se ejecuta cuando obtenemos un elemento desde el servidor, y en este caso especificamos que si estamos solicitando algún elemento de “layout” como el menú o la cabecera, ha de cachearlo durante 2 minutos, en caso contrario configuramos para que haga el procesamiento ESI (es decir, que intente unir los pedazos) y cachee el conjunto durante 30 segundos.

  • vcl_deliver: Nos permite editar la cabecera HTTP para saber si ha podido resolver el elemento en la caché o si ha tenido que acceder al servidor de aplicaciones.

Cacheando voy, cacheando vengo:

En este ejemplo hemos usado una plantilla de bootstrap que tiene el siguiente aspecto dentro de una aplicación prácticamente vacía en MVC5:

goal

Lo primero que podemos apreciar son tres zonas claramente diferenciadas, una cabecera, una barra lateral, y, finalmente, un área de contenido principal.

Estructura

Para mostrar la página, empleamos un controlador muy sencillo que genera una espera de 3 segundos para simular carga del servidor y almacena la fecha de generación en el ViewData:

public class HomeController : Controller
{
	public ActionResult Index ()
	{
		ViewData ["now"] = String.Format ("{0:HH:mm:ss}", DateTime.Now);
		System.Threading.Thread.Sleep (3000);
		return View ("Index");
	}
}

De manera adicional y para poder aplicar ESI, necesitaremos dividir nuestra vista en tres vistas diferentes que correspondan a acciones diferentes del controlador, que serán:

  • / <- que genera el contenido de la página
  • /layout/header <- que genera la cabecera
  • /layout/sidebar <- que genera la barra lateral

Las dos acciones del controlador Layout son idénticas, como muestra el código:

public class LayoutController : Controller
{
    public ActionResult Sidebar()
    {
		ViewData ["now"] = String.Format ("{0:HH:mm:ss}", DateTime.Now);
		System.Threading.Thread.Sleep (3000);
        return View ("Sidebar");
    }

	public ActionResult Header()
	{
		ViewData ["now"] = String.Format ("{0:HH:mm:ss}", DateTime.Now);
		System.Threading.Thread.Sleep (3000);
		return View ("Header");
	}
}

Nótese que por cada acción hemos agregado otros 3 segundos de retraso, teniendo un total de 9 segundos en el caso peor.

Para poder activar el ESI en las vistas, usamos etiquetas HTML que tienen el siguiente formato:

<esi:include src="/layout/sidebar" onerror="continue"/>

Además, a modo de prueba, podemos agregar algo de código javascript que se ejecute una vez cargada la página para apreciar la diferencia entre hora de generación y hora de renderización. Si todo ha ido bien, cuando carguemos por primera vez nuestra caché, se encontrará vacía, y sufriremos la espera de los 9 segundos.

En la imagen, G muestra la hora de generación en el servidor y R la hora de renderización en el cliente:

miss

Si volvemos a acceder, comprobaremos que el contenido de la página ya se ha cacheado, que las fechas de generación y de ejecución distan más de tres segundos, y que el inspector nos muestra el tiempo total de acceso a la página (700 milisegundos aprox):

hit

Conclusiones

Ha sido una prueba de concepto muy interesante, el hecho de descubrir que podemos tener nuestra web dividida en secciones con cachés diferentes nos da mucha movilidad al hacer portales con información dinámica. Varnish es una herramienta suficientemente compleja para ser tomada en serio y requiere que estudiemos a fondo sus características antes aplicarla a un sistema en producción.

Lecturas adicionales y enlaces