The Xint0 Code

XslCompiledTransform y codificaciones de caracteres.

2010-05-25T13:27:00.000-06:00

Recientemente estaba depurando una aplicación en la que se utiliza System.Xml.Xsl.XslCompiledTransform para aplicar una hoja de estilo XSL a un archivo XML en .Net y me topé con que la aplicación de la directiva <xsl:output encoding="iso-8859-1" /> depende de la clase utilizada para serializar la salida.

Codificación de caracteres en una transformación XML

Dado que XML utiliza la UTF-8 como la codificación predeterminada, se puede utilizar cualquier caracter Unicode en los valores de los elementos (algunos caracteres como < y > se deben codificar con su notación de entidad XML: < para < y > para >). A través de la directiva <xsl:output ... /> se puede indicar la codificación de caracteres que debe tener el resultado de la transformación utilizando el atributo encoding. De esta manera se puede producir un documento con una codificación diferente a UTF-8 en la cual los caracteres que utilicen códigos superiores a 255 (0x00FF) se codifican con la notación para códigos Unicode: &#nnnn; para la notación decimal o &#xnnnn; para la notación hexadecimal.

Codificación de caracteres con un XmlWriter

Normalmente se utiliza código como el siguiente para obtener el resultado de una transformación en una variable tipo string en memoria:

//Crear instancia de StringBuilder para construir salida.
var sb = new StringBuilder();
//Crear instancia para la transformación.
var xsl = new XslCompiledTransform();
//Cargar hoja de estilo para la transformación.
xsl.Load("transformacion.xsl");
//Crear instancia de XmlWriter a partir del StringBuilder y la configuración de salida
//indicada en <xsl:output />
var xw = XmlWriter.Create(sb, xsl.OutputSettings);
//Aplicar transformación.
xsl.Transform("entrada.xml", xw);
//Obtener resultado.
var resultado = sb.ToString();

Si ejecutamos este código el resultado que obtenemos es la entrada transformada, pero simpre codificada en UTF-8 aún cuando se indique otra codificación en la directiva <xsl:ouput encoding="..." />. ¿Por qué? Resulta, que las variables de tipo string son cadenas de caracteres Unicode y la codificación predeterminada es UTF-8 y StringBuilder no permite indicar el tipo de codificación deseada.

Para poder obtener el resultado con la codificación correcta en lugar de utilizar StringBuilder debemos utilizar un MemoryStream para obtener el resultado como una serie de bytes:

var resultado = string.Empty;
using (var ms = new MemoryStream()) {
  //Crear instancia para la transformación.
  var xsl = new XslCompiledTransform();
  //Cargar hoja de estilo para la transformación.
  xsl.Load("transformacion.xsl");
  //Crear instancia de XmlWriter a partir del StringBuilder y la configuración de salida
  //indicada en <xsl:output />
  var xw = XmlWriter.Create(ms, xsl.OutputSettings);
  //Aplicar transformación.
  xsl.Transform("entrada.xml", xw);
  //Cerrar instancia de XmlWriter
  xw.Close();
  //Restablecer posición del MemoryStream.
  ms.Position = 0;
  //Crear una instancia de StreamReader a partir del MemoryStream.
  using (var sr = new StreamReader(ms))
    //Obtener resultado.
    resultado = sr.ReadToEnd();
}

De esta manera la cadena resultante respetará la codificación indicada en la directiva <xsl:output encoding="..." />. Espero que esta nota les ahorre tiempo y dolores de cabeza al depurar transformaciones XSL utilizando .Net Framework.

Listas dependientes con jQuery: El plug-in

2010-05-02T11:43:00.000-06:00

En la nota "Listas dependiente con jQuery" presenté el código necesario para cargar dinámicamente las opciones de una lista en base al valor seleccionado en otra lista. En esta ocasión voy a presentar el resultado de la evolución del código presentado y cómo se transformó en un plug-in de jQuery.

jQuery plug-in

Para los neófitos en la programación web, jQuery es una biblioteca de funciones que facilitan la creación de aplicaciones web, a través de la manipulación del modelo de objetos de documento (DOM) y la comunicación con un servidor utilizando AJAX y JSON. Además de proveer una amplia gama de funcionalidad, jQuery permite la integración de funcionalidad personalizada a través de un mecanismo de extensión: los agregados o plug-ins.

Después de codificar la solución al problema de las listas dependientes, pensé que era un patrón lo suficientemente común como para que alguien hubiera creado un solución antes que yo. Entonces busqué en la biblioteca de extensiones de jQuery y efectivamente encontré un par de agregados que permiten cambiar las opciones disponibles en una lista dinámicamente a partir del valor seleccionado en otra lista. Sin embargo, estos agregados asumen que los datos ya están cargados, o dicho de otra manera, sólo filtran las opciones, no las cargan dinámicamente. Entonces, el siguiente paso lógico es crear un agregado de jQuery a partir de mi código.

La metamorfosis

Comencemos primero por ver el código base que se encarga de cargar las opciones de una lista dependiendo del valor seleccionado en otra:

<script type="text/javascript">
//Definir identificadores de campos
var idPadre = 'estado';
var idHijo = 'municipio';
//Definir objeto contenedor de lista de hijos por padre.
var padreHijos = {"0":[]};
//Definir código que se ejecuta al terminar de cargar la estructura del documento.
$(document).ready(function() {
    //Obtener referencia al campo padre.
    var padreSelect = $('#' + idPadre);
    //Definir código que se ejecuta al cambiar el valor del campo padre.
    padreSelect.change(function() {
        //Obtener referencia al campo hijo.
        var hijoSelect = $('#' + idHijo);
        //Obtener clave de identificación del estado seleccionado.
        var padreId = padreSelect.val();
        //Deshabilitar el campo hijo
        hijoSelect[0].disabled = true;
        //Vaciar la lista de hijos
        hijoSelect.empty();
        //Agregar la opción predeterminada.
        hijoSelect.append('<option value="0" selected="selected">-- Seleccionar --</option>');
        //Definir función para cargar opciones en elemento $lt;select>
        var cargarHijos = function(padreId) {
            //Obtener lista de hijos
            var hijos = padreHijos[padreId];
            //Agregar opciones para cada municipio.
            for (id in hijos) {
                hijoSelect.append('<option value="' + id + '">' + hijos[id] + '</option>');
            }
            //Habilitar la lista de hijos.
            hijoSelect[0].disabled = (padreId == 0);
        };
        //Si la clave de identificación del padre es mayor que cero
        //cargar lista de hijos.
        if (padreId > 0) {
            //Si no existe la lista de hijos, obtener la información
            //del archivo codificado en JSON.
            if (!padreHijos[padreId]) {
                var url = 'm' + padreId + '.json';
                $.getJSON(url, function(data) {
                    //Guardar lista de hijos en copia local.
                    padreHijos[padreId] = data;
                    cargarHijos(padreId);
                });
            } else {
                //Si ya existe la lista de hijos en la copia local, simplemente cargarla
                cargarHijos(padreId);
            }
        }
    });
});
</script>

