Archivo de la etiqueta: mvc

Materiales del evento: “Tres Tecnologías Microsoft que no se dan durante la carrera”

El pasado viernes a la hora de comer pasé una hora con los chicos de UAM.net en la Escuela Politécnica Superior de la UAM hablando sobre las tres tecnologías Microsoft que, a mi entender, no se impartían en la carrera cuando yo era estudiante.

IMG_8990

Concretamente, en esta charla estuvimos hablando de:

  • Windows Phone, Windows 8 y el resto de las plataformas móviles
  • ASP.net MVC, Web API, verbos HTTP, APIs REST y otros lenguajes como Ruby o PHP
  • Características disponibles en Azure y qué otros proveedores nos podemos encontrar en el mercado

El vídeo

Como novedad, esta vez hemos grabado la charla y está disponible en Youtube:

Las slides

Las slides, como siempre, están disponibles a continuación:

El código

El código de los ejemplos utilizados, y que en el caso de la web es el que se despliega directamente a Azure Websites está disponible también en un repositorio de Github: 201501-demo-uam

Finalmente, los enlaces recomendados que estaban al final de la presentación los dejo aquí:

Preparar la charla ha sido un reto muy interesante, ya que era la primera vez que volvía a dar una charla en la escuela después de haber terminado la carrera, así que espero que a los asistentes (y los que la hayáis visto en diferido) os haya gustado.

Desde aquí mi agradecimiento a la organización por la posibilidad de volver a la EPS y la enhorabuena por conseguir mantener a la gente interesada en las tecnologías .NET. Nos vemos en el próximo evento!

Anuncios

Vídeo y materiales del evento: ASP.NET vNext: qué cambia y cómo nos afecta

Siguiendo la lína de Lo que viene con C# 6 nos juntamos nuevamente varios desarrolladores para compartir y debatir sobre las novedades de la última versión de ASP.NET vNext, que ya podemos denominar ASP.NET 6. En esta ocasión repetían Juan Quijano (@jc_quijano), Eduard Tomás (@eiximenis) y se sumaba a la conversación Luis Ruiz Pavón (@luisruizpavon). Se sumaba a nosotros como patrocinador, una vez más, SyncFusion, ofreciendo una licencia de Essential Studio para ASP.NET

Durante un par de horas estuvimos viendo algunas novedades de la herramienta, como son los diferentes CLR que tenemos a nuestra disposición y sus diferencias, la carga de dependencias a través de nuget, la configuración bajo demanda a través de ficheros JSON, la inyección de dependencias de serie, las nuevas maneras de routing, así como los ViewComponents y el nuevo Special K con los comandos multiplataforma, entre otras tantas cosas que darán de qué hablar en los próximos meses en cuanto a desarrollo de aplicaciones web en .NET.

Vídeo

El vídeo del evento está disponible en Youtube:

Slides

Las slides usadas están también disponibles, en este caso en SlideShare:

Numeritos

Como hice anteriormente, me gustaría compartir con vosotros algunas estadísticas del evento:

4 +1s en la página del evento
28 asistentes de máxima
46 personas han visto el evento, de acuerdo con su estatus en la página de Google Plus.
88 tweets (incluyendo retweets) con el hashtag #vienecsharp6, “oficial” del evento, de acuerdo con las estadísticas de Topsy
79 visitas a la página del evento, de acuerdo con las estadísticas de Karmacracy.
59 visualizaciones del vídeo en Youtube en este momento.

Enlaces

Además, os dejo algunos enlaces vistos durante el evento y usados para prepararlo:

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

Probando módulos de NancyFx

En el artículo anterior de la serie de NancyFx hablábamos de diferentes tipos de respuesta así como el uso de plantillas en la plataforma. En este artículo veremos cómo crear pruebas unitarias para asegurarnos que nuestros módulos funcionan correctamente.

Creando nuestro primer test

Desde la documentación de Nancy se recomienda usar un proyecto diferente (es decir, un ensamblado diferente) para nuestros tests, ya que los módulos se descubren de manera automática por el “bootstrapper”. Una vez creado nuestro proyecto, necesitamos agregar las siguientes referencias, via nuget o de manera manual:

  • NUnit (o XUnit, o el framework que deseemos)
  • Nancy
  • Nancy.Testing

Una vez tenemos las referencias, podemos crear nuestro primer test (que tiene el original nombre de RoutesTest.cs). Dicho test estará dividido en tres partes:

  • Arrange: Toda la preparación necesaria para poder llevar a cabo el test
  • Act: La ejecución de nuestro test
  • Assert: La fase de comprobación de los resultados
[Test ()]
public void TestPut ()
{
        //Arrange
	var bootstrapper = new DefaultNancyBootstrapper();
	var browser = new Browser(bootstrapper);

        //Act
	var result = browser.Put("/routes", with => {
		with.HttpRequest();
	});

        //Assert
	Assert.AreEqual (HttpStatusCode.OK, result.StatusCode);
	Assert.AreEqual ("Response with Put\n", result.Body.AsString());
}

