Mixins

Los mixins se usan para poder inyectar el comportamiento (métodos) de una o más clases en otra.
Normalmente los usamos con el annotation @Mixin:
[groovy]
class Bird {
def fly(){
“Flying!”
}
}

class Fish {
def swim(){
“Swiming!”
}
}

@Mixin([Bird, Fish])
class Duck{
String name

def talk(){
“Cuack!”
}
}

def duck = new Duck()
assert “Flying!” == duck.fly()
assert “Swiming!” == duck.swim()
assert “Cuack!” == duck.talk()
[/groovy]

O también los podemos inyectar en runtime:
[groovy]
Duck.mixin Bird, Fish

def duck = new Duck()
assert “Flying!” == duck.fly()
assert “Swiming!” == duck.swim()
assert “Cuack!” == duck.talk()
[/groovy]

De esta manera podríamos implementar herencia múltiple en Java.

[Insertar 5 páginas de discusión sobre herencia múltiple aquí]

Que pasa si en un método del mixin queremos hacer referencia a un método o propiedad de la clase que lo implementa? Por ejemplo usar la propiedad name de Duck en el método fly. Quizás pensemos desde el mixin ejecutar super.name, pero siendo que no es una herencia, super no lleva a Duck.
Lo que hacemos es escribir los métodos del mixin como closures y dentro de los mismos podemos usar delegate para acceder a la clase en cuyo contexto esta corriendo el closure, en este caso Duck:
[groovy]
class Bird {
def fly = {
“Flying ${delegate.name}!”
}
}

…

def duck = new Duck(name: “Duckie”)
assert “Flying Duckie!” == duck.fly()
[/groovy]

Embedded

Embedded es una propiedad estática de las clases de dominio de Grails, la cual nos permite desnormalizar algunas propiedades en la base de datos.
Esto no afecta al modelo de objetos, las propiedades siguen siendo accedidas a través de la relación con la otra clase.
[groovy]
class Lake{
def address
}

class Duck{
String name
Lake lake
static embedded = ['lake']
}
[/groovy]

Esto generaría la tabla DUCK con las columnas: NAME y LAKE_ADDRESS.
Aun así se accedería a la dirección como duck.lake.address.

Delegate

Delegate nos permite muy fácilmente implementar un wrapper de un objeto. Simplemente agregamos el annotation @Delegate delante de la propiedad que hace referencia a otra clase, y de esta manera todos los llamados a los métodos de la clase referenciada se delegan a esta:
[groovy]
class Nest{
int eggs
}

class Duck{
@Delegate Nest nest
}

def nest = new Nest(eggs: 3)
def duck = new Duck(nest: nest)
assert 3 == duck.eggs
[/groovy]

Eventos de GORM

Si bien se usa Hibernate como implementación de ORM y tenemos acceso a los eventos del mismo, Grails ademas expone sus propios eventos de ORM para implementar:

• beforeInsert
• beforeUpdate
• beforeDelete
• beforeValidate
• afterInsert
• afterUpdate
• afterDelete
• onLoad

Es importante aclarar que se ejecutan los eventos mientras se hace un flush de la transacción de Hibernate. Para persistir cualquier cambio en otro objeto es necesario abrir otra transacción usando el método withNewSession. Por ejemplo:
[groovy]
class Duck {
String name
String type
def beforeInsert(){
type = “Baby duck”
Notification.withNewSession {
new Notification(message: “New baby duck is born!”).save()
}
}
}
[/groovy]

Llevándolo a la práctica

Vamos a ver un ejemplo real para implementar información de auditoria en una clase de dominio, usando algunas de estas funcionalidades. La idea es agregar las propiedades modificationDate y modificationUser cada vez que se crea o actualiza una entidad. Normalmente haríamos algo como:
[groovy]
class Duck {
String name

// Auditory code
Date modificationDate
User modificactionUser

def beforeUpdate() {
modificationDate = new Date()
User.withNewSession {
modificationUser = userService.getCurrentUser()
}
}
}
[/groovy]
Pero esto no seria reusable, tendríamos que repetir la misma lógica en cada entidad que queramos hacer auditable.
Aprovechando lo que vimos podemos definir 2 clases mas:
[groovy]
class UpdateData {
Date modificationDate
User modificactionUser
}

class Auditable {
def beforeUpdate = {
delegate.modificationDate = new Date()
User.withNewSession {
delegate.modificationUser = userService.getCurrentUser()
}
}
}
[/groovy]

Y de esta manera podemos reusar esta lógica en otras clases de dominio:

[groovy]
@Mixin(Auditable)
class Duck {
String name

// Auditory code
@Delegate UpdateData updateData = new UpdateData()
static transients = ['updateData']
}
[/groovy]

Nota: Agregamos la propiedad updateData como transient para que no intente crear una relación entre ambas clases. Solo queremos incluir las propiedades de UpdateData en las entidades de dominio.

La idea general de este post es generar una serie de tips o recomendaciones dadas por haber transitado por un proyecto en estas tecnologías.

Este blog no pretende enseñar a usar django ni python, para eso existen un montón de sitios que lo hacen muy bien. Simplemente se pretende recomendar algunas cuestiones relacionadas con el ambiente de desarrollo y decisiones generales.

virtualenv

virtualenv es una herramienta para la gestión de las distintas versiones de python que se puedan necesitar.
Te permite tener distintos ambientes configurados dentro de una misma máquina, pudiendo switchear entre ellos y probar el mismo proyecto con distintas versiones de python, django o cualquier otra librería.

