La Mina Digital

Hasta pronto

2008-08-27T17:48:00Z

Hace una semana, revisando el blog, me sorprendió ver el mes de mi último post: ¡FEBRERO! Es inútil negarlo... he fracasado como bloguero y he caído en el pozo de todos aquellos que tras el primer año dejan de postear. ¿Por qué?

En parte, siento que el blog es una herramienta de profesores y no de alumnos como yo...
En parte, siento que esta vida llena de quehaceres me fuerza a dejar el blog siempre para esos huecos que nunca llegan...
En parte, no me acabo de resignar a que "La Mina Digital" sea un cajón de sastre generalista, y es difícil seguir escribiendo sobre una tecnología con la que actualmente no estoy trabajando...
En parte, porque ya hay demasiados blogs y no veo que éste aporte mucho...
En parte, porque tal vez me esté haciendo viejo... Bueno, eso no.

Espero que hayáis pasado un buen rato leyendo esto. Yo me he divertido... pero ha llegado el momento de ampliar horizontes. Aprender nuevas materias, tal vez desarrollar algo interesante, o quién sabe... tal vez volver a bloguear. Eso nunca se sabe.

El AJK, la máquina de pila y el CLR

2008-02-21T22:59:00Z

Iba de camino al trabajo leyendo la MSDN Magazine, cuando me ha llamado la atención un artículo titulado "Cree un compilador de lenguaje para .Net Framework" (http://msdn.microsoft.com/msdnmag/issues/08/02/CompilerWriting/?loc=es). Me ha hecho sentirme joven y recordar a JosuKa: mi profe de compiladores en la universidad.

Lo primero por lo que he recordado a JosuKa es la similitud entre el CLR y la "máquina de pila" que inventó y desarrolló para sus prácticas. JosuKa... ¡eras un visionario!

Para los que no sepáis de qué hablo... JosuKa nos ponía como ejercicio el desarrollo de un compilador para un lenguaje y máquina objetivo ficticios. El lenguaje se llamaba "AJK" (que la verdad, no se que rayos significa) y generaba código para...¡¡tachán!! ... ¡¡¡la máquina de pila!!!. Precisamente Joel Pobar, el autor del artículo que os comentaba, nos presenta el CLR como una máquina de pila... muy similar a la de JosuKa (como no podría ser de otra forma).

Lo segundo que he recordado, es que en nuestras prácticas usábamos herramientas específicas para el desarrollo de compiladores, cosa que en el artículo no se hace.
• Par el escáner usábamos Flex, un clon del Lex.
• Para el parser usábamos Bison, compatible con Yacc.
• El generador de código se escribía en C, por medio de una librería proporcionada por JosuKa. En el artículo se utiliza System.Reflection.Emit
(Más sobre Lex, Yacc, Flex y Bison en http://dinosaur.compilertools.net)

Me he puesto a hurgar un poco por Internet y he encontrado unos clones de Lex y Yacc para .Net: GPLEX y GPPG (http://www.plas.fit.qut.edu.au/gppg/ y http://www.plas.fit.qut.edu.au/gplex/)

Por último, el artículo da unas pinceladas sobre cómo se enlaza el código en los lenguajes dinámicos... tan de moda con el DLR de Silverlight y con mi dulcemente odiado JavaScript (no es nada personal, mi querido lenguaje, todo es fruto de la incomprensión).

De verdad que os recomiendo la lectura del artículo... y seguro que añadiendo al "pack" estas herramientas, ¡podéis divertiros un buen rato!

¿Y por qué os cuento todo esto? Pues porque para mi, la moraleja es que todos los procesadores (reales o virtuales) son simples máquinas de pila, y todos los compiladores "comparten el 99% de los genes".

No se si este conocimiento sirve realmente de algo... de hecho, ni siquiera puedo decir que te vaya a ayudar a programar mejor (y si puedes programar peor, si caes en el antipatrón de la optimización temprana). Ocurre lo mismo que con los coches: para conducir un coche no es necesario saber cómo funciona un motor de explosión... y sin embargo, para quien le gustan los coches, este es un conocimiento sin el que símplemente no podría vivir.

Herramientas para diagnóstico de problemas en el MSDTC

2007-12-13T19:13:00Z

Ayer estuve peleándome con un servidor en el que había dejado de funcionar el MSDTC (había dejado de funcionar con un poco de ayuda por mi parte, he de admitir). Bueno, el tema es que tratando de diagnosticar el problema y tras ver que las trazas del MSDTC muchas veces dicen bien poco (TRANSACTION_ABORTED y poco más), di con dos herramientas que me resultaron bastánte útiles para diagnosticar problemas relacionados con la red. Allá van:

DTCTest: http://www.sqldev.net/misc/DTCTest.htm . Esta es una herramienta que permite ir probando si las transacciones distribuidas se inician y finalizan correctamente desde cada uno de los nodos de la red. Se puede probar a iniciar y finalizar (con éxito o con un rollback) la transacción, especificando qué msdtc coordinará, y sobre qué SQL Server se realizará. Permite además especificar la sentencia SQL con la que se testeará y si se iniciará la transacción con ODBC u OLEDB.
DTCPing: http://www.microsoft.com/downloads/details.aspx?FamilyID=5E325025-4DCD-4658-A549-1D549AC17644&displaylang=en . Esta herramienta se lanza en los dos nodos que participan en una transacción distribuida y verifica que no hay ningún impedimento de comunicaciones para que se pueda iniciar la transacción (ambos nodos pueden resolver el nombre de su "oponente", se pueden acceder entre sí por RPC... etc).

¡Espero que no necesitéis usar ninguna de las dos!

Guía de diseño para pantallas táctiles

2007-10-29T11:57:00Z

Navegando por ahí he encontrado una interesante guía de diseño para aplicaciones que corren en pantallas táctiles. Viene de SAP, que curiosamente tiene un estupendo sitio web sobre usabilidad... ¿lo utilizarán? ;-). La guía la podéis encontrar en http://www.sapdesignguild.org/resources/TSDesignGL/Index.htm

La estética también tiene leyes

2007-07-08T15:11:00Z

Cuando estudiaba en la universidad, recuerdo que me explicaron tan mal las leyes de la Gestalt, que acabé por no prestarles ninguna atención. Señor profesor, si me lee... no se lo tome a mal: no es nada personal contra usted. En general, en las universidades tiende a explicarse las cosas lo más alejadas de la aplicación práctica posible, y las leyes de la Gestalt sacadas del contexto del diseño de interfaces de usuario, parecen un conjunto de verdades de perogrullo meditadas en un momento de iluminación etílica.

Sin embargo, según pasan los años, me doy cuenta de que lo que deberían ser verdades de perogrullo, muchas veces se discuten en los equipos de desarrollo. Creedme... lleva mucho, muchísimo tiempo tomar una decisión con argumentos del tipo "a mi me gusta así" cuando probablemente podrían tomarse en un trís siguiendo criterios de la Gestalt. En este post pretendo hacer un repaso de las seis leyes de la Gestalt desde la perspectiva práctica del diseñador de interfaces Windows. Lo primero, para el que no haya oído hablar de estas leyes, podéis consultar la teoría aquí.

Leyes de la proximidad y de la semejanza

Agrupo estas dos leyes porque suele ser habitual aplicarlas en conjunto. La idea es que los elementos que están próximos, o los elementos que tienen una forma semejante, tienden a considerarse en su conjunto. En las interfaces de usuario, esto nos lleva a las agrupaciones de controles.

Si un grupo de controles se refieren a un mismo concepto, agrupándolos facilitaremos la comprensión de cada uno de los elementos (porque la mente humana los considerará como parte de un "todo"). Lo mejor es que lo veamos con un ejemplo:

Agrupación pésima (sacada de un ejemplo real). El grupo "archivo" se percibe como algo separado y distinto de la opción "generar script". De esta forma, no se entiende que el nombre de archivo que se solicita sea el nombre del script que se va a generar. La forma correcta de diseñar este diálogo sería:

En este ejemplo estamos aplicando:

Ley de la agrupación: se entiende que el textbox espacifica el nombre del archivo por el simple hecho de estar agrupado con el botón "archivo" y el checkbox de "generar script"
Ley de la similitud: el botón "OK" se llama ahora "Aceptar", con lo que se entiende que tiene una función idéntica al resto de botones "Aceptar" de Windows. Por otra parte el botón Archivo tiene puntos suspensivos, por lo que se entiende que sacará un cuadro de diálogo adicional.

Sobre la ley de la semejanza, hay que tratar de parecerse tanto a otras aplicaciones como a nosotros mismos. Trata de hacer tus interfaces siguiendo las guías de diseño de Windows. Trata de que tu aplicación se parezca a una que sea el referente en tu sector (todos los procesadores de texto acaban pareciéndose al que domina el mercado... pasó en su día con WordStar, luego con WordPerfect y ahora con Word). Por último, trata de que tu aplicación se parezca a sí misma: los diálogos deben ser similares, los conceptos deben expresarse con los mismos términos, y los iconos deben seguir los mismos paradigmas. Si dos cosas tienen un aspecto similar, el cerebro tiende a relacionarlas... y todo el conocimiento que haya adquirido sobre el modelo antiguo, lo aplicará al modelo nuevo. ¡Resultar familiar es la forma de tener que ahorrarte escribir un manual! ;-)

Ley del cierre y ley de continuidad

Estas leyes son más aplicables al diseño gráfico puro y duro que a la usabilidad, pero también pueden servirnos de ayuda. Básicamente, dicen que el cerebro tiende a cerrar cualquier figura a la que le falta un trozo, y que el cerebro continúa cualquier patrón que se interrumpe.

Su aplicación práctica principal están en mostrar más información de la que cabe en pantalla. Fijémonos en un procesador de texto:

Sólo vemos la esquina superior izquierda de un rectángulo, pero ya sabemos que representa parte de una hoja de papel (nuestro cerebro se ha encargado de cerrar la figura). Esto nos indica que lo que escribimos, se sitúa en determinado punto de la hoja de papel, y además sabemos que hay más sitio que no estamos viendo ahora mismo en pantalla. También se emplea la ley de continuidad para apoyar esta idea (se ha empleado un patrón gris, distinto del fondo blanco de la hoja, para reforzar la idea de que estamos escribiendo sobre un papel del que sólo vemos un trozo).

Ley de simetría

Literalmente dice "Las imágenes simétricas son percibidas como iguales, como un solo elemento, en la distancia". Esta es otra ley más aplicable al diseño puro y duro que a la usabilidad, pero sí que podemos tomar una lección: si no puedes usar grupos, utiliza la simetría. Si no nos cabe todo a un lado, podemos usar el lado opuesto... que parecerá que se refieren a lo mismo. Lo mejor es fijarse en una herramienta con muchos "toolbox" como Visual Studio. Todos los toolbox no cabrían en uno de los dos lados de la pantalla... colocando áreas de toolbox a la izquierda y a la derecha, se ha aumentado el espacio disponible para herramientas. Como las áreas de herramientas son simétricas, se perciben como iguales (se ve como natural que ámbas áreas contengan lo mismo, cuando en realidad no constituyen un grupo).

Ley de comunidad

"Muchos elementos moviéndose en la misma dirección son percibidos como un único elemento". De nuevo esta ley es más aplicable al diseño que a la usabilidad. Yo esta ley no la aplicaría, porque el movimiento dentro de un formulario Windows es algo que debería evitarse. Sin embago, también tiene su aplicación en los controles "Marquee" o marquesina. El típico control que muestra información bursátil. Se muestra mucha información en poco espacio, y además la información se percibe como un "todo".

Conclusión

Fíjate mucho en los programas de los demás, y fíjate en los patrones que siguen. Suelen estár ahí por algo... y aunque muchas veces creemos que en el diseño de un formulario prima la estética, lo cierto del caso es que se suelen tener en cuenta factores psicológicos que a cualquiera de nosotros (humildes programadores) se nos escapan. Trata de convencer a tus jefes de lo importante que es contratar a un experto en usabilidad, y si no te queda más remedio que tomar tú mismo las decisiones, innova todo lo que quieras, pero en áreas distintas a la interfaz de usuario. Revisa las guias de diseño de Windows, y recuerda... "inspirarse" en un programa conocido suele ser una buena idea: ¿por qué crees que todos los navegadores web se parecen al veterano Mosaic?

¿Depurar un script SSIS?

2007-04-18T18:58:00Z

Una de las mayores pegas que tiene Integration Services es el hecho de no poder depurar los scripts... bueno, ese y que el nodo script no soporte C# como lenguaje (sólo soporta Visual Basic). Si bien ninguno de los dos problemas tiene solución, el primero puede mitigarse en gran mediad con la capacidad que nos ofrece SSIS para lanzar trazas desde nuestros scripts. ¿Cómo se hace? ¡Atentos!

Los visores de datos: el script como una caja negra

Lo más sencillo para tratar de averiguar qué ocurre dentro de un script es observar qué salidas nos ofrece fuera. Para eso siempre podemos usar los "data viewers", que se añaden directamente al flujo de salida o de entrada en un script y nos muestran el contenido de los buffers. Esto está bien para detectar problemas serios, pero la mayoría de las veces no será de gran ayuda. En la imagen, tenemos un script que genera números del 1 al 100 y una transformación que los cuenta... si vemos que la salida es anormal, siempre podemos entrar en el código del script e inspeccionarlo en busca del comportamiento anómalo. Por cierto... en este sentido, ayuda el que los scripts sean sencillos y hagan el mínimo posible de cosas.

Cuando el exterior no ayuda, lo importante está en el interior.

Cuando el problema no es obvio, llega el momento de depurar. Lo que nos dice el sentido común es que pongamos un breakpoint en nuestro procedimiento, y que lo vayamos observando paso a paso:

¿Qué ocurre cuando ejecutamos el paquete SSIS? Absolutamente nada: no se detiene. Los breakpoints no funcionan para los scripts de SSIS (¡¡Microsoft, Socorro!!). Mientras los programadores de Redmond acudan en nuestra ayuda y solucionen este problema, veamos qué podemos hacer para sobrevivir:

Un punto de ruptura cutre: El MessageBox

Afortunadamente, tenemos una chapucilla que nos permitirá parar la ejecución de un script SSIS: El MessageBox. Alguno dirá... tantos años de evolución para volver a sacar mensajitos de "estoy aqui" o "voy por acá". Sí amigos... las viejas soluciones nunca mueren: "la chapu funciona" (máxima que aprendí en uno de las empresas en las que he trabajado hasta ahora). Colocar un "MessageBox.Show()" hará que el flujo del script se detenga hasta que pulsemos "OK".

Observar el valor de una variable privada

Cualquiera podría decir, si puedo sacar un MessageBox, puedo mostrar el valor de una variable privada. Cierto... sólo que si queremos saber el valor de una varible privada a lo largo de todas las iteraciones de un bucle, detener la ejecución a cada paso puede ser un tormento. Por fortuna, SSIS nos permite utilizar su potente soporte de Logging desde nuestros scripts. Para eso, vamos al menú SSIS -> Logging, habilitamos un proveedor de logging, y en la pestaña de "Details" seleccionamos la entrada "ScriptComponentLogEntry".

Eso habrá habilitado el logeo a los componentes script. En realidad ni siquiera es necesario especificar un destino para el log: bastará con mostrar la ventana "Log Events" (View -> Other Windows -> Log Events).... pero ojo, que el visor de logs tiene sus limitaciones que veremos más adelante.

Ahora sólo tenemos que usar el método "Log" que nuestro script habrá heredado de su clase base, de la siguiente forma:

Me.Log( messageText, dataCode, dataBytes() )

El método Log admite tres parámetros:

La cadena de texto que queremos mostrar en el log
Un valor numérico que queramos loguear: Cuidado, esta opción sólo funciona si hemos activado un destino para el log, si estamos viendo los logs con el visor de logs, curiosamente no se ve su valor
Un buffer de datos que queramos loguear. Ocurre lo mismo que con la opción anterior, sólo sirve si definimos un destino para los logs (no funciona con el visor de logs).

Como el visor de logs no permite ver los valores asignados a dataCode y dataBytes, generalmente nos convendrá loguear todo dentro de la cadena de texto, de la siguiente forma:

Me.Log( "El valor de i es " + i, 0, Nothing )

En fin, espero que esto os sirva para cogerle un poco más de cariño a la transformación Script, que no es tan mala como parece...

Material de la charla "Olap aún más fácil"

2007-03-22T20:31:00Z

Algún día tenía que ser, y este martes me toco a mi dar la charla mensual del grupo de usuarios de Euskadi, Artalde.NET. La charla fue una introducción muy básica a lo que es un sistema OLAP, y estuvo compuesta de:

Una pequeña charleta de 30 minutos, en la que vimos conceptos básicos.
Una demostración de hora y media, en la que hicimos una demo con un ETL y un cubo muy básicos... vamos, que nos marcamos un "OLAP Mundo" (por cierto... en la charla nadie se rio con ese chiste... ¿tan malo será?)

La verdad que tuvo bastante buena acogida, creo. Bueno, a lo mejor es que soy un optimista y no veía los bostezos de la gente... concentrado en ver cómo las transformaciones del dtsx cambiaban de color según pasaba el flujo de datos. Hubo algo menos de 40 personas, una de esas charlas en familia, en la que la gente que va de verdad está interesada en el tema. La gente se animó bastante a participar, y creo que el grupo de Artalde está cogiendo una "clientela fija" de fans incondicionales que son estupendos.

En fin, voy a dejar de enrollarme e iré al grano. Voy a dejar aquí el material de la charla, por si a alguien le interesa. Os dejo:

Las transparencias PowerPoint de la presentación.
La solución que contiene el ETL, y el cubo OLAP tal y como quedó al final.
Los datos de origen y el script de creación del Data Warehouse.

De los cubos no sacaréis mucha información, porque básicamente está construido a partir de datos aleatorios. Bueno... digamos que cogí la lista de clientes de AdventureWorks y la convertí en una lista de "nacimientos" (con el peso, talla y grupo sanguíneo del niño). Lugo le añadí datos sobre supuestos factores que determinaban el éxito social de esos retoños, y pretendía ser un "serio" estudio sobre la influencia que pueden tener factores como el signo del zodíaco en parámetros como el salario medio anual. Vamos... ¡verdadero papel mojado! Fue divertido... :-)