Qué hace el test?

  • Arrange: Para este test el primer paso es crear nuestro Bootstrapper que descubrirá los módulos existentes, seguido de un Browser con el que simularemos las llamadas a nuestros módulos.

  • Act: Una vez tenemos el browser, el siguiente paso es generar la peticion, en este caso Put, a una ruta especificada.

  • Assert: Con el resultado de la ejecución, comprobamos el estado de la respuesta (en este caso 200 OK) y que el texto corresponda con lo que necesitamos, que es “Response with Put\n”.

Una vez tenemos las referencias, recordemos qué contenía el módulo que queríamos probar:

public class Routes : NancyModule
{
	public Routes ()
	{
		Get["/routes"] = _ => "Response with GET\n";
		Post["/routes"] = _ => "Response with POST\n";
		Put["/routes"] = _ => "Response with Put\n";
                ...
	}
}

Podemos identificar claramente una línea donde el verbo PUT devuelve “Response with Put\n”, con lo cual nuestro test es correcto

Probando una ruta errónea

Al igual que podemos probar rutas correctas, los test son igual de válidos para comprobar que el acceso a una ruta no autorizada o no implementada se controla correctamente, como sucede a continuación:

[Test ()]
public void TestNotFound ()
{
	//Arrange
	var bootstrapper = new DefaultNancyBootstrapper();
	var browser = new Browser(bootstrapper);

	//Act
	var result = browser.Delete("/routes", with => {
		with.HttpRequest();
	});

	//Assert
	Assert.AreEqual (HttpStatusCode.MethodNotAllowed, result.StatusCode);
}

En este caso, la ruta no está implementada, con lo cual el resultado será un error de tipo “Method Not Allowed”.

Conclusiones

Con pocas líneas de código podemos comenzar a probar nuestros módulos de NancyFx, podemos probar la respuesta de los mismos, así como códigos de error. El sistema de test permite, adicionalmente, pasar parámetros (simulando el uso de un formulario) o navegar a través del DOM del HTML devuelto, si usamos un ViewEngine.

Sinatra, un framework web para Ruby

sinatra logo

Ruby es un lenguaje de programación que se ha hecho tremendamente conocido (de hecho es el lenguaje más usado en los repositorios de GitHub en estos momentos), Es un lenguaje dinámico y orientado a objetos que es sencillo de aprender. Además, posee diversos frameworks que lo convierte en un lenguaje potente para desarrollar aplicaciones web.

Uno de estos frameworks toma el nombre del célebre artista Frank Sinatra. Se usa en la actualidad por empresas como la BBC o la propia GitHub. Es tremendamente potente y bastante más sencillo que Ruby On Rails, más conocido y complejo. En este artículo veremos una brevísima introducción a qué es trabajar con Sinatra.

Instalación

Lo primero que necesitamos es una instalación de Ruby, para lo cual tenemos varios enlaces en su página oficial dependiendo de nuestro sistema operativo. Una vez instalado ruby podremos agregar nuevos paquetes usando RubyGems, y deberemos ejecutar el siguiente comando desde nuestra consola:

$ gem install sinatra

Descifrando el Hola Mundo

El hola mundo que nos ofrece el framework es muy sencillo, y es lo que podemos encontrar en la página principal. Acudimos a una carpeta cualquiera de nuestro sistema, y creamos un fichero llamado hi.rb:

require 'sinatra'

get '/hi' do
  "Hello World!"
end

Para ejecutar esta aplicación solamente tendremos que escribir el siguiente comando en nuestra terminal:

$ ruby -rubygems hi.rb
== Sinatra has taken the stage ...
>> Listening on 0.0.0.0:4567

A continuación se cargará el servidor de desarrollo de ruby, y solamente tendremos que acudir a localhost:4567 y ver nuestra página en funcionamiento.

El primer valor que se muestra es el comando HTTP al que responde (si recordamos este artículo los diferentes comandos HTTP son get, post, put, delete… ) con lo cual podemos hacer que nuestra aplicación responda a una petición en concreto, lo cual nos puede ser de gran utilidad si estamos desarrollando cualquier tipo de servicio web.

Además de mostrar código, podemos hacer uso de los diferentes motores de visualización que soporta. Uno de ellos se conoce como erb (acrónimo de embebed ruby), y permite tener en una página HTML código ruby.

Para ello editamos nuestra aplicación y agregamos el siguiente código:

...

get '/hello/:id' do
  @name = params[:id]
  erb :hello
end

Además necesitamos crear una carpeta llamada views (que contendrá las vistas de nuestra aplicación) y agregar el fichero, que tendrá extensión erb.


</pre>
<h2>Hello</h2>
<pre>


