miércoles, 29 de octubre de 2008

Introducción a las pruebas unitarias (I)

Directamente relacionado con los últimos posts de metodologías ágiles, scrum, publicados, en este artículo voy a tratar de explicar de manera sencilla que son las pruebas unitarias y en que nos puede ayudar su adopción. En un segundo artículo veremos un pequeño ejemplo de cómo aplicarlas con ayuda de las herramientas que nos proporciona Visual Studio.

¿Qué son?

Las pruebas unitarias (o Unit Testing cómo encontrareis en la mayoría de documentación existente) no son más que un mecanismo que nos permiten realizar pruebas de manera automatizada sobre las clases y componentes de nuestro código. A pesar de que las pruebas unitarias existen desde hace muchísimo tiempo en el mundo del desarrollo de software, ha sido el auge cada vez más grande de las metodologías ágiles lo que las ha popularizado hasta los límites en que se encuentran hoy en día, al ser una de las técnicas que más adeptos tiene entre los “adoptantes” de dichas metodologías.

También es importante destacar que dentro del contexto de las pruebas unitarias se pueden diferenciar dos corrientes importantes:

· Test-Last Development: O escribir las pruebas una vez realizado el código.

· Test-First Development: Escribir las pruebas antes del código, y a base de refactorización derivar éste último. Ésta corriente es la base del Test Driven Development (o desarrollo guiado por tests).

Cada una tiene sus ventajas e inconvenientes, pero si un equipo está en proceso de adopción de las pruebas unitarias yo, a modo personal, recomendaría una primera aproximación a desde el punto de vista del Test-Last Development.

¿Qué aportan?

Después de esta breve introducción vamos a ver en que nos puede ayudar realizar pruebas automáticas de nuestros desarrollos:

  • Facilidad en la integración de cambios. Gracias a los tests unitarios es inmediato ver si un cambio realizado por nosotros hace que deje de funcionar otra parte del código.
  • Documentación “dinámica” del código (Crece y se actualiza a la misma velocidad que lo hace el código)
  • Facilidad de refactorización. Podemos mejorar, optimizar y simplificar partes de nuestro código con la tranquilidad de saber que si el test que cubría aquella parte sigue siendo válido, el código también lo es.
  • Obligatoriedad de un análisis explícito previo al desarrollo. Para poder realizar las pruebas el desarrollador necesita entender realmente el alcance de la funcionalidad que va a implementar
  • Mejor diseño del software debido al punto anterior
    • Menos acoplamiento
    • Más mantenibilidad
    • Más legibilidad
  • Código más reutilizable. Al tener un mejor diseño de los componentes estos se pueden reutilizar con mayor facilidad haciendo que incremente la productividad del equipo.
  • Detección temprana de bugs. Por lo general cuanto más tarda en detectarse un fallo más impacto tiene en el cliente y mas impacto tiene en la dinámica de trabajo del equipo. Por lo tanto la detección de errores en las primeras fases de desarrollo asegura un menor impacto en el producto y de nuevo una mayor productividad.
  • Reducción del tiempo de depuración.

Todas estas ventajas que nos proporcionan los tests unitarios se pueden resumir en dos grandes mejoras, que, aunque parezcan contrarias, van realmente muy ligadas la una a la otra:

· Mayor velocidad de desarrollo

· Mayor calidad en el producto final

El principal problema para la adopción de las pruebas unitarias en un equipo surge si estas son vistas cómo un coste, y no cómo una inversión.

¿Cómo vamos a aumentar la velocidad de desarrollo si tenemos que perder tiempo en codificar las pruebas unitarias?

Aunque parezca una paradoja la realidad es que la inversión de tiempo realizada en el desarrollo de pruebas unitarias tiene un retorno muy rápido y en muy poco espacio de tiempo veremos cómo la calidad del código desarrollado

En este caso lo que hay que entender es que las pruebas unitarias son una inversión y no un coste, pero además son una inversión con un retorno de la misma casi inmediato y con unas ganancias para el equipo de desarrollo (y para todos los que dependan en mayor o menor medida de el trabajo de éstos) realmente abundantes.

Aparte de todo esto, no se debe perder de vista una máxima crucial en el mundo del desarrollo: la calidad del código nunca es negociable, lo que implica que las pruebas (ya sean unitarias o manuales) nunca deben ser opcionales, y por lo tanto la adopción de pruebas unitarias no debería ponerse en duda si de lo que se trata es de asegurar la calidad de nuestro código.