Aplicaciones prácticas de los algoritmos de minería de datos

2007-03-01T19:41:00Z

Hoy durante la comida, ha surgido un tema de conversación interesante: qué fácil resulta añadir nuevos algoritmos de minería de datos a SQL Server 2005... pero, ¿para qué puede servir? Lo cierto del caso es que meditando sobre el tema, no se me ha ocurrido ninguna aplicación práctica que no esté debidamente cubierta con los algoritmos "de serie". Todavía no estoy muy puesto en este tema, pero voy a hacer un esfuerzo mental y vamos a ver qué algoritmos trae Analysis Services y para qué los podemos utilizar.

Algoritmo Naive Bayes

Empezamos por este porque es el algoritmo que primero se suele utilizar para explorar datos. Básicamente, este algoritmo busca correlaciones entre atributos. Cuando no tenemos muy claro qué atributo se puede predecir en función de otros, una técnica muy habitual es tratar de utilizar el algoritmo de Naive Bayes tratando de predecir el valor de todos los atributos en función de todos los atributos (un "todos contra todos"). El resultado de esta orgía de correlaciones suele ser un modelo en el que tenemos más o menos claro qué vamos a poder predecir en esos datos.

Otra ventaja de este algoritmo es que se entrena muy rápido... pero su desventaja es que no es muy preciso. Vamos, yo lo usaría para:

Exploración inicial de los datos

Tareas de clasificación, en las que el rendimiento sea crítico. Se me ocurre, por ejemplo, entornos en tiempo real en los que queramos detectar entradas anómalas, validaciones, clasificaciones y filtrados de mensajes... etc.

Decision Trees (Árboles de decisión)

Los árboles de decisión son clarísimamente una herramienta potentísima de clasificación... de hecho, son probablemente el mejor algoritmo que podemos utilizar para clasificar. Básicamente, construyen un arbol del que se pueden extraer reglas, del estilo "Si eres hombre, tienes unos ingresos superiores a 'X', y eres comprador de revistas de coches... la probabilidad de que tengas coche es del 90%".

Nos pueden servir para tareas como:

Clasificación en general

Validaciones. Podemos detectar elementos anómalos en función de si encajan o no con las reglas surgidas del árbol (por ejemplo, "si tienes coche, menos de 20 años y estas en paro... probablemente mientas")

Predecir el valor de un atributo con precisión

Clustering

Sirve sobre todo para buscar elementos afines dentro de un conjunto. Por ejemplo, podemos usarlo para saber que en una población hay hombres y mujeres jovenes solteros, hombres mayores solteros, hombres y mujeres mayores casados... pero no mujeres mayores solteras.

Nos puede servir para:

Segmentar un mercado.

Validaciones (las entradas que no pertenecen a un cluster, pueden ser "outliners" o elementos anómalos).

Time Series (Series temporales)

Este algorimo es específico para predecir el valor de una magnitud en función del tiempo.

Por ejemplo:

Análisis bursátiles... ¿subirá o bajará el IBEX mañana?

Predicción de una magnitud analógica, en general.

Sequence clustering

Tambien es bastante específico para detectar secuencias típicas dentro de un conjunto de eventos. Por ejemplo... saber en qué orden hace click la gente en las noticias de una web, puede ayudarnos a ordenar los titulares de arriba a abajo y de derecha a izquierda.

Usos típicos:

Estudio de secuencias de eventos

Detección de algunas anomalías de comportamiento (eventos que llegan fuera de secuencia)

Association rules (Reglas de asociación)

Este se suele usar casi exclusivamente para análisis de cesta de la compra. Detecta asociaciones comunes entre elementos (por ejemplo, quien compra cerveza suele comprar también palitos salados).

Usos típicos:

Análisis de la cesta de la compra

Ofrecer recomendaciones al comprador: ¿has comprado cerveza, seguro que no quieres palitos salados?

Neural Network (Redes neuronales)

Al igual que los árboles de decisión, este algoritmo también resuelve problemas de clasificación y regresión. Puede ser adecuado para detectar patrones no lineales, difícilemente descriptibles por medio de reglas. Se usa como alternativa al algoritmo de arboles de decisión: lo mejor es probar ambos sobre un mismo problema y utilizar el que mayor acierto nos de en sus predicciones.

Nos pueden servir para tareas como:

Las mismas tareas que los árboles de decision, cuando los grupos en los que se divide la población no son lineales. Si no sabes a qué me refiero, imagina la tarea de clasificar puntos en un espacio... cuando no se pueden clasificar fácilmente trazando líneas, el problema no es lineal.
Regresiones (es similar a la clasificación, pero cuando se trata de predecir una magnitud contínua).

Bueno, el caso es que la riqueza de los algoritmos que vienen incorporados con SQL Server es tal, que no se me ha ocurrido ni un sólo escenario en el que se pueda necesitar algo distinto... ¿eres capaz de comentar alguno? La verdad que esta versión del 2005 es impresionante, ¿verdad?

Suprimir los warnings de FxCop para un proxy WCF

2007-02-13T20:07:00Z

Qué "antiestético" es el código con warnings, ¿verdad? Una de las cosas que más me llamó la atención, y tengo que reconocer que para mal, es la cantidad que saltan al pasar el FxCop sobre los proxies que genera Windows Communication Foundation. Da una sensación horrible, y cuando uno suprime los warnings, ver que al regenerar los proxies volvemos a la situación anterior, es tremendamente frustrante. Alguno estará pensando... ¿y qué hace este cenutrio pasando el analizador estático a código generado de forma automática? Bueno... mi problema es que no puedo elegir... al activar el análisis de código en las propiedades de un proyecto, se activa sobre todos los fuentes... incluidos los proxies. No puedo vivir sin FxCop, y tampoco puedo vivir con los warnings... supongo que hay amores que matan.

