Snahider's Blog

Coding Dojo Lima - Febrero 2013

2013-03-07T03:20:00.001-08:00

El jueves 21 de Febrero se realizó una nuevo Coding Dojo en las oficinas de Open Edge.

Los Coding Dojo son eventos que se realizan periódicamente en distintas ciudades al rededor del mundo y reúnen a los desarrolladores de todas las plataformas para trabajar en un reto de programación (Code Kata). El objetivo es divertirse, discutir y aprender entre todos nuevas habilidades de programación.

En esta oportunidad escogimos el kata Potter, que consisten implementar un programa que calcule el óptimo descuento para cualquier combinación de compra de libros de la saga de Harry Potter, donde existen diferentes reglas de descuentos de acuerdo a los libros comprados.

Asimismo se realizaron entrevistas a los asistentes y facilitadores para recoger sus opiniones sobre el Coding Dojo, podemos observarlas en el siguiente video.

Muchas gracias a Pamela (@pamcdm) por las entrevistas, grabación y edición de este fabuloso video.

Todos los materiales utilizados se pueden descargar aquí.

Hasta el próximo Coding Dojo, estén atentos a la inscripción que será publicada en la lista de Agile Perú.

Saludos
@Snahider

Test Automation .NET

2012-09-07T11:50:00.001-07:00

Les comparto los materiales que utilizo para facilitar talleres de "Test Automation .NET", para que todos puedan aprovecharlos en sus comunidades o trabajo.

Materiales completos (source code, slides, docs): https://github.com/snahider/Test-Automation-NET
Descripción del taller: http://www.openedgetech.com/calendario/490-pruebas-automatizadas-net
Slides: http://www.slideshare.net/snahider/test-automation-net
Licencia: Creative Commons Attribution-ShareAlike 3.0 Unported License

No es una guía paso a paso pero creo que cualquiera podrá entenderlos.
Si pueden brindar algún tipo de feedback o contribución sería buenísimo.

Espero les sea de utilidad.
Saludos
@Snahider

Cómo aprender a utilizar Resharper

2012-08-10T14:48:00.001-07:00

Resharper es un complemento indispensable para aquellos que utilizamos Visual Studio, ya que provee una gran cantidad de funcionalidad que potencia el IDE e incrementa notablemente la productividad del desarrollador.

Debido a que cada vez son los más desarrolladores y empresas que utilizamos esta herramienta, se escucha bastante la pregunta “¿Cómo puedo aprender yo y mi equipo a utilizar bien Resharper ?”.

Les comparto estos consejos y recursos de aprendizaje que los ayudarán a dominar esta increíble herramienta.

Free Pluralsight Training for ReSharper Customers: Si ya han adquirido la licencia de R#, seguramente les ha llegado un email con una suscripción por un mes para la capacitación online Resharper Fundamentals; consiste en casi 4 horas de videos separados por capítulos sobre las diversas características de R# que permiten mejorar nuestra productividad.
Si no tienen tiempo para ver las 4 horas, también pueden ver la estupenda VAN sobre Resharper de la comunidad Alt.Net Hispano, es un webinar de 2 horas donde se muestran diversos casos de uso donde se puede aprovechar al máximo R#.

Asimismo, la comunidad Alt.Net Hispano tiene una gran cantidad de webinars grabados sobre temas como Agile, .NET, Arquitectura, Patrones de Software, etc.
Algunas de las funcionalidades más útiles e impresionantes de R# se encuentran a nivel de Generación de Código, Refactoring y Pruebas Unitarias. Si quieren perfeccionar el uso de estas funcionalidades les recomiendo realizar algún Kata de Refactoring, uno muy bueno es el Gumball Machine Kata ya que adicionalmente los ayudará a practicar sobre Code Smells y Desing Patterns, pueden practicarlos por sí mismos o realizar un taller dirigido junto con todo tu equipo.
Tener a la mano los Hotkeys (VS Scheme o IDEA Scheme) y utilizarlos siempre que se pueda. Les recomiendo imprimirlos o guardarlos en un marcador dentro del navegador. Cuando estén programando y utilicen el mouse pregúntense ¿cómo podría haber hecho lo mismo utilizando un shortcut?.

Utilizar los shortcuts del teclado nos permiten trabajar mucho más rápido y distraernos menos. Toda la funcionalidad de R# combinada con los shortcuts puede incrementar muchísimo la productividad.
Para reforzar el uso y la práctica de R# les recomiendo asistir a Coding Dojos u organizarlos de manera interna en su empresa. Adicionalmente, les aconsejo elegir una kata sencilla y utilizar como restricción que “no está permitido utilizar el mouse”, pueden dividir el Coding Dojo en 2 sesiones consecutivas: la primera realizando el kata normalmente y la segunda utilizando la restricción.
De más está decir que la documentación es una muy buena fuente de consulta.
Busquen en su comunidad personas con quienes puedan compartir conocimiento o algún Partner local de JetBrains que pueda brindar capacitación y consultoría a su empresa.

Espero que les sea de mucha utilidad.

Saludos,
@Snahider

Videos para aprender HTML5 y CSS3

2012-08-06T12:15:00.001-07:00

Hola a todos, les comparto una serie de 21 videos gratuitos que nos enseñaran los fundamentos de HTML5 y CSS3.

Desde aquí podemos acceder a los videos y al código fuente de los ejercicios, estos se encuentran alojados en Channel 9 por lo que podremos descargarlos o verlos online.

Los videos han sido realizados por Bob Tabor que es muy conocido por crear otros varios recursos de aprendizaje sobre la plataforma .NET.

Saludos,
@Snahider

Single Page Applications – Parte 5 – Comunicación entre ViewModels

2012-07-30T04:11:00.001-07:00

En este post veremos como comunicar las 2 vistas que hemos creado anteriormente(Seleccionar Producto e Ingresar Pedido), de tal manera que cuando seleccionemos un producto en la primera pantalla, desaparezca esta pantalla y se muestre la pantalla de ingreso de pedido con los datos del producto seleccionado.

