[CatDotNet]: Microsoft TFS en Igualada con Luis Fraile

IMAGE_047Pues una vez más se celebró, el pasado viernes 22 de mayo, una nueva reunión del grupo de usuarios de la Calatuña Central, CatDotNet, y en esta ocasión le tocó el turno a Team Foundation Server de la mano de uno de los mayores expertos del tema, Luis Fraile.

Como viene siendo habitual en las reuniones de CatDotNet, pedimos a Luis que tratara de enfocar el evento desde un punto de vista práctico y básico, como si de vender las características del producto se tratara y lo cierto es que lo consiguió, como era de esperar, con creces.

Además de compartir unas cuantas fotos, queremos aprovechar para agradecerle el viaje que hizo desde Madrid con coche y esperamos que disfrutara de la zona durante todo el fin de semana y, por supuesto, abrirle las puertas a futuras participaciones con CatDotNet.

 IMAGE_049

‘this.’ is the question

Desde mis comienzos siempre he ido utilizando la palabra clave “this”, desde C++ hasta ahora con C#. El por qué, es porque me ha resultado más comodo a la hora de escribir y me ha resultado más comprensible el código a la hora de entenderlo, de la misma forma que uso otra de las palabras clave de acceso como ‘base’, aunque ésta únicamente se utilice en clases derivadas.

Por otro lado, desde hace algo más de un año vengo utilizando Resharper de jetbrains, y pese que en la versión 4.0 noté ciertos problemas de rendimiento, ahora, con la versión 4.5 recién lanzada, la verdad es que me resulta una herramienta productiva y útil. Bien, la cuestión es que Resharper, por defecto, lanza un “warning” cuando encuentra un “this.” en el código e indica que se trata de una palabra redundante, y  ciertamente en muchas de las ocasiones lo es, de la misma forma que lo es “base” o el uso del constructor de un delegado o el método ToString(), en algunas ocasiones. Pese a las “advertencias” he seguido utilizandola principalmente, y como he dicho, por comodidad y percepción de entendimiento del código y creí que estaba dentro de las “pautas de buenas practicas” el no usar redundancias dentro del código. A mi me la repampinfla. El uso de “this” no afecta al rendimiento ni me aporta ningún inconveniente, ergo seguiré utilizándola.

resharper_warning

Sin embargo, de camino a casa, en el tren, he estado probando Microsoft StyleCop para la evaluación de sintaxis C# el cual he utilizado para comprobar el código de un servicio WCF, generado por el asistente de Visual Studio a partir de la plantilla de proyecto WCF Service Library. Esta plantilla implementa un DataContract (CompositeType) con un par de propiedades las cuales no hacen uso de la palabra clave “this” y StyleCop, al ejecutarlo, me ha dado un warning [SA1101]. Esto me ha echo pensar si realmente la supuesta doctrina de buenas practicas recomienda o no el uso de esta palabra clave, es decir si realmente existe como tal.

stylecorp_result

Más allá de lo trivial del asunto, he estado mirando por Internet y no he encontrado, o no he sabido encontrar, nada relativo a ello y es por ello que ahora, a parte de estar haciendo tiempo en el tren de caminito a casa, me pregunto, en modo de curiosidad, ¿vosostros utilizáis “this” en vuestros desarrollos?

this

   1: [DataContract]
   2: public class CompositeType
   3: {
   4:     bool boolValue = true;
   5:     string stringValue = "Hello ";
   6:  
   7:     [DataMember]
   8:     public bool BoolValue
   9:     {
  10:         get { return this.boolValue; }
  11:         set { this.boolValue = value; }
  12:     }
  13:  
  14:     [DataMember]
  15:     public string StringValue
  16:     {
  17:         get { return this.stringValue; }
  18:         set { this.stringValue = value; }
  19:     }
  20: }

not this

   1: [DataContract]
   2: public class CompositeType
   3: {
   4:     bool boolValue = true;
   5:     string stringValue = "Hello ";
   6:  
   7:     [DataMember]
   8:     public bool BoolValue
   9:     {
  10:         get { return this.boolValue; }
  11:         set { boolValue = value; }
  12:     }
  13:  
  14:     [DataMember]
  15:     public string StringValue
  16:     {
  17:         get { return stringValue; }
  18:         set { stringValue = value; }
  19:     }
  20: }

 

NOTA: Probablemente este código no describa el valor descriptivo del uso de this, pero es que no me ha dado tiempo de crear un código descritivo para tal fin.

Proyecto “Huron”: Montacargas hacia la nube

Dentro de la plataforma Microsoft Azure, aparece cada vez con más fuerza un proyecto del que se ha venido hablando en los últimos meses y que promete ser, a priori, un revulsivo dentro de la apuesta de Microsoft en escenarios de sincronización. Huron (nombre en clave del proyecto) nace de la comunión de SQL Data Services y Microsoft Sync Framework. La idea es clara, Huron sera la plataforma de sincronización entre los datos “en la nube” y clientes desconectados. Huron, además, tratará de minimizar toda la complejida que conlleva la compartición de orígenes de datos, tales como la configuración y la seguridad, mediante el uso de herramientas de configuración (Huron Management Studio) y componentes de desarrollo.

Obviamente, los proveedores para los que, incialmente, estaran soportados seran SQL Server y SQL Server Compact, aunque se prevee soporte para Microsoft Access tal y como explica desde el blog del equipo de desarrollo de Microsoft Sync Framework. En dicho blog, se detalla algunas de las modificaciones respecto a las pretensiones iniciales, que ha sufrido Huron y de las cuales algunas ya se han hablado en Geeks.ms.

Por otro lado, y dado el contexto que se trata, Huron pretende ir más allá ofreciendo características tales como:

  • Publicar bases de datos en la nube
  • Suscribirse a una base de datos publicada en la nube y mantenerla sincronizada automaticamente.
  • Propagar las modificaciones sobre SQL Data Services a las bases de datos suscritas.
  • Habilitar la sincronización programada en background.
  • Realizar Backups y Restores de bases de datos hacia y desde la nube, respectivamente.

En definitiva, un proyecto del que deberemos estar al tanto y cuyas perspectivas iniciales le auguran un importante hueco “entre las nubes”.

MSBuild DotNetNuke Tasks

El amigo Vicenç Masanas acaba de publicar en codeplex, un intersantisimo proyecto para la actualización del archivo de manifiesto (.dnn) en el desarrollo de módulos para DotNetNuke. Tuve la oportunidad de ver como realizaba los compilados con MSBuild Community Task para la actualización de dependencias y versionado durante la última visita de Vicenç a Igualada. Pese a ello quedaban algunas lagunas y lo que MSBuild DotNetNuke Tasks ofrece es la posibilidad de realizar automáticamente todas las tareas tales como la actualización de la versión y lista de archivos incluidos en la distribución del módulo o la referenciación de scripts de SQL o DLL, según versionado.

En fín, yo poco más puedo decir, así que si sentís tanto curiosidad como necesidad, aquí os dejo el enlace.