[bash]sudo pip install virtualenv virtualenvwrapper[/bash]
A modo ejemplo defino que para un proyecto dado (prrac) se utilizará la versión 2.6 de python (por defecto Ubuntu tiene la 2.7):
[bash]virtualenv prrac –python=/usr/bin/python2.6 –distribute[/bash]
y luego la utilizo:
[bash]workon prrac[/bash]
Más Info

pip

pip es una herramienta para la gestión de las librerías de python, actualmente tiene alrededor de 30.000 librerías.
Es de muy fácil instalación y de muy fácil uso:
[bash]sudo apt-get install python-pip python-dev build-essential[/bash]
Y luego por ejemplo:
[bash]pip install simplejson[/bash]
[bash]pip install mock[/bash]
[bash]pip install django[/bash]
[bash]pip install django-facebook-api[/bash]
Más Info

PyCharm

PyCharm no tiene nada que envidiarle a eclipse para java, y sin duda es muy superior a cualquier plugin que éste último pudiera incorporar.
Más Info

South

Si alguien quisiera llevar en todo momento el versionado de la base de datos sincronizado con el código, ésta es la herramienta.
Más Info

ipython

Es un plugin para agregarselo a la consola de django en la cual se puede ejecutar código python y utilizar la base de datos con el modelo de negocio.
Más Info

REST + json

En líneas generales no existen archivos XML, si existen configuraciones y demás cuestiones, pero están en archivos de python .py.
En caso de necesitar servicios web, si bien existen librerías para SOAP, lo más recomendado es utilizar REST + json.

Levantar el servidor en tan solo 3 segundos

Sacando ventaja de python como lenguaje interpretado, levantar el servidor “cuesta” 3 segundos, y si la aplicación creciera 100 veces, también seguiría costando lo mismo levantar el servidor.

Resumen final: es sin duda una alternativa excelente para la construcción de aplicaciones web.

• List, ver un listado de la entidad.
• Show,  mostrar el detalla de una entidad.
• Create, crear la entidad.
• Save, grabar una entidad por primera vez.
• Edit, editar la entidad.
• Update, grabar los cambios que realizamos en una entidad.
• Delete, eliminar una entidad.

Grails provee un template predefinido con el comportamiento que van a tener los ABMs y sus flujos de pantallas. Si se requiere que esto sea distinto (a nivel aplicación), una propuesta es cambiar esos templates.

En lugar de eso, nuestra propuesta es crear unas pocas vistas y un controlador generales, que necesiten ser extendidos con un mínimo esfuerzo para cada nuevo ABM del sistema. Esto posibilita a su vez reunir el comportamiento común, y que sea fácil cambiarlo consistentemente a toda la aplicación.

El controlador mencionado, al cual nombramos ABMController, es una clase abstracta generada inicialmente a partir del template de controller de Grails, y que luego se fue generalizando para armar una jerarquía de controladores, que en principio sólo necesiten redefinir unos pocos y simples métodos abstractos. También se generaron otros métodos necesarios para todas las pantallas, fuera del estándar de Grails , como por ejemplo, exportar (nos permite a partir del uso de un plugin, exportar el contenido de la lista de la entidad a un documento .xls, pdf, entre otros). A continuación vemos el código principal de esta clase:

[groovy]
abstract class ABMController implements GroovyObject {
static allowedMethods = [save: 'POST', update: 'POST', delete: 'POST']

static final protected String LIST = ‘list’

def exportService

def excelExportService

def filterPaneService

def index() {
redirect(action: LIST, params: params)
}

def list() {
if(!params.max) params.max = 10
if(!params.offset) params.offset = 0

if(isExportacionRequerida()){
params.max = null

if (params.filter) {
exportar(filterPaneService.filter(params, entidadClass))
} else {
exportar(entidadClass.findAll(params))
}
}
def parametros = [entidad: entidad, entidadClass: entidadClass, propiedades: propiedades]

if (params.filter) {
parametros['listaEntidad'] = filterPaneService.filter( params, entidadClass )
parametros['cantEntidad'] = filterPaneService.count( params, entidadClass )
parametros['filtroParams'] = org.grails.plugin.filterpane.FilterPaneUtils.extractFilterParams(params)
} else {
parametros['listaEntidad'] = entidadClass.findAll(params)
parametros['cantEntidad'] = entidadClass.count()
}
beforeList(parametros['listaEntidad'])
renderList(parametros)
}

/** Devuelve true si llega un request de exportacion de la tabla */
boolean isExportacionRequerida() {
params?.format && params.format != ‘html’
}

def exportar = { datosAExportar ->
excelExportService.export(response, params, entidadClass, propiedades, entidad, datosAExportar)
}

def create() {
beforeCreate()
def entidadInstance = entidadClass.newInstance(params)
renderCreate(entidadInstance)
}

def edit(Long id) {
def entidadInstance = entidadClass.get(id)
if (!entidadInstance) {
setErrorMessage(‘default.not.found.message’, id)
redirect(action: LIST, params: getRedirectParams())
return
}
beforeEdit()
renderEdit(entidadInstance)
}

def save() {
def entidadInstance = entidadClass.newInstance(params)
beforeSave(entidadInstance)
if (!entidadInstance.save(flush: true)) {
renderCreate(entidadInstance)
return
}

setInfoMessage(‘default.created.message’, entidadInstance.id)
redirect(action: LIST, params: getRedirectParams())
}

def update(Long id, Long version) {
def entidadInstance = entidadClass.get(id)
if (!entidadInstance) {
setErrorMessage(‘default.not.found.message’, entidadInstance.id)
redirect(action: LIST, params: getRedirectParams())
return
}

if (chequearConcurrencia(entidadInstance, version)) {
return
}

entidadInstance.properties = params
beforeSave(entidadInstance)

if (!entidadInstance.save(flush: true)) {
renderEdit(entidadInstance)
return
}

setInfoMessage(‘default.updated.message’, entidadInstance.id)
redirect(action: LIST, params: getRedirectParams())
}

def delete(Long id) {
def entidadInstance = entidadClass.get(id)
if (!entidadInstance) {
setErrorMessage(‘default.not.found.message’, id)
redirect(action: LIST, params: getRedirectParams())
return
}

try {
entidadInstance.delete(flush: true)
setInfoMessage(‘default.deleted.message’,id)
redirect(action: LIST, params: getRedirectParams())
}
catch (DataIntegrityViolationException e) {
setErrorMessage(‘default.not.deleted.message’, id)
redirect(action: ‘edit’, id: id)
}
}
abstract protected List getPropiedades()

abstract protected String getEntidad()

abstract protected Class getEntidadClass()

protected String getForm() {
‘/forms/’ + entidad
}

private String getEntidadLabel() {
entidad + ‘.label’
}

protected String getPlugin(){
“general”
}
}
[/groovy]