Del código anterior, se pueden identificar las siguientes funciones:

Inicializar - Obtener referencia al campo padre y agregar código que responda al evento change.
Limpiar Hijo - Elimina las opciones del campo hijo y agrega la opción predeterminada.
Cargar Hijo - Agrega las opciones del campo hijo de acuerdo al valor del campo padre.
Obtener Datos - Si las opciones no están en el almacén local, obtenerlas del almacén persistente (servidor) y guardarlas en el almacén local.

Adicionalmente, ya que la idea de crear un agregado es que pueda aplicarse de manera genérica, el código debe permitir la configuración de la funcionalidad. Entonces es deseable que se pueda configurar el patrón de la nomenclatura para los archivos que contienen los datos.

Finalmente todo esto lo tenemos que empaquetar de acuerdo al patrón sugerido en la documentación de jQuery. Este patrón consiste basicamente de una función que recibe como parámetro el objeto global jQuery al cual le agregamos una función con el nombre del agregado a través de la propiedad fn.

La arquitectura de jQuery consiste en extender un objeto del DOM. En este caso el agregado proveería una función adicional a través de la cual se extiende el campo padre indicándole el identificador del campo hijo y el patrón de la nomenclatura de los archivos de datos.

El código resultante

(function($) {
    var ParentChild;
    ParentChild = function(element, childId, urlPattern) {
        this.domSelect = element;
        this.domSelect.data('parentChild', this);
        this.child = $('#' + childId);
        this.pattern = urlPattern;
        this.data = {};
        var me = this;
        this.getData = function(parentId) {
            $.getJSON(this.getUrl(parentId), function(data) {
                me.data[parentId] = data;
                me.populateChild(parentId);
            });
        };
    };
    ParentChild.prototype = {
        emptyChild: function() {
            this.child.empty();
            this.child.append('');
        },
        getUrl: function(parentId) {
            var url;
            if ((!this.pattern) || (this.pattern == ""))
                url = parentId;
            else
                url = this.pattern.replace(new RegExp("\\{p\\}", "gi"), parentId);
            return url;
        },
        disableChild: function() {
            this.child[0].disabled = true;
        },
        populateChild: function(parentId) {
            if(!this.data[parentId]) {
                this.getData(parentId);
            } else {
                for (childId in this.data[parentId])
                    this.child.append('');
                this.child[0].disabled = false;
            }
        }
    };
    $.fn.parentChild = function(childId, urlPattern) {
        var child = $('#' + childId);
        this.each(function() {
            var pc;
            pc = $(this).data("parentChild");
            if ((!pc) || (typeof pc === "undefined")) {
                pc = new ParentChild($(this), childId, urlPattern);
            }
            $(this).change(function() {
                var parentId = $(this).val();
                pc.emptyChild();
                pc.disableChild();
                if (parentId > 0)
                    pc.populateChild(parentId)
            });
        });
    };
})(jQuery);

El código de las líneas 2 a la 42 definen una clase privada que modela la funcionalidad básica y contiene los datos. En el constructor (líneas 3 a la 16), se guarda la referencia al elemento padre extendido en la propiedad domSelect. Luego, se almacena la instancia de la clase utilizando la llave parentChild. Se obtiene y se guarda la referencia al elemento hijo en la propiedad child. Se guarda el patrón para construir los URL en la propiedad pattern. Se inicializa la propiedad data a un objeto vacío (recuerden que en JavaScript no hay arreglos asociativos, sino que los objetos permiten acceder a los valores de sus propiedades utilizando la sintaxis de arreglos). Se almacena la autoreferencia this en la variable me. En las líneas 10 a la 15 se define el método getData que recibe un parámetro con la clave de identificación del padre y utiliza el método de jQuery getJSON para obtener los datos de manera asíncrona. El URL se obtiene de la función getUrl definida más adelante, y en la función de retrollamada (líneas 12 y 13) básicamente se almacenan los datos recibidos en el almacén local y se llama la función populateChild con la clave de identificación del padre. Nótese que se utiliza la variable me para referenciar la instancia de la clase ParentChild ya que en este contexto this es la referencia a la función de retrollamada (la función anónima definida en las líneas 12 y 13).

En las líneas 17 a la 42, se definen las funciones:

emptyChild - Líneas 18 a la 21. Vacía las opciones de la lista dependiente y agrega la opción predeterminada.
getUrl - Líneas 22 a la 29. Genera el URL del archivo con los datos en formato JSON a partir de la clave de identificación del padre. Se utiliza una expresión regular muy simple para remplazar {p} en el patrón con la clave de identificación del padre.
disableChild - Líneas 30 a la 32. Deshabilita el campo hijo.
populateChild - Líneas 33 a la 41. Verifica si existen los datos para el padre indicado. Si no existen, llama a la función getData. Si ya existen, agrega las opciones correspondientes y habilita el campo hijo.

Lo interesante de estos métodos es que están definidos en el prototipo de la clase, y por lo tanto sólo existe una copia de ellos. A diferencia del método getData, el cual debido al concepto de cerradura (Closure) se replicaría en cada instancia de la clase ParentChild.

Finalmente en las líneas 43 a la 59, se define la función de extensión de jQuery, es decir, el agregado. Cabe notar que jQuery opera sobre uno o más elementos del DOM, por lo que el patrón sugerido itera cada uno de los elementos asociados al objeto jQuery (línea 45). Básicamente primero determina si ya existe una instancia de la clase ParentChild asociada con el elemento en cuestión, si no existe, entonces la crea pasando la referencia al elemento extendido con jQuery, la clave del elemento hijo y el patrón para construir el URL. Finalmente, agrega código para responder al evento change (Líneas 51 a la 57) que obtiene el valor del campo padre, vacía el campo hijo, deshabilita el campo hijo y si el valor del padre es mayor que cero, llena la lista del campo hijo.

Conclusión

Crear un agregado para jQuery es relativamente sencillo. Hay que tomar en cuenta que se está extendiendo el objeto jQuery que a su vez extiene uno o más elementos del DOM. Hay que tener en cuenta el contexto de ejecución cuando se utiliza la referencia this, ya que puede hacer referencia a algo totalmente diferente de lo que creemos. El propósito de un agregado es encapsular funcionalidad genérica, por lo que debemos proveer flexibilidad a través de parámetros de configuración. Eventualmente, liberaré el código con una licensia de código abierto.

De Subversion a Git

2010-04-24T14:29:00.000-06:00