Hoy he estado buscando una forma de suprimir los warnings sobre los proxies sin que al regenerarlos se borren las supresiones, y he aquí que he dado con una receta para el éxito.

El truco consiste en poner las supresiones en el "GlobalSupressions.cs". Los que uséis FxCop "a secas", podéis hacer esto de una forma bastente sencilla... sólo hay que seleccionar el error y tras hacer click con el botón derecho, seleccionar "Copy As -> SuppressMessage". Por desgracia, los que tenemos el FxCop integrado en Visual Studio 2005, no tenemos esta opción (nos la han prometido para Visual Studio Orcas).

No todo está perdido... todavía hay una solución. Solo, tenemos que actuar de la siguiente forma:

Suprimimos el error que ha detectado el analizador de código sobre el proxy. Esto meterá un atributo "SupressMessage" sobre el punto en el que se ha detectado el error. Nos fijamos en si el SupressMessage está sobre una clase, o sobre un método.
Quitamos el SupressMessage del proxy, y lo copiamos en el GlobalSupressions... poniéndole como prefijo "assembly". Es decir:

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2239:ProvideDeserializationMethodsForOptionalFields")]
Ahora tenemos que indicar dónde se encuentra el error original. Para eso, debemos especificar cual era el ámbito de la regla FxCop que ha saltado. Si ha saltado sobre una clase, el ámbito es "type", y si ha saltado sobre un método, es "method". Añadimos el ámbito por medio del parámetro "Scope" del atributo SuppressMessage:

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2239:ProvideDeserializationMethodsForOptionalFields", Scope = "type"]

o por ejemplo...

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1051:DoNotDeclareVisibleInstanceFields", Scope = "member"]
Por último, tenemos que indicar el punto en el que se encontraba el error. Para eso, utilizaremos el parámetro de nombre "Target", en combinación con el siguiente valor:

Si se trataba de una clase, se indica el nombre totalmente cualificado de la clase (con namespace)
Si se trataba de una propiedad o un miembro, el nombre totalmente cualificado del miembro.
Si se trataba de un método, el nombre totalmente cualificado del método, sin incluir los nombres de los argumentos (sólo los tipos) e indicando el tipo de retorno al final (con dos puntos, al estilo de C++).
Por ejemplo:

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2239:ProvideDeserializationMethodsForOptionalFields", Scope = "type", Target = "Sisteplant.Captor.Terminal.EventsBrokerProxy.EventInfo")]

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1051:DoNotDeclareVisibleInstanceFields", Scope = "member", Target = "Sisteplant.Captor.Terminal.WorkplaceServiceProxy.GetInManufacturingOrdersRequest.dateTime")]

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1030:UseEventsWhereAppropriate", Scope = "member", Target = "Sisteplant.Captor.Terminal.EventsBrokerProxy.IEventsBroker.RaiseEvent(Sisteplant.Captor.Terminal.EventsBrokerProxy.EventInfo):System.Void")]

Alguno podría tratar de suprimir varios errores tratando de establecer el Scope a "namespace"... pues bien, ni lo intentéis porque no funciona... hay que ir suprimiendo los errores uno por uno, y la lista de errores que os vais a encontrar es probablemente esta:

CA1030:UseEventsWhereAppropriate
CA1051:DoNotDeclareVisibleInstanceFields
CA1709:IdentifiersShouldBeCasedCorrectly
CA1711:IdentifiersShouldNotHaveIncorrectSuffix
CA2227:CollectionPropertiesShouldBeReadOnly
CA2239:ProvideDeserializationMethodsForOptionalFields

En fin, esperemos que la calidad del código generado automáticamente mejore... y no sólo haciendo que funcione el atributo "AutoGeneratedCode" que el svcutil añade a los proxies (y que por cierto, el FxCop no se toma muy en serio). Yo me pregunto... ¿tanto cuesta generar código que supere la regla CA1709?

Nueva guía de optimización de Analysis Services 2005

2007-02-05T17:00:00Z

Microsoft ha publicado una guía de optimización para SSAS 2005. En la guía menciona que es aplicable a partir del Service Pack 2 (que estará disponible en breve y del que hace tiempo que se puede descargar una CTP)... sin embargo, muchos de los puntos que indican son aplicables desde ahora. De momento sólo le he podido echar un vistazo rápido, pero prometo contaros mis impresiones tras una lectura detallada. Podéis descargaros la guía desde esta URL:

http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SSAS2005PerfGuide.doc

Clase Singleton vs. estática

2007-02-01T20:28:00Z

Esta es una duda que nos suele surgir muy a menudo a todos... ¿merece la pena desarrollar un Singleton, o me basta con una clase estática? ¿Cual es el enfoque correcto? ¿Es el Singleton la clase estática de los "pijos", o la clase estática el Singleton de los pobres? La verdad es que como siempre que hablamos de estos temas, suele haber opiniones para todos los gustos... así que contribuiré con una más a que el mundo sea todavía más caótico.

Bueno, como todos sabéis, una clase estática y una singleton tienen, a grandes rasgos, una gran diferencia: la clase Singleton es aquella para la que existe una única instancia accesible por nuestra aplicación y la clase estática es aquella para la que ni siquiera existe instancia (todos sus métodos y miembros son estáticos). Aparentemente sirven para lo mismo, así que... ¿por qué debería usar un Singleton?

El principal motivo, a mi entender, es la capacidad que tiene el Singleton de evolucionar hacia una clase que tenga más de una instancia. Puede que no vemos sentido a esto, pero el principio de encapsulación que hay detrás de un Singleton es el mismo que distingue una propiedad de un miembro, o un evento de un delegado. La clase que hace un GetInstance de un Singleton asume que está obteniendo "la instancia" de esa clase, ¡pero nada nos obliga a que esa clase tenga que ser única! Es decir... ¿cúanto nos costaría ampliar el código que os pongo abajo, para añadirle un contador de instancias y permitir un máximo de tres? (lo dejo como ejercicio espiritual para mentes ávidas de pensar). En resumen... un puntito para el Singleton.

class Singleton
{

   private static Singleton _instance;

   private Singleton()
   {
   }

   public static Singleton Instance
   {
    get
       {
           if (_instance == null)
           {
               _instance = new Singleton();
           }
           return _instance;
        }
   }
}

Otra ventaja del Singleton está en que los métodos no son estáticos, y por tanto se pueden sobreescribir en las clases herederas (son "overrideables"). No se puede hacer un override de un método estático. Vamos, que si pretendemos hacer una jerarquía de clases de instancia única, más nos vale que tiremos hacia el singleton... de lo contrario tendremos problemas. Singleton 2, Estática 0
La clase Singleton tiene instancia, y eso en sí ya es una ventaja. Por ejemplo, eso nos facilitará que nuestro Singleton pueda implementar interfaces que sencillamente una clase estática nunca podrá implementar. De nuevo, la clase Singleton puede "crecer" con más facilidad que la estática en este sentido. Singleton 3, Estática 0
En cuanto a qué es mejor para implementar una clase Thread Safe, fijaros que básicamente el problema que tenemos es el mismo: si tenemos varios threads modificando miembros de la clase, habrá que sincronizarlos y asegurarnos de que sólo uno es capaz de alterar un miembro cada vez. La clase Singleton tiene una peguilla adicional, y es que tenemos que proteger también el método que obtiene la instancia. No es un gran problema... hay un artículo muy interesante de cómo hacerlo AQUÍ. Yo diría que en cuanto a la seguridad de threads, ambas clases "empatan".
Algunos opinan que la clase Singleton es más adecuada para representar clases que mantienen un estado. En realidad esta puede ser más una cuestión de gusto (buen gusto, se entiende) que un requisito real. Ambas clases pueden contener perfectamente un estado. De nuevo otro empate.
¿Y dónde gana la clase estática? En su simplicidad. Así que como el "Keep it Simple" es un argumento que vale por tres, ¡digamos que Singleton y clase estática empatan a puntos! Singleton 3, Estática 3

