Hasta pronto

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

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

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:




  1. 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.


  2. 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!

La estética también tiene leyes

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?

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"

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

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

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

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