Para crear el ABM genérico definimos los métodos:

• comunes a todos los controller, como el list, create, save, edit, update y delete.
• abstractos getPropiedades, getEntidad y getEntidadClass,
• concretos getForm, getEntidadLabel y getPlugin

Los controllers hijos que necesitan heredar dicha funcionalidad, deben definir ciertos métodos que son utilizados en la clase padre Por ende, debemos definir los métodos como

• getPropiedades: define los atributos de la clase entidad como string. Se envian al gsp para su utilización.
• getEntidadClass(): es el .class utilizado para obtener todas las instancias de la entidad u obtener una única instancia enviada como parámetro desde el gsp, para su edición o eliminación.
• getEntidad: string que se envía al gsp, para su utilización.
• getPlugin (opcional) explicar cuando se debe usar.

Luego, en nuestro caso, se generalizaron tres gsp:

• list.gsp
• edit.gsp
• create.gsp

En el list.gsp, se definió para la cabecera un each que recorre las propiedades definidas en el getPropiedades:

[html]

<thead>
<tr>
<g:each in=”${propiedades}” status=”i” var=”propiedad”>
<g:sortableColumn property=”${propiedad}”
title=”${message(code: entidad+’.'+propiedad+’.label’, default: propiedad)}” />
</g:each>
<g:set var=”headerColumna” value=”Eliminar” />
<gna:hasProperty object=”${entidadClass}” property=”habilitado”>
<g:set var=”headerColumna” value=”Habilitado” />
</gna:hasProperty>
<th>
${headerColumna}
</th>
</tr>
</thead>

[/html]

Tambien se creo el metodo hasProperty en el caso de que un columna se necesite para ciertas entidades que las posee. Esto incluye setear ciertas variables declaradas en nuestro gsp para modificar cualquier atributo de un elemento html.

[html]

<gna:hasProperty object=”${entidadInstance}” property=”habilitado”>
<g:set var=”clase”
value=”${entidadInstance?.habilitado == false ? ‘disable’ : (i % 2) == 0 ? ‘even’ : ‘odd’}” />
</gna:hasProperty>

[/html]

Luego enviamos una lista con un nombre genérico, sin importar de qué tipo es, que van a ser cada una de las filas de la grilla.

[html]

<g:each in=”${propiedades}” status=”s” var=”propiedad”>
<td>
${fieldValue(bean: entidadInstance, field: propiedad)}
</td>
</g:each>

[/html]

Cabe aclarar, que en el ABMController, al realizar el render genérico, se envían parámetros genéricos, que representa cada uno de los parámetros en manera general y no de manera particular a la entidad.

[groovy]

protected renderList(parametros) {
render(view: ‘/abm/list’, model: parametros)
}

[/groovy]

En el create.gsp, cabe destacar, el uso del parámetro forms, el cual es enviado como parámetro desde el ABMController. El método que lo define, utiliza la entidad declarada como string en la clase hija, por lo tanto, el gsp definido debe ser nombrado con el nombre de la entidad. También debemos enviar el plugin como parámetro, en caso de que el formulario estén en un plugin distinto al controller. En el edit, la utilización de los parámetros, es muy similar al del create.

[groovy]

protected String getForm() {
‘/forms/’ + entidad
}

[/groovy]

También se puede generalizar el seteo de la variable flash del controller para los mensajes de error o de otro tipo, por ejemplo, mensajes de información.

[groovy]

private setErrorMessage(String code, Long id) {
flash.message = message(code: code, args: getEntidadConIdMessageArgs(id))
}

private setInfoMessage(String code, Long id) {
flash.info = message(code: code, args: getEntidadConIdMessageArgs(id))
}

[/groovy]

Si tenemos algún comportamiento específico de un entidad en alguna de las acciones definidas en el ABMController, se puede redefinir el método que representa a la acción, en la clase hija. También se pueden agregar acciones que no afecten al comportamiento de las anteriores.

Dentro de cada método, se definieron los métodos abstractos beforeSave, beforeEdit, etc.Los mismos son redefinidos, en caso de ser necesario, en cada clase hija, principalmente para setear atributos o agregar cierta lógica, antes de realizar la acción que se requiere realizar.

Como conclusión, gracias al Scaffolding y a los templates que podemos modificar, Grails nos provee una fuerte herramienta para poder personalizar los ABMs. Nosotros lo que tratamos de hacer, fue dar un pasito mas y abstraernos de funcionalidades comunes en toda nuestra aplicación. Esto nos permitió crear ABMs en cuestión de minutos, solamente heredando y definiendo un solo .gsp.

Qué es y para qué sirve?

Es una herramienta para hacer migraciones sobre una Base de Datos Relacional. Nos permite manejar el “versionado” de una Base de Datos para poder facilitar las tareas para hacerlo y no depender del trabajo manual de generar scripts con cambios incrementales, versionarlos, ponerlos en el orden indicado para ser corridos, y un largo listado de etcéteras.

Esta herramienta nos provee de:

• Una API para definirlas
• Un ejecutable de línea de comandos para correrlas
• Y un DSL (Domain Specific Language) para declarar cada sentencia de la migración. Haciendo honor a su nombre, expone una interfaz fluida q nos permite fácilmente declarar estas sentencias de forma muy similar a cómo lo haríamos en SQL pero con la ventaja que tenemos un chequeo estático de tipos.

Está inspirado de rails: http://guides.rubyonrails.org/migrations.html

Cómo se instala?

La instalación para Visual Studio es muy fácil.

Primeramente, puede instalarse desde el siguiente link de NuGet: http://visualstudiogallery.msdn.microsoft.com/en-us/27077b70-9dad-4c64-adcf-c7cf6bc9970c/file/37502/5/NuGet.Tools.signed.vsix

Luego, para utilizarlo debemos crear un proyecto para nuestras migraciones. En este caso, corresponde que creemos un Class Library Project

Luego, desde la consola del package manager tipear:

• PM> Install-Package FluentMigrator
• PM> Install-Package FluentMigrator.Tools -> para poder correr las migraciones desde la línea de comandos

Y listo, ya estamos listos para empezar!

Fluent Interface

Como mencionamos escuetamente al principio de este post, FluentMigrator expone una interfaz fluida que permite declarar sentencias de forma muy similar a cómo lo haríamos en SQL.

Como por ej:

• Podemos crear tablas con un simple:
  Create.Table("TableName")
.WithColumn("ColumnName").AsInt64().NotNullable().PrimaryKey().Identity();
.WithColumn("AnotherColumnName").AsString().NotNullable();
• O podemos renombrar tablas con un simple:
  Rename.Table("TableName").To("AnotherTableName");

Para más ejemplos de posibles sentencias pueden dirigirse al siguiente link:https://github.com/schambers/fluentmigrator/wiki/Fluent-Interface

Cómo definir una migración?

Esencialmente para definir una migración necesitamos de:

• Una clase que cuente con 2 métodos : Up( ) and Down( ), y el número de versión de migración.
  Una vez que tenemos estos métodos definidos para cada migración, es que podremos “ir y venir” en las migraciones sin problemas desde cualquier punto.
  Por supuesto, teniendo cuidado en dichas migraciones  la pérdida de datos. Es probable que necesitemos backpups de los mismos.
• Un archivo de configuración (App.config) que cuente con el connection string a la base.
  A decir verdad, este archivo de configuración no es estrictamente necesario. El connection string puede explicitarse por línea de comandos sin necesidad de ser incluido en un App.config

A continuación les comparto mi clase y mi archivo de configuración de mi proyecto MyExample.

Y a todo esto… cómo se corre esta cosa?

Buena pregunta!

En una línea de comando escribimos:

> PathDelArchivo"Migrate.exe" -a PathDeLaDll -db NombreDelMotor -conn NameDelConnectionString

En mi caso de MyExample sería:

C:\Users\user\Documents\Visual Studio 2012\Projects\MyExample\packages\FluentMigrator.Tools.1.0.6.0\tools\x86\40> Migrate.exe -a "C:\Users\user\Documents\Visual Studio 2012\Projects\MyExample\MyExample\bin\Debug\MyExample.dll" -db sqlserver2008 -conn "DataAccess.AppConnectionString"

Y el resultado es el siguiente:

Si vamos a la Base de Datos en cuestión para ver si efectivamente se realizaron los cambios correspondientes, veremos que:

• Se han creado las tablas correspondientes
• Se han insertado los datos correspondientes

Problemas frecuentes

Un problema con el que nos topamos es que en mucha de la información que hay en Internet, mencionan que es necesario escribir en la línea de comandos el nombre del archivo de configuración  en lugar de decir: el nombre del connection string que pusimos en el archivo de configuración.

Attenti con eso!

Información extra

FluentMigrator tiene algunas cosas interesantes que pude descubrir.

Vamos a mencionar 2 de ellas:

• Profiles: Se usa para migraciones que aplican selectivamente. Por ej, se puede definir un Profile para Desarrollo y otro para Testing. Estos Profiles se corren si se especifican.
• Extensions: Cuenta con algunas extensions copadas. Para más información ver: https://github.com/schambers/fluentmigrator/blob/master/src/FluentMigrator.Example/FluentMigrator.Example/Migrations/MigrationExtensions.cs

Esto ha sido una reseña de FluentMigrator. Más información: https://github.com/schambers/fluentmigrator

1 – “Quiero usar un slider, pero no quiero que aparezca el input con el valor”

Cuando usamos agregamos un slider a nuestra aplicación lo hacemos de la siguiente manera:

[html]
Input slider:

Y el resultado es el siguiente:

Pero quizás no queremos tener el input con el valor numérico, solamente queremos el slider. Para quitarlo tenemos que agregar display:none al style del input. De esa manera no se muestra más el input numérico:

[html]
Input slider:

2 – “Agrego contenido dinámico a mi listview pero aparece sin formato”

Quizás tenemos una lista vacía en nuestro HTML que llenamos dinámicamente con datos, como en el siguiente ejemplo:
[html]

[/html]
Y usamos un script como el siguiente:
[javascript]
$(“#resultados”).on(“pageshow”,function(){
$.ajax({
url: “http://someserver/resultados.json”,
success: function(data){
var lista = $(“#lista”);
$(data).each(function(i, resultado){
lista.append(“

“);
});
}
});
});
[/javascript]
Pero cuando lo ejecutamos obtenemos lo siguiente:

El problema es que cuando agregamos elementos a la lista, jQuery Mobile ya renderizo la página y sus componentes, entonces los nuevos componentes no tienen aplicados los estilos de jQuery Mobile.
Para solucionar esto simplemente ejecutamos el metodo listview(“refresh”) sobre la lista, así se vuelve a renderizar la misma incluyendo los elementos que se agregaron:
[javascript]
$(“#resultados”).on(“pageshow”,function(){
$.ajax({
url: “http://someserver/resultados.json”,
success: function(data){
var lista = $(“#lista”);
$(data).each(function(i, resultado){
lista.append(“

“);
});
lista.listview(“refresh”);
}
});
});
[/javascript]

3 – “Quiero que el header y/o el footer aparezcan en un extremo de la pantalla y no scrolleen”

Por default el header y footer de una pagina están ubicados inmediatamente antes y después del content, con lo cual su posición depende del contenido del mismo y están sujetos al scroll si lo hubiere.
Si en alguna de las 2 secciones tenemos contenido relevante quizás queramos que aparezcan fijos al principio y final de la pantalla y no dependan del scroll. Para eso usamos el atributo data-positon=”fixed” que cumple exactamente esa función. Ejemplo:
[html]

[/html]

4 – “Quiero reutilizar un footer en varias paginas de mi aplicación”

Actualmente jQuery Mobile no soporta reutilizar el footer o header en varias paginas. Pero podemos lograr el mismo efecto con un poco de código de jQuery.
Primero tomamos el codigo del footer que vamos a reutilizar y lo anidamos en un div que no se muestre:
[html]

[/html]

Luego en nuestras paginas creamos el footer pero lo dejamos vacío:
[html]

[/html]
Finalmente, cuando se crea cada pagina vamos a tomar el codigo del div oculto y lo vamos a copiar a los footers vacios, con el siguiente javascript:
[javascript]
$(document).on(“pagebeforecreate”, function(){
$(“div[data-role='footer']:empty”).parent().on(“pagecreate”,function(eventObject){
$(eventObject.target).children(“div[data-role='footer']“).html($(“#myFooter”).html());
});
});
[/javascript]
Hay varias cosas para aclarar acá:

• El selector div[data-role='footer']:empty va a obtener todos los footers que estén vacíos
• De esos footers vacíos obtenemos el padre, es decir la page, y le agregamos un handler que se va a ejecutar con el evento pagecreate de la página
• El handler va a tomar el código de nuestro div oculto ($(“#myFooter”).html()) y lo va a copiar en el footer de la pagina cuando se crea ($(eventObject.target).children(“div[data-role='footer']“).html( … );)
• Finalmente, esta registración del handler se va a hacer durante el evento pagebeforecreate del document, que se ejecuta antes del pagecreate de cada página

5 – “Me da un error cuando quiero navegar a otra pagina que esta en otro archivo html”

No es un tema de jQuery Mobile, pero es común toparse con este error al navegar a otra página contenida en otro html:

XMLHttpRequest cannot load file:///….html. Origin null is not allowed by Access-Control-Allow-Origin.

Básicamente es un feature de los browsers que, por seguridad, impiden obtener recursos de otro dominio distinto.
Más detalles: http://www.w3.org/TR/cors/.
Esto aplica a los requests por Ajax, como los que usa jQuery Mobile para la navegación entre páginas.
La solución más simple es no abrir los archivos desde el filesystem y en vez usar un webserver (Apache, IIS, etc) y acceder a la página a traves del mismo desde una url.

Introducción

Integración con MVC

[csharp]
protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
    FluentValidationModelValidatorProvider.Configure();
}
[/csharp]

[csharp]
[Validator(typeof(ContactValidator))]
public class Contact
{
    public int Id { get; set; }

    [DisplayName("First Name")]
    public string FirstName { get; set; }

    [DisplayName("Last Name")]
    public string LastName { get; set; }

    [DisplayName("Nick")]
    public string NickName { get; set; }

    [DisplayName("Email Address")]
    public string EmailAddress { get; set; }
}
[/csharp]

[csharp]
public class ContactValidator : AbstractValidator<Contact>
{
    public ContactValidator()
    {
        RuleFor(contact => contact.FirstName).NotNull();
        RuleFor(contact => contact.LastName).NotNull();
        RuleFor(contact => contact.NickName).NotNull();
        RuleFor(contact => contact.EmailAddress).EmailAddress();
    }
}
[/csharp]

FluentValidation - Create Contact

Condicionales y Validadores

Acá es donde se ve la parte más poderosa de este framework. En FluentValidation podemos definir condicionales sobre nuestras validaciones (por ejemplo: Validar que la fecha de nacimiento no sea nula sólo si el usuario marcó que es mayor de 18 años). Hacer algo así con el esquema de validación estándar de MVC 4 es algo imposible sin ensuciar mucho el código, ya que no está soportado como parte del framework. FluentValidation incorpora condicionales (when, unless) y varios validadores (NotNull, NotEmpty, Email, etc).

Digamos que introducimos en nuestro proyecto una nueva entidad, Address, y la asociamos a Contact, en el momento de validar una dirección nos va a interesar que la primera línea de la misma no sea nula sólo si la segunda línea tiene contenido.

[csharp]
using Contacts.Models;
using FluentValidation;

namespace Contacts.Validators
{
    public class AddressValidator : AbstractValidator<Address>
    {
        public AddressValidator()
        {
            RuleFor(address => address.FirstLine).NotNull()
                .Unless(address => !string.IsNullOrEmpty(address.SecondLine));
            RuleFor(address => address.City).NotNull();
            RuleFor(address => address.SubnationalEntityId).NotNull();
        }
    }
}
[/csharp]

Conclusión

En esta (muy) breve introducción a FluentValidation hemos visto lo fácil que es generar validaciones complejas de manera muy prolija en nuestros proyectos. Espero que esto los motive a pasarse por el sector de documentación del proyecto en CodePlex y vean que lo que mostramos acá es sólo “la punta del iceberg”.

Pero que pasa con la base de datos? Muchas veces esos cambios impactan en la estructura de la base de datos, por ejemplo al agregar o quitar atributos a persistir. Estas modificaciones a la base de datos tienen que estar a su vez asociadas a una versión específica del código para que la aplicación funcione. Y ademas suele haber varias instancias de la base de datos (en distintos ambientes como desarrollo, test, producción, etc), en las cuales es necesario impactar los cambios al deployar una nueva versión del código.
Todo esto implica mucho trabajo manual de generar scripts con cambios incrementales, secuenciarlos, versionarlos y, al deployar la aplicación en un nuevo ambiente, analizar que versión de la base de datos esta instalada y cuales son los cambios que deberían impactarse en la misma.
Para simplificar esta problemática tenemos Liquibase.

Qué es Liquibase?

Liquibase es una librería que nos permite llevar a cabo cada una de estas tareas. Para eso usa archivos XML llamados Changelogs que contienen los cambios a aplicar en la base de datos en una manera legible y “human friendly”. Sobre estos changelogs podemos ejecutar distintos comandos:

• Generate Changelog: Para generar un nuevo changelog a partir de una DB existente. Suele ser útil cuando queremos empezar a usar Liquibase en una aplicación que ya tiene una DB creada
• Diff: Si bien lo normal sería agregar manualmente los cambios al changelog a medida que surgen, es posible generarlos a partir de un diff entre la DB donde queremos aplicarlos y otra DB de referencia con los cambios aplicados, o los mapeos de Hibernate de nuestra aplicación.
• Update: Aplicar los cambios necesarios a una DB. Liquibase automáticamente evalua cuales son los cambios que es necesario aplicar y los ejecuta en secuencia.
• Rollback: A veces los cambios que hacemos en la aplicación no suelen funcionar como esperábamos y necesitamos hacer un rollback de la aplicación deployando una versión anterior. Liquibase nos permite hacer lo mismo con los cambios en la base de datos, haciendo un rollback a una versión anterior.

Para los últimos 2 comandos es posible generar un script SQL en vez de aplicar los cambios directamente en la DB, en caso de que queramos revisarlos primero.
Ademas es posible ejecutar Liquibase de 3 formas:

• Desde linea de comandos
• Como una tarea de Ant
• Como un plugin de Maven

Como implementarlo?

Vamos a ver un ejemplo del uso típico de Liquibase.

Setup

Descargamos Liquibase y al descomprimir el archivo obtenemos un jar y un bat para ejecutarlo. Normalmente agregamos el directorio al path del sistema para poder ejecutar los comandos desde cualquier directorio.
Vamos a crear un directorio dentro de nuestra aplicación donde guardar los changelogs, y creamos el changelog-master.xml principal vacío:
[xml]



[/xml]

Changelog inicial

Para esto usamos el comando generateChangeLog:

liquibase --driver=org.postgresql.Driver --classpath=postgresql-9.1-901.jdbc4.jar --changeLogFile=changelog.xml --url="jdbc:postgresql://localhost:5432/db_test" --username=test --password=test generateChangeLog

O para simplificar podemos guardar todos esos parámetros en un liquibase.properties en el directorio donde lo ejecutamos:

driver=org.postgresql.Driver
classpath=postgresql-9.1-901.jdbc4.jar
changeLogFile=changelog-base.xml
url=jdbc:postgresql://localhost:5432/db_test
username=test
password=test

Y ejecutamos:

liquibase generateChangeLog


Luego agregamos la referencia del changelog generado a nuestro changelog-master.xml:

[xml]




[/xml]

Generando cambios en el esquema

Si por ejemplo estamos desarrollando un requerimiento en el cual se agregan los atributos fecha y estado a la clase Pedido y borramos edad en la clase Persona, generaríamos un nuevo changelog con los siguientes datos:
[xml]



Agrego fecha y estado a pedido

Con NDepend, la calidad del software se puede medir con métricas, visualizándola en gráficos y diagramas de árbol, y cumpliendo con normas/reglas estándares y personalizadas.

La herramienta también realiza instantáneas de código, de comparación y validación de reglas arquitectónicas y de calidad. Se pueden escribir reglas definidas por el usuario, utilizando consultas LINQ.

Esta posibilidad se denomina CQLinq. La herramienta también viene con un gran número de reglas predefinidas de código CQLinq.

Dichas reglas de Código se pueden comprobar automáticamente en Visual Studio o durante la integración continua.

En las primeras versiones se usaba como un complemento externo al Visual Studio, ahora, la herramienta tiene un plugin completamente integrada al Visual Studio.

Las principales características de NDepend son:

• Visualización de dependencia (usando gráficos de dependencia, y matriz de dependencia).

• Métricas de software (NDepend actualmente soporta 82 métricas de código:. Cyclomatic complexity; Afferent and Efferent Coupling; Relational Cohesion; Google page rank of .NET types; Percentage of code covered by tests, etc.).

• Regla de código declarativo sobre consulta LINQ (CQLinq).

• Integración con CruiseControl y TeamCity.

• Restricciones opcionales de código en el código fuente con los atributos de CLI.
• Comparación de versión de dos versiones del mismo asembly.

Desde la versión 4 NDepend, la herramienta de consulta propone live code query y reglas de código a través de consultas LINQ. Esta es una de las innovaciones de NDepend. Por ejemplo:

- La clase base no debe usar derivados:

// Base class should not use derivatives
warnif count > 0
from baseClass in JustMyCode.Types
where baseClass.IsClass && baseClass.NbChildren > 0
select new { baseClass, derivedClassesUsed }

- Evite hacer complejos métodos aún más complejo (complejidad ciclomática del código fuente)

//Avoid making complex methods even more complex (Source CC)
warnif count > 0
from m in JustMyCode.Methods where
!m.IsAbstract &&
m.IsPresentInBothBuilds() &&
m.CodeWasChanged()
let oldCC = m.OlderVersion().CyclomaticComplexity
where oldCC > 6 && m.CyclomaticComplexity > oldCC
select new { m,
oldCC,
newCC = m.CyclomaticComplexity,
oldLoc = m.OlderVersion().NbLinesOfCode,
newLoc = m.NbLinesOfCode,
}

En el siguiente link, muestra los features que contiene la herramienta NDepend.

http://www.ndepend.com/Features.aspx

¿Qué me dice el informe NDepend acerca de mi código? 

Application Metric: Esta sección le da una idea de la topología de su aplicación.

Assembly Metric: Esta sección le da una idea del tamaño de cada conjunto en su aplicación en términos de instrucciones #IL y otras métricas.

VisualNDepend View:  En esta sección se ilustra el tamaño de sus asamblies, namespaces, types y methods en términos de instrucciones #IL . Se puede browsear por esta vista dinámica haciendo clic en el  Launch Visual NDepend en este icono de NDepend.Project UI.

Assembly Abstracness vs. Instability: En esta sección se ilustra el principio Abstracness / Inestabilidad se explica en la sección Assembly Metric.

Assembly Dependencies: Esta sección muestra todas las dependencias entre las asambleas de su aplicación en una tabla.

Assembly Dependency Diagram: Esta sección muestra todas las dependencias entre las asambleas de su aplicación en un diagrama.

Assembly build order: Esta sección ofrece uno de las posibles build order de los assemblies. Si existe un ciclo en el gráfico de dependencias de los assemblies, esta sección lo informa.

NDepend information and warnings: Esta sección le da consejos acerca de su código:

Le avisa cuando un assembly depende de un assembly menos estable que el mismo.

Le advierte cuando la visibilidad de un tipo o de un miembro no es óptima (en el contexto de la aplicación analizada).

Le avisa cuando un tipo o un miembro no se utiliza (en el contexto de la aplicación analizada).

CQLinq Queries and Rules: Esta sección recoge las reglas predeterminadas CQLinq que han sido violadas.

Type Metrics: Esta sección resume métricas de tipo en una tabla.

Ejemplo de uso de NDepend.

Esta vista tiene muchas cosas que pueden explotarse, ya que la herramienta viene con un lenguaje de consultas, que te permite entre otras cosas, saber cuantos métodos de tipo string con mas de 50 lineas de código.

En la vista se puede observar por ejemplo, que las consultas por defecto que te muestra son, Restricciones de Calidad de Código, Restricciones de nombre (las cuales, se puede personalizar), Diseño, Performance, Código que nunca usas!, etc.

La herramienta te permite realizar tus propias consultas, como hemos mencionado anteriormente. En el siguiente ejemplo, se realiza una consulta sobre la cantidad de líneas de código de cada objeto.

Se pueden saber los métodos donde no tienen mucho comentario, como así también los métodos que son muy extensos. Se puede parametrizar la cantidad de líneas que pueden tener esos métodos para la consulta en NDepend.

Si cliqueamos sobre la consulta, me muestra un resumen de la misma.

Si aun queremos mas detalle, cliqueamos sobre los objetos y nos muestra los datos que se ven en la siguiente imagen.

Pros

• Extremadamente versátil y extensible, gracias a CQL.
• Apunta a las áreas problemáticas en su código.
• Introduce un nuevo lenguaje para la comunicación entre los desarrolladores.
• Visual NDepend como una gran interfaz gráfica de usuario.
• Útil conjunto de métricas para empezar, ampliable si es necesario.

Contras

• CQL carece de algunas características interesantes (posiblemente agregados, la comparación de las métricas)
• NDepend.Console.exe tiene un conjunto limitado de parámetros.
• El informe HTML se crea siempre, incluso en escenarios de CI, con los archivos XML habría sido suficiente.

• Ejecutar el build de un proyecto cuando se sube un cambio para code review, para saber si ese cambio rompe el build antes de hacer el review del mismo
• Deployar un proyecto y generar un branch con el código del mismo

Code Review

Descripción

El proceso que vamos a implementar es el siguiente:

El programador hace varios commits. Luego hace un push al repositorio remoto y el cambio queda pendiente para code review.
Ante ese evento se dispara un build que obtiene ese cambio aún no aprobado. El resultado del build exitoso o fallido es informado a Gerrit y queda registrado como Verified +1 o Verified -1.
Cuando otro usuario ingresa a Gerrit para hacer el code review, ya tiene en el campo Verified la información para saber si el cambio compila o no. En caso afirmativo y que pase el code review, se hace el merge del cambio al master y queda disponible para el resto de los programadores.

Configuración

1. Configuramos el trigger de gerrit para que dispare un nuevo build con cada cambio subido. Ponemos el nombre del proyecto y un path por si queremos filtrar algunos cambios en particular (en nuestro caso ponemos ** para todos los cambios). Y agregamos los eventos que queremos escuchar. En nuestro caso Draft Published (cuando se sube un cambio pendiente de code review) y Patchset Created (cuando se sube un patchset para corregir algo de un Draft ya creado).
2. Especificamos en la configuración del respositorio las variables $GERRIT_REFSPEC y $GERRIT_BRANCH para el refspec y el branch respectivamente. Esto hace que no baje el último cambio del master (por default), sino el cambio del branch que disparó el evento.

De esta manera, cuando hacemos un push de un cambio nuevo jenkins notifica a gerrit si ese cambio esta verified o no segun el resultado del build:

Branch y Deploy

Descripción

Este es el diagrama del proceso que vamos a automatizar:

Periódicamente vamos a disparar un build en Jenkins que va a obtener el código actual del master de Git.
Si el build es exitoso se van a hacer 3 cosas:

• Hacer un deploy del proyecto empaquetado en el servidor
• Crear un branch con el codigo del release
• Notificar al Project Manager por email del release exitoso

Si el build falla se notifica al desarrollador por mail.

Configuración

Email

Para configurar el envío de mails agregamos un Editable Email Notification como Post-build Action, y agregamos distintos destinatarios segun el resultado del build:

Adicionalmente se pueden configurar el subject, el contenido del mail, los attachments, etc.

Deploy

Para hacer el deploy de un artifact agregamos la tarea Deploy war/ear to a container como Post-build Action.
Configuramos la ubicación del archivo a deployar, el Context path (en caso de querer especificar uno distinto al default), el Application server a usar, la url y las credenciales a usar:

Branch

Finalmente vamos a crear un branch con el código del build, agregando un Git Publisher como Post-build Action.
Marcamos la opción Publish Only If Build Succeeds, para crear el branch solo si el build fue exitoso.
Finalmente ingresamos los datos del branch a crear. En el nombre usamos la variable de entorno $BUILD_ID de Jenkins que contiene el timestamp de la fecha.
Y en Target remote name el nombre del repositorio remoto (origin es el default, pero podríamos elegir otro si tenemos mas de 1 repositorio remoto).

Definiciones

Git es un SCM desarrollado inicialmente por un tal Linus Torvalds, que a diferencia de CVS o SVN implementa el concepto de repositorios distribuidos. La idea es que cada integrante tiene un repositorio local en su PC y al menos 1 o más repositorios remotos a los cuales se suben cambios desde el repositorio local. Como consecuencia, aun cuando el repositorio remoto este offline, es posible seguir haciendo commits, branchs, merges, etc. al repositorio local y luego hacer un “push” de los cambios al repositorio remoto. Mas información: http://git-scm.com/

Gerrit es una aplicación de code review y administración de repositorios Git desarrollada por Google. Permite hacer code reviews de cada commit antes de mergearlo al branch principal (master), pudiendo agregar comentarios en cada linea de código y notificar explícitamente a algún integrante en particular para que revise un cambio. Mas información: http://code.google.com/p/gerrit/

Jenkins es un servidor de integración continua. Es open source y tiene un mecanismo de plugins muy completo, que permite agregar soporte a distintos SCM, herramientas de compilación, generación de reportes, publicación de resultados, triggers para distintos eventos, customización de la UI, etc.. Mas información: http://jenkins-ci.org/

Release Notes

Vamos a configurar Jenkins y Gerrit para que genere un archivo de release notes detallando los cambios incluidos en el build de un proyecto y lo envíe por mail en la notificación del mismo.

1. Creamos un nuevo job en Jenkins y configuramos la sección de Source Code Management con los datos del repositorio de Git de donde obtener y compilar el código del proyecto.

   

2. Configuramos la sección de Build Triggers para disparar el build periódicamente. En este ejemplo, lo vamos a disparar a través de un expresión cron todos los viernes a las 12:00 hs.

   

3. Agregamos un Build Step de tipo Shell Script al job de Jenkins, en el cual vamos a generar el archivo con los cambios introducidos en este build.
   Para eso hacemos uso del comando log de git, al cual por parámetro le pasamos que nos devuelva los detalles de los commits agregados a este proyecto desde la última semana (–since={1.week.ago}), y en formato fecha – email_del_autor – mensaje_del_commit.
   El output del comando lo redirigimos al archivo release_notes.txt, y como disponemos de un shell, aprovechamos para formatear cada linea usando sed. Básicamente buscamos los mensajes de commit que empiezan con “tfs ” y lo reemplazamos por la url de TFS, para generar el link al issue y tener algo mas de trazabilidad.

   

4. Finalmente agregamos como tarea de Post-Build el envío del mail con el resultado del build. Simplemente agregamos como attachment el archivo release_notes.txt.

   

Y al llegar el mail podemos ver el archivo generado:

Thu Feb 7 11:26:22 2013 -0300 – emalvino@hexacta.com – https://tfs.hexacta.com/tfs/web/wi.aspx?id=1133 – Bugfix del reporte de saldo
Thu Feb 7 11:17:54 2013 -0300 – emalvino@hexacta.com – https://tfs.hexacta.com/tfs/web/wi.aspx?id=2345 – Validación del email del usuario
Thu Feb 7 11:12:42 2013 -0300 – emalvino@hexacta.com – https://tfs.hexacta.com/tfs/web/wi.aspx?id=1234 – ABM de Usuario agregado
Tue Feb 5 17:38:53 2013 -0300 – emalvino@hexacta.com – Commit inicial
Tue Feb 5 17:27:15 2013 -0300 – emalvino@hexacta.com – Initial empty repository

En el próximo post vamos a ver otros ejemplos de tareas automatizadas usando Jenkins, Git y Gerrit.