Vamos, que la idea con la que nos debemos quedar es que una clase Singleton va a hacer nuestro programa un pelín más difícil de comprender, así que como todo, es un recurso que sólo debemos utilizar si es necesario. Y yo, como siempre, que sigo sin mojarme... ¿quieres mojarte tú? ¡¡pues mándame tus comentarios!! Los espero ansioso.

El verdadero geek no se queja de que su reproductor de MP3 no ordene las canciones...

2007-01-23T20:22:00Z

... el verdadeo geek, escribe una rutina que ordene alfabéticamente los archivos y directorios de un directorio FAT.

Sí, lo reconozco: tengo un reproductor de MP3 que es una verdadera porquería. Antes tenía un Creative MuVO V200, pero desde que me lo cargué con una actualización de firmware, mi vida se había vuelto gris y anodina. Sabía que si me compraba algo mejor que el MuVO, también acabaría tratando de "tunearlo" a toda costa, y por ende, cargándomelo, así que me decanté por un modelo baratito. Así, al menos, cuando me lo cargase, tampoco me daría demasiada pena.

El caso es que mi nuevo reproductor desde el principio me dejó desconcertado. Resulta que cuando cargaba canciones desde el Windows Media Player, estas no se reproducían en orden alfabético, sino en el orden en el que las había añadido al reproductor. ¡Qué invento del demonio!

<< Tanto esmero en ordenar mi biblioteca de emepetreses para que este chisme con vida propia decida que mi vida requiere un orden distinto al que yo he previsto. No me gusta... no, no, no y no. Me niego a la regir mi vida al ritmo de un tirano digital >>. Tenía que hacer algo, así que busqué una explicación a semejante ultraje.

Lo primero que pensé fue: "el ceporro que haya programado esto, ordena las canciones por fecha de creación del archivo". Es curioso... los programadores siempre pensamos que el resto de programadores son unos ceporros, ¿verdad? Y resulta que no es ni más ni menos certero que el nivel ceporrismo que tú, querido lector, puedas intuir en mis palabras. Lo cierto del caso es que el programador del firmware de mi MP3 no es un ceporro. Es un programador ágil, que no ha implementado ninguna característica porque nadie se la ha solicitado.

El problema de mi reproductor de MP3 es muy común, y no está causado por la mala baba de un programador que quiera dominar el mundo imponiendo su propio orden a nuestros archivos: está causado por la implementación del sistema de archivos FAT.

Pensemos en cómo es un directorio FAT:

Bueno, además de ver que soy un cutre que dibuja en las servilletas de papel, vemos que un directorio es una simple tabla con el nombre, extensión, atributos... y un apuntador al primer cluster en el que se encuentra el archivo. ¿Cual es el problema con mi reproductor de MP3? El problema es que cuando añadimos archivos o subdirectorios a un volumen FAT, estamos añadiendo secuencialmente entradas a esta tabla. El programador de mi reproductor, va leyendo y reproduciendo cada una de estas entradas, así que si las pilla desordenadas, las reproduce tal cual (provocando la ira de los que como a mi, nos gusta oir las canciones en un determinado orden).

¿Cómo se puede solucionar esto?

Lo primero que se nos ocurre es: ¡Ordenemos esa tabla! Se trata sólo de leer estructuras de tamaño fijo desde disco a un buffer, ordenarlas, y volver a volcarlas a disco. Es cierto, el problema es tan sencillo como ese... pero este enfoque tiene dos desventajas:

Requiere acceso directo a disco, por lo que en Windows sólo podría funcionar con permisos de administrador.
Las estructuras a manejar son distintas en función del tipo de FAT que tenga el disco (hay FAT12, 16 y 32, con ligeras diferencias en el directorio... nombres largos... etc).

La segunda solución requiere aprovecharse del conocimiento de la mente de los programadores. Sí amigos... pensad en cómo MOVERÍAIS archivos en un directorio FAT. Desde luego, a nadie se le ocurriría moverlos físicamente en disco... ¡basta con cambiar las entradas de la tabla!. Así que ese es el truco que siempre funciona para ordenar archivos en un volumen FAT: ir moviéndolos a un nuevo directorio, sabiendo que la nueva tabla se irá creando secuencialmente. Una vez completada la operación, sólo tenemos que sustituir el directorio original por el nuevo.

Así que ahora ya puedo ir tranquilamente por el mundo, escuchando mis canciones en el orden que a mi me gusta, y mirando por encima del hombro a todo aquel que tiene un iPod, Muvo, Zune, o cualquier reproductor de "pedigree". Vosotros tendréis un reproductor mejor que el mío, pero el mío venía con rompecabezas de regalo, ¡y lo he solucionado!.

PD: Os dejo los fuentes y binarios del programita que uso para ordenar el directorio de mi reproductor de MP3. A ver si alguien le pone una bonita interfaz gráfica de usuario, lo modifica para que ordene por distintos criterios al alfabético, ¡y de paso me lo envía de vuelta!

Transacciones en Integration Services

2006-12-19T19:49:00Z

Uno de los puntos de SSIS que muchas veces nos pasa desapercibido y que sin embargo conviene conocer, utilizar y amar, es el soporte para transacciones. Estamos cargando un DataMart, y ¡zas! la carga falla a mitad de camino. ¿Qué hacemos? ¿Parece mentira que la ejecución de un ETL que puede hacer infinidad de cambios en nuestro DataMart se pueda deshacer en caso de fallo, verdad? ¡Pues se puede!

Para controlar las transacciones, todos los objetos del "Control Flow" (incluido el propio control flow) tienen una propiedad llamada "TransactionOption", que puede tomar los siguientes valores:

Required: Este elemento se ejecuta en el contexto de una nueva transacción.
Supported: El elemento se ejecuta en el contexto de la transacción que ya estuviese abierta (por alguno de sus "padres"). En caso de que no se hubiese iniciado ninguna transacción, el objeto no es transaccional. Es el valor por defecto que da Integration Services a todos los elementos del flujo de control.
NotSupported: El objeto no es transaccional, aunque esté ejecutándose en el contexto de una transacción

Entonces, hacer un ETL transaccional es tan sencillo como pulsar en el fondo del "Control Flow" de un paquete y establecer TransactionLevel a "Required". Eso hará que todos los elementos que arrastremos al flujo se ejecuten por defecto en el contexto de una transacción. Si uno de estos elementos falla, se desharán los cambios realizados por el resto de elementos que se hubiesen ejecutado dentro de la misma transacción.

El segundo parámetro a tener en cuenta es IsolationLevel, que especifica cómo gestionará SSIS la transacción. Podéis buscar información en MSDN sobre este parámetro... yo sólo os dejo caer un par de notas:

Cuanto menos restrictivo sea el modo de funcionamiento de la transacción, mayor será el rendimiento. Por ejemplo, ReadUncommited y Chaos permiten ver los cambios antes de que estos se hagan permanentes con un Commit. O sea, que si estamos cargando un DataMart y mientras tanto alguien accede al mismo, obtendrá datos inconsistentes. Si nuestras circunstancias permiten "evitar" el acceso al DataMart mientras esté siendo cargado, puede ser una buena opción.
Serializable es el más restrictivo, pero a la vez más seguro: evita que se pueda acceder a los datos nuevos que insertemos en el DataMart hasta que se haga un Commit, y evita que se modifiquen los datos anteriores al inicio de la transacción. Generalmente es el más adecuado para cargar un DataMart (es la opción por defecto).
Snapshot es nuevo en SQL Server 2005, y permite trabajar a la transacción sobre una "copia" de los datos tal y como estaban al inicio de la transacción, sin bloquearlos. Al finalizar la transacción, se consolidan los cambios. Esta es la que menos impacto supondrá en el resto de aplicaciones que accedan al DataMart mientras lo estamos cargando, pero a costa de usar parte de nuestro espacio de almacenamiento. Personalmente no le veo demasiado uso en la carga de un DataMart, porque por su propia naturaleza, los datos del DataMart no suelen sufrir modificaciones (por lo que Serializable puede ser una mejor opción)