Para lograr que nuestros 2 viewmodels se comuniquen tenemos las siguientes opciones: crear un objeto padre que se encargue de coordinar todas los view models; utilizar las urls, hasbangs (#!) y routing; o utilizar el patrón publish/suscribe entre las vistas.

En esta oportunidad utilizaremos un objeto padre para coordinar todos los viewmodels del proceso de delivery, pero en los siguientes posts veremos las otras alternativas.

Implementamos este objeto dentro del archivo /Scripts/App/ViewModels/deliveryviewmodel.js, este objeto tendrá una propiedad por cada uno de los viewmodels que esté coordinando.

var DeliveryViewModel = function () {
    var self = this;
 
    self.chooseProduct = ko.observable();
    self.placeOrder = ko.observable();
};

Asimismo, este objeto tendrá métodos que serán responsables de mostrar cada una de las vistas del proceso de delivery.

var DeliveryViewModel = function () {
    var self = this;
 
    self.chooseProduct = ko.observable();
    self.placeOrder = ko.observable();
 
    self.showChooseProduct = function () {
        //TODO: Mostrar la primera vista y ocultar las demás
    };
 
    self.showPlaceOrder = function (productId) {
        //TODO: Mostrar la segunda vista y ocultar las demás
    };
 
    self.showConfirmation = function () {
        //TODO: Mostrar la tercera vista y ocultar las demás
    };
 
    self.showChooseProduct();
};

Los viewmodels ChooseProductViewModel y PlaceOrderViewModel dependerán este nuevo objeto padre y le delegarán la responsabilidad de mostrar la vista adecuada.

var ChooseProductViewModel = function (parent) {
    var self = this;
    self.products = ko.observableArray();
 
    self.goToPlaceOrder = function (product) {
        parent.showPlaceOrder(product.id);
    };
 
    self.init = function () {
        ProductsDataSource.getAll(function (data) {
            self.products(data);
        });
    };
 
    self.init();
};

var PlaceOrderViewModel = function (productId, parent) {
    var self = this;
 
    self.order = ko.observable();
 
    self.postOrder = function () {
        OrdersDataSource.create(self.order, function () {
            parent.showConfirmation();
        });
    };
 
    self.init = function () {
        ProductsDataSource.get(productId, function (product) {
            self.order(new Order(product));
        });
    };
 
    self.init();
};

El objeto DeliveryViewModel, cada vez que los objetos hijos le delegen mostrar una nueva vista, instanciará el viewmodel adecuado para esta vista.

var DeliveryViewModel = function () {
    var self = this;
 
    self.chooseProduct = ko.observable();
    self.placeOrder = ko.observable();
 
    self.showChooseProduct = function () {
        self.chooseProduct(new ChooseProductViewModel(self));
        self.placeOrder(null);
    };
 
    self.showPlaceOrder = function (productId) {
        self.chooseProduct(null);
        self.placeOrder(new PlaceOrderViewModel(productId, self));
    };
 
    self.showConfirmation = function () {
        //TODO: Mostrar la Tercera vista y ocultar las demás
    };
 
    self.showChooseProduct();
};

Podemos observar que para ocultar una vista simplemente asignamos null a la propiedad, esto se debe a que Knockoutjs automáticamente eliminará toda la sección HTML si es que el valor del binding es null.

Necesitamos enlazar toda la aplicación al nuevo objeto DeliveryViewModel, para esto modificamos el archivo /Scripts/application.js donde se inicializan los viewmodels.

function initializeApplication() {
initializeViewModels();
}

function initializeViewModels() {
ko.applyBindings(new DeliveryViewModel());
}

Enlazamos cada vista de manera individual a una propiedad del DeliveryViewModel, para esto modificamos el archivo /Views/Home/Index.cshtml.

<div data-bind="with: chooseProduct">
    @Html.Partial("_ChooseProduct")
</div>
 
<div data-bind="with: placeOrder">
    @Html.Partial("_PlaceOrder")
</div>
 
<script type="text/javascript">
    $(function () {
        initializeApplication();
    });
</script>

Por último agregamos las referencias a todos los nuevos scripts dentro del archivo /Views/Shared/Layout.cshtml.

<script src="~/Scripts/Lib/jquery-1.6.2.min.js" type="text/javascript"></script>
<script src="~/Scripts/Lib/knockout-2.1.0.js" type="text/javascript"></script>
<script src="~/Scripts/App/Data/productsdatasource.js" type="text/javascript"></script>
<script src="~/Scripts/App/Data/ordersdatasource.js" type="text/javascript"></script>
<script src="~/Scripts/App/Models/order.js" type="text/javascript"></script>
<script src="~/Scripts/App/ViewModels/deliveryviewmodel.js" type="text/javascript"></script>
<script src="~/Scripts/App/ViewModels/chooseproductviewmodel.js" type="text/javascript"></script>
<script src="~/Scripts/App/ViewModels/placeorderviewmodel.js" type="text/javascript"></script>
<script src="~/Scripts/application.js" type="text/javascript"></script>

Si ejecutamos la aplicación podremos ver el listado de productos.

Si seleccionamos alguno de los productos aparecerá la pantalla para completar los datos de la orden.

En el siguiente post veremos la tercera pantalla del proceso de delivery.

Saludos
Angel Núñez Salazar

Single Page Applications – Parte 4 – Más KnockoutJS

2012-07-20T19:47:00.001-07:00

En este post vamos a implementar la segunda pantalla de nuestra panadería online.

Pantalla: Ingresar Pedido

Pantalla a través de la cuál un usuario ingresa los datos del pedido para que este sea enviado a la dirección especificada.

Creamos el ViewModel para esta pantalla dentro del archivo /Scripts/App/ViewModels/placeorderviewmodel.js. Este ViewModel recibirá como parámetro el código del producto seleccionado para el pedido.

var PlaceOrderViewModel = function (productId) {
    var self = this;
 
    self.order = ko.observable();
 
    self.postOrder = function () {
        OrdersDataSource.create(self.order, function () {
            //TODO: Ir a la pantalla de confirmación
        });
    };

};

Delegamos la creación de la orden al objeto OrdersDataSource y lo implementamos dentro del archivo /Scripts/App/Data/ordersdatasource.js.

var OrdersDataSource = (function () {
    return {
        create: function (order, success) {
            $.ajax({
                type: "POST",
                url: "/api/orders",
                dataType: "json",
                contentType: "application/json;charset=utf-8",
                data: ko.toJSON(order),
                success: success
            });
        }
    };
} ());

Completamos el código del PlaceOrderViewModel para cargar los datos del producto que serán mostrados en el formulario de la orden.

Agregamos un nuevo método dentro del objeto ProductsDataSource.

Creamos la clase Order dentro del archivo /Scripts/App/Models/order.js, esta clase contendrá los datos del pedido que serán enviados al servicio REST.

var Order = function (product) {
    var self = this;
    self.address = ko.observable();
    self.email = ko.observable();
    self.quantity = ko.observable(1);
    self.productId = product.id;
    self.product = product;
    self.total = ko.computed(function () {
        return (self.product.price * self.quantity()).toFixed(2);
    });
}

Utilizamos la sentencia ko.observable() para relacionar las propiedades de esta clase con los campos del formulario. También utilizamos la sentencia ko.computed() para crear una función observable que dependa de otros observables, esto permitirá que el monto total de la orden se actualice automáticamente cuando el valor de la cantidad cambie.

Completamos el código del PlaceOrderViewModel para instanciar una nueva orden apenas se reciba los datos del producto.

var PlaceOrderViewModel = function (productId) {
    var self = this;
 
    self.order = ko.observable();
 
    self.postOrder = function () {
        OrdersDataSource.create(self.order, function () {
            //TODO: Ir a la pantalla de confirmación
        });
    };
 
    self.init = function () {
        ProductsDataSource.get(productId, function (product) {
            self.order(new Order(product));
        });
    };
 
    self.init();
};

Creamos la vista parcial /Views/Home/_PlaceOrder.cshtml y agregamos el código HTML correspondiente esta pantalla.

<!-- ko with: order -->
<h1 data-bind="text: 'Place Your Order: '+product.name">
</h1>
<form action="" method="post">
    <fieldset class="no-legend">
        <legend>Place Your Order</legend>
        <img class="product-image order-image" 
             data-bind="attr:{ src:'/content/images/products/thumbnails/' + product.imagename, 
                        alt:product.name }" />
        <ol>
            <li>
                <label for="orderEmail">Your Email Address</label>
                <input type="text" id="orderEmail" name="orderEmail" data-bind="value:email" />
            </li>
            <li>
                <label for="orderShipping">Shipping Address</label>
                <textarea rows="4" cols="20" id="orderShipping" name="orderShipping" 
                          data-bind="value:address">
                </textarea>
            </li>
            <li class="quantity">
                <label for="orderQty">Quantity</label>
                <input type="text" id="quantity" name="quantity" 
                       data-bind="value:quantity, valueUpdate: 'afterkeydown'" />
                x <span id="orderPrice" data-bind="text:product.price"></span>
                = <span id="orderTotal" data-bind="text:total()"></span></li>
        </ol>
        <p>
            <input type="submit" value="Place Order" data-bind="click:$parent.postOrder" />
        </p>
    </fieldset>
</form>
<!-- /ko –>

Examinemos brevemente los nuevos “bindings” que estamos utilizando.

with: Crea un “contexto” dentro del cuál todos los bindings hacen referencia al objeto asignado. Una característica de este binding es que lo podemos utilizarlo dentro de un comentario sin la necesidad de crear un nuevo tag.
value: Asocia el atributo “value” con el valor de una propiedad dentro del ViewModel. Típicamente usado con elementos dentro de un formulario como: <input>, <select>, <textarea>, etc.
valueUpdate: Por defecto los bindings se actualizan cuando se el usuario cambia el foco del elemento. Esta propiedad nos permite controlar cuando se actualizarán los cambios, por ejemplo: “afterkeydown”, “keyup”, “keypress”, etc.

Desde el archivo /Views/Home/Index.cshtml hacemos referencia a la vista parcial recién creada.

<div>
    @Html.Partial("_ChooseProduct");
</div>
 
<div>
    @Html.Partial("_PlaceOrder");
</div>
 
<script type="text/javascript">
    $(function () {
        initializeApplication();
    });
</script>

Agregamos las referencias de los nuevos scripts dentro del archivo /Views/Shared/Layout.cshtml.