Y esto es todo, en el próximo post veremos una visión práctica de lo expuesto en este artículo utilizando el Framework de Test integrado en Visual Studio, MSTest.

domingo, 26 de octubre de 2008

SCRUM (I)

Qué es SCRUM

Scrum es un marco de trabajo para el desarrollo ágil de proyectos de software, aunque lo podéis aplicar a cualquier otro ámbito. Si quereis gestionar vuestra vida de pareja con Scrum, adelante!

Scrum, cómo buena metodología ágil y moderna divide el trabajo en iteraciones, a las que llama sprints, que generalmente se alargan entre 2 y 4 semanas. Cada sprint parte de un conjunto de histórias de usuario ( el llamado product backlog ) de las que el equipo de desarrollo con la ayuda del product owner y en la reunión de inicio de sprint escogen aquellas que entraran en el sprint, decidiendo así el sprint backlog. A lo largo del sprint el equipo realiza una reunión diária ( sprint daily meeting ) en la que cada miembro describe el estado de su tarea. Al final del sprint se realiza una demo para mostrar el avance del proyecto en el sprint y después una reunión para evaluar el sprint y su desarrollo ( sprint review meeting ). El objetivo de todo esto es poder entregar un incremento de valor del producto al cliente cada cierto periodo de tiempo de una manera regular.

Si todo esto os suena a chino, no os precupéis que ahora lo vamos detallando un poco.

Los actores de Scrum

Antes de ver cuáles són los diferentes roles en un equipo de Scrum os voy a contar un cuento. Resulta que un dia se encontraron una gallina y un cerdo en el campo. La gallina le dijo al cerdo: He tenido una idea. Vamos a montar un restaurante entre tu y yo. El cerdo le preguntó que cómo se llamaría el restaurante, a lo que la gallina le respondió que huevos con jamón. Cuando lo escuchó el cerdo desestimó la idea alegando que el estaria realmente comprometido con el proyecto, mientras que la gallina sólo estaria involucrada. Si aplicamos esto a Scrum, significa que los desarrolladores són los cerdos ( con perdón :D ) y son los que están realmente comprometidos con el avance del proyecto, ya que son los que lo desarrolan, mientras que la demás gente son gallinas, y aunque de alguna manera u otra están involucrados en el proyecto no estan tan involucrados como los desarrolladores.

Scrum define básicamente tres roles: El equipo, el scrum master ( o facilitador ) y el product owner.

Product owner
O propietario del producto. Es el encargado de mantener el product backlog ( la lista con las historias de usuario ) actualizado y priorizado. Representa al cliente y está presente con voz y voto en la reunión de inicio de sprint para explicar al equipo de trabajo las historias con detalle y llegar a un acuerdo con este sobre las que entran en el sprint backlog.

Equipo de desarrollo
Son los más cerdos de todos ( en el sentido scrumiano de la palabra ). Són los responsables de desarrollar el proyecto. Se reunen con el product owner para aclarar todas las dudas sobre las histórias, estiman lo que van a tardar en hacerlas y se reunen cada dia con el scrum master para controlar el avance del proyecto. Al finalizar el sprint, realizan la demo para mostrar el resultado de su trabajo y se reunen con el scrum master para hacer la evaluación del sprint.

Scrum master
O facilitador. Es el encargado de hacer todo lo posible para que el equipo de desarrollo pueda realizar su faena de la mejor de las maneras. Es su representante en el exterior. Se encarga de eliminar todos los problemas que pueda tener el equipo y de hacer que las reglas de Scrum se cumplan.

El resto de personajes que puedan estar en el proceso son las gallinas de nuestra historia. Pueden asistir a las reuniones pero no tienen voto en ninguna de ellas y voz en muy pocas. Entre estas gallinas podemos encontrar a otros grupos de desarrollos, gente de la empresa interesada en el proyecto, comerciales, etc. Pueden dar su opinión, en ocasiones muy valiosa, pero no pueden interferir en el desarrollo del proyecto.

Y por hoy ya está todo. En próximas entregas veremos la documentación asociada y las diferentes reuniones. Nos leemos!

lunes, 20 de octubre de 2008

Proyectos de instalación con Visual Studio