Espero que después de esto en vuestras oficinas dejen de oirse gritos y lamentos debido a ese corte de luz que sucede siempre justo en medio de la ejecución de un ETL...

Y ya sabés, feliz navidad.... ¡y prósperas transformaciones!

¿Te gusta mi Software Factory?

2006-12-06T11:54:00Z

Hay dos cosas que me pierden: el merchandising de los eventos de Microsoft, y casi todo lo nuevo que voy probando. Sí, si, lo se... soy un poco "pattern happy", un poco amante de los gadgets y muy, muy "friki" (en el sentido más puramente hispano de la palabra). Actualmente me está atrayendo poderosamente la idea de las Software Factories y los Domain Specific Languajes (DSL). Me atrae tan poderosamente que, como me conozco, empiezo a dudar sobre si lo que me atrae es real, o son cantos de sirena.

¿Software factoqué?

Cuando el famoso cocinero de la tele nos prepara un delicioso Marmitako, o nos deleita con una chuletitas de cordero ricas, ricas, ricas... nos está enseñando una receta. Nos da un conjunto de pasos, técnicas y conocimientos, que nos ayudan a triunfar en un determinado dominio: la cocina. Digamos que la distancia para sorprender a nuestra churri, es más corta si seguimos una receta que si tratamos de improvisar en los fogones.

Una Software Factory sigue el mismo principio: es un conjunto de patrones, documentación (recetas), plantillas y mucha, mucha, mucha... ¡generación automática de código! Personalmente estoy usando la Smart Client Software Factory, que te ayuda a desarrollar Smart Clients que se sustentan sobre Composite UI Application Block (CAB).

Vale, eso tiene sentido... ¿y los DSL?

Las Software Factory casi siempre van de la mano de los DSL, o "Domain Specific Languajes". ¿Te imaginas que el programa de Arguiñano se hiciese en el plató de Bricomanía? ¿Sería raro, verdad? Cada situación requiere un conjunto distinto de herramientas, y cada dominio, un lenguaje adaptado a su contexto. El problema de los lenguajes de propósito general, es que son como el plató de Bricomanía... por el simple hecho de que tengamos una sierra de calar, podemos sentir la tentación de usarla para trinchar el pavo. La solución para evitar el error, es deshacerse de la sierra de calar.

Hace poco, alguien, tratando de hacerme bajar de mi nube, me decía que hace 20 años que tratan de vendernos los lenguajes de 4ª generación, y me insinuaba que esto es el mismo perro con distinto collar. Bueno, en cierto modo los DSL se parecen a los 4GL en que buscan ser declarativos (yo digo lo que quiero, y no cómo lo quiero) pero no pretenden ser tan ambiciosos. Ciñéndose a un dominio, es más fácil tener éxito con un lenguaje declarativo.

Lo cierto es que cada vez que abrimos el diseñador de interfaces de Visual Studio, ya estamos usando un DSL. Nosotros añadimos controles a un formulario y enlazamos eventos con código usando un lenguaje visual, basado en el paradigma de arrastrar y soltar. Lo mismo ocurre cuando desarrollamos un ETL con Integration Services... los DSL llevan años acompañándonos.

En algunos casos, el DSL ni siquiera requiere que se abandone el lenguaje de propósito general... simplemente, se limita a ocultar la complejidad del mismo, y nos guía para que sólo utilicemos aquella parte del lenguaje adecuada a nuestros fines. Llevamos años encapsulando para tratar de ocultar la complejidad... ¿por qué somos tan reacios a que una herramienta nos abstraiga del propio lenguaje procedural?

Lo pasamos por la batidora, y directo al horno (220ºC)

Microsoft nos está preparando un buen plato a base de DSLs, patrones, Software Factories y demás ingredientes. Los muchachos se llaman GAX, GAT (Guided Automation Extensions y Guided Application Toolkit, respectivamente) y DSLTools y están a punto de llegar a este lado del Mississippi.

Esta pretende ser una revolución en la forma en la que desarrollamos software. Paremonos a pensar en la mayoría de ISVs y sus catálogos de software... es habitual que los ISV se especialicen en un dominio, ¿verdad? Los hay quienes hacen herramientas de desarrollo, software de tratamiento de imágenes, productos de seguridad... pero generalmente, igual que cada cabra tira a su monte, cada ISV va a su terreno. Luego hay consultoras capaces de hacer de todo (hasta botijos, si estuviesen bien pagados), pero bueno, estamos hablando de desarrollo de software, y no de tratantes de carne humana (huy lo que he dichoooooo...), y estoy seguro que hasta éstas pueden beneficiarse de las Software Factories.

Imaginaos este mundo idílico, en el que nuestro arquitecto desarrolla la Software Factory adecuada a nuestro dominio, y nuestros desarrolladores la utilizan para programar aplicaciones específicas para el dominio. ¿Acaso no es una forma estupenda de transferir el conocimiento?

¡Camarero una manzanilla!

Para acabar sin indigestión, os voy a recetar un poco de descanso (a poder ser en vuestro sofá más cómodo) y cuando vuestro cerebro pida guerra, unos cuantos links:

Tom Hollander's blog: Habla mucho sobre GAT y GAX, y también da noticias sobre nuevos "application blocks"
Matias Woloski: Sobre todo habla de la Smart Client Software Factory
Patterns & Practices: Software Factories: Noticias sobre las software factories de Microsoft.

Y ahora, ya puedes opinar... ¿Estamos hablando de la Piedra Rossetta del desarrollo de software, o son cantos de sirena?

Ya tenemos RadarCube NET Windows Forms for Microsoft Analysis Services

2006-11-28T19:59:00Z

El mercado de los controles del tipo "pivot table" empieza a activarse. Señores... hay demanda para un sustituto de los Office Web Controls, y RadarSoft está echando el resto. Hoy han lanzado RadarCube NET Windows Forms, un control Winforms para .NET 2.0 que permite presentar datos multidimensionales en nuestras aplicaciones Windows. Podéis encontrar más información y unos cuantos pantallazos en esta URL: http://www.radar-soft.com/products/radarwin_msas.aspx.

Además hoy han anunciado que bajan los precios del RadarCube ASP.NET.

Dos estupendas noticias... a ver si hay suerte y se empiezan a popularizar herramientas que hasta ahora estaban reservadas sólo a una élite. Como diría Groucho... ¡¡¡Más madera!!!

Testeo unitario de cubos OLAP

2006-11-20T19:01:00Z

En Internet no se encuentran muchas páginas sobre cómo testear un cubo OLAP... probablemente, como en toda tecnología "emergente", cada uno se las arregle como pueda y pocas cosas estén ampliamente extendidas. Sin embargo, con el resto de tecnologías "más convencionales" todo el mundo tiene una opinión formada sobre el testeo unitario o el "test driven development" (generalmente para bien). ¿Se pueden conciliar ambos terminos? ¿Puedo escribir "unit tests" para mis cubos OLAP?

La respuesta es "SIN DUDA". El mundo del Business Intelligence puede beneficiarse en gran manera del testeo unitario, gracias a lo que se conoce como "Data Driven Unit Test". ¿De qué va esto?

Analicemos las siguientes sentencias SQL y MDX, lanzadas respectivamente contra la base de datos "Adventure Works" y el cubo de Analysis Services correspondiente:

SELECT Production.Product.ProductNumber AS Product,
SUM(Sales.SalesOrderDetail.OrderQty) AS Quantity
FROM Sales.SalesOrderDetail, Production.Product
WHERE Sales.SalesOrderDetail.ProductID = Production.Product.ProductID
GROUP BY Production.Product.ProductNumber
ORDER BY Product ASC
SELECT NON EMPTY [Product].[Product Key].[Product Key] ON ROWS,
[Measures].[Order Quantity] ON COLUMNS
FROM [Adventure Works]