<script src="~/Scripts/Lib/jquery-1.6.2.min.js" type="text/javascript"></script>
<script src="~/Scripts/Lib/knockout-2.1.0.js" type="text/javascript"></script>
<script src="~/Scripts/App/Data/productsdatasource.js" type="text/javascript"></script>
<script src="~/Scripts/App/Data/ordersdatasource.js" type="text/javascript"></script>
<script src="~/Scripts/App/Models/order.js" type="text/javascript"></script>
<script src="~/Scripts/App/ViewModels/chooseproductviewmodel.js" type="text/javascript"></script>
<script src="~/Scripts/App/ViewModels/placeorderviewmodel.js" type="text/javascript"></script>
<script src="~/Scripts/application.js" type="text/javascript"></script>

Luego de todos estos cambios, la estructura final de archivos ha quedado de la siguiente manera.

En el siguiente post veremos como comunicar nuestros 2 ViewModels para permitir que la segunda vista recién se muestre luego de seleccionado un producto.

Saludos
Angel Núñez Salazar

Single Page Applications – Parte 3 – UI Patterns, KnockoutJS

2012-05-27T19:02:00.001-07:00

En esta oportunidad vamos a hablar sobre como estructurar la aplicación y como organizar el código. Los patrones más comúnmente usados para organizar aplicaciones en el “front-end” son 2: MVC y MVVM.

MVC en Javascript

MVC es probablemente el patrón de presentación más antiguo que existe y es utilizado en múltiples lenguajes de programación. Dentro de Javascript existen las siguientes implementaciones:

Examinemos los componentes de este patrón dentro de Javascript:

Models: Contienen los datos que se van a manejar en la aplicación, muchas veces implementan el Observer Pattern(Publisher/Subscriber Pattern) para notificar a las vistas que necesitan actualizarse cuando se ha producido algún cambio en el modelo.

Views: No necesariamente constituyen directamente el HTML que se va a mostrar, sino son los encargados de renderizar el modelo, en varios de los casos utilizando “Templates”.

Controllers: Intermediarios entre las Vistas y el Modelo, coordinan la actualización del Modelo de acuerdo a los cambios producidos en las vistas y viceversa. Varias implementaciones MVC en Javascript tienen un concepto diferente de lo que es convencionalmente llamado un “Controller”, por esto podemos encontrar que la “C” puede estar representada por “Colecciones” de objetos o “Rutas” o dependiendo del caso.

MVVM en Javascript

Es otro patrón que busca separar el desarrollo de la interfaz de usuario, de la lógica de la aplicación. Fue originalmente definido por Microsoft para ser usado junto con WPF, pero ha sido adoptado por otros lenguajes.

En estos últimos años se han creados algunas implementaciones de este patrón dentro de Javascript:

Examinemos los componentes de este patrón dentro de Javascript:

Models: Representan la información del dominio sobre el cuál trabajará la aplicación. Dentro de este patrón, no siempre los miembros del modelo se encuentran directamente en código Javascript, muchas veces los objetos del modelo se encuentran en el lado del servidor.

Views: A diferencia del patrón MVC, estas vistas son “activas” es decir no solo se encargan de mostrar los datos sino también envían al ViewModel información sobre eventos. Generalmente son documentos HTML que contienen “bindings” hacia el ViewModel.

ViewModels: Representan a las vistas, a sus datos y operaciones que se realizan sobre estas. Se mantienen sincronizados con las vistas a través de los “bindings” que funcionan en doble sentido.

Para nuestra aplicación vamos a utilizar el Patrón MVVM junto con KnockoutJS.

Lo primero que haremos será agregar los scripts necesarios para usar KnockoutJS dentro del archivo /Views/Shared/Layout.cshtml. KnockoutJS lo podemos descargar desde su página web o utilizando Nuget.

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>Fourth Coffee</title>
    <link href="~/Content/Site.css" rel="stylesheet" type="text/css" />
    <script src="~/Scripts/Lib/jquery-1.6.2.min.js" type="text/javascript"></script>
    <script src="~/Scripts/Lib/knockout-2.1.0.js" type="text/javascript"></script>
</head>

Creamos la siguiente estructura de directorios para nuestros archivos Javascript.

App: Contendrá los archivos de la aplicación que han sido desarrollados por nosotros..
- Data: Contendrá los objetos mediante los cuales accederemos a los servicios REST.
- Models: Contendrá a los objetos que constituyen el Modelo de la aplicación.
- ViewModels: Contendrá a los ViewModels de la aplicación.
Lib: Contendrá los archivos pertenecientes a frameworks y librerías externas: Jquery, KnockoutJS, etc.

Creamos el HomeController, la acción Index y el archivo /Views/Home/Index.cshtml sin ningún contenido.

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
}

Luego de esto, podremos levantar la aplicación y ver una pantalla inicial.

Ahora crearemos las Vistas, Modelos y ViewModels de nuestra aplicación. En este post nos vamos a enfocar únicamente en la primera pantalla y vamos a crear los elementos necesarios para su funcionamiento.

Pantalla: Selección de Producto

Pantalla a través de la cuál un usuario puede seleccionar cuál será el producto que desea comprar.

Creamos el ViewModel para esta pantalla dentro del archivo /Scripts/App/ViewModels/chooseproductviewmodel.js. Recordemos que un ViewModel es una representación de los datos y operaciones que se pueden realizar en la pantalla, entonces lo que vamos a encontrar en este ViewModel será una propiedad que representé al “Listado de “Productos” que vamos a mostrar en la pantalla y una función que nos permita gestionar el click al botón “Order Now”.

var ChooseProductViewModel = function () {
    var self = this;
    self.products = ko.observableArray();
 
    self.goToPlaceOrder = function (product) {
        //TODO: Mostrar la vista para ingresar la orden de compra del producto 
    };

};

Podemos observar la sentencia ko.observableArray(), de esta manera le indicamos a KnockoutJS que cree una sincronización en doble sentido entre la propiedad y la vista. Si el valor de una propiedad “observable” es actualizado en el ViewModel este se verá automáticamente reflejado en la vista; de la misma manera, si este valor es cambiado en la vista, este se actualizará automáticamente dentro del ViewModel.

Completamos el código del ChooseProductViewModel para cargar los productos desde los servicios REST.

var ChooseProductViewModel = function () {
    var self = this;
    self.products = ko.observableArray();
 
    self.goToPlaceOrder = function (product) {
        //TODO: Mostrar la vista para ingresar la orden de compra del producto 
    };
 
    self.init = function () {
        ProductsDataSource.getAll(function (data) {
            self.products(data);
        });
    };
 
    self.init();
};

Delegamos la responsabilidad de obtener los productos al objeto ProductsDataSource y lo implementamos dentro del archivo /Scripts/App/Data/productsdatasource.js. Podemos observar que la función getAll recibe como parámetro un ”callback” que será ejecutado cuando se reciban los datos del servicio.

Utilizaremos “Partial Views” para organizar nuestras vistas. Creamos la vista parcial /Views/Home/_ChooseProduct.cshtml y agregamos el código HTML correspondiente esta pantalla.

<ul id="products" data-bind="foreach: products">
    <li class="product">
        <div class="productInfo">
            <h3 data-bind="text: name">
            </h3>
            <img class="product-image" 
                 data-bind="attr:{ 
                        src:'/content/images/products/thumbnails/' + imagename,
                        alt:name }" />
            <p class="description" data-bind="text: description"></p>
        </div>
        <div>
            <p class="price" data-bind="text: price"></p>
            <a class="order-button" 
               data-bind="attr:{ title:name }, click:$parent.goToPlaceOrder">
                Order Now
            </a>
        </div>
    </li>
</ul>

Podemos observar la presencia de atributos data-bind dentro de los tags HTML, estos son los “bindings” a través de los cuales enlazamos los elementos de las vistas a las propiedades del ViewModel. Existen “bindings” de todo tipo: texto (value, text), apariencia (css, html, attr, style), control (foreach, if, with), etc.

Examinemos brevemente los “bindings” que estamos utilizando en esta oportunidad.

foreach: Duplica una sección por cada elemento dentro del arreglo. En este caso creará un bloque “<li></li>” por cada producto que tengamos.
text: Establece como texto el valor de la propiedad asociada.
attr: Establece el valor de cualquier atributo HTML.
click: Establece un evento que será llamado cada vez que se haga click sobre el elemento. En esta oportunidad estamos utilizando la sentencia $parent para referirnos al padre del objeto producto, ya que la función goToPlaceOrder se encuentra en el ViewModel.

Desde el archivo /Views/Home/Index.cshtml hacemos referencia a la vista parcial recién creada.