En el mundo de desarrollo de software empresarial, los instaladores son una pieza de software a la que, por norma general, no se le da la importancia necesaria. De hecho suele ser en lo último en lo que piensa un equipo de desarrollo cuando se empieza un nuevo proyecto, cosa paradójica (y peligrosa) ya que la instalación es la primera toma de contacto que el cliente tiene con el nuevo sistema.

Además hay que tener en cuenta que en los tiempos que corren la mayoría de usuarios a los que va a ir destinado nuestro sistema es gente más o menos familiarizada con los ordenadores y con el software (todo el mundo tiene PC en casa, móviles de última generación, etc.) y un proceso de instalación que sea sencillo y visible aportará confianza y un mayor grado de implicación del usuario en la adopción del nuevo sistema.

Si por el contrario el proceso de instalación es oscuro, difícil y complicado, con multitud de ficheros de configuración ininteligibles y que prácticamente es necesario un master para llevarlo a cabo, los usuarios finales percibirán que están tratando con algo complicado y el rechazo a la implantación del nuevo sistema será mayor.

Todo este rollo de introducción viene a cuento para explicar como realizar instaladores de manera sencilla con Visual Studio. Algo que a mucha gente le parece complicado y tedioso, pero que realmente ,para instaladores no excesivamente complejos, es un proceso bastante simple.

Visual Studio tiene un tipo de proyecto que sirve para este propósito, proyectos llamados Setup Projects (o Proyectos de Instalación en la edición en castellano). Este tipo de proyectos permiten crear diferentes paquetes de instalación para Windows, entre ellos los comúnmente conocidos msi. Para crear un nuevo proyecto de este tipo hay que ir al menú File -> New -> Project y seleccionar el tipo de proyecto Setup Project


Aparecerá una pantalla similar a esta:


En ella podemos distinguir varias zonas:

1) En esta zona de la pantalla aparecen los menús y paneles relativos a la opción del instalador que estemos editando en ese momento. En este caso la opción seleccionada (la que aparece al crear el proyecto) es el sistema de archivos (File System)

2) Barra de herramientas de la pestaña Solution Explorer. En esta barra de herramientas aparecen las diferentes opciones que tenemos para el instalador (por ejemplo el Sistema de Archivos, el editor del Registro, etc.) Hay que tener en cuenta que esta barra irá cambiando según el elemento que tengamos seleccionado en la zona 3 (Solution Explorer). Para visualizar las diferentes opciones del instalador en la barra hay que seleccionar el elemento que representa el proyecto (en nuestro caso SetupExampleProject)

3) Solution Explorer. Representa los elementos que se van añadiendo al proyecto en forma de árbol.

Ahora explicaré las diferentes opciones que Visual Studio nos permite configurar para un proyecto de instalación.

File System Editor

La primera opción que tenemos para personalizar nuestro instalador es el editor del sistema de archivos.



Esta pantalla nos permite crear la estructura de carpetas (lógica) que nuestro instalador creará y utilizará en la máquina de destino y nos permite definir que archivos o componentes contendrán cada una de estas carpetas. Esta estructura se representa en el árbol etiquetado cómo File System on Target Machine en el panel de mas a la izquierda.

Por defecto la estructura cuenta con 3 carpetas, Application Folder, que representa la carpeta donde se instalará la aplicación, User’s Desktop, que representa el escritorio del usuario de la máquina de destino y User’s Program Menú, que representa el menú Programas del usuario. Estas carpetas son representaciones lógicas del sistema de archivos de la máquina destino, y hasta el momento de la instalación no se mapearán a unidades concretas (aunque hay excepciones).

Aparte de las carpetas por defecto se pueden añadir mas carpetas a la estructura, ya sean subcarpetas (por ejemplo subdirectorios de la carpeta de la aplicación) u otros directorios especiales del sistema (por ejemplo la carpeta System32)

Nuevas carpetas añadidas a la estructura de destino


El proceso de añadir una carpeta es tan simple cómo botón derecho sobre la carpeta padre (o la raíz si queremos añadir una carpeta especial) y escoger la opción deseada (la carpeta especial o el nombre de la nueva carpeta según queramos)

Añadiendo una carpeta del SO a nuestro instalador


Una vez creada la estructura es hora de añadir ficheros, ensamblados o accesos directos a nuestro instalador.

El proceso de añadir ficheros o ensamblados es tan simple cómo arrastrarlos a la carpeta deseada (se consigue lo mismo mediante el menú contextual del directorio escogido)