Llevo años utilizando algún tipo de sistema para la administración de cambios. Desde mi primer acercamiento a la materia con Visual Source Safe, pasando por CVS, luego dándole preferencia a Subversion y recientemente decidí cambiar a Git. A continuación explico las razones por las que decidí explorar otras alternativas, porque opté por Git.

Desarrollo de Software Esbelto o haciendo software en tiempos de crisis

Una de las premisas de la manufactura esbelta que se han trasladado al desarrollo de software es la de la eliminación de aquellas actividades o consumo de recursos que no aportan valor al producto final. Esta práctica ha tomado mayor relevancia en la actualidad debido a la crisis que se vive y a la necesidad de hacer más con menos.

Para los proyectos en los que participo había estado utilizando repositorios de Subversion con tres proveedores (assembla.com, repositoryhosting.com, xp-dev.com) evitando las complicaciones administrativas de mantener un repositorio de Subversion, aún y cuando soy el único programador en la mayoría de los casos. Sin embargo, el inconveniente es que Subversion requiere conexión al repositorio para prácticamente todas las operaciones, por lo mismo puede resultar muy tardado dependiendo del enlace, especialmente las operaciones que envían datos al repositorio a través de un enlace asíncrono (Alta velocidad de recepción/Baja velocidad de envío), entiéndase todos los enlaces domésticos.

Entonces decidí explorar alternativas que hicieran más eficiente la operación de un sistema de gestión de cambios y de esta manera reducir los tiempos de espera. Fue entonces que investigué acerca de los sistemas de gestión de cambios distribuidos como Git, Bazaar, y Mercurial.

Sistemas de gestión de cambios distribuidos

La principal diferencia entre Subversion y Git, es que el primero pertenece a la categoría de Sistemas de Gestión de Cambios Centralizados y el segundo a la categoría de Sistemas de Gestión de Cambios Distribuidos. En el esquema centralizado, los meta-datos y la historia se almacenan en un repositorio central (servidor) y los clientes se conectan a ese servidor central para enviar sus cambios y obtener la versión deseada (por lo general la última) del repositorio.

Por otra parte, en el esquema distribuido cada copia del repositorio contiene toda la historia y todos los meta-datos. Ya no es necesario un servidor central para que funcione el repositorio. La principal ventaja es la velocidad, pues ya no se requiere comunicarse con el servidor central a través de la red para realizar las operaciones comunes.

Todavía se puede mantener un repositorio principal para efectos administrativos, a partir de ese repositorio principal los participantes de un equipo de desarrollo pueden obtner una copia (clonar el repositorio) y colaborar entre sí (compartir modificaciones entre sus propios repositorios) y una vez que se ha concluido, enviar las modificaciones al repositorio principal, ya sea a través de parches (archivos diff) o mezclando las modificaciones y copiando la historia de los repositorios locales.

Consumo de espacio (Tu repositorio a dieta)

Otro factor que influyó en la decisión, fue el espacio que consume el repositorio. En mi caso, un repositorio que en Subversión ocupaba alrededor de 80 MB, en Git se redujo a 28 MB. Sin embargo esto puede variar considerablemente, por ejemplo si almacenan archivos binarios (imágenes, ejecutables, etc.), en Git estos pueden consumir mucho espacio rápidamente, ya que no puede grabar las diferencias únicamente, y en la mayoría de los casos no se pueden comprimir (archivos JPEG por ejemplo).

Mire m'ijo, algún día, todo este repositorio será suyo...¿Y las herramientas apá?

Aún cuando las herramientas disponibles para trabajar con Git en Windows no tienen la madurez de las disponibles para Subversion, son aceptables y quien se sienta agusto en la línea de comandos quedará más que satisfecho, pues Git como Subversion tienen como interfaz nativa la línea de comandos.

Dicen que Mercurial tiene mejores herramientas para Windows, no me consta. No utilicé Mercurial, porque Git aunque más complicado, es más flexible. Tal vez, un día de estos experimente con Mercurial y les platico. Bazaar sólo lo he utilizado para obtener directamente código de proyectos como MySQL y OpenERP. No lo utilicé, porque simplemente los servicios que utilizo para hospedar mis repositorios privados no ofrecen Bazaar. Eso sí, si algún día deciden colaborar en proyectos de software libre tales como: Ubuntu, MySQL, Inkscape, OpenERP o Bugzilla, pues van a tener que utilziar Bazaar.

Conclusión

Los sistemas más populares son Subversion, Git y Mercurial, en ese orden. Las principales ventajas de utilizar Git son: velocidad, consumo de espacio, flexibilidad. La mayor desventaja es cambiar la manera de pensar y trabajar con tu sistema de gestión de cambios distribuido. En mi caso particular, la era de Subversion y en general de los sistemas de gestión de cambios centralizados está terminando. De ahora en adelante, utilizaré sistemas de gestión de cambios distribuidos, de preferencia Git, aunque aún me falta experimentar con Mercurial.

Nuevos precios 2010

2010-04-24T00:15:00.000-06:00

Xint0 Software reduce sus precios

$15.00 dólares/hora + IVA en contrataciones de menos de 40 horas
$10.00 dólares/hora + IVA en contrataciones de 40 horas o más

Para más información visite: xint0.com o escriba a: ventas@xint0.com

Listas dependientes con jQuery

2010-04-23T20:32:00.000-06:00

Recientemente me solicitaron que modificara un formulario de un sitio web para que al seleccionar un Estado, se cargara la lista de Municipios correspondientes de manera dinámica. La restricción era que no podía depender de procesamiento en el servidor debido a la plataforma en la que está construido el sitio. La solución que se me ocurrió fue utilizar JavaScript para cargar dinámicamente los municipios. A continuación les presento el código y una breve explicación de su funcionamiento.

El problema: Campos dependientes

Es muy común que al crear formularios tengamos campos dependientes como el caso de los Estados y Municipios o Categoría y Productos. El reto es cargar las opciones del campo dependiente de manera dinámica en base al valor seleccionado en el campo padre. También es deseable que, para mejorar la experiencia del usuario, la información se cargue progresivamente. Es decir, cargar los municipios hasta que se seleccione el estado y cargar sólamente los municipios del estado seleccionado.

Herramientas

jQuery

En algún momento experimenté con AJAX, antes de que se hicieran populares bibliotecas como jQuery, Prototype, MooTools, etc. Luego, utilicé Prototype en algunos proyectos, pero nunca había trabajado con jQuery, así que me aproveche la oportunidad y utilicé jQuery para aislar los problemas de compatibilidad entre navegadores a la hora de manipular la estructura de una página web.

JSON

JavaScript Object Notation es una notación simple para describir objetos desarrollada por Douglas Crockfort basada en el lenguaje JavaScript. Es un formato apliamente utilizado debido a que es más breve que XML y permite transferir datos relativamente complejos de manera eficiente.

La solución

A grandes rasgos la solución es simple:

Determinar el Estado seleccionado.
Vaciar la lista de Municipios.
Cargar los Municipios del Estado seleccionado.

Para lograr esto podemos responder al evento change del elemento <select> utilizando jQuery de la siguiente manera:

Primera versión

<script type="text/javascript">
//Definir objeto con las listas de municipios por estado.
var padreHijos = {
    "0": [],
    "1": {
        "1": "Aguascalientes",
        "2": "Asientos"
        //Agregar municipios por estado.
        }
    };
//Definir identificadores de campos
var idPadre = 'estado';
var idHijo = 'municipio';
//Definir código que se ejecuta cuando se termine de cargar la estructura del documento.
$(document).ready(function() {
    //Obtener referencia al campo padre.
    var padreSelect = $('#' + idPadre);
    //Definir código que se ejecuta cuando cambia valor de campo padre.
    padreSelect.change(function() {
        //Obtener referencia al campo hijo.
        var hijoSelect = $('#' + idHijo);
        //Obtener clave de identificación del elemento padre.
        var padreId = padreSelect.val();
        //Deshabilitar el campo hijo.
        hijoSelect[0].disabled = true;
        //Eliminar las opciones del campo hijo.
        hijioSelect.empty();
        //Agregar opción predeterminada.
        hijoSelect.append('<option value="0" selected="selected">-- Seleccionar --</option>');
        //Obtener lista de hijos para el padre seleccionado.
        var hijos = padreHijos[padreId];
        //Agregar opciones para cada hijo.
        for (id in hijos) {
            hijoSelect.append('<option value="' + id + '">' + hijos[id] + '</option>');
        }
        //Habilitar campo hijo.
        hijoSelect[0].disabled = (padreId == 0);
    });
});
</script>

El código anterior depende de que exista un objeto padreHijos que funciona como un arreglo asociativo de las claves de identificación de los estados y su lista de municipios. Luego, se definen los identificadores de los elementos <select> para los campos estado y municipio

El primer problema con este código es que la base de datos puede requerir mucho espacio y por lo tanto, retrasar la descarga del código. Por lo tanto, la primer mejora sería cargar la información gradualmente. Para esto, podemos usar la función getJSON que permite hacer una petición asíncrona de un archivo con datos en notación JSON. Entonces, en lugar de declarar todos los municipios en el código que se carga inicialmente, creamos un archivo con la lista de municipios para cada estado. Por ejemplo, para el caso de los municipios correspondientes a Aguascalientes, creamos el siguiente archivo:

m1.json

{"1":"Aguascalientes",
"2":"Asientos",
"3":"Calvillo",
"4":"Cosío",
"5":"Jesús María",
"6":"Pabellón de Arteaga",
"7":"Rincón de Romos",
"8":"San José de Gracia",
"9":"Tepezalá",
"10":"El Llano",
"11":"San Francisco de los Romo"}

Nótese que los archivos con la lista de municipios van a utilizar la nomenclatura: m{id}.json en la que se remplaza {id} por la clave de identificación del estado correspondiente.

Luego hay que modificar el código para cargar los municipios dinámicamente a partir el estado seleccionado:

Segunda versión

<script type="text/javascript">
//Definir identificadores de campos
var idPadre = 'estado';
var idHijo = 'municipio';
//Definir objeto contenedor de lista de hijos por padre.
var padreHijos = {"0":[]};
//Definir código que se ejecuta al terminar de cargar la estructura del documento.
$(document).ready(function() {
    //Obtener referencia al campo padre.
    var padreSelect = $('#' + idPadre);
    //Definir código que se ejecuta al cambiar el valor del campo padre.
    padreSelect.change(function() {
        //Obtener referencia al campo hijo.
        var hijoSelect = $('#' + idHijo);
        //Obtener clave de identificación del estado seleccionado.
        var padreId = padreSelect.val();
        //Deshabilitar el campo hijo
        hijoSelect[0].disabled = true;
        //Vaciar la lista de hijos
        hijoSelect.empty();
        //Agregar la opción predeterminada.
        hijoSelect.append('<option value="0" selected="selected">-- Seleccionar --</option>');
        //Definir función para cargar opciones en elemento $lt;select>
        var cargarHijos = function(padreId) {
            //Obtener lista de hijos
            var hijos = padreHijos[padreId];
            //Agregar opciones para cada municipio.
            for (id in hijos) {
                hijoSelect.append('<option value="' + id + '">' + hijos[id] + '</option>');
            }
            //Habilitar la lista de hijos.
            hijoSelect[0].disabled = (padreId == 0);
        };
        //Si la clave de identificación del padre es mayor que cero
        //cargar lista de hijos.
        if (padreId > 0) {
            //Si no existe la lista de hijos, obtener la información
            //del archivo codificado en JSON.
            if (!padreHijos[padreId]) {
                var url = 'm' + padreId + '.json';
                $.getJSON(url, function(data) {
                    //Guardar lista de hijos en copia local.
                    padreHijos[padreId] = data;
                    cargarHijos(padreId);
                });
            } else {
                //Si ya existe la lista de hijos en la copia local, simplemente cargarla
                cargarHijos(padreId);
            }
        }
    });
});
</script>

Conclusión

Al utilizar jQuery se evitan las complicaciones de compatibilidad entre navegadores. También se facilita la creación de código que cargue gradualmente la información necesaria en lugar de cargar todo desde el principio.

Posteriormente publicaré un artículo con la versión final y con la incorporación de esta funcionalidad en un plug-in de jQuery.

Gestión de Configuración

2010-03-27T15:38:00.000-07:00

Gestión de Configuración de Software

Durante el desarrollo de cualquier producto de software, sea pequeño o sea grande, no importa el tamaño del equipo, ni el lenguaje de programación, el único factor que permanece constante irónicamente es el cambio. El desarrollo se refiere a que los componentes o artefactos que creamos y combinamos para crear nuestro producto de software, van evolucionando a lo largo del tiempo hasta que llegamos a una configuración que satisface el conjunto de requisitos que son prioritarios para los interesados en el producto en ese momento.

Cuando hacemos un programa pequeño, de manera personal, el grado de complejidad es bajo. Por lo tanto somos capaces de administrar los cambios de manera aceptable. Sin embargo, qué pasa cuando tres meses después de estar trabajando en otras cosas, volvemos a tratar de mejorar ese pequeño programa, cambiando el código para utilizar algún patrón que recién aprendimos o agregarle funcionalidad.

La mayoría de los programadores aborrecen la documentación y en un proyecto pequeño, inclusive evitan agregar comentarios al código, pues resulta obvio lo que está haciendo y cómo lo hace. Muy probablemente sí era obvio el qué y el cómo mientras se estaba tecleando el código. Pero tres meses después, ya no resulta tan obvio e inclusive puede despertar dudas acerca de la efectividad o eficiencia del código. Esa capacidad limitada de retención de memoria a largo plazo tiene su lado positivo, es lo que permite la evolución de las ideas.

