netstandard–El “estándar” que viene

Cuando .NET salió, las cosas eran muy sencillas: había una sola versión de .NET, el .NET Framework, así que como mucho debíamos saber para que versión de .NET era una determinada librería. “Oh, la librería es solo para .NET 2.0 y yo uso .NET 1.1, que mala suerte”. Al margen de eso no había mucho más, todos teníamos claro que significaba .NET.

Continúa leyendo netstandard–El “estándar” que viene

Creando formateadores de salida en asp.net core

Cuando salió WebApi lo hizo con la negociación de contenido incorporada de serie en el framework. Eso venía a significar, básicamente, que el framework intentaba suministrar los datos en el formato en que el cliente los había pedido. La negociación de contenido se basa (generalmente) en el uso de la cabecera accept de HTTP: el cliente manda en esa cabecera cual, o cuales, son sus formatos de respuesta preferidos. WebApi soporta de serie devolver datos en JSON y XML y el sistema es extensible para crear nuestros propios formatos.

“MVC clásico” (es decir hasta MVC5) no incluye soporte de negociación de contenido: en MVC si queremos devolver datos en formato JSON, debemos devolver explícitamente un JsonResult y si los queremos devolver en XML debemos hacerlo también explícitamente.

En ASP.NET Core tenemos a MVC6 que unifica a WebApi y MVC clásico en un solo framework. ¿Como queda el soporte para negociación de contenido en MVC6? Pues bien, existe soporte para ella, pero dependiendo de que IActionResult devolvamos en nuestros controladores. Así, si en WebApi la negociación de contenido se usaba siempre y en MVC clásico nunca, en MVC6 la negociación de contenido aplica solo si la acción del controlador devuelve un ObjectResult (o derivado). Esto nos permite como desarrolladores decidir sobre qué acciones de qué controladores queremos aplicar la negociación de contenido. Es evidente que aplicarla siempre no tiene sentido: si devolvemos una vista Razor su resultado debe ser sí o sí un HTML que se envía al cliente. No tendría sentido aplicar negociación de contenido sobre una acción que devolviese una vista. De hecho la negociación de contenido tiene sentido en APIs que devuelvan datos (no vistas) y en MVC6 para devolver datos tenemos a ObjectResult, así que es lógico que sea sobre este resultado donde se aplique la negociación de contenido.

En WebApi la negociación de contenido estaba gestionada por los formateadores (formatters). Básicamente a cada content-type se le asociaba un formateador. Si el cliente pedía datos en un determinado content-type se miraba que formateador podía devolver datos en dicho formato. Si no existía se usaba por defecto el formateador de JSON. En MVC6 se ha mantenido básicamente dicho esquema.

Continúa leyendo Creando formateadores de salida en asp.net core

Middlewares de autenticación en asp.net core

La autenticación y autorización de peticiones es una de las funcionalidades que más quebraderos da en el desarrollo de aplicaciones en ASP.NET. Además es que ha ido cambiando con el tiempo… En un escenario de internet, en ASP.NET clásico, ya fuese Webforms o MVC usábamos FormsAuthentication. Por otra parte cuando apareció WebApi, incorporó sus propios mecanismos de autenticación y autorización, generalmente basados en la implementación de MessageHandlers.

Continúa leyendo Middlewares de autenticación en asp.net core

Autenticación por AAD en ASP.NET Core

Este es un post introductorio, de una serie de posts, donde veremos como podemos integrar ASP.NET Core y Azure Active Directory (AAD). En este primer escenario el objetivo es tener una aplicación web, donde se requiera hacer login contra AAD para autenticarse.

Nota: El post está basado en la RC1 de ASP.NET Core… Lo digo porque bueno, a saber que romperán mejorarán en futuras versiones, pues igual algo cambia :)

Continúa leyendo Autenticación por AAD en ASP.NET Core

WebApi–¿objeto o HttpResonseMessage?