Esto no es del todo cómodo ya que nos obliga a repetir el código de marcado para cada vista que queramos tener en nuestra aplicación, sin embargo lo que podemos hacer es tener una plantilla que inserte cierto código antes y después de la vista, para lo cual usamos un fichero llamado layout.erb que contendrá la estructura básica del sitio, y actualizaremos el código para mostrar esta diferencia.

    
    

 


El código anterior contiene una etiqueta, yield, que especifica donde se ha de cargar el código específico de nuestra vista. El fichero de la vista actualizado contendría la siguiente información:

</pre>
<h2>Hello</h2>
<pre>

Con esto seríamos capaces de crear un portal básico que responda a ciertos parámetros de entrada.

Pasos adicionales

Tenemos mucho más que poder agregar a nuestra app: Modelos de datos con DataMapper, autorización con Warden, posibilidad de devolver los resultados en formato json (y usarlo entonces como un servicio web)… Las posibilidades son infinitas, pero todo comienza con get “/hi”….

Más información

Half ToDo: Un caso de uso de ASP.net MVC4

Página principal

He de reconocer que me gustan los gestores de tareas, me imagino que será por lo mal que gestiono yo las mías. He probado muchos de los disponibles en el mercado y además quería hacer mi propia solución. Han sido varios intentos (MVCTask usando Azure, MetroTask para Windows 8, otro cliente por línea de comandos), pero creo que esta es la buena.

Las bases

La idea para desarrollar la aplicación era la siguiente:

  • Debía de ser simple
  • Debía de ser visualmente atractiva
  • Debía de resolver un problema

La idea era simple: Una práctica está dividida en varias tareas, y las tareas pueden tener dos estados, completada y sin completar. El porcentaje de terminación de una práctica está definido por el cociente entre las prácticas completadas dividido entre las prácticas totales.

Además, cada práctica estará enlazada a una persona concreta, de tal manera que yo solamente tenga acceso a las mías y no a las del resto de la gente (por aquello de la seguridad y tal).

Bajo el capó

Con esas tres premisas abrí Visual Studio y empecé un proyecto de nombre PracticasManager, ya que en un principio el proyecto va destinado a gestión de prácticas en la universidad.

Para realizar el proyecto me basé en la última versión de ASP.net MVC, la 4 que se encuentra en estos momentos en su fase de Developer Preview, ya que quería probar ciertas capacidades relativas al uso como aplicación móvil. El lenguaje de programación es C# y la interfaz para la creación de la aplicación es Razor.

El sistema ORM para el mapeo desde los objetos hasta la base de datos no podía ser otro que Entity Framework, usando el método Code-First, que permite definir nuestros objetos usando POCO (Plain Old C# object) y que las tablas de la base de datos se generen automáticamente.

La base de datos está gestionada por un SQL Server 2008 R2 que proporciona el proveedor del alojamiento.

Una cara bonita

Para la interfaz gráfica he usado Twitter Bootstrap, un conjunto de plantillas CSS y Javascript que permiten a los desarrolladores que no sabemos combinar colores que salga una interfaz decente. Finalmente la barra de progreso está creada con JQuery UI.

Detalle del listado de las tareas

También para móviles

Otra de las cosas que quería probar era el comportamiento de la aplicación en un móvil, así que usando las nuevas características de ASP.net MVC4, jQuery Mobile (y algun que otro paquete de nuget), pude implementar una interfaz básica de la aplicación para dispositivos móviles.

Detalle de la interfaz para dispositivos móviles

Alojamiento

Para el alojamiento decidí buscar algo diferente, tras probar Azure para otros proyectos (muy potente, y muy escalable, pero muy complejo para las necesidades de este proyecto) descubrí AppHarbor, un sistema de despliegue en la nube basado en Git (como Heroku, el sistema de despliegue preferido de las aplicaciones Ruby on Rails), completamente gratuito (para proyectos pequeños) y muy fácil de usar. La experiencia ha sido muy gratificante y recomiendo probarlo aunque sea con proyectos muy pequeños.

Detalle de interfaz de administración de AppHarbor

Conclusiones

Este proyecto me ha servido para poder lanzar una solución funcional para un problema concreto, así como la ocasión de probar tecnologías que no había visto hasta ahora, como JQuery Mobile, Bootstrap, el despliegue en AppHarbor entre otros.

Te animo a que la pruebes, está en una fase bastante experimental, así que puedes encontrar algún que otro fallo. Tanto si te gusta como si no, dejame un comentario y sabré qué puedo mejorar.

Enlace: Half todo en AppHarbor

En Ontuts: Monográfico MVC – Introducción

Ayer se publicó otro de mis artículos en el portal Ontuts, un portal en español muy recomendable con artículos de diseño y desarrollo web.

La semana pasada me surgió la necesidad de hacer un sistema de gestión de eventos para el DotNetClub del que formo parte y, aprovechando que lo estábamos estudiando en la carrera, decidí emplear el patrón Modelo-Vista-Controlador (MVC) y crear esta serie de artículos.

El enlace, aquí: Monográfico MVC – Introducción