Por ejemplo vamos a añadir a la carpeta de nuestra aplicación un ejecutable para una sencilla aplicación Windows.

Añadimos el exe a la carpeta ApplicationFolder


Añadimos las imágenes a la carpeta de Imágenes creada anteriormente


Ahora podemos crear un acceso directo a nuestra aplicación. Para ello hay que seleccionar el exe que acabamos de añadir y marcamos la opción del menú contextual Create Shortcut to WindowsFormApplication1

Esto nos creará en la misma carpeta un fichero con el nombre Shortcut to WindowsFormApplication1. Podemos cambiarle el nombre por el que queramos, por ejemplo VisorImagenes y lo arrastramos al directorio de la estructura que nos interese. Por ejemplo al Escritorio.


De él acceso directo podemos configurar varias propiedades. Para acceder a la pantalla de propiedades del acceso directo pulsamos Properties en el menú contextual del mismo. La pantalla de propiedades del acceso directo muestra lo siguiente:



Entre otras cosas puede configurarse el icono del acceso directo, los argumentos que se le pasan al ejecutable por línea de comandos, etc.

De la misma manera se pueden configurar distintas propiedades para las carpetas y los archivos.

Por ejemplo, por defecto las carpetas que no son de sistema no se crean en la màquina de destino si están vacias, para evitar esto y forzar a que siempre se creen hay que poner el valor de la propiedad AlwaysCreate de la carpeta en cuestión a True.

La pantalla de propiedades del fichero ejecutable muestra las siguientes propiedades:




Entre otras opciones se puede configurar si se debe registrar el fichero, si es permanente (no se borra al desinstalar la aplicación),etc.

Propiedades de AppFolder

La carpeta de la aplicación tiene una serie de propiedades que vale la pena reseñar:

DefaultLocation : Se muestra la ruta donde se creará la carpeta del instalador. Esta ruta tiene la siguiente forma al inicio-> [ProgramFilesFolder][Manufacturer]\[ProductName]

ProgramFilesFolder indica la carpeta da Archivos de Programa, que puede cambiar de ubicación según el equipo, el sistema operativo, etc.

Manufacturer y ProductName son propiedades genéricas de WindowsInstaller que se pueden definir en las propiedades del proyecto.

Pantalla de propiedades del proyecto


Entre estas propiedades hay muchas importantes para el proceso de instalación, entre ellas las de ProductCode, Upgrade Code o RemovePreviousVersion que se utilizan para actualizar versiones antiguas de la aplicación (podéis encontrar una explicación más detallada aquí -> http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/ )

Registro de ficheros COM

Visual Studio permite registrar ficheros COM en el proceso de instalación. Las opciones que proporciona el IDE para registrar estas librerías varían en función de su tipo, objeto COM tradicional o Dll .Net exponiendo interfaces y clases COM.



  • Objetos COM tradicionales

Un objeto COM tendrá las siguientes opciones de registro:

    • vsdrfCOMSelfReg : Auto registro. Windows Installer llama a RegSvr32 en el momento de la instalación. No es la opción recomendada.
    • vsdrfCOM: Los datos de registro se crean en el momento de la instalación pero el código de la dll no es llamado en ese punto. Esto asegura que no haya fallos en situaciones donde la dll está linkada a otra dll que todavía no se ha registrado.
    • vsdrfCOMRelativePath: El mismo tipo de registro que el anterior pero en esta opción el Path del objeto es relativo, no absoluto. Se usa en variedades muy específicas de instalaciones.

  • DLL’s .NET

Este tipo de ficheros tienen 2 opciones de registro que corresponden con las dos últimas del punto anterior. Las diferencias entre un tipo y otro se basan básicamente en que los objetos COM tienen la información de registro en la propia dll mientras que las librerías .Net no contienen información del tipo de datos COM. El instalador usa para esto la herramienta tlbExp.exe que genera la información de registro asociada a la librería .Net.

Jugando con las diferentes ideas expuestas anteriormente se puede configurar completamente la estructura de directorios y ficheros que utilizará nuestro instalador.


Registry Editor


Esta sección del instalador permite crear editar o borrar entradas en el registro de Windows. Por ejemplo si queremos crear una entrada en el registro con la localización donde hemos instalado la aplicación, tenemos que ir a la rama del registro deseada y allí crear una nueva clave.


Creando una nueva clave en el registro