El otro día hablando con Carlos (aka @3lcarry) surgió el tema de como devolver datos en una WebApi. En WebApi tenemos hasta tres maneras generales de devolver unos datos desde una acción de un controlador. Devolver un objeto, devolver un HttpResponseMessage o devolver un IHttpActionResult. (Una discusión equivalente aparece en MVC6 donde tenemos dos alternativas, devolver un objeto o bien un IActionResult.) ¿Cuál es la mejor?

Continúa leyendo WebApi–¿objeto o HttpResonseMessage?

Creating middlewares de asp.net core

Asp.net core se basa en el concepto de middleware. En este modelo la petición web viaja a través de un conjunto de componentes. Cada componente recibe la petición y puede:

  1. Modificar la petición y enviarla al siguiente componente
  2. O bien, generar una respuesta y enviarla de vuelta al componente anterior.

Continúa leyendo Creating middlewares de asp.net core

Routers en asp.net core

Cuando hablamos del routing solemos referirnos al proceso por el cual una petición es enrutada hacia una acción concreta de un controlador. Esa definición es cierta en el contexto de una aplicación ASP.NET MVC (y/o WebApi) pero en ASP.NET Core, el concepto de routing es una parte integral del framework.

Por ello, en ASP.NET Core entendemos el routing como el proceso mediante el cual una petición web es enrutada hacia donde tenga que ser tratada. El destino puede ser una acción de un controlador, pero no tiene por qué (el middleware de MVC6 podría no estar instalado en el pipeline de la aplicación). En este post vamos a ver como funciona este proceso de enrutado.

Continúa leyendo Routers en asp.net core

Nuevo blog: eiximenis.github.io

Actualizado (17/2/2016): Antes me quejo, antes actualizan geeks.ms 😛 Después de la actualización uno de los motivos para salirme de geeks.ms ha desaparecido. Después de meditarlo he decidido que todo lo que sea de .NET y JS lo iré dejando en geeks.ms. En mi otro blog colocaré todo aquello que no tenga que ver con esas tecnologías y con las que estoy trasteando ahora mismo y que me apetezca escribir. Son posts que considero, por mi propia opinión personal, que su sitio “natural” no es geeks.ms y estos los hospedaré en Git Hub Pages. El resto seguirá por aquí. :)

El mundo ha cambiado. Lo siento en el agua, lo siento en la tierra, lo huelo en el aire.

Sirvan esas palabras de Fangorn para decir que abro un nuevo blog, alojado en GitHub pages, que podeis encontrar en eiximenis.github.io. Llevaba ya bastante tiempo meditando un cambio y al final, después de hablar con Álex Casquete, me he decantado por usar Jekyll y hospedar el blog en GitHub pages.

¿Por qué el cambio?

Hace ya casi ocho años que abrí el blog en geeks.ms y la verdad es que muchas cosas han cambiado en este tiempo. Por un lado, la propia plataforma de geeks se queda un poco corta, en especial los templates para móvil son bastante malos. Hace años era un mal menor, ahora es importante, cada vez se consumen más y más blogs desde móviles. Es importante para mí que mi blog se vea bien en dispositivos móviles, y eso con geeks era complicado. Y no hay que negar que al community server se le notan los años y algunas tareas eran complicadas o tediosas… y suerte de Live Writer, porque si no, ¡si que hubiese sido infernal!

No es tampoco la única razón: en todo esto tiempo he intentado mantener este blog centrado en .NET y el desarrollo web (las tecnologías que más uso en mi día a día). Pero desarrollo en muchas otras tecnologías, quizá no a nivel profesional, pero también me apetece contar cosas sobre esas otras tecnologías que poco o nada tienen que ver con .NET o con Microsoft. Tengo la sensación que este blog no es el lugar apropiado (aunque nunca nadie me ha dicho que puedo o no puedo publicar en geeks).

La verdad es que el cambio siempre me ha dado mucha pereza… pero ahora creo que es el momento.

¿Eso significa que este blog en geeks muere?