En cuanto comenzamos a modificar el código de hace unos meses, estamos modificando la configuración de los componentes de nuestro producto de software, o sea, nuestro programa. Si tenemos suerte, después de hacer las modificaciones el código compila, pero eso no significa que el programa siga funcionando como esperamos. De hecho lo peor que puede suceder es que el código pase sin problemas las fases de análisis léxico y sintáctico del compilador y se produzca un nuevo ejecutable y que al utilizarlo nos genere un error de ejecución críptico en el método con el código más obvio de todos y que ni siquiera tocamos durante la modificación.

Aprender de la historia o ¿por qué el programador odia la documentación?

Utilizar un sistema de gestión de configuración, también conocido como control de cambios o control de versiones, es registrar la evolución de nuestro producto a lo largo del tiempo. Considero que es la documentación más importante que podemos registrar en cualquier proyecto de desarrollo.

La aversión que tienen la mayoría de los programadores con respecto de la documentación, proviene de las prácticas del milenio pasado. Las primeras metodologías para el desarrollo de software eran muy estrictas y extrapolaban prácticas que funcionaban bien en otras industrias, como la construcción, en las que el grado de incertidumbre es relativamente bajo. Sin embargo, todo proyecto para el desarrollo de software comienza con una gran incertidumbre que va disminuyendo paulatinamente hasta que al final conocemos la configuración final del producto el día en que se pone en operación.

Debido a esta incertidumbre, el tratar de definir un producto de software y plasmarlo en documentación inamovible es una causa perdida. En el desarrollo de software es imposible tener los planos antes de empezar a codificar. Para empezar, la persona o grupo que pide la creación de un producto de software, rara vez sabe exactamente y a nivel detallado qué es lo que quiere, y no se diga qué necesita en realidad. Luego, a diferencia de la construcción de un edificio en la que resulta relativamente sencillo conocer el impacto que tiene la modificación de las especificaciones iniciales. En el desarrollo de software, al ser un producto intangible, resulta muy difícil comprender el impacto que tiene un cambio en los requisitos, por minúsculos e insignificantes que le parezcan al interesado.

Entonces, ese tipo de documentación aplicado al desarrollo de software simplemente no sirve. En cambio, las prácticas contemporáneas que se han agrupado bajo el término de Metodologías Ágiles, tienen como premisa la incertidumbre inherente al desarrollo de software y en lugar de tratar de amoldar el desarrollo a la rigidez del método, se adaptan de manera flexible al proceso evolutivo del desarrollo de software.

Como ya lo expuse, desarrollo implica un proceso evolutivo, cambios constantes y es por eso que en lugar de tratar de reducir la cantidad de cambios a través de documentación rígida, lo racional y lógico es aceptar la constancia del cambio y documentar la evolución. En lugar de intentar detener el río y caminar sobre el agua, hay que fluir con la corriente.

Un sistema de gestión de configuración nos permite guardar la historia evolutiva de nuestro producto de software. Así la podemos revisar para saber por qué se tomaron decisiones en el diseño de los componentes y entender cómo llegamos al estado actual. A partir de esta historia, podemos deducir cuánto costará agregar o modificar funcionalidad. También puede servir como un curso abreviado para miembros nuevos del equipo. Es más interesante para un programador novato ver la evolución del código que leer manuales técnicos con análisis y diseño que nunca llegó al producto final.

¿Por qué es importante?

A medida que crece un producto de software y que el equipo de desarrollo pasa de una sola persona a una docena, la complejidad de la configuración de los componentes, así como la de los canales de comunicación crece geométricamente, o sea, no se suma, se multiplica. Resulta pues, que aventurarse a intentar desarrollar software sin un sistema de gestión de configuración, es como conducir un automóvil de carreras a través de un túnel de doble sentido, sin luces y con los ojos vendados.

Cualquiera que se autodenomine como desarrollador de software debe utilizar un sistema de gestión de configuración para todos sus proyectos. Si te fascina codificar y compilas en la mente, te hace falta una cosa para ser un buen programador: registrar la historia de tu código. Si tan sólo pudieramos ejecutar

diff

entre el presente y la historia del mundo y aplicar

patch

sobre todas las injusticias del mundo...

Colaboración en proyectos de código abierto: MySQL Workbench

2009-11-25T09:33:00.000-07:00

Hoy recibí la contestación de Mike Lischke en relación a un pequeño parche (dos líneas) que envié para corregir un ligero error en MySQL Workbench 5.2, parece que sí lo integraron. Me siento bien orgulloso, porque hace mucho que no leía y depuraba código C++ mentalmente—es decir, en notepad, fuera de Visual Studio—. Pueden ver el reporte de incidencia (bug) en:
http://bugs.mysql.com/39929
Por cierto, si trabajan con bases de datos MySQL, les recomiendo que pongan a prueba la siguiente versión de MySQL Workbench, 5.2 que se encuentra en beta actualmente. Todavía le falta afinar muchos detallitos—claro que siempre pueden contribuir a solucionarlos—, pero en general es un gran avance de versiones anteriores y se perfila como un excelente remplazo para las herramientas GUI de MySQL al integrar la funcionalidad de MySQL Query Browser, MySQL Server Administrator y una herramienta de documentación y modelación de esquemas de bases de datos extensible a través de rutinas escritas en Lua.

Aproveche descuento en antivirus este viernes

2009-11-25T09:16:00.000-07:00

Sunbelt Software tiene una oferta especial para este viernes 27 de noviembre:

70% de descuento en la compra de VIPRE Antivirus.

Esto significa que pueden adquirir la suscripción personal por un año a tan sólo $9.95 USD y por $19.95 USD pueden adquirir la licencia para el hogar, con la que pueden proteger TODAS las computadoras de su casa.

Para adquirir su licencia haga clic en la siguiente imagen:

¿Por qué recomiendo este producto?

Simplemente te da más valor por tu dinero:

No entorpece el desempeño de tu computadora. Yo buscaba un producto que protegiera mi configuración, sin degradar el desempeño durante los procesos de compilación.
Ocupa pocos recursos. A diferencia de otros productos, VIPRE ocupa pocos recursos durante su operación, algo crítico para mi entorno de trabajo.
Buen desempeño y bajo costo. Con la licencia para el hogar, protejo la computadora de mi esposa que abre todas las cadenas de correo que le envían y desde que lo instalé no he tenido que reinstalar el sistema operativo en su computadora.

Además te regalo un descuento de $5 USD en la compra de una licencia de VIPRE, simplemente ingresa el código de descuento:
VIPRESAP
durante el proceso de pago.

Recuerda sólo este viernes 27 de noviembre de 2009 "Black Friday":

