ASP.NET 5, Owin y Katana

Con todo esto del ASP.NET5, ASP.NET 4.6, MVC6, DNX, DNX Core, etc. No queda muy claro donde encajan ciertos componentes que antes ya nos resultaban familiares. Como el caso de Owin y Katana que, con el anuncio de ASP.NET 5, no supe donde quedaron o qué iba a pasar con ellos.

Afortunadamente el equipo de ASP.NET documentó el tema y solo tenía que buscar un poco.

Con la información obtenida en el articulo me quedaron claras algunas cosas:

  • En el repositorio de Katana ya habían dicho que la siguiente versión sería parte de “vNext” y que el proyecto se movería de codeplex a GitHub, en el mismo repo de ASP.NET. Además renombraron todo para alinearlo con ASP.NET 5 y la versión sería de nuevo la 1.0.katanaroadmap
  • Con esta movida no solo cambiaron de nombre las cosas, también cambió el cómo funcionaban, es el caso del IAppBuilder, que ahora es IApplicationBuilder, y que usa un AppFunc diferente. O el IOwinContext, que ahora es HttpContext.
  • Si hay forma de usar los viejos (Katana 3.0) middlewares en ASPNET 5.

Algo de código

Hasta aquí he comentado lo que entendí de aquel articulo. Pero unas cuantas lineas de código nos mostrara que quiere decir esto y nos aportará nuevas dudas.

¿Cómo luce un middleware hoy?

Para crear un middleware compatible con el pipeline de Katana basta con definir una clase que use el AppFunc y tenga un método Invoke, algo de la forma:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading.Tasks;

namespace MisMiddelwares
{
    using AppFunc = Func<IDictionary<string, object>, Task>;

    public class DebugMiddleware
    {
        private readonly AppFunc _next;

        public DebugMiddleware(AppFunc next)
        {
            _next = next;
        }

        public async Task Invoke(IDictionary<string, object> enviroment)
        {
            var path = (string) enviroment["owin.RequestPath"];
            Debug.WriteLine("--Incoming request. Path: " + path);
            await _next(enviroment);
            Debug.WriteLine("--Outgoing request. Path: " + path);
        }
    }
}

¿Cómo se usa un middleware hoy?

El middleware anterior lo podemos integrar en el pipeline de Katana 3.0 de manera muy, muy sencilla:

    using Owin;
    using MisMiddlewares;
    public class Startup
    {        
        //... Configure Web API for self-host. 
        var config = new HttpConfiguration();
	appBuilder.Use<DebugMiddleware>();
        appBuilder.UseWebApi(config);      
    }

Si quisiéramos agregar nuestro middleware usando la forma app.UseXXX, deberíamos agregar una clase estática al ensamblado del middleware, agregar una dependencia a Katana (Microsoft.Owin) y usar el siguiente código

namespace MisMiddlewares
{
    using Owin;

    public static class DebugMiddlewareExtensions
    {
        public static void UseDebug(this IAppBuilder app)
        {
            app.Use<DebugMiddleware>();
        }
    }
}

Usar mi middleware en ASP.NET 5

Ahora viene lo nuevo, en un proyecto de ASP.NET 5 (DNX) vamos a intentar usar el middleware que acabamos de crear. Para ello lo primero que haré será remover el dnxcore50 de la sección frameworks del project.json, esto porque no lo usaré y necesito una referencia al middleware (cproj). Una vez hecho esto agrego una referencia al proyecto (con todo lo que hace por detrás), esto lo hago solo para ver que pasaría en el caso de querer reutilizar el componente sin tener que escribir nada más, además de ver que tiene el nuevo Katana que nos permita reutilizar lo anterior.

En el startup vemos que el nuevo IApplicationBuilder aún expone un método Use, pero con una firma muy diferente para el AppFunc que no nos sirve en nuestra anterior implementación. Podríamos intentar construir uno (AppFunc) a partir de este, o mejor aún, usar lo que ya tiene Katana vnext (el vnext se lo puse yo :P) para esto. En el articulo hay un enlace a un repo que contiene un ejemplo, algo engorroso, que muestra cómo hacerlo. Pero en ese mismo repositorio hay otro ejemplo un poco más claro. Partiendo de este ejemplo, si queremos usar de nuevo nuestro middleware empezaremos por instalar el paquete Microsoft.AspNet.Owin, que nos expone el método UseOwin, y, en la clase Startup ya podemos agregarlo al pipeline:

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            app.UseOwin(addToPiepline =>
            {
                addToPiepline(next =>
                {
                    var middleware = new DebugMiddleware(next);
                    return middleware.Invoke;
                });
            });

