Este año el Developer Day está dedicado a la seguridad. Por suerte esta vez contamos con un superhéroe a nuestro lado que nos ayudará a librarnos de los malos, aunque bien es cierto no es la primera vez que nos echa una mano, trayéndose a unos amigos por si acaso.

En ocasiones es necesario medir el tiempo que transcurre en completarse alguna operación en nuestro código, ya sea para optimizar su rendimiento o por cualquier otra razón. Para ello, en ciertas situaciones se puede utilizar la propiedad 'Now' de la clase DateTime, que devuelve una instancia de DateTime con la fecha y hora actuales. Se toma este valor en dos puntos diferentes del código y se restan para obtener el tiempo transcurrido.

Esta aproximación sólo será válida si la duración de la operación a realizar es relativamente larga, pero, en muchas ocasiones, la precisión ofrecida por este método no será suficiente y obtendremos que el tiempo transcurrido es 0, lo que no da mucha información. Para estos casos se usan habitualmente las funciones QueryPerformanceFrequency y QueryPerformaceCounter del API de Windows. Si se realiza una búsqueda sobre estas funciones en cualquier buscador, se verán cientos de artículos explicando su funcionamiento, con lo que no voy a extenderme aquí en su uso.

Lo que si puede resultar interesante en este caso es saber que estas funciones también se pueden utilizar en Windows CE, y, por tanto, están disponibles en Pocket PC y SmartPhone. Para utilizarlas hay que declararlas mediante P/Invoke de la siguiente forma:

[DllImport("coredll")]
private static extern bool QueryPerformanceCounter(out long lpPerformanceCount);

[DllImport("coredll")]
private static extern bool QueryPerformanceFrequency(out long lpFrequency);

Como se ve están definidas en la librería coredll.dll que contiene casi todo el API nativo de Windows CE.

Para mostrar su uso, se adjunta un ejemplo (PerformanceMeter.zip) que contiene una solución de Visual Studio 2005 para Windows Mobile 2005 Pocket PC, con lo que es necesario disponer del SDK de Pocket PC 2005 para poder probarlo tal cual está (si no se dispone de ese SDK, se puede crear una solución en Compact Framework 2.0 para Pocket PC 2003 y añadir las clases a ese proyecto para utilizarlas). Esta solución contiene 2 proyectos. El primero, llamado PerformanceMeter, contiene tres clases cuyo objetivo es facilitar la realización de pruebas de rendimiento a lo largo del código de manera cómoda y reutilizable. El proceso sería el siguiente:

• Crear una instancia de la clase PerformanceMeter
• Crear un nuevo test de rendimiento mediante la llamada a PerformanceMeter.NewTest(), que devuelve una instancia de la clase PerformanceTest. Esta instancia es almacenada automáticamente en una colección interna de PerformanceMeter.
• En el punto en el que se quiera iniciar el test, se hace una llamada a la función Start() de la instancia de la clase PerformanceTest obtenida en el paso anterior.
• Cuando se quiera finalizar el test, se hace una llamada a la función Stop() de la misma instancia anterior.
• Para ver los resultados de los test realizados hay que consultar la propiedad PerformanceTests que contiene la colección de pruebas realizadas.

El objetivo de estas clases es el de poder realizar varios tests de rendimiento a lo largo de las pruebas de una aplicación dada para posteriormente poder crear un informe de cómo han resultado las pruebas, de la manera menos intrusiva para el código posible. Cada test contiene la siguiente información:

• Nombre y descripción del test, útil si se va a disponer de varios tests y se quiere sacar un listado de ellos.
• Número de iteraciones que realiza el test de un código determinado. Este valor sólo es una propiedad que se usa para calcular una media, de manera que si se entre la ejecución de la función Start y la función Stop el código realiza 10 iteraciones, la podemos establecer con ese valor para que devuelva la media por iteración.
• Fecha y hora de inicio y fin del test, obtenidos con DateTime.Now. Hay que tener en cuenta que los contadores de precisión no devuelven la hora.
• Tiempo de ejecución del test en milisegundos obtenidos con la resta de los anteriores.
• Duración media por iteración en alta precisión (propiedad AverageDurationPerIteration - tipo double), si se miden varias iteraciones.
• Tiempo de ejecución del test en alta precisión (propiedad TotalDuration - tipo Double)

Como ejemplo del uso de estas clases está el segundo proyecto incluido en la solución, PerformanceTests. Este proyecto presenta un formulario para Pocket PC y un menú, Tests, que hace, a modo de ejemplo, dos tests, uno de concatenación de strings y otro de búsquedas en un documento XML.

El primer test compara lo que tarda el código en concatenar 2000 cadenas con y sin usar la clase StringBuilder, y el otro test mide lo que tarda el código en acceder un nodo de un documento XML con XmlDocument y lo compara con lo que se tarda en acceder al mismo nodo usando XmlTextReader.