No, lo que se llama morir no. Cuando publique un post que tenga que ver con .NET en mi nuevo blog, publicaré aquí un resúmen con el enlace completo al blog nuevo. No haré crossposting al uso, primero porque no me gusta y segundo porque no sé como hacerlo desde Jekyll. Así que cuando publique algo que vea que tiene sentido que también esté aquí, publicaré aquí un pequeño resúmen y pondré el enlace al post completo en mi blog.

Pero al margen de eso no habrán nuevas actualizaciones en este blog.

¿Por qué Jekyll?

Realmente Jekyll no es un sistema de blogs tradicional, como puedan ser blogger, el community server que hospeda geeks o el más famoso wordpress. Jekyll es un generador de sitios estáticos: toma unas plantillas que tienen una sintaxis específica (parecida a mustache, que ellos llaman “Liquid templates”), procesa todas esas plantillas y genera ficheros .html planos. Luego esos ficheros puedes servirlos con cualquier servidor web estático.

La idea es muy simple y es una maravilla.

Primero porque los posts pasan a ser código. En el caso de jekyll los posts se suelen codificar en markdown (aunque puedes usar directamente html) y luego mediante una plantilla se convierte a html y se le pone el layout. Jekyll genera resúmenes, paginadores, tags ¡e incluso un feed! Pero no hay base de datos alguna, no hay un sistema CMS por debajo, ni nada parecido.

A pesar de no haber base de datos, es posible dar soporte a comentarios gracias a Disqus, o sea que el tema de los comentarios también está solucionado 😉

Y luego está la integración con GitHub Pages. Jekyll es el motor que hay debajo de GitHub Pages, por lo que eso significa que si hospedas tu blog allí, no subes los contenidos estáticos que te genera Jekyll, si no que subes las plantillas y GitHub las ejecuta y actualiza tu GitHub pages con el resultado de ejecutar Jekyll. Eso tiene la ventaja de que tu blog pasa a ser un repositorio de GitHub: si tienes que editar un post, simplemente editas el markdown asociado, haces push y automáticamente GitHub hace el resto. El inconveniente es que debes ceñirte al entorno que tengan en GitHub pages: hay ciertos plugins de Jekyll que no puedes usar y cosas similares. Nada es perfecto :)

¿Qué habrá en el nuevo blog?
Pues básicamente lo mismo que en este, pero hablando de más cosas, no solo de .NET. Pero va a haber lo mismo: artículos técnicos, algún artículo de opinión de vez en cuando y todo aquello que me apetezca hablar.

¡O sea que nada más! Si me has estado siguiendo todo este tiempo en geeks.ms, ya sabes donde encontrarme ahora.

¡Nos seguimos leyendo!

Como depurar fácilmente el código de ASP.NET5

¡Muy buenas! Para los que andamos trasteando con versiones alfas y betas con nula o poca documentación, poder depurar el código fuente de las librerías es una manera muy buena de ver qué hace y como lo hace. Cierto, solo leyendo el código fuente se puede aprender mucho, pero poder depurarlo paso a paso es todavía más útil.

El primer paso es, por supuesto, disponer del código fuente. En según que librerías eso no es posible, aunque siempre se podía tirar de los desensambladores (por más que eso pueda no ser legal). El problema de usar los desensambladores es que el código fuente obtenido no siempre es muy legible y que por otro lado no puedes depurarlo a no ser que tu desensemblador soporte la creación de PDBs.

Depurar ASP.NET MVC nunca ha sido un problema importante, en tanto el código fuente estaba disponible. Podías descargarte el código fuente de ASP.NET MVC, compilarlo en alguna carpeta local, pongamos c:mvc, junto con sus PDBs. Luego tenías que modificar tu proyecto web, quitar las referencias a ASP.NET MVC reales y sustituirlas por las versiones locales con PDBs. Con eso, podías depurar ASP.NET MVC sin muchos problemas. Pero era un poco peñazo el tener que sustituir las referencias reales por las tuyas compiladas, lo que podía redundar en algún cambio adicional de configuración (por estar firmadas las reales y no estarlos, o estarlo con otra clave, las locales).