<div>
    @Html.Partial("_ChooseProduct");
</div>

Necesitamos enlazar la vista al ChooseProductViewModel, para esto creamos el archivo /Scripts/application.js donde inicializaremos los viewmodels. Utilizaremos este archivo para configurar todo lo necesario para el funcionamiento de la aplicación.

function initializeApplication() {
initializeViewModels();
}

function initializeViewModels() {
ko.applyBindings(new ChooseProductViewModel());
}

Agregamos el siguiente script al final del archivo /Views/Home/Index.cshtml para inicializar la aplicación.

<div>
    @Html.Partial("_ChooseProduct");
</div>
 
<script type="text/javascript">
    $(function () {
        initializeApplication();
    });
</script>

Por último agregamos las referencias a todos los nuevos scripts dentro del archivo /Views/Shared/Layout.cshtml.

<script src="~/Scripts/Lib/jquery-1.6.2.min.js" type="text/javascript"></script>
<script src="~/Scripts/Lib/knockout-2.1.0.js" type="text/javascript"></script>
<script src="~/Scripts/App/Data/productsdatasource.js" type="text/javascript"></script>
<script src="~/Scripts/App/ViewModels/chooseproductviewmodel.js" type="text/javascript"></script>
<script src="~/Scripts/application.js" type="text/javascript"></script>

Luego de todos estos cambios, la estructura final de archivos ha quedado de la siguiente manera.

Si ejecutamos la aplicación podremos observar el listado de productos.

En los siguientes posts veremos el resto de pantallas del proceso de delivery.

Saludos
Angel Núñez Salazar

Single Page Applications – Parte 2 – Server Technologies (ASP.NET MVC y ASP.NET Web API)

2012-04-30T01:02:00.001-07:00

Durante estos posts nos enfocaremos principalmente en el Lado del Cliente (HTML y Javascript) pero de todas maneras necesitamos un Lado del Servidor para trabajar.

Este post lo dedicaremos a implementar el lado del servidor, para esto utilizaremos ASP.NET MVC 4 y ASP.NET Web API, aunque podría ser cualquier otra tecnología de nuestro agrado.

Nota: ASP.NET MVC 4 y ASP.NET Web API actualmente se encuentran en Beta y pueden ser descargados de aquí.

Al aplicar estas tecnologías, el lado del servidor quedaría de la siguiente manera:

ASP.NET MVC 4

Utilizaremos esta tecnología para organizar y crear los recursos HTML, Javascript y CSS que luego serán servidos por parte del servidor.

Lo primero que haremos será crear un proyecto ASP.NET MVC 4 en blanco.

Agregamos la hoja de estilos y modificamos el _Layout.cshtml según el Bakery Template de WebMatrix.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>Fourth Coffee -@ViewBag.Title</title>
    <link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/css")" rel="stylesheet" type="text/css" />
    <link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/themes/base/css")" rel="stylesheet" type="text/css" />
    <script src="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Scripts/js")"></script>
</head>
<body>
    <div id="page">
        <div id="header">
            <p class="site-title">
                <a href="~/">Fourth Coffee</a></p>
            <ul id="menu">
                <li><a href="~/">Home</a></li>
                <li><a href="~/About">About Us</a></li>
            </ul>
        </div>
        <div id="body">
            @RenderBody()
        </div>
        <div id="footer">
            ©@DateTime.Now.Year - Fourth Coffee
        </div>
    </div>
</body>
</html>

Creamos la clase HomeController que retorne la única vista de nuestra aplicación.

public class HomeController : Controller
{
    public ActionResult Index()
    {
            return View();
    }
}

ASP.NET Web API

Nos permite crear y exponer de manera muy simple servicios bajo el protocolo HTTP siguiendo un estilo de arquitectura REST. Algunos de sus beneficios son:

Crear servicios REST.
Consultas ODATA.
Diferentes tipos de formatos: JSON, XML, etc.
Soporte de varios elementos ya existentes dentro ASP.NET: Model Binding, Routing, Validation, Filters, etc.
Soporte de inyección de dependencias.
Fácilmente testeable de manera unitaria.

Mediante ASP.NET Web API implementaremos nuestro Data Services endpoint para exponer servicios que envíen y reciban datos en formato JSON desde el cliente. Para esto realizaremos lo siguiente:

Creamos las clases del modelo para la aplicación y crearemos un DbContext típico de Entity Framework.

public class AppDbContext : DbContext
{
    public AppDbContext() : base("bakery") { }

    public IDbSet<Product> Products { get; set; }
}

Utilizando Nuget agregamos la referencia a AspNetWebApi.Data, luego creamos un controller que herede de AspNetWebApi.Data.DbDataController, los controllers dentro de Web API funcionan de manera muy similar a MVC y permiten exponer servicios HTTP.

También creamos un servicio que devuelva todos los productos en formato JSON.

public class ProductsController : DbDataController<AppDbContext>
{
    public IQueryable<Product> Get()
    {
        return DbContext.Products.AsQueryable();
    }
}

Nota: Retornar los datos como IQueryable y no como IEnumerable permite que se puedan realizar consultas ODATA.

Probamos nuestro servicio levantando toda la aplicación y accediendo a la siguiente URL: http://[domain]/api/products.

Esta URL corresponde a nuestro servicio HTTP, debido a que existe la siguiente ruta registrada dentro del Global.asax.

Asimismo, nuestro servicio HTTP dentro del controller tiene el nombre de “Get”, entonces por convención será mapeado automáticamente a todos los GET Request.

Por otro lado el servicio HTTP ha retornado XML, esto se debe a que Chrome envía por defecto en la cabecera de la solicitud Accept: application/xml; si en la cabecera se envía Accept: application/json, el servicio retornaría automáticamente los datos en formato JSON.

Por el momento esto es todo lo que necesitamos implementar en el lado del servidor.

Recursos Adicionales

Hasta el siguiente post.
Saludos.

Single Page Applications – Parte 1 – Definición y Arquitectura

2012-04-29T19:28:00.001-07:00

En esta serie de posts veremos los conceptos detrás de las SPAs y como implementar una de estas aplicaciones.

¿Qué son las Single Page Applications?

SPAs son aplicaciones o sitios web que se ejecutan persistentemente sobre la misma página sin necesidad de recargar sin importar como el usuario interactúe.

Son aplicaciones ricas y responsivas que combinan lo mejor de la web y el escritorio, implementadas con Javascript y HTML5.

¿Qué beneficios tienen?

Por qué deberíamos considerar este tipo de aplicaciones:

Buena experiencia de usuario.
Reducen la carga en el servidor.
Similares a las aplicaciones nativas.
Pueden trabajar offline.
Pueden desplegarse en App-Stores

¿Cuál es su arquitectura?

Una aplicación “multi-page” tradicional usualmente sigue una arquitectura similar a la siguiente:

Web UI: Contiene la lógica de negocio y a su vez se encarga de servir recursos HTML, JS, CSS desde el servidor.
Visible UI: Renderiza en el navegador la página web.
Application Layer: Código Javascript para manipular el comportamiento de la página dentro del navegador.

En cambio una aplicación SPA tiene una arquitectura similar a la siguiente:

Web UI: Contiene la lógica de negocio y a su vez se encarga de servir recursos HTML, JS, CSS desde el servidor.
Data Services: Provee datos en formato JSON o XML desde el servidor.
Data Access Layer: Se encarga de solicitar datos al servidor para que estos sean mostrados, enviar datos para que sean procesados.
Application Layer: También contiene mucha otra lógica relacionada a Navegación, Binding, etc.
Visible UI: También hace uso de templates para renderizar los datos.

¿Cómo implementar una SPA?

En los posts sucesivos veremos detalladamente como implementar una de estas aplicaciones. Como ejemplo utilizaremos el “Bakery Template” que es uno de los templates para construir aplicaciones web que viene por defecto dentro de WebMatrix.

Reutilizaremos su layout y estilos pero reharemos por completo toda la funcionalidad para que funcione como un SPA.

Hasta el siguiente post.
Saludos.

Refactoring Golf

2011-11-08T12:23:00.001-08:00

Los días 11, 12 y 13 de Octubre se realizó en Buenos Aires (Argentina) la conferencia Agiles2011, es el evento latinoamericano más grande sobre metodologías ágiles, al cual tuve el placer de asistir y dar una ponencia junto con Gustavo Quiroz.