Cuando finalizan los tests, muestra en la ventana los tiempos medidos.

En este ejemplo, para que los resultados sean más reales, conviene ejecutar cada test dos veces y usar los resultados de la segunda ejecución, ya que la primera vez que se ejecutan cada uno de ellos hay un tiempo de carga e instanciación de clases que hacen que el primer test sea mucho más lento que el segundo.

Espero que resulte interesante.

Ya está disponible el Service Pack 1 de SQL Server 2005. Y aquí está la lista de errores corregidos en este service pack.

Recientemente he estado leyendo varios artículos y blogs que hablan sobre el patrón singleton. Su objetivo es asegurar que, dada una clase concreta, se dispone de una única instancia de ella en una aplicación.

La referencia principal sobre patrones es el libro “Design Patterns: Elements of Reusable Object-Oriented Software” donde se explica cómo funciona de manera genérica.

La gente sigue muchas veces al pie de la letra el libro y eso puede hacer que no se tengan en cuenta detalles del lenguaje o la plataforma que se esté utilizando y se llegue a situaciones que puedan complicarse, generándose errores en el código difíciles de detectar.

En el caso de .NET, hay una discusión bastante a fondo sobre el tema en el artículo “Exploring the Singleton Design Pattern”, donde se tienen en cuenta las ventajas del entorno concreto, evitando así muchos de los problemas que pueden darse si se intenta hacer una implementación directa según se copia el código del libro.

Teniendo esto en mente, en C# el código para un Singleton es bastante sencillo:

public class MiClase
{
 private MiClase() {}

 public static readonly MiClase Instance = new MiClase();

 public void HazAlgo()
 {
  …
 }
}

Como se ve, la implementación básica consta de 2 líneas de código, un constructor privado y una variable estática (Instance en este caso) que da acceso a la instancia única. Para entender los detalles de por qué esto funciona así, leer con detalle el artículo mencionado arriba.
A la instancia (única) de la clase se accederá desde el código cliente de la siguiente forma:

…
MiClase.Instance.HazAlgo();
…

Bajo mi punto de vista, esto queda muy limpio y sencillo de usar.

Los usos que se le pueden dar al Singleton son múltiples, como por ejemplo clases que almacenan información de configuración de la aplicación, clases para hacer logs, etc. Eso sí, ojo con su uso en aplicaciones web ya que podéis encontraros con problemas de concurrencia si no se tiene cuidado.

Después de las quejas y peticiones por parte de mucha gente acerca del modelo de licencias de SQL Mobile (sólo licenciado para usarse en Windows CE y Tablet PC), Microsoft ha respondido y se va a modificar la política de licencias apareciendo bajo un nuevo nombre, SQL Server Everywhere Edition, que podrá usarse en cualquier entorno a partir de finales de año.

El producto es exactamente el mismo, lo único que cambia es su nombre y la política de licencias.

Esto va a posibilitar el desarrollo de aplicaciones que compartan una misma base de datos en múltiples entornos, lo que va a facilitar la vida a más de uno.

Acude al taller que se celebra el día 27 de abril de 2006 en Barcelona.

Yo participo como ponente en una de las sesiones.

Ultimamente he estado probando diferentes dispositivos con diferentes versiones de ActiveSync (4.1, 3.5, 3.8, ...).

Después de instalar/desinstalar ActiveSync varias veces y volver a quedarme con la última versión (la 4.1 en este momento), vi que la opción de conectar ActiveSync con DMA había desaparecido de su sitio (en la versión en ingles de ActiveSync está en File-Connection Settings-Allow connections to one of the following -> DMA). Esta opción se instala con Visual Studio 2005 para permitir la conexión de los emuladores mediante ActiveSync y así poder probar diferentes cosas simulando un entorno más 'real'.

Si os ocurre lo que a mi, al perder esta opción de conexión se pierde la capacidad de conectar el emulador a ActiveSync, pero se puede restaurar fácilmente. Existe una dll COM en el directorio de instalación de los emuladores (típicamente en "\Program Files\Microsoft Device Emulator\1.0") llamada "SERDMAAsPlugin.dll". Este componente es el que implementa el tema de DMA en ActiveSync y tiene que estar registrado.

Para habilitar la opción de nuevo, primero hay que cerrar el proceso de ActiveSync (terminar la tarea 'wcescomm.exe' con el administrador de tareas) y ejecutar el comando

regsvr32.exe serdmaasplugin.dll

en el directorio en el que tengais esa dll. Una vez registrado de nuevo el componente, al arrancar ActiveSync estará de nuevo disponible la opción DMA y el emulador debería conectar sin problemas.

Yo de mayor quiero hacer cosas de estas...