En ASP.NET5 el proceso se ha vuelto ridículamente simple. El proceso es como sigue:

  1. Clona los repositorios de ASP.NET5 que quieras. P. ej. yo he clonado algunos de ellos en la carpeta c:tfsaspnet5.
  2. Crea un proyecto web con VS2015 que use ASP.NET5. O abre un proyecto existente, eso es lo de menos.
  3. Abre el fichero global.json que está en Solution Items

Este fichero contiene en “projects”, la lista de carpetas en las que VS2015 sabe que hay código que debe incorporar como parte de tu proyecto (por defecto las carpetas src y test). Añade la carpeta base en la cual has clonado los repos de aspnet5 que quieras depurar:

  1. {
  2.   "projects": [ "src", "test", "c:/tfs/aspnet5/mvc/src" ],
  3.   "sdk": {
  4.     "version": "1.0.0-beta8"
  5.   }
  6. }

En mi caso en c:tfsaspnet5mvc he clonado el repo de ASP.NET MVC6 así lo añado en projects (debo añadir el /src final que es donde hay los proyectos). Eso automáticamente me añade los proyectos de ASP.NET MVC6 a mi solución:

image

Además en el solution explorer VS2015 nos indica, con un icono distinto, qué referencias ha cargado en local:

image

Ahora puedes navegar por el código fuente y colocar breakpoints sin ningún problema… ejecutar tu aplicación y ¡depurar!

image

Eso sí, la clave para que te funcione es que tengas los repos sincronizados con la versión que estás usando. P. ej. si en el project.json estás referenciando la versión 1.0.0-beta8 debes tener los repos con el código fuente que se corresponda a dicha versión (todas las versiones tienen un tag de Git asociado, así que puedes obtener la que quieras). También que estés usando el entorno de ejecución correspondiente (no te funcionará si intentas depurar beta8 usando el dnx de beta5).

Observa que no es necesario cambio alguno en nuestro proyecto. Cuando hayas depurado, basta con que elimines del global.json el directorio con los fuentes y tu aplicación pasará a referenciar los paquetes NuGet oficiales.

Más fácil, ¡imposible!

Saludos!

PD: Antes de que me deis las gracias, se las dáis a Hugo Biarge (@hbiarge) que fue quien me lo contó. En este post hay más info (un poco desactualizada, ojo): http://blogs.msdn.com/b/webdev/archive/2015/02/06/debugging-asp-net-5-framework-code-using-visual-studio-2015.aspx

Variables privadas en clases ES2015

Una de las novedades de ES6 es la posibilidad de usar clases. Si bien esas clases son realmente sugar syntax sobre el patrón de función constructora, tienen alguna característica que simplifica el uso de dicho patrón y ofrecen una sintaxis que según como se mire puede ser más cómoda. Pero el estándard de ES2015 no tiene ningún mecanismo para indicar que una variable de una clase sea pública o privada. La visibilidad de variables en JavaScript es un clásico, sobre el que ya he escrito algún post. Pero las técnicas que usábamos hasta ahora para simular la visibilidad privada no aplican cuando usamos la sintaxis de clases… y debemos usar mecanismos alternativos. En este post veremos dos de ellos.

Supongamos que tenemos una clase ES2015 como la siguiente:

  1. class Foo {
  2.     constructor(name) {
  3.         this._name = name;
  4.     }
  5.  
  6.     get name() {
  7.         return _name;
  8.     }
  9. }

El objetivo es que _name sea privado y solo pueda accederse a su valor a través de la propiedad name.

Símbolos al rescate