La ponencia se titula “Refactoring Golf”, es un workshop avanzado de Refactoring que está inspirado en la ponencia original realizada en el Software Craftmaship 2010.

Materiales

Les dejo todos los materiales del workshop, están decentemente reutilizables. Pueden utilizarlos libremente, solo déjenme sus comentarios e ideas para poder mejorar el material. Pueden hacer un fork al repositorio para agregarle más cosas pero no se olviden de avisarme para que yo también pueda usarlas =).

Descripción y Reglas.

Repositorio Github: Contiene código fuente, diapositivas y documentos para imprimir.

Ponencia Original.

Diapositivas

Adicionalmente he subido la presentación a Slideshare para que puedan comentarla y compartirla.

Retrospectiva

Esta es una imagen con la retrospectiva realizada al final del workshop.

Saludos
Angel Núñez Salazar

Refactoring to Design Patterns

2011-10-25T03:26:00.001-07:00

En este screencast vamos a ver cómo podemos refactorizar una clase para implementar el patrón State. El código pertenece al caso “Gumball Machine” que se encuentra en el libro Head First Design Patterns.

El código inicial y final que veremos en el screencast lo podemos descargar de https://github.com/snahider/Head-First-Design-Patterns.

Te recomiendo verlo en HD.
Un agradecimiento especial a Israel Antezana (@israelantezana) que me dio esta idea y con el cuál tuve una pequeña sesión de pair programming durante Agiles2011.

Update
Resharper 7 ya viene con el refactoring Extract Class que nos permite mover miembros de una clase a otra que aún no existe.

Saludos
Angel Núñez Salazar

Entity Framework 4.1 y ASP.NET MVC 3

2011-03-27T21:28:00.001-07:00

Con la salida de EF 4.1 ha vuelto la discusión sobre el manejo de la Unit of Work en una aplicación web. En este caso vamos a ver algunos pasos utilizando EF 4.1, MVC 3 y StructureMap.

Paso 1: El Dominio

    public abstract class Entity
    {
        public int Id { get; set; }
    }

    public class Post:Entity
    {
        public String Title { get; set; }

        public String Body { get; set; }

        public List<Comment> Comments { get; set; }

    }

    public class Comment:Entity
    {
        public string Content { get; set; }

        public int PostId { get; set; }

        public Post Post { get; set; } 
    }

Paso 2: DbContext y la cadena de conexión

Creamos una clase que extienda de DbContext para que a través de ella interactuemos con la base de datos. Por defecto busca una cadena de conexión que tenga el mismo nombre de la clase que lo implementa, en este caso una cadena con el nombre de DatabaseContext. Podemos cambiar el nombre de esta cadena si ingresamos un nuevo parámetro al constructor del DbContext.

    public class DatabaseContext : DbContext
    {

        public DatabaseContext() : base("Blog") {}

    }

    <add name="Blog" connectionString="xXx" providerName="System.Data.SqlClient" />

Paso 3: Los Repositorios

No me gusta la idea de tener todos los DbSet dentro del DatabaseContext, es por esto que creamos un repositorio base que instancie un DbSet para su correspondiente entidad y también agregamos algunos métodos comunes.

    public class Repository<T> where T : Entity
    {
        public Repository()
        {
            var database = ObjectFactory.GetInstance<DatabaseContext>();
            this.Set = database.Set<T>();
        }
 
        protected readonly DbSet<T> Set;
 
        public IEnumerable<T> All()
        {
            return this.Set.ToList();
        }
 
        public void Add(T entity)
        {
            this.Set.Add(entity);
        }
 
        public T Get(int id)
        {
            return this.Set.SingleOrDefault(x=>x.Id==id);
        }
 
        public void Delete(T entity)
        {
            this.Set.Remove(entity);
        }
    }

En este caso no estamos inyectando el DatabaseContext por el constructor sino lo obtenemos a través de un Service Locator, esto con la finalidad de no tener que escribir el constructor en todos los repositorios hijos.

    public interface IPostRepository
    {
        Post Get(int id);
 
        void Add(Post post);
 
        void Delete(Post post);
 
        IEnumerable<Post> All();
 
        IEnumerable<Comment> Comments(int idPost);
    }
 
    public class PostRepository : Repository<Post>, IPostRepository
    {
        public IEnumerable<Comment> Comments(int idPost)
        {
            return this.Set.SelectMany(p => p.Comments)
                        .Where(c => c.Post.Id == idPost).ToList();
        }
    }

Paso 4: Inyección de Dependencias

En ASP.NET MVC 3 se ha formalizado la inyección de dependencias, es por esto que podemos implementar la nueva interfaz IDependencyResolver e indicarle a MVC que utilice esta clase para determinar cuál es la instancia correcta cuando se solicite un determinado tipo.

    public class StructureMapDependencyResolver:IDependencyResolver
    {
        public StructureMapDependencyResolver(IContainer container)
        {
            this.container = container;
        }
 
        private readonly IContainer container;
 
        public object GetService(Type serviceType)
        {
            if (serviceType.IsAbstract || serviceType.IsInterface)
            {
                return this.container.TryGetInstance(serviceType);

            }
 
            return this.container.GetInstance(serviceType);

        }
 
        public IEnumerable<object> GetServices(Type serviceType)
        {
            return container.GetAllInstances<object>()
                .Where(s => s.GetType() == serviceType);
        }
    }

Ahora configuramos StructureMap y registramos la clase anterior dentro del Global.asax. El punto más importante en cuanto al manejo de la unidad de trabajo es configurar el contenedor para que se tenga una única instancia del DatabaseContext a nivel de todo un request.

    protected void Application_Start()
    {
        ObjectFactory.Initialize(x =>
        {
            x.For<DatabaseContext>().HybridHttpOrThreadLocalScoped();
            x.For<IPostRepository>().Use<PostRepository>();
        });
 
        DependencyResolver.SetResolver(
            new StructureMapDependencyResolver(ObjectFactory.Container));
 
        AreaRegistration.RegisterAllAreas();
        RegisterGlobalFilters(GlobalFilters.Filters);
        RegisterRoutes(RouteTable.Routes);
    }

Si utilizamos StructureMap necesitamos limpiar todos los objetos que tienen un ciclo de vida a nivel de request, en este caso el DatabaseContext.

    protected void Application_EndRequest(object sender, EventArgs e)
    {
        ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects();
    }

Paso 4: El Filtro de Transacción

Ahora que se comparte el mismo DatabaseContext en todo un request, cuando este finalice, necesitamos enviar a la base de datos todos los cambios que se hayan realizado como si fueran una sola unidad o transacción. Para esto creamos un filtro de acción que guarde los cambios realizados dentro del DatabaseContext.

    public class TransactionAttribute : ActionFilterAttribute
    {
        public DatabaseContext Context { get; set; }
 
        public override void OnActionExecuted(ActionExecutedContext filterContext)
        {
            if (filterContext.Exception == null)
            {
                try
                {
                    Context.SaveChanges();
                }
                catch (DbUpdateConcurrencyException)
                {
                    //manejar errores de concurrencia como sea conveniente
                }
                catch (Exception)
                {
                    //manejar errores genéricos como sea conveniente
                }
            }
        }
    }

Para poder inyectar la instancia correcta del DatabaseContext dentro del filtro, necesitamos extender la clase FilterAttributeFilterProvider.

    public class StructureMapFilterProvider : FilterAttributeFilterProvider
    {
        private readonly IContainer container;
        public StructureMapFilterProvider(IContainer container)
        {
            this.container = container;
        }
 
        public override IEnumerable<Filter> GetFilters
        (ControllerContext controllerContext, ActionDescriptor actionDescriptor)
        {
            var filters = base.GetFilters(controllerContext, actionDescriptor);
 
            foreach (var filter in filters)
            {
                container.BuildUp(filter.Instance);
            }
 
            return filters;
        }
    }

Modificamos el Global.asax para registrar la clase anterior e indicarle a StructureMap que realice inyección a través de propiedades para el DatabaseContext.

    protected void Application_Start()
    {
        ObjectFactory.Initialize(x =>
        {
            x.For<DatabaseContext>().HybridHttpOrThreadLocalScoped();
            x.For<IPostRepository>().Use<PostRepository>();
            x.SetAllProperties(p => p.OfType<DatabaseContext>());
        });
 
        DependencyResolver.SetResolver(
            new StructureMapDependencyResolver(ObjectFactory.Container));
        FilterProviders.Providers.Add(
                new StructureMapFilterProvider(ObjectFactory.Container));
 
        AreaRegistration.RegisterAllAreas();
        RegisterGlobalFilters(GlobalFilters.Filters);
        RegisterRoutes(RouteTable.Routes);
    }