Si las ejecutamos, ambas producen resultados similares... una sobre el sistema OLTP y la otra sobre el sistema OLAP. Vaya, empezamos a entender... ¡si ambos sistemas producen resultados similares, eso debe significar que nuestro sistema OLAP funciona correctamente! Eso es el Data Driven Unit Testing, y nos vendrá de miedo para probar nuestros cubos. Recordemos que el escenario habitual en un desarrollo de BI será partir de un sistema existente, así que... ¿qué mejor prueba de que nuestro sistema funciona, que demostrar que devuelve los mismos resultados que el sistema de partida?. Cuantos más cruces de dimensiones comparemos con salidas del sistema OLTP, mejor será nuestra batería de tests.

Es difícil, por no decir imposible, tener una cobertura del 100% del cubo, pero como se suele decir, testear algo es infinitamente mejor que no testear.

Data Driven Unit Test en Visual Studio Team System

Para realizar testeo unitario guiado por datos, tenemos que partir de una tabla de base de datos en la que tendremos almacenado cada uno de nuestros juegos de pruebas. En el ejemplo que he puesto, si no disponemos de tabla, tendremos que crear una vista.

CREATE VIEW Test.vOrderQuantityPerProductKey AS
SELECT Production.Product.ProductNumber AS Product,
SUM(Sales.SalesOrderDetail.OrderQty) AS Quantity
FROM Sales.SalesOrderDetail, Production.Product
WHERE Sales.SalesOrderDetail.ProductID = Production.Product.ProductID
GROUP BY Production.Product.ProductNumber

Este es el punto que menos me gusta, tener que partir obligatoriamente de una tabla accedida mediante OleDB y no poder partir de una sentencia SQL... pero bueno, sigamos a lo nuestro. Nos ponemos las botas de programar, nuestra música favorita, y creamos un nuevo proyecto de tipo "Test Project".

Visual Studio creará por nosotros una clase de test, con un método de test. Tendremos que indicar que el método de test es "Data Driven", para eso, editamos las propiedades del test e indicamos:

Data Connection String: Cadena de conexión a nuestra base de datos.
Data Table Name: El nombre de la tabla donde se encuentran los valores a probar, junto con los resultados esperados.
Data Access Method: Squential. Con esto indicamos que se deberá probar secuencialmente con todos y cada uno de los valores de la tabla.

Como resultado de la edición de estas tres propiedades, Visual Studio decorará nuestro método de test con un atributo DataSource, señal clara de que nuestro test es guiado por datos.

        [DataSource("System.Data.SqlClient",
            "Data Source=.;Initial Catalog=AdventureWorks;Integrated Security=True",
            "Test.vOrderQuantityPerProductKey",
            DataAccessMethod.Sequential),
            TestMethod()]

Rematando la faena: escritura del test

Escribir el test unitario es sencillo... lo primero que tenemos que hacer es tener una propiedad de tipo TestContext, llamada TestContext. En esta propiedad, Visual Studio nos irá dejando el contexto de cada test, es decir, en nuestro caso, los valores para cada uno de los juegos de prueba.

private TestContext _myTestContext;

        public TestContext TestContext
        {
            get { return _myTestContext; }
            set { _myTestContext = value; }
        }

Lo siguiente es escribir el test:

        public void OrderQuantityPerProductKeyTestMethod()
        {
            // Construimos la sentencia MDX para el producto actual, y obtenemos la cantidad del cubo.
            String mdxQuery = "SELECT [Measures].[Order Quantity] ON COLUMNS "
                              + "FROM [Adventure Works] WHERE [Product].[Product Key].["
                              + TestContext.DataRow["Product"]
                              + "]";
            AdomdCommand mdxQueryCommand = new AdomdCommand(mdxQuery, _adomdConnection);
            CellSet cubeResult = mdxQueryCommand.ExecuteCellSet();

            // Comparamos el resultado del cubo, con el resultado de la base de datos.
            int result = (int)cubeResult.Cells[0].Value;
            int expected = (int)TestContext.DataRow["Quantity"];
            Assert.AreEqual(expected, result, 16);

}

Como veis, me limito a ejecutar una sentencia MDX que me devuelva de los cubos OLAP el valor equivalente al del juego de ensayo. Para obtener el juego de ensayo, leo del diccionario "DataRow" del TestContext cada una de las columnas de mi tabla de pruebas, y por último pruebo con un Assert que los resultados del cubo sean los esperados.

La invocación de Assert.AreEqual tiene un tercer parámetro que vale 16... ¿qué significa?

Este parámetro, es el "delta" de la función. Muchas veces, cuando metemos datos en un cubo por medio de un ETL, durante el proceso de limpieza se pierde precisión en los datos. Como resultado de la limpieza, los valores extraidos de la base de datos OLTP y OLAP podrían no coincidir... pues bien, el "delta", es la desviación que toleraremos en nuestra prueba (en este caso, +/- 16 enteros). Podéis descargaros el proyecto completo que he adjuntado a este post, y experimentar todo lo que queráis (por ejemplo, probad a bajar el valor del delta y observad qué pasa...).

Despidiendo el post

Hemos visto cómo los test unitarios no están de más en el mundo de la inteligencia de negocios... y recordad que tal y cómo dice SCRUM, un proyecto no está terminado mientras no esté probado.

Happy testing!

RadarCube for Analysis Services (o cómo el ratón a veces rinde más que el puma)

2006-11-07T20:17:00Z

Ahora que los Office Web Control ya son historia, Microsoft nos ofrece MOSS 2007 y su espectacular Excel Services como solución de representación de datos multidimensionales. Hoy lo he estado probando y ver cómo se muestran en la web las hojas de trabajo de Excel 2007 por obra y arte de AJAX es espectacular (hablo de la tecnología, no de cierto producto de limpieza) . Si tenemos Sharepoint implantado en nuestra empresa, no cabe duda de que sería una locura no aprovecharlo...(read more)

UDM, posiblemente lo mejor de Analysis Services 2005

2006-10-24T17:03:00Z

El salto cualitativo que ha dado Analysis Services es tal, que cuando uno trata de elegir su característica favorita lo puede tener francamente complicado. Hay nuevos algoritmos de minería de datos, tiene la posibilidad de tener cubos con varias tablas de hechos, las "linked measures", los ETL con flujos de datos y flujos de control separados... sin embargo, si me preguntasen cual es para mi la mejor característica de SSAS 2005 no dudaría ni un segundo en responder que en el "UDM".

El UDM, o Unified Dimensional Model, es una capa intermedia que permite a SSAS abstraerse de la fuente de datos en la que se almacenan los hechos y dimensiones de un cubo. De esta forma, ya no necesitamos disponer físicamente de una base de datos con un modelo relacional en estrella, sino que podemos partir de cualquier modelo relacional y construir una "estrella virtual" sobre el UDM. Esta estrella virtual es algo parecido a si organizásemos una estrella en base a vistas sobre una base de datos relacional, pero tiene la ventaja de que puede tomar datos desde distintos orígenes.

Parece sencillo, ¿verdad? ¿y por qué es a mi entender, la mejor característica de SSAS2005? Puede que no parezca una característica revolucionaria, pero el UDM nos abre las puertas de la "minería de datos operacional".

Tradicionalmente, las aplicaciones basadas en tecnología OLAP se han utilizado para el análisis de datos históricos: existía un entorno OLTP, un Data Warehouse y un proceso batch, llamado ETL, que transladaba datos de uno a otro. Los cubos OLAP se montaban sobre los datos del Data Warehouse, y por lo tanto estaban disponibles para su análisis únicamente tras la ejecución del ETL (y en el caso de los cubos MOLAP, tras el procesado de los cubos, en los que se cargan los distintos niveles de dimensiones y se construye la base de datos de agregados).

Con UDM, podemos prescindir del Data Warehouse y tomar los hechos directamente del almacén OLTP (de ahí el nombre de "minería de datos operacional"). Incluso podemos tomar datos de varios almacenes OLTP, de una combinación de almacenes OLTP y DataMarts, o por qué no, de datos obtenidos en tiempo real que pudiesen representarse en forma de tabla (cualquier origen OLEDB o ADO.NET puede aportar tablas a nuestro modelo UDM).