VIPRE Antivirus + Antispyware por $9.95 USD

Google libera herramientas para JavaScript

2009-11-06T09:00:00.000-07:00

Atención programadores de JavaScript, Google ha liberado como Código Abierto algunas de las herramientas que utilizan sus programadores para crear y optimizar el código JavaScript de sus aplicaciones web como GMail, Google Docs, etc. He aquí una liga a la anotación del blog en la que se anuncia la liberación:

Google Code Blog: Introducing Closure Tools

Posted using ShareThis

Personalización del proceso de construcción de MSBuild

2009-11-05T03:42:00.000-07:00

En la anotación anterior utilicé los eventos que se generan antes y después de la construcción (pre-build y post-build) para ejecutar, primero una rutina que genera el código para restaurar un respaldo de una base de datos en el ambiente de desarrollo; y finalmente ejecutar el código generado previo al despliegue de la actualización de un proyecto de base de datos. Ahora voy a explorar una alternativa más flexible y poderosa: personalizar el proceso de construcción de MSBuild.

Los entornos para desarrollo integrados, se llaman así porque integran diversas herramientas que se utilizan durante la elaboración de software. Una de esas herramientas es la que construye el producto de software, utilizo el verbo construir para referirme a este proceso, ya que con la evolución de los entornos y herramientas, ahora la construcción involucra más que la compilación del código fuente en código objeto, el enlace de bibliotecas y la creación de un programa ejecutable o biblioteca de rutinas.

En el caso de Visual Studio y de .Net Framework en Windows, la herramienta encargada de orquestar la construcción se llama MSBuild. De hecho, MSBuild es parte de .Net Framework y técnicamente no se necesita Visual Studio para crear asambleas o programas que utilicen CLR (Ejecutor de Lenguaje Común, por sus siglas en inglés). Más bien, es al revés, Visual Studio requiere de MSBuild para construir los ejecutables y asambleas.

Un proceso de construcción se define en MSBuild a partir de los siguientes elementos en términos generales:

Elementos
Conjuntos de elementos
Tareas
Condiciones

La manera de expresar estos elementos es a través de un archivo XML, en el caso de Visual Studio el archivo de proyecto contiene además de las características utilizadas por el entorno, la definición de tareas requeridas para construir el proyecto.

De entrada, MSBuild cuenta con una amplia gama de tareas predefinidas. Estas van desde lo más simple como copiar un archivo, hasta la invocación del compilador de recursos de .Net para generar las asambleas satélite de recursos para globalización. Si no es suficiente, existe la tarea Exec que permite ejecutar un comando arbitrario. De hecho, los eventos pre-build, post-build son tareas Exec y simplemente ejecutan la línea de comandos que se captura a través de los atributos del proyecto. Además, se pueden definir otras tareas a través de una asamblea, que contenga clases que implementen algunas interfaces. Una discusión más detallada será tema de futuras entradas. Por ahora, me limitaré a decir que podemos modificar el archivo de proyecto, para agregar algunas tareas que dependan del paso build y que a su vez, sean requisitos del paso deploy.

En la siguiente entrada, detallaré paso a paso, como moví las líneas de comando de los eventos pre-build y post-build a un par de tareas que dependen de la ejecución exitosa del paso build, que se ejecutan sólo cuando lo indique una variable definida en el archivo de proyecto, y que sean requisitos previos del paso deploy.

Ejecutar una rutina T-SQL en los eventos Pre-Build y Post-Build en Visual Studio 2008

2009-10-23T12:16:00.002-06:00

En la entrada anterior expuse una rutina para obtener la información de los respaldos de una base de datos de Microsoft SQL Server para generar una rutina que restaurara el respaldo. El objetivo es integrar la rutina en el proceso de construcción de la solución/proyecto en Visual Studio 2008. En esta ocasión voy a utilizar los eventos "Pre-Build" y "Post-Build" para generar la rutina de restauración y ejecutarla para obtener una copia fresca de los datos antes de que se ejecute el despliegue (Deploy) de un proyecto de base de datos.

Entorno

Para poner en práctica esta idea, vamos a utilizar:

Visual Studio 2008 Team System Database Edition GDR R2
Microsoft SQL Server Express 2005

Los eventos Pre-Build y Post-Build

Visual Studio nos ofrece una manera fácil y rápida de ejecutar un comando previo a la construcción de un proyecto y otro después de la construcción. Para ver/modificar los comandos debemos acceder a la pestaña "Eventos de Construcción" (Build Events) en la ventana de Atributos del Proyecto (Project Properties):

Pestaña de Eventos de Construcción (Build Events)

[Insertar Imagen]
En los campos para la línea de comando de los eventos podemos escribir comandos que se ejecutarán en la línea de comandos de Windows, con la característica de que tenemos acceso a ciertas macros que nos permiten incrustar los valores de algunos atributos del proyecto en el texto del comando que se ejecuta:

Ventana de Línea de Comando para el Evento Pre-Build

sqlcmd

Antes de la interfaz gráfica existía el nirvana de la línea de comandos. Una simple interfaz que nos permite automatizar diversas tareas. Digamos que es el lenguaje natural de programación que nos ofrece el sistema operativo.
Cuando instalamos SQL Server Express, tenemos la opción de instalar las herramientas de administración y línea de comandos. Para el mortal promedio, estos programas adicionales no son de mucha utilidad, sin embargo para el verdadero programador son como una caja llena de bloques Lego(tm). Uno de esos bloques es: sqlcmd.exe, un programa que nos permite:

Conectarnos a un servidor SQL Server —valga la redundancia— y enviarle comandos de manera interactiva o,
lo que nos interesa, especificando un archivo de entrada a través del modificador -i
Además, podemos utilizar variables en el código del archivo y especificar su valor al momento de ejecución a través del modificador -v

Ejecución condicional en la línea de comandos

A pesar de que el intérprete de comandos de Windows está muy limitado en comparación con Bash, nos permite condicionar la ejecución de un comando utilizando la directiva if que tiene variantes para evaluar expresiones booleanas que comparen cadenas de caracteres, determinar la existencia de un archivo, entre otras.
Si creen que necesitan un intérprete más rico en expresiones y comandos, pueden utilizar Windows Scripting Host para ejecutar rutinas escritas en VBScript o JScript. Otra alternativa más reciente y que exploraré próximamente es PowerShell

El comando para generar la rutina de restauración

Recordando los viejos tiempos de DOS e inspirado por las rutinas de Bash tan socorridas en Linux, escribí el siguiente comando para ejecutar mi rutina de T-SQL para generar el código para restaurar la base de datos en mi ambiente de desarrollo (ajusté el formato para mayor claridad, pero en realidad va en una sola línea):