Inquietudes

Con esta implementación me queda la inquietud de cómo harán las personas que mantienen este tipo de proyectos para dar soporte a las aplicaciones DNX y a las tradicionales, cómo será el tema del código compartido… o si será algo automático

Ejemplo

He dejado el código de este artículo aquí

Espero les sea de utilidad esta breve aclaración

Hasta el próximo post.

ASP.NET 5, Owin y Katana

[F#] Tail Recursion y el Stack

En la entrada anterior veíamos cómo, de manera sencilla, podíamos razonar y entender las funciones recursivas. Pero ¿Cómo funcionan estas llamadas recursivas en .NET?

Empecemos por aclarar algo. Cuando se llama a una función, el computador debe recordar el lugar desde donde fue llamada, la dirección de retorno, de modo que pueda volver a ese lugar con el resultado una vez la llamada se ha completado¹. Estas direcciones son almacenadas en el call stack. Una vez la función retorna un valor la pila de llamadas se borra y el programa continúa desde la función llamadora.

Si una función recursiva se llama a si misma una y otra vez, como un loop, el stack se irá llenando con dichas direcciones (las llamadas a si mismo). El problema es que el stack no es infinito y podemos recibir una conocida excepción, si, la Stack Overflow Exception.

Podemos comprobar este comportamiento si escribimos una función que calcule el factorial de un número de manera recursiva, algo de la forma:

    let rec factorial =
        function
        | x when x > 1 -> x * factorial (x-1)
        | _ -> 1

Usando Visual Studio, podemos poner un breakpoint en el otherwise, donde esta el “1“, llamar la función y ver que pasa:

factorial

Ahora podemos probar calculando el factorial de Int32.MaxValue y ver que pasa… Process is terminated due to StackOverflowException.

Entonces, ¿Es posible escribir funciones recursivas que no llenen el call stack? La respuesta es si, y es lo que llamamos tail recursion (lo dejo en inglés porque recursión de cola no me gusta). Este tipo de recursión se basa en que todas las llamadas recursivas aplicarán la optimización de tail call. Esta optimización la obtenemos cuando la función llamadora retorna directamente el valor de la función llamada sin aplicar ninguna transformación/operación/reducción sobre dicho valor de retorno. Entonces, si todas las llamadas de la función recursiva son tail calls tendremos tail call recursion.

¿Pero cómo podemos lograr esto? Si analizamos de nuevo el tail call la respuesta pasa por retornar directamente la llamada a la función sin aplicar la función x*. Pero… ¿Y por cual valor multiplicamos? pues tendremos que usar un valor inicial (seed/acumulador/…). Con lo que la función factorial, tail recursive, puede ser definida así:

    let factorial' =
        let rec fact acc = 
            function
            | x when x > 1 -> fact (acc*x) (x-1)
            | _ -> 1
        fact 1

Cómo podemos ver ahora hay una nueva función dentro de la definición de factorial'. Esta función recibirá el valor del acumulador, que será 1 y el parámetro n. Si ponemos nuevamente un breakpoint en el otherwise, donde está el “acc“. Y usamos la función con Int32.MaxValue, esta vez veremos un call stack como el siguiente:

factorial1

De esta forma retornamos directamente la función sin hacer ninguna operación (x*) sobre la función.

En lenguajes funcionales, como F#, es común que el compilador optimice este código, y lo convierta a loops cómo los que tendríamos en lenguajes imperativos, logrando así el mismo comportamiento y performance.

Por el contrario, si queremos aplicar esta tipo de recursión en lenguajes como C# veremos que no hay ninguna optimización y el call stack se irá llenando con cada llamada a la función. El por qué en C# no se hace esta optimización es un misterio para mi, pero para eso esta F#.

Espero les sea de utilidad.

Hasta el próximo post.

Referencias

¹ Véase Wikipedia, Tail call, consultado: 7/11/2015.

MSDN Blog, Tail calls in F#

MSDN Blog, Understanding Tail Recursion

StackOverflow, Why doesn’t .NET/C# optimize for tail-call recursion?

[F#] Tail Recursion y el Stack

[F#] Funciones recursivas a lápiz y papel

Si hay algo que me ha gustado de la programación funcional (en lo poco que llevo estudiándole) es poder razonar sobre las funciones que escribo como meras funciones matemáticas, nada de tener que pensar en mutaciones de estado de un objeto o efectos colaterales al invocar determinada función. Y si hay algo que me gusta de las matemáticas, y la algoritmia en particular, es llenar hojas enteras de números, formulas y dibujos para razonar, abstraer y entender distintos conceptos y problemas. Hay gente que usa algún software u hojas de calculo para esto, a mi me gusta el lápiz y el papel.

El concepto de función recursiva es un tema fundamental en cualquier texto de programación funcional (al menos en los que yo he visto siempre tocan el tema), y en la web podemos encontrar definiciones, y en MSDN la implementación de F#

Lo que quiero exponer aquí es cómo razonar sobre las funciones recursivas cómo si estuviéramos operando sobre una función matemática. ¿Por qué? porqué hasta hace muy poco me complicaba y terminaba acudiendo a algún trace/log.

I'm a sad panda

Ahora veamos un ejemplo de cómo se puede analizar una función recursiva. Dada la función maxlist del tipo 'a list -> a que retornará el elemento mayor de una lista.

    let rec maxlist = 
        function
        | []    -> failwith "Lista vacia"
        | [x]   -> x
        | x::xs -> max x (maxlist xs)

Siempre que se usa recursividad con listas se puede sacar provecho del pattern matching para escribir código más expresivo. Viendo la función podemos deducir que: Para una lista vacía se lanzará una excepción, para una lista con un elemento regresaremos ese único elemento, y, para una lista con más de un elemento se aplicará la función max para el head de la lista y el resultado de llamar, nuevamente, la función maxlist con el tail de la lista como argumento. Entonces, usando lápiz y papel, podemos resolver la ecuación:

 
maxlist [5;1;3;7]
= max 5 (maxlist [1;3;7])
= max 5 (max 1 (maxlist [3;7]))
= max 5 (max 1 (max 3 (maxlist [7]))) //maxlist de una lista con un elemento retorna dicho elemento
= max 5 (max 1 (max 3 7))
= max 5 (max 1 7)
= max 5 7
= 7

De esta forma, resolviendo las ecuaciones como si fueran funciones matemáticas, podemos resolver las funciones recursivas.

En el siguiente ejemplo usaremos tres funciones: halve que partirá una lista en dos (retornando una tupla con las dos listas). La función mergeordlist que ordenará dos listas cuyos elementos ya estén ordenados dentro de una nueva lista. Y, finalmente, la función msort que usando estas otras dos funciones ordenará los elementos de una lista.

    let halve xs = List.splitAt (List.length xs / 2) xs

    let rec mergeordlists xs ys = 
        match (xs, ys) with
        | ([], ys) -> ys
        | (xs, []) -> xs
        | (x::xs, y::ys) -> 
            if x <= y then x :: mergeordlists xs (y::ys)
            else y :: mergeordlists (x::xs) ys

    let rec msort  =
        function
        | [] -> []
        | [x] -> [x]
        | xs -> 
            let (ys, zs) = halve xs
            mergeordlists (msort ys) (msort zs)

¿Cómo podemos resolver la función msort para un determinado conjunto de datos? ¡Fácil! reemplazando valores y resolviendo las ecuaciones siguiendo el orden de los paréntesis

msort [3;1;5;2]
= halve [3;1;5;2] // ([3;1],[5;2]) primero se resuelve halve
--> mergeordlist (msort [3;1]) (msort [5;2]) // reemplazamos los valores y se llama de nuevo a msort
= halve [3;1] // ([3],[1]) 
--> mergeordlist (mergeordlist (msort [3]) (msort [1])) (msort [5;2])
= mergeordlist (mergeordlist [3] (msort [1])) (msort [5;2]) //llamar a msort con una lista de un elemento devuelve la lista "[3]"
= mergeordlist (mergeordlist [3] [1]) (msort [5;2])
= halve [5;2] // ([5], [2])
--> mergeordlist (mergeordlist [3] [1]) (mergeordlist (msort [5]) (msort [2]))
= mergeordlist (mergeordlist [3] [1]) (mergeordlist [5] (msort [2]))
= mergeordlist (mergeordlist [3] [1]) (mergeordlist [5] [2])
= mergeordlist [1;3] (mergeordlist [5] [2])
= mergeordlist [1;3] [2;5]
= [1;2;3;5]

Entender una función recursiva usando lápiz y papel es como comerse una naranja

Espero les sea de útilidad.

Hasta el próximo post.

[F#] Funciones recursivas a lápiz y papel

[ASP.NET] Simplificando los controladores

Hace unos días Juanma publicó un tweet con un articulo que me resultó interesante. En este se describe como “mejorar” el código de las aplicaciones web escritas en lenguajes orientados a objetos y sobre frameworks MVC usando “técnicas” un poco más cercanas a un paradigma funcional, y describe, además, lo difícil de adaptar el mundo stateless de la programación web (server side) a lo que propone un diseño orientado al dominio.

Me pareció interesante, además, porque en las últimas semanas he estado replanteándo como hago yo este tipo de desarrollos… en un nuevo proyecto. Siempre que puedo trato de cambiar en algo el como escribo y organizo mi código, casi siempre influenciado por lecturas (libros, blogs, twitter), conferencias, y demás, y me han llevado por escribir aplicaciones como lo planteaba el libro negro de la Arquitectura Orientada al Dominio con Tecnologías Microsoft, si, con todo y los cien ensamblados. He escrito aplicaciones con todo el código en los controladores o, en el mejor de los casos, llamando a clases que “encapsulan” estos procedimientos, pero igual, todo muy acoplado. He escrito aplicaciones con modelos de dominio anémicos y un montón de servicios que inyecto en los controladores, con y sin repositorios, etc. Pero ahora quise probar algo que vi en el blog de Bogard, quien propone usar el patrón mediador para escribir aplicaciones que usen un modelo CQS. Incluso creó una librería para resolver los Handlers de las consultas y comandos, con una que otra cosa de más, llamada MediatR, que se integra bien con y sin contenedores de dependencias.

En resumen, lo que se busca con CQS es separar las consultas de las escrituras, para simplificarlo podríamos verlo como los GET y los POST en nuestras aplicaciones, y con la aplicación del patrón mediador es tener una única dependencia en los controladores (el mediador) y que sea este ultimo quien resuelva que hadler hace que.

Para ilustrar mejor esta definición veamos un ejemplo:

    public interface ICommand<out TResult> { }

    public interface ICommandHandler<in TCommand, TResult> where TCommand : ICommand<TResult>
    {
        Task<TResult> HandleAsync(TCommand command);
    }

    public class AddItemCommand : ICommand<AddedItemViewModel>
    {
        public AddItemCommand(Guid itemId, Guid storeId)
        {
            ItemId = itemId;
            StoreId = storeId;
        }

        public Guid ItemId { get; private set; }
        public Guid StoreId { get; private set; }
    }

    public class AddItemHandler : ICommandHandler<AddItemCommand, AddedItemViewModel>
    {
        private readonly IApplicationDbContext _context;

        public AddItemHandler(IApplicationDbContext context)
        {
            _context = context;
        }

        public async Task<AddedItemViewModel> HandleAsync(AddItemCommand command)
        {
            var itemId = command.ItemId;
            var storeId = command.StoreId;
            var store = await _context.Stores.FirstAsync(s => s.Id == strtoreId);

            //Todas las reglas del dominio al dominio.
            var item = store.ShipItem(itemId);
            //...
            
            _context.SaveChanges();
            var resp = new AddedItemViewModel
            {
                Location = item.Location,
                //...
            };
            return resp;
        }
    }

Podemos detenernos aquí y recibir en el constructor del controlador cuantos handlers deseemos y usarlos en los métodos de acción que los requieran, o, si queremos ir más allá, podemos crear un objeto que resuelva y llame al handler adecuado a partir del comando, para esto crearemos un mediador o usamos MediatR. De hecho podemos detenernos en el Command y “encapsular” allí, acoplado o no, toda la funcionalidad de dicho comando y ser felices, todo depende de nuestra aplicación, sus requerimientos, y la facilidad para testear el código que deseemos.

Con esto habré transcrito aquí lo que entendí de la serie de artículos de Bogard, así que iré un poco más allá y voy a discutir algo que vi hace un tiempo en un video del buen Greg Young.

Greg Young afirma que la magia, en el código, es mala. Expone el caso de los dynamic proxy y de cómo nos explicarían eso a los desarrolladores junior, o cómo entendemos la magia de los frameworks que usan en un proyecto cuando recibimos los fuentes. Habla de los contenedores de dependencias y su magia, nos habla de buscar una interfaz común y cambiar nuestro problema con el fin de evitar la magia. Muestra una implementación de comandos y consultas, en lago similar a la que ya vimos… en fin, es un buen video y estoy seguro que algo aprenderás como lo hice yo.

Revisando la implementación anterior

Viendo el código de nuestro command handler vemos que la interfaz común nos indica que habrá un parámetro de entrada y uno de salida con un única acción: procesar el comando. Todo lo que necesitemos para llevar a cabo esta acción lo pasaremos como parámetro al constructor, y el único estado que contendrá esta clase serán dichas dependencias. Si no hay más estado que dichas dependencias y la interfaz común solo expone una acción con una entrada y una salida… ¿no luce esto como una función?

Ya Mark Seemann había escrito sobre el tema, y en español, Juanma también nos compartió sus opiniones.

En este caso me inclino a pensar un poco más funcional, es decir, darle todo lo necesario a la función para que haga su trabajo y no tener un estado que no aporta mucho en el objeto. Así las cosas podríamos olvidarnos de las interfaces y usar solo funciones:

    public class AddItemCommandHandler
    {
        public static Func<AddItemCommand, IApplicationDbContext, IAzure, Task<AddedItemViewModel>> Handle = HandleBody;

        private static Task<AddedItemViewModel> HandleBody(AddItemCommand command, IApplicationDbContext context, IAzure azure)
        {
            throw new NotImplementedException();
        }
    }
    public class RemoveItemCommandHandler
    {
        public static Func<AddItemCommand, IApplicationDbContext, Task<RemovedItemViewModel>> Handle = HandleBody;

        private static Task<RemovedItemViewModel> HandleBody(AddItemCommand command, IApplicationDbContext context)
        {
            throw new NotImplementedException();
        }
    }

El problema de ahora pasar como parámetro todas las dependencias a nuestros métodos es que hemos roto la interfaz común que habíamos logrado. Así que, ¿cómo lo conseguimos?

Aplicación parcial de funciones

La aplicación parcial de funciones es algo muy común en la programación funcional, podemos verla como la función resultante de llamar a una función sin todos sus argumentos. La manera más fácil de entenderlo es mediante un ejemplo:

    Func<int, int, int> Multi = (a, b) => a * b;
    Func<int, int> DosPor = a => Multi(a, 2);
    DosPor(3); // 6 😛

Haciendo uso de la aplicación parcial de funciones podemos pasar los parámetros extra (repositorios, contexto, loggers, helpers) para trabajar con una función que reciba un solo parámetro, el command, y recuperar así nuestra interfaz común.

Ok, ¿y cómo se resuelven los Handlers?

Ya no tenemos interfaces para inyectar y resolver desde el mediador. Pero podemos usar un contenedor de Comandos (un diccionario) para usarlos desde el controlador. ¿No es este un acoplamiento con dicho contenedor que hará más difícil testear mis controladores? te preguntarás, sí, si deseas hacerle test unitarios al controlador lo “mejor” sería sacarle una interfaz a esta dependencia (pero no me gusta hacerle unit testing a los controladores…)

¿Cómo queda este contenedor de comandos?

    public class ApplicationCommands
    {
        private static readonly Dictionary<Type, Func<ICommand, Task<IResult>>> Handlers = new Dictionary<Type, Func<ICommand, Task<IResult>>>();

        public static void Register<T>(Func<T, Task<IResult>> handler) where T : ICommand
        {
            if (!Handlers.ContainsKey(typeof(T))) Handlers.Add(typeof(T), command => handler((T)command));
        }

        public static async Task<IResult> HandleAsync(ICommand command)
        {
            return await Handlers[command.GetType()](command);
        }
    }

La interfaz ICommand la tenemos desde la primera implementación, pero ahora no será genérica y nos servirá de marker interface. Y la interfaz IResult tendrá dos métodos que uso para eso de mostrar mensajes de error y ayuda. La definición de las interfaces es:

    public interface IResult
    {
        void AddHttpInfo(HttpViewModelInfo info);
        IList<HttpViewModelInfo> GetHttpInfo();
    }

    public interface ICommand { }

Ya podremos cargar nuestro contenedor de comandos haciendo algo como:

            ApplicationCommands.Register<AddItemCommand>(
                async command => await AddItemHandler.Handle(command, new ApplicationDbContext(), new AzureManager()));

¿Y cómo se maneja el ciclo de vida de los objetos?

Al manejar un diccionario estático con los comandos no se puede registrar una instancia con ciclo de vida por request, lo que estaría por request es el comando, pero el dispose de, por ejemplo, el DbContext queda fuera de nuestro control. Por lo que no sé si convendría más usar un contenedor por request, es decir, reconstruirlo para cada controlador o actualizar la entrada en el diccionario (agradezco sugerencias en los comentarios) :S

Para verlo más claro vamos a cargar los applications commands para el Web Api:

    public class WebApiCompRoot : IHttpControllerActivator
    {
        public IHttpController Create(
            HttpRequestMessage request,
            HttpControllerDescriptor controllerDescriptor,
            Type controllerType)
        {
            if (controllerType == typeof(ShippingController))
            {
                var context = new ApplicationDbContext();
                var azureContext = new AzureContext();
                ApplicationCommands.Register<AddItemCommand>(async command => await AddItemHandler.Handle(command, context, azureContext));
                request.RegisterForDispose(context); //Ciclo de vida por request
                return new ShippingController();
            }
            return (IHttpController) Activator.CreateInstance(controllerType);
        }
    }

Si ejecutamos así el primer request funcionará perfecto. Pero para los siguientes no se creará un nuevo context y recibiremos la excepción indicando que ya se ha hecho Dispose. Podemos entonces reescribir la entrada en el diccionario en el ApplicationCommands o crear un contenedor por request y pasarlo a cada controlador.

Notas

En esta entrada solo mostré el uso de comando y no de consultas, pero la idea es la misma.

“¿No deben los comandos ser de tipo void (Action)?” eso dicen, pero noté que siempre quiero informar algo y si no es así, siempre puedes crear un IResult Unit, como el de F#

Ese código se ve horrible, ¿por qué no usas mejor un lenguaje funcional? Si, ya me lo han dicho y espero estar hablando sobre el tema pronto.

Espero les sea de utilidad, y si tienen feedback, bienvenido!

Hasta el próximo post.

[ASP.NET] Simplificando los controladores

[F#] Composición de funciones y conversión eta

Las funciones en F# tiene asociatividad de izquierda a derecha, esto es, dada la función:

let f g h i = g h i

Será lo mismo que (g h) i. Aplicando parcialmente g h y pasando i como argumento a la función resultante.

Teniendo presente el concepto de asociatividad de funciones, entonces ¿qué es la composición de funciones? en matemáticas Wikipedia dice:

Dadas dos funciones, bajo ciertas condiciones podemos usar los valores de salida de una de ellas como valores de entrada para la otra., creando una nueva función.

Lo que sería, aplicar una función al resultado de otra -> f(x) -> g(x) ->. Lo podemos representar de la forma (g ∘ f)(x) = g(f(x)).

Haciendo el ejercicio en álgebra, podríamos ver algo como lo siguiente.

Dadas las funciones:
f(x) = 2x²+3x
g(x) = 5x-2

(f ∘ g)(x) = f(g(x))
(f ∘ g)(x) = f(5x-2) = 2(5x-2)² + 3(5x-2)

Para verlo más claro en el código veamos un ejemplo. Dadas las funciones:

not //(bool -> bool) 
esPar //(int -> bool)

Crear una función esImpar (int -> bool)

Un primer enfoque podría ser:

let esImpar x = not(esPar(x))

Nótese que haciendo uso de los paréntesis estamos cambiando la asociatividad y hacemos explicito que se avalúe primero la función esPar.

Con esto se ve ya un poco más claro, y menos difícil de entender el f(g(x)). Con lo que podríamos entonces escribir una función que nos ayude con dicha composición, algo como:

let compoc f g x = f(g(x))

compoc tendrá la firma f:('a -> 'b) -> g:('c -> 'a) -> x:'c -> 'b

Podríamos usarla así:

let esImpar x = compoc not esPar x

Y podríamos simplificarlo un poco más haciendo uso de la conversión eta (η-conversión), que, en resumen y como entiendo su aplicación: si el último argumento está en los dos lados de la expresión podemos removerlo. En nuestro caso, en la expresión esImpar x = compoc not esPar x. El último y único argumento es x, y aparece en los dos lados de la expresión, por lo que sería lo mismo escribir:

let esImpar = compoc not esPar

Teniendo claro que F# es un lenguaje “functional first” era de esperarse que exista ya un operador para la composición de funciones, así como en Haskell tenemos el “.“, en F# tenemos el >> (forward composition operator).

La definición de este operador es:

let (>>) f g x = g(f x)

Qué es muy similar a lo que teníamos, dadas dos funciones f y g calculamos f(x) y pasamos su resultado a g.

Haciendo uso de este operador podemos reescribir nuestra función así:

let esImpar = esPar >> not

¿Qué pasa si las funciones tienen más parámetros? Podemos usar este operador sin problema y dado que su prioridad es más baja que las otras funciones no debemos preocuparnos por agruparlas con paréntesis, a diferencia de nuestra primera implementación. De esta forma conseguimos código más conciso.

Espero les sea de utilidad.
hasta el próximo post.

[F#] Composición de funciones y conversión eta

Cómo usar el custom authentication de Azure Mobile Services .NET back-end

Trabajando con ZUMO .NET back-end tuve la necesidad de implementar una autenticación personalizada, es decir, que no sea con proveedores de terceros sino con usuarios y contraseñas que están en x base de datos. Afortunadamente para mi, Microsoft tiene esta documentación, así que no me esforzaré en reescribir lo que allí se explica. Lo que allí no comentan es el lío que hay con las versiones de los paquetes, cómo usar el token desde un cliente ni cómo obtenerla identidad del usuario en el lado del servidor.

TL;DR;

No actualicen la versión del System.IdentityModel.Tokens.Jwt Usar el header “X-ZUMO-AUTH” para pasar el token al servicio.

Líos con las versiones de los paquetes

Una vez creado el proyecto lo primero que hice fue actualizar los paquetes, hace falta agregar unos cuantos assembly binding redirects y cuando todos ya están listos falla con pantalla amarilla y  el error:

Method not found: 'Void System.IdentityModel.Tokens.JwtSecurityTokenHandler.set_CertificateValidator(System.IdentityModel.Selectors.X509CertificateValidator)'. 

Si ya la has cagado como yo, la solución esta en ejecutar dos comandos en el Package Manager Console:

> uninstall-package System.IdentityModel.Tokens.Jwt -Version 3.0.2 -Force
> uninstall-package System.IdentityModel.Tokens.Jwt -Version 4.0.1 -Force
> install-package System.IdentityModel.Tokens.Jwt -Version 3.0.2

En los comentarios de la entrada en inglés dicen que aparentemente la autenticación no se realiza por culpa de la versión de este paquete, pero en lo que probé parece que solo es lío de usar la cabecera correcta.

Cabecera de autenticación

Después de leer algo de la documentación no encontré nada que dijera algo sobre la cabecera X-ZUMO-AUTH y al hacer la búsqueda parece que no hay documentación oficial (Si encuentran algo no duden es comentarlo). La encontré después de leer algunos blogs. En fin, para poder usar el token de autenticación  hay que pasar la cabecera X-ZUMO-AUTH y no el Authorization. El token lo recuperamos haciendo un request a /customlogin/ y este será pasado a las acciones que requieran autenticación.   image   image   image

Obtener el usuario en el back-end

Aunque WAMS es una envoltura al rededor de ASP.NET WEB API y otros servicios, ciertamente hay cosas que cambian y aún no entiendo muy bien, cómo por qué cambia el Type del claim que guarda la identidad del usuario. Basta con hacer algo de debug para encontrarlo y recuperarlo de la forma:

    [AuthorizeLevel(AuthorizationLevel.User)]
    public class HelloController : ApiController
    {
        public IHttpActionResult Get()
        {
            var user = ClaimsPrincipal.Current.FindFirst(claim => claim.Type == "uid").Value;
            if (user.Contains(":")) user = user.Split(':')[1];
            return Ok("Hello! " + user);
        }
    }

Conectando con JavaScript

El proyecto en el que estoy trabajando en este momento requiere que desde un sitio web se invoquen ciertas acciones expuestas en el servicio móvil. Lo que nos pone ahora la tarea de solucionar el lío del cors. Por fortuna para nosotros desde la actualización 1.0.342 se usa  ASP.NET WEB API 2, y entre sus características está el trabajo con CORS, pero por supuesto, encapsuladas. Para usarla solo basta con agregar un nuevo appSetting en el web.config:

 
<add key="MS_CrossDomainOrigins" value="http://mysite.com" />

Con esto ya podemos llamar desde el cliente js:

 
        $.ajax({
            type: 'POST',
            contentType : "application/json",
            url: 'http://localhost:54085/api/customlogin',
            data: JSON.stringify(userModel)
        }).done(function (data) {
            sessionStorage.setItem('supertoken', data.authenticationToken);
            AppViewModels.assignVM.initView();
        }).fail(function() {
            alert("Usuario o contraseña invalidos");
        });

El código del ejemplo esta aquí

Espero les sea de utilidad.

Hasta el próximo post.

Cómo usar el custom authentication de Azure Mobile Services .NET back-end

[AutoMapper] Convertir de Utc a determinada zona horaria

Dado un modelo como el siguiente:

public class User
{
	//Otras propiedades...
	public string TimeZoneId { get; set; }		
}

public class UserAction
{
	//Otras propiedades...
	public DateTime DateInUtc { get; set; }
}

Al registrar una acción del usuario registraremos la fecha en utc, pero a la hora de recuperarla y mostrarla al usuario, esta deberá ser de nuevo convertida, de Utc a la zona horaria del usuario. Si recuperamos una colección de acciones del usuario sería necesario crear una colección del ViewModel y en un bucle construir las fechas:

var timeZoneId = GetTimeZoneId();
var timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById(timeZoneId);
var userActions = GetUserActions();
var viewModel = new List<UserActionViewModel>();
foreach(var userAction in userActions)
{
	viewModel.Add(new UserActionViewModel()
		{
			ValidDate = TimeZoneInfo.ConvertTimeFromUtc(userAction.DateInUtc, timeZoneInfo)
		});
}

Podemos extraer el código y reutilizarlo para construir los ViewModels que necesitemos y hagan uso de las fechas y las zonas horarias. Pero si ya hemos incluido AutoMapper como una dependencia más de nuestro proyecto… ¿cómo lo podemos hacer?

IMappingOperationOptions y ValueResolver

AutoMapper ofrece la opción de “pasar información” al custom map haciendo uso de la segunda sobrecarga del método Map. Algo de la forma:

var timeZoneId = GetTimeZoneId();
var viewModel = Mapper.Map<UserActionViewModel>(userAction, opts=>opts.Items.Add("timezone", timeZoneId));

Y ahora ¿Cómo recuperamos dicho valor en el custom map?. Debemos convertir de alguna forma el valor de origen y recuperar el TimeZoneId. Para esto haremos uso de un ValueResolver, pues nos ofrece la posibilidad de acceder al contexto. Algo de la forma:

        class LocalizedDateTimeResolver : IValueResolver
        {
            public ResolutionResult Resolve(ResolutionResult source)
            {
                var timeZoneId = source.Context.Options.Items["timezone"].ToString();
                var utc = (DateTime)source.Value;
                var timezoneInfo = TimeZoneInfo.FindSystemTimeZoneById(timeZoneId);
                var dateTime = TimeZoneInfo.ConvertTimeFromUtc(utc, timezoneInfo);
                return source.New(dateTime);
            }
        }

Con esto, en el custom map podemos usar el método ResolveUsing, de la forma:

            Mapper.CreateMap<UserAction, UserActionViewModel>()
                .ForMember(des => des.ValidDate,
                    opts => opts.ResolveUsing<LocalizedDateTimeResolver>().FromMember(src => src.DateInUtc));

Espero les sea de utilidad. Hasta el próximo  post.

[AutoMapper] Convertir de Utc a determinada zona horaria