Una vez configurados todos los orígenes de datos (DataSources) podremos unificarlos y darles el aspecto que queramos utilizando un DataSourceView, en el que podremos:

Relacionar tablas
Establecer vistas
Establecer campos calculados

¿Qué ventaja obtenemos con esto? Sencillo... el UDM nos permite romper con la barrera del tiempo y realizar análisis sobre los datos según se producen. Por supuesto, esto tiene sus implicaciones de rendimiento y su ciencia particular: tendremos que usar ROLAP o HOLAP (configurando adecuadamente la Proactive Cache) para prescindir del procesado de cubos en batch al que nos obliga MOLAP. ¡Uau! ¡Cubos OLAP sin procesos batch! En resumen UDM es una verdadera "revolución silenciosa" que abre las puertas del OLAP en tiempo real.

Business Intelligence y privacidad

2006-10-18T18:29:00Z

El otro día, mientras probaba unos cubos OLAP en la oficina, alguien se me acercó y curioseó a mi espalda. Increíble... estaba cruzando dimensiones y generando informes que hasta ahora las aplicaciones corporativas no podían obtener. Por arte de magia, estaba cruzando averías surgidas en un conjunto de máquinas con los operarios que las manejaban en ese momento. Por supuesto se trataba de datos falsos y para mi sólo era una prueba explorando las capacidades de los nuevos cubos... pero quien estaba tras de mí no pudo dejar de recordarme que yo era poco menos que el demonio.

Desde entonces he pensado mucho en el tema. Curiosamente, los grandes volúmenes de información que se tiene de nosotros, garantizan en cierta forma nuestro anonimato. Esta es una afirmación un tanto chocante y que a más de uno le puede hacer chirriar las tuercas, pero no deja de ser por eso menos verdadera. Todos los días generamos cientos de "pedacitos" de información que van quedando en uno y otro lugar, entremezclados con los pedacitos de información que han dejado otros. El volumen de datos es tal, que es imposible obtener información de ellos, sencillamente porque el bosque es tan inmenso y cerrado, que nos es imposible encontrar un árbol concreto. Pero vaya... las tecnologías de Business Intelligence nos facilitan acceder al árbol que buscamos... ¡y a todos sus parientes genéticos! ¡y con un par de clicks de ratón!

Mi primer pensamiento fue...

Bien, con mi sistema, se puede se puede poner nombre y apellidos a información que de otra forma serían puras estadísticas anónimas. Así que podemos saber que Serapio es más hábil manejando una fresadora que Fulgencio, y que a Fulgencio se le estropea cada dos por tres. ¿Perjudica esta información a Serapio y Fulgencio? Evidentemente, perjudica a Fulgencio y Beneficia a Serapio. ¿Pero es esto malo? ¿Soy el demonio?

Mmm... el sistema beneficia a quien lo hace bien, y perjudica a quien lo hace mal. Además lo hace basándose en una enorme cantidad de variables, y de forma totalmente imparcial. A mi me parece bastante justo, ¿no? Ese día pude dormir tranquilamente, a sabiendas de que mi sistema, en buenas manos, sería una herramienta que permitiría impartir justicia.

Pero esa noche tuve una pesadilla... ¿En buenas manos?

Al día siguiente, al llenar el depósito de mi coche, pasé la "Travel" en mi gasolinera habitual... y pensé, ¡allá va mi pedacito de información!. Pero me quedé inquieto. ¿Irá ese pedazo de información a buenas manos? ¿Qué se podría hacer con esa información? Amigos míos... ¿imagináis qué se puede hacer con las tecnologías actuales de business intelligence sobre la base de datos de "Travel Club"? Y por supuesto, no es sólo la Travel... son mis "tracking cookies" cuando navego por Internet, mi "historial" en los distintos sitios web en los que me autentico con un Microsoft Passport (o Windows Live Id) y un montón de actividades que realizo a diario. Muchos, muchos, muchos pedacitos de información.

No me considero el demonio... ¡pero estoy seguro de que la misma tecnología sobre la que escribo en este blog, es un arma de destrucción masiva en manos del Demonio! De hecho, me pregunto qué sería de las empresas que desarrollan spyware sin la ayuda del "business intelligence".

Y llegamos al punto que quería atacar... ¿quién, y sobre todo cómo, me protege de los abusos? Más de uno dirá, ¡para eso está la legislación, amigo! Entonces comparo mi trabajo con el de quien explota información obtenida del spyware, y... ¡vaya! Realmente en algunos casos los hechos pueden ser tremendamente similares, y las tecnologías que empleamos muy parecidas. Realmente nos diferencian las intenciones... ¡pero es que se juzgan los hechos, y no las intenciones!

Bueno, todo esto me ha hecho empatizar con los legisladores... uff, ¡qué difícil tiene que ser legislar contra el spyware! Y me surge otra pregunta... ¿y si alguien utiliza un sistema creado con buena fe, para obtener información que se podría emplear con mala fe... el desarrollador del sistema es responsable en parte?

No me ha quitado demasiado el sueño, porque sigo pensando que la tecnología es éticamente neutra, y que lo moral o inmoral es el uso que se hace de ella. Seguro que los metereólogos podrían sacar chispas al "business intelligence". Mi conciencia está tranquila. Pero los años me recuerdan que habitualmente, las leyes van tres pasos por detrás de la moral.

Paths relativos en Integration Services

2006-10-10T18:05:00Z

Uno de los aspectos más molestos de SSIS, es el hecho de que no permita utilizar rutas relativas en las cadenas de conexión a archivos. Esto es un problema si queremos realizar un ETL que se vaya a desplegar en una ruta distinta a la utilizada en tiempo de diseño... pero por fortuna, aunque un poco rebuscado, hay un truco que permite utilizar paths relativos.

Atended pues, a esta receta con la que podréis desarrollar un ETL rico, rico, rico... que os permita:

Utilizar archivos como orígenes de datos sin tener que colocarlos en rutas fijas
Lanzar archivos "dtsx" que se almacenen en el directorio en el que se está ejecutando el ETL
... etc, etc, etc...

Vamos pues, paso a paso con el truquillo:

Lo primero que hay que hacer es definir una variable con el path en el que se desplegará el ETL. Definidla de forma que sea global al archivo "dtsx" principal en el que se haya implementado el ETL. Ya sabéis, se va a la pestañita de "Control Flow" y se define la varible desde allí.
Cuando creamos una conexión a un archivo, Integration Services nos obliga a establecer como cadena de conexión, la ruta absoluta a un archivo existente. Pues bien, satisfaremos los deseos de SSIS haciendo que la conexión apunte a un archivo existente.
Seleccionamos “Propiedades” de la conexión sobre la que queremos establecer la ruta relativa.
Seleccionar “Expresiones” (pinchamos en los tres puntitos al lado de "expressions" en la ventana de propiedades).
Seleccionar “ConnectionString”
Establecer una expresión que construya un path absoluto en función de la variable con el path de despliegue: en mi ejemplo, @[User::DeploymentPath] + "\\Data\\DayOfWeekNameValues.txt". Esta expresión, se resolverá en tiempo de ejecución y sobreescribirá el valor de la propiedad que hubiésemos establecido en tiempo de diseño.
Por último, deberemos propagar el valor de la variable a paquetes hijos, por medio de la opción "SSIS-> Package Configurations". De todas la opciones disponibles, seleccionaremos la opción de tomar una configuración de una variable desde el paquete padre.
La variable que marca la ruta al paquete, también puede configurarse desde "SSIS-> Package Configurations". La opción más adecuada en este caso, es tomar su valor de una entrada de registro, o de una variable de entorno (consultad los libros en pantalla, que las entradas de registro tienen que tener un formato específico).

Bueno, espero que os haya gustado mi primer post tras la vuelta de vacaciones. Os deseo un buen comienzo de curso, y ya sabéis... ¡felices transformaciones!