Paso 5: Registrando las entidades en el DatabaseContext

Debido a que los DbSets de nuestras entidades no se encuentran dentro del DatabaseContext, este no las reconoce para poder utilizarlas; para registrarlas debemos sobrescribir el método OnModelCreating y por cada entidad llamar al método genérico modelbuilder.Entity<T>.

    public class DatabaseContext : DbContext
    {
        public DatabaseContext() : base("Blog"){}
 
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            var method = typeof(DbModelBuilder).GetMethod("Entity");
 
            var types = Assembly.GetExecutingAssembly().GetExportedTypes()
                .Where(t => typeof(Entity).IsAssignableFrom(t) && 
                            !t.IsAbstract && !t.IsInterface)
                .ToList();
 
            foreach (var type in types)
            {
                var genericMethod = method.MakeGenericMethod(new[] { type });
                genericMethod.Invoke(modelBuilder, null);
            } 
        }
    }

Paso 6: Utilizando lo anterior en los Controllers

Creamos un controller y algunas acciones que utilicen los repositorios y el filtro anteriormente creado.

    public class PostsController : Controller
    {
        private readonly IPostRepository postRepository;
 
        public PostsController(IPostRepository postRepository)
        {
            this.postRepository = postRepository;
        }
 
        public ActionResult Index()
        {
            IEnumerable<Post> posts = postRepository.All();
            return View(posts);
            
        }
 
        public ActionResult Create()
        {
            return View();
        }
 
        [HttpPost]
        [Transaction]
        public ActionResult Create(Post post)
        {
            postRepository.Add(post);
            return RedirectToAction("index");
        }

    }

Último Paso: Creando la Base de datos

Por último podemos crear la base de datos y sus tablas de forma manual o dejar que estas se creen automáticamente cuando se instancie por primera vez el DatabaseContext.

Con esto ya tenemos todo lo necesario para el manejo de la unidad de trabajo a nivel de request.
Hasta el siguiente post.

Saludos
Angel Núñez Salazar

Integración Continua – Resultado Final

2011-01-09T14:39:00.001-08:00

En este post veremos cuál es el resultado final al que llegaríamos si realizamos toda la configuración de nuestro proceso de integración continua.

Te recomiendo verlo activando la calidad HD

En la serie de posts sobre integración continua hablaremos con más detalle de todo lo visto en el video. No se lo pierdan.

Saludos.
Angel Núñez Salazar

Integración Continua Series

2011-01-09T13:03:00.001-08:00

Acá tenemos la lista de posts de la serie de Integración Continua.

Parte 1.- Introducción, Roles y Transformaciones XML
Parte 2.- Compilación y Transformaciones XML
Resultado Final

Saludos
Angel Núñez Salazar

Integración Continua – Parte 2

2010-12-21T23:35:00.001-08:00

Anteriormente vimos como podemos utilizar las transformaciones XML para manejar diferentes configuraciones en nuestras aplicaciones. Pero existe un problema con estas transformaciones: solo se realizan cuando publicamos o creamos un paquete de despliegue.

Esto impide los siguientes escenarios:

Aprovechar las configuraciones al momento de probar nuestra aplicación desde el mismo VS utilizando F5.
Utilizas las configuraciones desde diferentes proyectos para realizar pruebas de integración en diferentes ambientes utilizando alguna herramienta de testing.

Por suerte existe la capacidad de poder utilizar las transformaciones de manera independiente a una publicación, esto es posible gracias al task “TransformXML” de MsBuild.

    <TransformXml Source="{Source File}" 
                  Transform="{Transform File}" 
                  Destination="{Destination File}" />

El inconveniente con este task es que el “source file” y el “destination file” no pueden ser el mismo archivo Web.config. Esta dificultad la podemos solucionar si organizamos nuestros archivos de una manera diferente.

Para esto copiamos el archivo Web.config y a este nuevo archivo le cambiamos de nombre a Web.Template.config.

Editamos nuestro archivo de proyecto.

Y modificamos la sección donde se encuentran nuestros archivos config a lo siguiente.

<ItemGroup>
    <None Include="Web.Template.config" />
    <Content Include="Web.config">
      <DependentUpon>Web.Template.config</DependentUpon>
    </Content>
    <None Include="Web.Development.config">
      <DependentUpon>Web.Template.config</DependentUpon>
    </None>
    <None Include="Web.ContinuousIntegration.config">
      <DependentUpon>Web.Template.config</DependentUpon>
    </None>
    <None Include="Web.Production.config">
      <DependentUpon>Web.Template.config</DependentUpon>
    </None>
</ItemGroup>

De esta manera le indicamos al VS que agrupe todos nuestros archivos config dentro del Web.Template.config. Asimismo utilizamos el nodo Content únicamente en el Web.config para que todos los demás archivos se borren al momento de realizar una publicación.

Para lograr que la transformación se realice siempre e inmediatamente después de la compilación, descomentamos el target “AfterBuild” e incluimos dentro el task “TransformXML”.

Con esto el VS siempre que compile realizará una transformación utilizando el Web,Template.config como origen, utilizará el archivo de transformación correspondiente de acuerdo a nuestra configuración y dará como resultado un archivo Web.config.

Ahora que nuestra transformación se ejecuta al momento de compilar tenemos que evitarla al momento de publicar.

  <PropertyGroup>
    <TransformWebConfigEnabled>False</TransformWebConfigEnabled>
  </PropertyGroup>

Para finalizar y poder utilizar el task “TransformXml” lo importamos desde la instalación del VS.

Grabamos y cargamos nuevamente nuestro proyecto.

Para probar la transformación simplemente cambiamos de configuración.

Compilamos y al finalizar veremos que el contenido del Web.config ha sido el resultado de una transformación.

Resumen

Las transformaciones facilitan el manejo de múltiples configuraciones, pero existen algunos escenarios en los cuales necesitamos que estas no solo se realicen al momento de publicar. Utilizando los pasos anteriores podemos aprovechar las transformaciones también al momento de compilar y sin afectar la publicación.

Lo que se viene

En los siguientes post veremos como aprovechar estas transformaciones para realizar tareas más complejas utilizando MsBuild.

Saludos
Angel Núñez Salazar

Integración Continua - Parte 1

2010-12-21T16:53:00.001-08:00

El Problema

La mayoría de los proyectos de software tienen un retraso oculto desde el momento que el equipo dice “terminado” hasta que el software está realmente listo a ser potencialmente puesto en producción.

Una de las causas principales es que la integración del trabajo de todo el equipo se realiza al final de la iteración o inclusive del proyecto, esto ocasiona toda clase de problemas: falta de visibilidad del estado real (valor y calidad), errores en etapas finales el proyecto y excesivo tiempo al integrar el trabajo.

Integración Continua

La “Integración Continua” surge como una práctica en el desarrollo e software que pretende solucionar estos problemas.

“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build to detect integration errors as quickly as possible.” - Martin Fowler.

En su forma más simple esta práctica no requiere de herramientas complejas ni nada parecido, nada más se necesita constancia para integrar y verificar que se cumplen los estándares que el equipo establece.

La herramientas existen para simplificar y automatizar las tareas que son difíciles de realizar y que nos consumen mucho tiempo, siéntanse libres de utilizar las herramientas que más prefieran, por mi parte aprovechare esta serie de posts para mostrarles las que a mi me gustan.

Para esto reutilizaremos las fuentes de nuestro proyecto ASP.NET MVC “ThunderJob” que ya hemos estado avanzando anteriormente. Comenzemos!

Web.config Transformations

VS2010 trae una nueva característica que nos permite modificar nuestros archivos web.config (en general cualquier XML) de manera automática y con configuraciones diferentes para los ambientes de nuestra aplicación (desarrollo, test, producción, etc)

Lo que tenemos que hacer es crear los diferentes roles de configuración que va a tener nuestra aplicación, esto lo hacemos mediante el Configuration Manager:

Por defecto tenemos 2 roles: Debug y Release, pero podemos agregar o eliminar los que queramos. Para nuestro ejemplo vamos a modificar los roles de nuestra aplicación MVC de la siguiente manera:

Ahora lo que tenemos que hacer es producir un nuevo Web.config por cada configuración diferente.

Y nos dará como resultado

Si abrimos uno de los archivos generados (Web.Development.config) veremos que solo tiene un pequeño contenido y no todo el Web.config original.

Esto se debe a que las transformaciones del Web.config funcionan sobre un motor de transformaciones XML, el cuál toma el archivo original (Web.config), un archivo de transformación (Web.Development.config) y aplica la reglas que se encuentran en este último para generar un Web.config final.

Existen múltiples tipos transformaciones que podemos utilizar, en este artículo Web Deployment: Web.Config Transformation podremos encontrar información más detallada sobre estas.

Para probar nuestras transformaciones vamos a publicar nuestra aplicación. Para esto primero seleccionamos la configuración que queremos utilizar.

Y desde el VS publicaremos la aplicación a un directorio local.

Al dirigirnos al directorio destino y ver el contenido del archivo Web.config, nos daremos cuenta que el contenido de este ha sido modificado según la transformación correspondiente a nuestra configuración (Web.Development.config).

Resumen

Las nuevas transformaciones XML del VS2010 nos permite un mejor manejo de roles con diferentes propiedades para cada uno de los ambientes donde se vaya a desplegar nuestra aplicación.

Lo que se viene

A continuación veremos cuales son algunas de las limitaciones que tienen estas transformaciones y como podemos superarlas.

No se pierdan esta nueva serie de posts, saludos.
Angel Núñez Salazar

Taller de ASP.NET MVC

2010-12-05T15:29:00.001-08:00

Tengo el agrado de contarles la apertura del taller de ASP.NET MVC, donde podrán aprender el uso y la aplicación de esta gran tecnología.

Debido a varias sugerencias hemos decidido mover el inicio al 8 de enero ya que diciembre es un poco difícil para algunos y así nadie pueda perderse el taller.

El precio final se establecerá de acuerdo al número total de inscritos, así que inviten a sus amigos y compañeros de trabajo.

Pueden registrar su interés aquí: Taller ASP.NET MVC
No se pierdan esta gran oportunidad.

Saludos
Angel Núñez Salazar

Presentación Spring.NET

2010-12-04T16:08:00.000-08:00

Este 27 de noviembre se realizó el Spring Community Day 2010 en el cuál estuve dando una presentación sobre Spring.NET.

El código de la presentación lo podemos descargar desde GoogleCode con nuestro cliente de subversion favorito.
https://springperu.googlecode.com/svn/trunk/scd2010/spring-net

El evento fue totalmente orientado a gente Javera así que fue una presentación difícil de dar.

La presentación fue puramente código(desarrollo casi desde cero de una aplicación web con ASP.NET MVC y Spring). Esto resultó muy beneficioso para los que tenían experiencia en esta framework y así se dieran una idea de su uso en el mundo NET, pero creo que también fue muy complicada para los recién iniciados.

Saludos
Angel Núñez Salazar

¿Realmente sabes Refactorizar?

2010-10-17T23:45:00.001-07:00

Primero definamos algunos conceptos:

Smell: Indicador de que algo podría estar mal en nuestro código ( mal diseño, responsabilidades incorrectas, etc).
El lugar donde no queremos estar.
Refactoring: Cambios a la estructura interna del software con la finalidad de mejorarla y sin que se haya visto afectado su comportamiento.
El camino hacia…
Pattern: Solución reutilizable a un problema que se presenta de manera común en el diseño de software.
El lugar donde queremos estar.

Para cada uno de estos existen catálogos con listas innumerables, pero lo que no encontramos fácilmente es como aplicarlos correctamente. En este post nos vamos a enfocar en Refactoring y en algunas estrategias para su aplicación.

Las dos estrategias que veremos son: Paralell Change y Narrowed Change. Entonces, para que gastar más líneas si podemos verlo en el siguiente video:

Te recomiendo verlo en HD para una mejor calidad.

Para comprender cuál es la finalidad de todo esto les recomiendo ver “The Limited Red Society” del gran Joshua Kerievsky.

No se olviden de practicar sus refactorings y hasta el siguiente Post.
Saludos

Ágiles 2010: 3ras Jornadas Latinoamericanas sobre Metodologías Ágiles

2010-09-08T09:42:00.001-07:00

Ágiles 2010 es una excelente oportunidad para encontrase con profesionales de IT de la región, interesados en compartir sus experiencias, debatir y capacitarse en temas relacionados con el desarrollo de software a través del uso de metodologías ágiles.

Esta tercera edición, con sede en la ciudad de Lima, Perú, contará con la presencia de especialistas locales e internacionales, quienes compartirán su conocimiento durante los cuatro días que durará el evento.

El programa incluye distintos tipos de actividades: presentaciones, sesiones interactivas, talleres y espacios abiertos de debate.

Entre los invitados internacionales se encuentran los keynote speakers Lee Devin y Joshua Kerievsky, que también estarán brindando cursos durante el evento.

¡Inscríbete y se parte de Ágiles 2010!

ASP.NET MVC y otras Yerbas – Parte 7

2010-05-04T06:33:00.001-07:00

Como Configurar NHibernate “From Zero to Hero”

Seguramente lo que más confunde cuando alguien va a empezar con NHibernate es la gran cantidad de formas, colores y sabores que existen para integrarlo en la infraestructura y arquitectura de nuestra aplicación. A continuación solo una de ellas:

También pueden verlo en HD.

No se olviden de ver el resto de la serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos

ASP.NET MVC Series

2010-03-26T22:22:00.001-07:00

Acá tenemos la lista de posts de la serie ASP.NET MVC y otras Yerbas

Parte 1.- DDD (Domain Driven Design)
Parte 2.- Unit Testing and TDD (Test Driven Development)
Parte 3.- TDD: Kata Prime Factors
Parte 4.- Domain Services and Repositories
Parte 5.- Controllers and ViewModels
Parte 6.- Bootstrap MVC with IOC (Inversion of Control)
Parte 7.- Configure NHibernate

Saludos.

ASP.NET MVC y otras Yerbas – Parte 6

2010-03-26T20:58:00.001-07:00

Es hora de hablar sobre “Inversion of Control”:

El Problema

Qué observamos en el código anterior:

La clase SmtpClient está directamente referenciada por la clase HomeController y está última controla su creación, lo que tiene como consecuencia un fuerte acoplamiento entre estas dos clases.
La clase HomeController es consciente de la clase SmtClient y su funcionamiento, por lo tanto si alguna vez tenemos que realizar algún cambio sobre el envió de correo: como enviarlo por una cola de mensajes o incluso cambiar por una nueva librería, la clase HomeController se verá afectada.
Se dificulta la realización de pruebas sobre la clase HomeController.

La Solución

Si somos capaces de cambiar el control de la creación de la clase SmtpClient a una tercera entidad, podremos ver resuelto nuestro problema. Y esa solución es: Inversion of Control.

Inversion of Control

“Is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to traditional architecture of software”
Wikipedia

Podemos implementar este patrón de 2 maneras distintas:

Dependency Inyeccion

La idea es tener un objeto en el “mundo exterior” que se encargue de proveer o inyectar la implementación adecuada (EmailSender) a la clase listener (HomeController)

Service Locator

La idea es tener una entidad “dentro de la clase” que conozca cómo obtener la implementación adecuada que esta clase podría necesitar.

Ahora veamos cómo estas cosas se utilizan en nuestra aplicación de ejemplo y adicionalmente veremos como podemos configurarla para que levante y ejecute.

También podemos verlo en HD

No se olviden de ver el resto de la serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos

ASP.NET MVC y otras Yerbas – Parte 5

2010-03-05T12:15:00.001-08:00

Le llego el turno al Controlador y al ~~Modelo~~ ViewModel.

Para una mejor calidad también podemos verlo en HD.

Controlador.- Es el encargado de recibir y manejar las peticiones realizadas por los usuarios, y mostrar la vista adecuada.

ViewModel.- Es aquí donde viene el dilema. Comúnmente existe el problema en decidir cuál es la “M” dentro de nuestro modelo MVC. Es una entidad ?, un DTO ? , algo más ?.

Para algunos la “M” se refiere a una clase que ha sido diseñada para satisfacer las necesidades específicas de una vista en particular - “ViewModel”. Pero cuales son las razones que nos llevan a optar en utilizar una nueva clase únicamente para una vista, ya que esto supone un mayor esfuerzo (aparentemente):