Como se ve en la imagen vamos a crear una clave en el registro en la entrada correspondiente a HKEY_CURRENT_USER -> Software -> [Manufacturer]. Este Manufacturer corresponde a la misma propiedad que comentamos brevemente que se puede modificar en las propiedades del proyecto.

Finalmente la el editor de registro quedaria así:



Vemos que hemos añadido una carpeta más a la ruta del registro ([ProductName]) y que después hemos añadido una clave (haciendo botón derecho en el carpeta donde se quiere añadir la clave aparece un menú contextual) a la que le hemos dado el nombre de Location y el valor [TARGETDIR]. Este valor es de nuevo una propiedad del proyecto, que como vemos se pueden utilizar en diferentes sitios del instalador para no tener que establecer los valores en tiempo de compilación. De todas formas también se podía haber optado por colocar una cadena de texto fija (por ejemplo si tuviéramos una ruta de instalación fija y conocida de antemano).

File Types Editor

La sección de Tipos de Archivo permite asociar tipos de archivo a nuestra aplicación. Por ejemplo si nuestra aplicación utiliza unos archivos con extensión “.jkp” podemos definir que se abra automáticamente nuestra aplicación al abrir uno de estos ficheros. No entraremos más en detalle al estar fuera de las funcionalidades más básicas de un instalador.

User Interface Editor


En esta sección se pueden definir las diferentes pantallas de las que constara el instalador. Por ejemplo si habrá una pantalla de bienvenida, de información de licencia al usuario, la de finalización de la instalación, etc.

Hay un número suficiente de formularios de usuario y tiene algunas opciones para personalizarlos, cómo cambiar el banner por defecto, aunque aún está bastante lejos del nivel de personalización de aplicaciones de terceros.

La pantalla muestra dos árboles diferentes, Install y Administrative Install. La primera es la instalación tradicional, donde el programa a instalador está en la máquina a instalar, mientras que la segunda corresponde a una instalación de red, donde hay una fuente desde donde los usuarios de la red pueden instalarse la aplicación.

Un punto a destacar es la instalación silenciosa, o sin interfaz de usuario. No es posible configurar un instalador para que se instale de manera silenciosa, la única manera de hacerlo es a través de la línea de comandos de Windows Installer (msiexec.exe).

Custom Actions Editor


Las acciones personalizadas son la característica de los instaladores de Visual Studio que mas flexibilidad aportan a la generación de instaladores. No entraremos en detalle porque escapan un poco del acercamiento básico de este artículo pero a grandes rasgos lo que permiten es definir una serie de acciones a realizar por el instalador. La forma de definir estas acciones es a través de librerías de código, ejecutables o scripts. Por ejemplo:

· Definir una acción personalizada que nos abra una página de internet que nos interese por cualquier razón.

· Que aparezca un formulario para configurar los parámetros iniciales de una aplicación una vez haya finalizado toda la instalación, o cualquier cosa que se nos ocurra.

· Controlar el tiempo del progreso de la instalación y mostrar el tiempo restante al usuario

Algunas características de las Custom Actions son:

· Se ejecutan SIEMPRE una vez haya finalizado todo el proceso de instalación. Es decir primero se llevan a cabo los pasos definidos en los otros puntos del instalador y finalmente se empiezan a ejecutar las CustomActions, en el orden en que se hayan añadido.

· Se pueden definir acciones para los procesos de instalación, desinstalación, confirmación y rollback (deshacer?). Lo mas normal es que una misma acción tenga implementados todos los casos.

Información más detallada de las Custom Actions en MSDN

Launch Conditions Editor

La última sección proporciona información de las dependencias y condiciones que se han de dar en la maquina de destino para que se lleve a cabo la instalación.

Algunas ya aparecen por defecto, por ejemplo la versión del .Net Framework:



Pero además podemos añadir tanto condiciones de inicio cómo que se haga una búsqueda de un fichero, una clave del registro o un instalador en la máquina de destino, y si estas no se cumplen la instalación no se llevará a cabo.

Con todo esto es posible comenzar a crear instaladores sencillos, que permitan realizar las funciones básicas de un instalador y que además cubren muchos de los casos de las aplicaciones empresariales.