if "$(Configuration)" == "Debug" (
  if "$(DeployToDatabase)" == "True" (
    sqlcmd -U sa -P contraseñaSA -S nombre.host.servidor,puerto
      -v ProductionDatabaseName="BaseDeDatosProduccion"
      -v DatabaseName="$(FinalTargetDatabase)"
      -v RestorePath="X:\Ruta\Restauracion"
      -i "$(SolutionDir)Ruta\A\Rutina\GenerarRutinaRestauracion.sql"
      -o "$(SolutionDir)NombreProyecto\$(OutputPath)Restaurar.sql"
  )
)

Básicamente el comando anterior se traduce a:

Si la configuración del proyecto es igual a "Debug", entonces:
- Si está marcada la opción "Deploy to Database", entonces:
  - Utilizar sqlcmd para ejecutar la rutina que genera la rutina de restauración, utilizando los parámetros indicados

El comando para ejecutar la rutina de restauración

El comando para ejecutar la rutina que se generó en el event Pre-build es el siguiente:


if "$(Configuration)" == "Debug" (
  if "$(DeployToDatabase)" == "True" (
    if exist $(SolutionDir)NombreProyecto\$(OutputPath)Restaurar.sql (
      sqlcmd -U sa -P contraseñaSA -S nombre.host.servidor,puerto
        -v DatabaseName="$(FinalTargetDatabase)"
        -i $(SolutionDir)NombreProyecto\$(OutputPath)Restaurar.sql
    )
  )
)

Como ven es muy similar, les dejo de tarea su interpretación.

Conclusión

Visual Studio nos permite integrar acciones de manera fácil y rápida al proceso de construcción de una solución. Con un poco de ingenio podemos mejorar nuestra eficiencia al dejar que las tareas tediosas y repetitivas de nuestro proceso de desarrollo sean ejecutadas por la misma herramienta de construcción.
En algún momento en el futuro, exploraré más a detalle el proceso de construcción de Visual Studio. Tengo curiosidad por conocer el proceso de construcción más a fondo y poder extenderlo más allá de los simples eventos. Por lo pronto esta solución simple funciona y me ha permitido tener más tiempo disponible (mientras espero a que se complete el proceso de construcción de Visual Studio) para poder publicar esta entrada.

SQL Server 2005 Express y Visual Studio 2008 : Restaurar Respaldo

2009-10-21T13:22:00.003-06:00

En uno de los proyectos en los que trabajo, tuve la necesidad de modificar el esquema de la base de datos. Aún cuando Visual Studio Team Suite 2008 Database Edition GDR R2 facilita el trabajo con bases de datos de SQL Server, hay que programar rutinas para la migración de datos. Además, creo que es bastante común el utilizar un respaldo de la base de datos del ambiente de producción en nuestro ambiente de prueba o de representación. Este artículo trata de cómo generar una rutina para automatizar la restauración del respaldo como parte del proceso de construcción del proyecto en Visual Studio 2008.

Ya está publicada la nota sobre la integración de esta rutina en el proceso de construcción de Visual Studio

El ambiente de desarrollo

En mi caso particular tengo la siguiente configuración:

Ambiente de Desarrollo
- Visual Studio 2008 Team System SP1
- Visual Studio 2008 Team Suite Database Edition GDR R2
Servidor de Base de Datos:
- SQL Server 2005 Express Edition SP3

La solución está compuesta por varios proyectos, incluyendo dos de base de datos:

Proyecto de Base de Datos de Servidor - Incluye la base de datos 'master' y la definición de un usuario y su respectiva cuenta utilizada por la aplicación para conectarse a la base de datos.
Proyecto de Base de Datos de la Aplicación - Este es el proyecto en el que se define el esquema de la base de datos de la aplicación en cuestión. Tiene una referencia a la base de datos del servidor y es en este proyecto en el que agregué las rutinas de migración de datos y de generación de rutina para restaurar el respaldo.

La base de datos de la aplicación está configurada con el modelo de recuperación completa (FULL RECOVERY) y se tiene calendarizada la ejecución de rutinas de respaldo para generar un respaldo completo de la base de datos a las 2:00 a.m. todos los días y generar un respaldo de las bitácoras de transacciones (TRANSACTION LOGS) a partir de las 2:30 horas, cada hora. Los respaldos se almacenan en un archivo correspondiente al día del respaldo. Debido a la naturaleza de los cambios al esquema de la base de datos, se requiere la creación de rutinas de migración de datos. Para poder probar estas rutinas, se me ocurrió restaurar un respaldo de la base de datos del ambiente de producción en el ambiente de prueba. Al principio, hice el proceso manualmente. Pero al estar depurando las rutinas de migración de datos, se hizo evidente que necesitaba automatizar el proceso e integrarlo al proceso de construcción/compilación de la solución en Visual Studio. El primer reto fue averiguar cómo generar la rutina para restaurar el respaldo. Utilizando SQL Server Management Studio Express, se puede generar el código en Transact-SQL con algunos clics. Y se obtiene algo como:

RESTORE DATABASE [LaBaseDeDatosDesarrollo]
FROM DISK = N'X:\Ruta\Al\Archivo\De\Respaldo.bak' WITH FILE = 3,
MOVE N'BaseDeDatosProduccion.mdf' TO N'X:\Ruta\Al\Archivo\Restaurado1.mdf',
MOVE N'BaseDeDatosProduccionBitacora.ldf' TO N'X:\Ruta\Al\Archivo\Restaurado1.ldf',
NORECOVERY, NOUNLOAD, REPLACE, STATS = 10;
GO
RESTORE LOG [LaBaseDeDatosDesarrollo]
FROM DISK = N'X:\Ruta\Al\Archivo\De\Respaldo.bak' WITH FILE = 4,
NORECOVERY, NOUNLOAD, STATS = 10;
GO
RESTORE LOG [LaBaseDeDatosDesarrollo]
FROM DISK = N'X:\Ruta\Al\Archivo\De\Respaldo.bak' WITH FILE = 5,
NORECOVERY, NOUNLOAD, STATS = 10;
GO
RESTORE LOG [LaBaseDeDatosDesarrollo]
FROM DISK = N'X:\Ruta\Al\Archivo\De\Respaldo.bak' WITH FILE = 6,
NOUNLOAD, STATS = 10;
GO

Sin embargo, yo quería que fuera un proceso totalmente automático y que se ejecutara como parte de la acción "desplegar" (deploy) en Visual Studio. Entonces, pensé: Si SQL Server Management Studio Express puede generar el código de Transact-SQL, debe haber una manera en la que yo pueda hacer lo mismo en Transact-SQL.

La base de datos msdb

SQL Server guarda la información de los respaldos en las tablas [backupfile], [backupset], [backupmediafamily], [backupmediaset] de la base de datos [msdb]. Ya que el motor de SQL Server está diseñado para cubrir una amplia gama de necesidades en aplicaciones de todos los tamaños, muchas veces el control interno puede parecer muy rebuscado y complejo. Sin embargo, leyendo un poco de la documentación podemos entender lo suficiente para nuestro propósito.