A medida que las vistas se vuelven más complicadas es difícil mantener una sincronización entre las clases del dominio y las necesidades de la vista. Imaginemos una vista con un wizard que envía información sobre el paso al cual quiere ir el usuario, definitivamente no vamos a querer agregar esa información a una entidad del dominio ya que es únicamente de interés de la vista.

Muchas veces escribimos lógica innecesaria dentro de una vista, esto se puede representar en algo tan simple como: Html.Hidden(“id”,Model!=null?Model.ID:0) .Debido a que las vistas son difíciles de probar es recomendable mover esta lógica a otra clase que facilite esta tarea.

Al utilizar las entidades como “Model”, la vista tendrá conocimiento detallado de parte de dominio, lo cual para algunos puede significar que se daña de cierta manera la estructura y la arquitectura de la aplicación. Creo que esto no es más que otra decisión de diseño y esto lo podemos ver en varias aplicaciones antiguas, en especial aquellas que tienen a la base de datos relacional como centro de la aplicación y utilizan a las “entidades” como simples transmisores de datos. Después de vivir tantos años con estas aplicaciones podemos decir que las bases de datos relacionales no lo son todo en esta vida.

Los siguientes links tienen bastante información de los patrones que podemos utilizar para diseñar un ViewModel y las ventajas y desventajas de estos.

http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
http://blogs.msdn.com/simonince/archive/2010/01/26/view-models-in-asp-net-mvc.aspx

No se olviden de ver el resto de las serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos.

ASP.NET MVC y otras Yerbas – Parte 4

2009-12-15T21:47:00.001-08:00

Sin más que decir volvamos a la acción:

Para una mejor calidad también podemos verlo en HD.

A continuación tenemos una explicación de algunas de las cosas que hemos visto:

¿Cuál es la estructura de un test? Un Test tiene comúnmente la siguiente estructura:
- Arrange: Creamos todas las precondiciones y entradas necesarias.
- Act: Realizamos la acción en el objeto que estamos probando.
- Assert: Verificamos que los resultados que esperamos se han producido.
¿Qué es lo primero que hacemos para agregar alguna funcionalidad? Sin duda alguna, lo primero es realizar el Test.
¿Cómo nombramos al Test? Tener un estándar para los nombres de los test resulta importante ya que nos brinda un descripción entendible por propios y extraños sobre lo que realiza el test. Recuerden los Test son Documentación. La convención de nombre Método_Escenario_ComportamientoEsperado nos ayuda bastante a lograr lo anteriormente mencionado.
¿Qué es lo que probamos primero? De todas las opciones que tenemos, probamos la más simple, pero que cree funcionalidad real o valor.

Se acuerdan del Kata de Números Primos, la primera prueba que realizamos fue verificar que el número 1 nos devolvía una lista vacía. No comenzamos probando que el número 9 nos devolviera 2 primos, ni tampoco que un número menor a uno 1 arrojara una excepción.

Pero, ¿porqué comenzamos con la más simple?… Imaginen que hubiéramos comenzado probando cuales son los números primos de 9, la cantidad de código escrito habría sido mucho mayor en relación a una prueba de los números primos de 1 y por lo tanto habría transcurrido mucho más tiempo en completarse el ciclo de TDD ( Red – Green – Refactor) y en obtener el feedback que nos aporta el mismo.

Espérate un momento!, en el video no todas las pruebas han comenzado con la opción más simple….Tomemos como ejemplo un método que suma 2 números (x, y), entonces según lo dicho anteriormente el camino más simple sería crear un test que verifique 0+0=0 y en el código de producción retornamos 0, nuestro siguiente test podría ser que 1+0=1 y en el código de producción retornamos x, por ultimo probar que 2+1=3 y en el código retornamos x+y. (este camino se parece bastante a nuestro Kata verdad). Pero creo que todos sabemos que la implementación a un método de suma es x+y. Entonces en estos casos donde la implementación es un poco obvia, no tenemos que pedir permiso a varios test para poder escribir el código de producción.

Algo parecido sucede en nuestro ejemplo, ya que de alguna manera se tiene una noción de como los servicios y repositorios interactúan juntos; de igual manera, tampoco nos preocupamos de temas más complejos como validaciones ni reglas de negocios. Por lo tanto nos sentimos con cierto nivel de confianza para dar pasos ligeramente más grandes pero de manera muy rápida.

Como sabemos que podemos optar por esto, una pista muy simple la encontramos al escribir el test, si en ese momento nos ponemos a pensar mucho en los detalles (nombre, entradas, salidas) es una señal de que la implementación no es tan simple como parece. Asimismo si nos sentimos seguros de dar pasos más grandes y observamos que los test se rompen muy seguido, quizás debamos hacer pasos más pequeños.
¿Qué es lo primero que escribimos en el test? De abajo para arriba, lo primero es el Assert. Esta es una práctica que he encontrado muy útil, ya que al realizar el test, nuestro cerebro se pone a pensar muchas cosas al mismo tiempo: ¿cómo nombramos los elementos?, ¿cómo lo voy a verificar?, ¿qué me sugieren hacer los otros test?, etc.

Entonces al realizar el Assert primero, aislamos uno de los problemas del resto: ¿cómo lo voy a verificar?, y en base a esto construimos el resto del test:
- ¿Cómo lo voy a verificar? Probando que se llame al método Agregar del Repositorio.
- ¿Dónde se llama al método Agregar? Desde el método Registrar de la clase AdministrarEmpresa.
- ¿Qué se requiere para llamar al método Registrar? Pasarle un objeto Empresa.
Está práctica junto con la anterior convención de nombres son una combinación muy buena. Asimismo te permite aprovechar bastante las herramientas que te otorga el entorno de desarrollo (Resharper Rulz!).
Volvamos por un momento al post anterior, ahí hemos observado el uso de tests para construir una clase que no depende internamente de ninguna otra.

Pero en la cruel realidad no todo es tan bonito y simple. Las clases dentro de nuestras aplicaciones tienen dependencias para poder funcionar (bases de datos, web services, etc)

Y esto se pone peor, ya que esas dependencias tienen también sus dependencias, y estas dependencias tienen más dependencias y así sucesivamente. Entonces crear un test puede parecer que se vuelve en una tarea complejísima y posiblemente imposible.

¿Cuál es la solución? Eliminar esas dependencias, pero sin esas dependencias nuestra clase no va a funcionar, reemplacemos esas dependencias por algo más simple; y como hacemos para que la clase utilice esas nuevas dependencias, hagamos que el test sea quien controle esas dependencias:

Aquí es donde entran los famosos Test Doubles (“Generic term for any kind of pretend object used in place of a real object for testing purposes” – Martin Fowler ).

En nuestro ejemplo hemos usado 2 Test Doubles (Other Simple Class), esto debido a que necesitamos probar nuestras clases RegistrarEmpresa (Class Under Test) y ReclutarPersonal (Class Under Test), y ambas clases dependen de un implementación de IEmpresaRepository (Other Class) para persistir la información.

Estos Test Doubles los podemos identificar fácilmente ya que son los objetos que tienen los nombres más raros de todo el ejemplo: mockEmpresaRepository y stubEmpresaRepository.

Pero, ¿porqué uno se llama mock y el otro stub ? Para darnos cuenta entre la diferencia que tienen, podríamos definirlos de manera muy simple:
- Mock: Es el Test Double sobre el cuál realizamos un Assert. Ejm:
  mockEmpresaRepository.AssertWasCalled(x => x.Agregar(empresa));
  Estamos verificamos que el método Agregar del IEmpresaRepository se ha llamado dentro del método que estamos probando.
- Stub: Es el Test Double que nos permite poder realizar el test. Ejm:
  stubEmpresaRepository.Expect(x => x.Obtener(idEmpresa)).Return(empresa);
  Estamos indicando que cuando se llame el método Obtener del IEmpresaRepository nos devuelva una empresa cualquiera y así la prueba del método pueda continuar.

Bueno, hasta aquí hemos visto algunos temas del video, pero aún nos falta otros que dejaremos para un siguiente post. Espero les sirva de algo mi pequeño granito de arena. Y les prometo mejorar mi redacción.

No se olviden de ver el resto de las serie ASP.NET MVC y otras Yerbas.
Saludos.