La primera solución implica el uso de un nuevo concepto de ES2015: los símbolos. Un símbolo permite definir un nombre único desconocido y que tan solo puede ser obtenido a partir de la referencia al símbolo original que ha creado dicho nombre.  El siguiente código explica el uso de símbolos:

  1. var sfoo = Symbol("foo");
  2. var a = {};
  3. a[sfoo] = "sfoo";
  4. console.log(a.sfoo); // undefined
  5. console.log(a[sfoo]);   // sfoo
  6. console.log(a[Symbol("foo")])    // undefined

Podemos asignar una propiedad de un objeto a un símbolo, y entonces requerimos del símbolo para poder obtener el valor de la propiedad. Observa que necesitamos el símbolo original (almacenado en sfoo), crear otro símbolo a partir de la misma cadena, no sirve. Los símbolos son únicos.

Por lo tanto ahora podemos simular variables privadas de la siguiente manera:

  1. const s_name = Symbol("name");
  2. export default class Foo {
  3.     constructor(name) {
  4.         this[s_name] = name;
  5.     }
  6.     get name() {
  7.         return this[s_name];
  8.     }
  9. }

Los objetos de la clase Foo tienen una variable cuyo nombre es el símbolo guardado en s_name. Esa variable “no es realmente pública”, pero no hay manera de encontrar su nombre fuera del módulo que declara la clase (la variable s_name que contiene el símbolo, es privada del módulo por lo que no es accesible desde el exterior). Observa que no basta que alguien mire el código fuente del módulo y se cree otro Symbol(“name”) para acceder a la variable “privada”: los símbolos son únicos, o lo que es lo mismo: Symbol("a") != Symbol("a").

Este método no genera variables totalmente privadas. Las variables que están almacenadas en una propiedad cuyo nombre es un símbolo, no se listan en Object.getOwnPropertyNames y tampoco participan de la iteración de for..in pero se pueden obtener todos los símbolos asociados a un objeto mediante Object.getOwnPropertySymbols, que devuelve un array con todos los símbolos usados como nombre de propiedad del objeto. Basta con usar los símbolos devueltos para acceder a las variables “privadas”.

Por lo tanto este sistema, vendría a equivaler a la visibilidad private de C# para entendernos: Por defecto es imposible acceder a la propiedad, pero tenemos un mecanismo (en C# es Reflection) que nos permite saltarnos esa protección y acceder al contenido de la variable “privada”.

Weak maps

El uso de weak maps nos permite tener variables completamente privadas. Para ello usamos el nuevo tipo WeakMap de ES2015, que básicamente es un diccionario clave, valor, pero es especial porque no impide al GC de JavaScript recolectar todos aquellos valores almacenados en el weak map, siempre y cuando la referencia a la clave que tenga el weak map sea la única restante. Es decir, a todos los efectos el weak map no cuenta para el GC: aunque un objeto esté almacenado en él, si la clave usada no está referenciado por ningún otro objeto, el GC lo podrá eliminar.

El código usando WeakMap es el siguiente:

  1. const privates = new WeakMap();
  2. export default class Foo {
  3.     constructor(name) {
  4.         privates.set(this, {name: name});
  5.     }
  6.     get name() {
  7.         return privates.get(this).name;
  8.     }
  9. }

La idea es muy sencilla: por cada objeto que se cree de Foo, se almacena un valor en el WeakMap privates. La clave de dicho valor es this, que es el propio objeto Foo que se crea. Este objeto (privates.get(this)) almacena todo el estado “privado” del objeto Foo en cuestión. Gracias al hecho de que privates es un WeakMap no hay memory leak: Cuando el objeto Foo deje de usarse podrá ser eliminado por el garbage collector, aunque esté referenciado por el WeakMap como una de las claves usadas (precisamente por ser un privates Weak Map).

La clave (nunca mejor dicho :P) del asunto está en usar this como clave del Weak Map privates.

Al igual que en el caso del símbolo, el Weak Map es una variable privada del módulo, por lo que no se puede acceder a fuera desde él. Y a diferencia del caso del símbolo, ahora si que no hay nada que nadie pueda hacer para acceder a la variable privada que almacena el valor del nombre.

Saludos!