No voy a repetir aquí la documentación de SQL Server. Lo único que nos interesa es lo siguiente:

El nombre del archivo en el que se almacenó el respaldo está en la columna [physical_device_name] de la tabla [msdb]..[backupmediafamily]
La tabla [msdb]..[backupset] contiene un registro por cada respaldo que se generó con mucha información del mismo. Las columnas que nos interesan son:
- [position] - La posición dentro del archivo de respaldo
- [database_name] - El nombre de la base de datos que se respaldó
- [type] - 'D' si fue respaldo de base de datos o 'L' si fue respaldo de la bitácora de transacciones
- [backup_set_id] - Número de identificación del conjunto
La tabla [msdb]..[backupfile] contiene un registro por cada archivo de base de datos que se respaldó en un conjunto. Las columnas que nos interesan son:
- [logical_name] - Nombre lógico del archivo
- [file_type] - Tipo de archivo ('D' si es de base de datos o 'L' si es archivo de la bitácora de transacciones)
- [create_lsn] - Número de secuencia de creación de la base de datos
- [backup_set_id] - Número de identificación del conjunto al que pertenece
El comando RESTORE y sus variantes:
- RESTORE DATABASE
- RESTORE LOG

El Código

Armado con la información anterior, hice la siguiente rutina:

DECLARE @backup_set_id INT;
DECLARE @physical_device_name NVARCHAR(260);
DECLARE @batch_text VARCHAR(MAX);
DECLARE @last_position INT;

-- Obtener el valor de [backup_set_id] para el último
-- respaldo completo de la base de datos del ambiente
-- de producción
SELECT @backup_set_id = MAX([backup_set_id])
FROM [msdb]..[backupset]
WHERE [database_name]='$(ProductionDatabaseName)'
AND [type]='D';

-- Obtener el valor de [physical_device_name] de
-- la tabla [backupmediafamily] asociado al [backupset]
-- identificado por el comando anterior
SELECT
@physical_device_name = [mf].[physical_device_name]
FROM
[msdb]..[backupset] AS [bs] INNER JOIN
[msdb]..[backupmediafamily] AS [mf]
ON [bs].[media_set_id] = [mf].[media_set_id]
WHERE
[bs].[backup_set_id] = @backup_set_id;

-- Obtener el valor de [position] para el último
-- respaldo de la bitácora de transacciones realizado
-- después del último respaldo de base de datos
SELECT @last_position = MAX([position])
FROM [msdb]..[backupset]
WHERE [database_name]='$(ProductionDatabaseName)'
AND [type]='L'
AND [backup_set_id] > @backup_set_id;

-- Comenzar a generar el texto de la rutina
SET @batch_text =
'PRINT ''RESTAURANDO BASE DE DATOS DE DESARROLLO '
+ '$(DatabaseName)...'';' + CHAR(13) + CHAR(10)
+ 'GO' + CHAR(13) + CHAR(10)
+ 'USE [master]' + CHAR(13) + CHAR(10)
+ 'GO' + CHAR(13) + CHAR(10);

-- Agregar el comando para restaurar el último
-- respaldo de base de datos
SELECT @batch_text = @batch_text +
'RESTORE DATABASE [$(DatabaseName)] FROM DISK = N'''
+ @physical_device_name + ''' WITH FILE = ' 
+ CONVERT(VARCHAR, [position]) + ',' + CHAR(13) + CHAR(10)
FROM [msdb]..[backupset]
WHERE [backup_set_id] = @backup_set_id;

-- Agregar cada uno de los archivos en el conjunto de
-- respaldo, indicando su nueva ruta de localización
SELECT @batch_text = @batch_text +
CHAR(9) + 'MOVE N''' + [logical_name]
+ ''' TO N''$(RestorePath)\$(DatabaseName)'
+ CONVERT(VARCHAR, ROW_NUMBER() OVER
(PARTITION BY [file_type] ORDER BY [create_lsn]))
+ CASE WHEN file_type='D' THEN
'.mdf'
ELSE
'_log.ldf'
END + ''',' + CHAR(13) + CHAR(10)
FROM [msdb]..[backupfile]
WHERE [backup_set_id] = @backup_set_id;

-- Terminar el comando de restauración de base de datos
SET @batch_text = @batch_text + CHAR(9)
+ 'NORECOVERY, NOUNLOAD, REPLACE, STATS = 10;'
+ CHAR(13) + CHAR(10)
+ 'GO' + CHAR(13) + CHAR(10);

-- Para cada respaldo de la bitácora de transacciones en el
-- conjunto de respaldos, agregar un comando que restaure
-- dicho respaldo
SELECT @batch_text = @batch_text
+ 'RESTORE LOG [$(DatabaseName)] FROM DISK = N'''
+ @physical_device_name + ''' WITH FILE = '
+ CONVERT(VARCHAR, [position]) + ','
+ CASE WHEN [position] < @last_position THEN
' NORECOVERY,'
ELSE
''
END
+ ' NOUNLOAD, STATS = 10;' + CHAR(13) + CHAR(10)
+ 'GO' + CHAR(13) + CHAR(10)
FROM [msdb]..[backupset]
WHERE [backup_set_id] > @backup_set_id
AND [POSITION] <= @last_position
AND [database_name]='$(ProductionDatabaseName)';

-- Finalmente terminar con un mensaje 
SET @batch_text = @batch_text
+ 'PRINT ''BASE DE DATOS DE DESARROLLO RESTAURADA...'';'
+ CHAR(13) + CHAR(10)
+ 'GO' + CHAR(13) + CHAR(10)
+ 'USE [$(DatabaseName)]' + CHAR(13) + CHAR(10)
+ 'GO';

-- Escribir el resultado a la salida estándar
PRINT @batch_text;

Nótese la utilización de variables de sustitución (todas las cadenas con el patrón “$(identificador)”) para la ejecución con SQLCMD. De esta manera podemos pasar parámetros a nuestra rutina de acuerdo a valores de variables del proyecto de Visual Studio, la idea es que se ejecute esta rutina como parte de la construcción del proyecto. En la siguiente parte del artículo utilizaremos los eventos de pre-construcción y post-construcción para ejecutar esta rutina.

El Código Xint0 / The Xint0 Code

2009-10-21T11:55:00.001-06:00

Este es mi blog dedicado a mi área de conocimiento especializado: Programación y Desarrollo de Software. Publicaré artículos en español, enfocados principalmente en los lenguajes y tecnologías que utilizo a diario:

.Net Framework
C#
SQL Server 2005
XHTML
CSS
PHP
MySQL

Sus preguntas y comentarios son bienvenidos.