Únicamente faltaría compilar el instalador y si no hay errores proceder a la instalación del mismo. Destacar por último que esta instalación puede realizar de varias maneras:

  • Desde el propio Visual Studio, con un menú contextual que aparece sobre el elemento que representa el proyecto en el explorador de soluciones.
  • Desde el propio msi generado, haciendo doble click en el mismo (o con algunas de las opciones de su menú contextual)
  • Directamente desde la línea de comandos con la utilidad msiexec.exe.

Para obtener más información y funcionalidades avanzadas de los proyectos de instalación con Visual Studio podéis consultar el siguiente enlace : http://msdn.microsoft.com/en-us/library/aa372845(VS.85).aspx

También interesante es el siguiente blog donde se muestran una serie de artículos muy interesantes sobre los proyectos de instalación de Visual Studio: http://www.simple-talk.com/dotnet/visual-studio


Esperamos vuestros comentarios con impaciencia!



domingo, 19 de octubre de 2008

Implantando una metodología ágil

Implantar una metodología ágil en una empresa no es fácil. Desde nuestra posición de desarrolladores se pueden hacer algunas cosas pero es importante tener un jefe que te permita ciertas licencias. Si este es tu caso, siempre tienes posibilidades de llegar más lejos en tu implantación.

Aqui vienen algunas directrices desde nuestra pequeña expieriéncia en nuestra empresa. Quizá no es el mejor modo de hacer las cosas, pero es el que nosotros hemos podido hacer dentro de nuestras posibilidades. Esperemos que te sirva de ayuda.
  • Implanta un repositorio de código: Si quieres hacer trabajo colaborativo, que el hacer merge de tu código con el de tus compañeros no sea un infierno en el que se pierden funcionalidades y mucho tiempo, si quieres recuperar versiones anteriores sin dificultad, esto es lo primero que debes hacer. Y lo mejor de todo es que no hace falta que te gastes un duro. Puedes, por ejemplo, utilizar subversion. Si todavía te quieres complicar menos la vida, instala el servidor de subversion llamado svnserver. Y sobretodo, aprende a utilizar bien el repositorio de código. Si no lo haces puedes perder el trabajo de varias horas de trabajo y lo que conseguirás es justo el resultado contrario: no vas a poder implantar la metodología.
  • Empieza a programar testeos unitarios en tu código: Al principio verás que tu velocidad de programación se reducirá bastante ( puede llegar a descender hasta un 50% ) pero a medio plazo ( o incluso a corto plazo ) verás que tener tu red de seguridad de los tests unitarios es una gozada. Puedes refactorizar el código, hacer canvios en el diseño, hacer pequeños cambios en el código o lo que quieras, que siempre sabrás que tu código cumple con lo que especifican los tests. No hace falta que hagas TDD, con hacer los tests después de programar hay suficiente.
  • Porque no pruebas SCRUM? O alguna otra metodología ágil. Nosotros te recomendamos esta, que es la que intentamos implantar. Te será dificil al principio concienciar a tus jefes de seguir esta metodología al pie de la letra, pero poco a poco los irás convenciendo. Intenta ser estricto en su utilización. Programa las reuniones de inicio de sprint, utiliza planning poker para tus estimaciones, decide la duración de tu sprint, decide qué cosas entran y cuales no en tu sprint, programa un dia para la demo y diselo a todo el mundo. Haz las reuniones diárias y que estas no se alarguen en demasía. Haz la demo el dia que has programado y haz después una reunión de revisión de sprint.
  • Implanta un sistema de integración continua: Algo muy importante para mejorar el rendimiento de tu equipo es la detección temprana de errores. Junto con el testeo unitario, otra de las herramientas claves para conseguirlo es la implantación de un sistema de integración continua (CI). Puedes hacer que cada vez que alguien sube código al repositorio, el servidor de CI inicie una compilación del código, pase los tests programados y te enviee el resultado de todo esto. Así puedes saber al momento si una modificación hecha por algún desarrollador ha roto la build.
  • Conciencia a tu equipo de las bondades de las metodologías ágiles: todo el equipo tiene que estar concienciado en este nuevo camino. Si no motivas al equipo, no notarás el avance en la implantación. Si la gente no es consciente de que todo lo que se está haciendo es para mejorar el trabajo de todo el mundo no se esforzarán lo suficiente en hacer todo lo que se propone. Es importante que entre todos paséis el abismo que se abre al implantar una nueva forma de trabajar para poder avanzar a mayor velocidad.
  • Documentate: Lee mucho. Sé critico con tu trabajo y también con lo que lees. Aprende de la expieriéncia de la gente que lleva muchos años más que tu implantando este tipo de cosas. Documéntate sobre otras metodologías y evalua cual se adapta mejor a tu entorno. Habla con tu equipo, con tus jefes y con todo el mundo que puedas sobre tus ideas. No intentes imponer nada, sinó que intenta que todo el equipo sea quien toma la decisión.
Bueno, estos son sólo unos pequeños consejos que provienen de nuestra experiéncia. No los tomes al pie de la letra, cada uno tiene un equipo distinto, trabaja en una empresa distinta, tiene unos jefes distintos, etc. Tampoco hace falta que los implantes en este orden. Este es el orden en que lo hemos hecho nosotros y por ahora nos va bastante bien ( por lo menos sobrevivimos! ).

Nos leemos en el siguiente artículo.

domingo, 12 de octubre de 2008

Procedimientos almacenados en Firebird

Todo gestor de base de datos que se precie ofrece a los usuarios la posibilidad de programar procedimientos almacenados. Firebird no podía ser menos, así que en este artículo veremos cómo crear dichos procedimientos y cómo llamarlos desde nuestra aplicación .Net.

Creación

Veamos un pequeño ejemplo de procedimiento y después pasaremos a comentarlo línea por línea.

CREATE PROCEDURE FILL_MOVIE ( PARAM1 INTEGER )
AS
DECLARE VARIABLE VAL INTEGER;DECLARE VARIABLE CNT INTEGER;
begin
DELETE FROM MOVIE;
val = 0;
val = GEN_ID (GEN_MOVIE_ID, val - GEN_ID (GEN_MOVIE_ID,0) );


Cnt = 1;
WHILE (Cnt <= 3) DO BEGIN INSERT INTO MOVIE (TITLE, DIRECTOR,YEAR) values('Trainspotting','Danny Boyle', '1996'); Cnt = Cnt + 1; END suspend; end


Este pequeño procedimiento lo que hace es insertar tres veces la película Trainspotting en nuestra base de datos.

En la primera línea del procedimiento estamos creando el mismo, indicándole su nombre y si tiene parámetros, tanto de entrada cómo de salida, el nombre y el tipo de los mismos. En la siguiente línea, y siempre entre el AS y el BEGIN ponemos la declaración de las variables que se utilizaran en el procedimiento. Esta declaración se realiza mediante las palabras reservadas DECLARE VARIABLE seguidas del nombre de la variable y su tipo.

Ya en el cuerpo del procedimiento, lo primero que se hace és borrar el contenido de la tabla MOVIES y resetear el generador de identificadores asociado a la tabla. Cómo no existe ninguna función para establecer directamente el valor de este generador, deberemos llamarlo pasándole como incremento su valor actual en negativo.

Una vez hecho esto, pasamos a realizar un bucle utilizando un WHILE donde haremos el INSERT y actualizaremos el valor de la variable CNT.


Llamada desde .Net

Una vez tenemos hecho el procedimiento, es hora de poder llamarlo desde nuestra aplicación .Net. Para hacer esto nos ayudaremos de la libreria para acceder a Firebird desde .Net. Desde nuestras clases de acceso a datos, deberemos crear una nueva función enargada de llamar a un procedimiento remoto. Esta función será prácticamente igual a la que tengamos para ejecutar un ExecuteNonQuery, con la salvedad que antes de hacer la llamada, deberemos establecer el tipo de comando a StoredProcedure.

private int ExecuteStoredProcedure(string pNameStoredProcedure, bool pIgnoreError)
{
try
{
using (FbConnection connection = new FbConnection(Connection.ConnectionString))
{
int result = 0;
connection.Open();
FbTransaction transaction = connection.BeginTransaction( IsolationLevel.ReadUncommitted);
if (transaction != null)
{
FbCommand command = new FbCommand(pNameStoredProcedure, transaction.Connection, transaction);
command.CommandType = CommandType.StoredProcedure;
result = command.ExecuteNonQuery();
transaction.Commit();
}

connection.Close();
return result;
}
}
catch (Exception e)
{
Tracer.WriteLine("ExecuteStoredProcedure : '" + pNameStoredProcedure + "'. Missatge: " + e.Message);
return -1;
}
}


return 0;
}

Y hasta aquí este pequeño tutorial. Espero que os sea útil. Para cualquier duda, nos leemos en los comentarios!