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

Error: No se puede mostrar un mensaje de error porque no se pudo encontrar un ensamblado de recursos opcional que lo contiene.

Aka: Could not find resource assembly

Esta mensaje de error aparece cuando se produce una excepción y no se encuentra el archivo de recursos de descripciones de errores para .NET Compact Framework.

Todas las cadenas de error asociadas a .NET Compact Framework 2.0 se almacenan en un archivo de recursos externo, llamado System.SR.dll. Este ensamblado no se distribuye para liberar memoria RAM del dispositvo.

La solución pasa por instalar el CAB System.SR.[Lang].cab dónde Lang denota el idioma en el que queremos mostrar el mensaje de la excepción. Dicho CAB se encuentra en:

%PROGRAM_FILES%Microsoft.NETSDKCompactFrameworkv2.0WindowsCEDiagnostics

NOTA: De forma análoga sucede lo mismo para mensajes de error relacionados con .NET Compact Framework 3.5. Alejandro Mezcúa publicó hace poco un post sobre ello.

Bluetooth en .NET [Compact] Framework

Hará aproximadamente tres años empecé a desarrollar una  libreria en .NET para la gestión de Bluetooth en Windows Mobile a raíz de un artículo que se publicó en dotNetMania num 35 (Marzo 2007).

Durante el tiempo que estuve desarrollando dicha libreria, pude apreciar realmente la dificultad que entraña un desarrollo sobre dicha tecnologia. De hecho, la libreria para Windows Mobile no pude finalizarla –se quedó con algunos Bugs- y la de Windows XP/Vista (unicamente 32 bits) logré que permitiera gestionar la radio Bluetooth, buscar dispositivos cercanos, emparejarse y comunicarse via COM mediante el servicio RFCOMM; quise expandir la libreria mediante el uso de la capa SDP (Service Discovery Protocol) de búsqueda y uso de servicios específicos a través del API de Bthioctl.dll de Windows Vista, pero ahí se quedó por falta de tiempo.

Desde que el material está expuesto en desarrolloMobile.NET, recibo muy a menudo preguntas o curiosidades en mi buzón de correo personal de las que, pese a que algunas desconozco, la mayoria hacen referencia a cómo empezar y de ahí el motivo de este post, para todos aquellos que quieran saber por dónde pueden empezar a implementar soluciones basadas en Bluetooth en sus proyectos.

Aspectos básicos

Incialmente, tanto Windows Mobile como Windows XP/Vista nos ofrece librerias nativas para poder inicializar y obtener la información de la radio bluetooth local y algunas de esas APIs las podemos ver en el siguiente código y cuyas referencias las encontraréis aqui.

   1: public enum BthEstadosRadio : int
   2: { Desactivado, Activado, Detectable };
   3:  
   4: public class BTHRadio : IDisposable
   5: {
   6:     [DllImport("bthutil.dll", SetLastError = true)]
   7:     private static extern int BthGetMode(out BthEstadosRadio mode);
   8:     [DllImport("bthutil.dll", SetLastError = true)]
   9:     private static extern int BthSetMode(BthEstadosRadio mode);
  10:     [DllImport("Btdrt.dll", SetLastError = true)]
  11:     private static extern int BthReadLocalVersion(
  12:     ref byte phci_version, ref ushort phci_revision,
  13:     ref byte plmp_version, ref ushort plmp_subversion,
  14:     ref ushort pmanufacturer, ref byte plmp_features);
  15:     [DllImport("Btdrt.dll", SetLastError = true)]
  16:     private static extern int BthReadCOD(ref CategoriaDispositivo pcod);
  17:     [DllImport("Ws2.dll", SetLastError = true)]
  18:     public static extern int WSACleanup();
  19:     [DllImport("Ws2.dll", SetLastError = true)]
  20:     public static extern int WSAStartup(ushort version, byte[] wsaData);
  21:     //los enumeradores Fabricantes y CategoriaDispositivo son
  22:     //identificadores únicos (http://www.bluetooth.org)
  23:     private Fabricantes _fabricante;
  24:     private short _versionRadio;
  25:     private CategoriaDispositivo _claseDisp;
  26:     //constructor
  27:     public BTHRadio()
  28:     { // inicializamos sockets
  29:         ushort wsv =
  30:         ((ushort)(((byte)(2)) | ((ushort)((byte)(2))) << 8));
  31:         byte[] _data = new byte[512];
  32:         WSAStartup(wsv, _data);
  33:         //obt. versión y fabricante
  34:         byte version = 0, lversion = 0, caract = 0;
  35:         ushort revision = 0, lsubrevision = 0, fab = 0;
  36:         BthReadLocalVersion(ref version, ref revision,
  37:         ref lversion, ref lsubrevision, ref fab, ref caract);
  38:         this._fabricante = fab;
  39:         this._versionRadio = (short)lsubrevision;
  40:         //obtenemos categoría disp.
  41:         BthReadCOD(ref this._claseDisp);
  42:     }
  43:     //propiedad lectura/escritura del estado de radio
  44:     public BthEstadosRadio EstadoRadio
  45:     {
  46:         get
  47:         {
  48:             BthEstadosRadio currentMode;
  49:             BthGetMode(out currentMode);
  50:             return currentMode;
  51:         }
  52:         set
  53:         { BthSetMode(currentMode); }
  54:     }
  55:     //liberamos WS2.dll
  56:     public void Dispose()
  57:     { WSACleanup(); }
  58: }

Con esta clase podemos empezar a gestionar nuestro Bluetooth (siempre y cuando se MS Bluetooth Stack) pero en realidad nos ofrecerá muy poca funcionalidad al no ser que la finalidad de la aplicación sea mostrado el estado e información de la radio. La información, en definitiva, que muestra este código es la que podemos ver en la siguiente captura de pantalla:

Inforadio

Aspectos avanzados

Sin embargo, el uso de esta tecnología en nuestros desarrollos requiere unos requisitos previos. En primer lugar es altamente recomendable que se entienda el funcionamiento de Bluetooth. A grandes rasgos, remarcaría dos conceptos muy distintos.

 PRIMERO: Debemos conocer el perfil sobre el queremos trabajar. Bluetooth es un protocolo y com tal gestiona el intercambio de mensajes en base a un estándard desarrollado con el fin de comunicar dos dispositivos. No haremos “nada” sólo con Bluetooth, en todo caso sobre Bluetooth y lo haremos a través de los perfiles los cuales definen el comportamiento de los dispositivos y la comunicación. No es lo mismo que una aplicación haga uso de Bluetooth para la gestión de un manos libres que para el intercambio de archivos entre un dispositivo Windows Mobile y Windows Vista, por ejemplo. Los perfiles definen el cómo se lleva a cabo la comunicación. La comunicación con un manos libres utiliza un perfil (HFP), y el intercambio de objectos (archivos, contactos y demás) utiliza otro (OBEX).especificacion

SEGUNDO: En cuanto a la conexión entre dispositivos recordad que el proceso que normalmente realizamos para el emparejamiento manual se debe hacer programaticamente, con todo lo que ello conlleva. Para conectarnos a un dispositivos necesitamos saber la dirección del dispositivo y el Guid del servicio al que queremos conectarnos. El proceso de emparejamiento podría ser algo así:

   1: public class BTHDispositivo
   2: {
   3:     [DllImport("Btdrt.dll", SetLastError = true)]
   4:     private static extern int BthCreateACLConnection(byte[]
   5:     remoteBthAdd,
   6:     ref ushort phandle);
   7:  
   8:     [DllImport("Btdrt.dll", SetLastError = true)]
   9:     private static extern int BthCloseConnection(ushort phandle);
  10:  
  11:     [DllImport("Btdrt.dll", SetLastError = true)]
  12:     private static extern int BthAuthenticate(byte[] remoteBthAdd);
  13:  
  14:     [DllImport("btdrt.dll", SetLastError = true)]
  15:     private static extern int BthSetPIN(byte[] localBthAdd,
  16:     int pinLength, byte[] ppin);
  17:  
  18:     public string _nombre;
  19:     public byte[] _direccion;
  20:  
  21:     //pin.Length => 0 y pin.Length <= 16
  22:     public void EstablecerPIN(string pin)
  23:     {
  24:         byte[] pinbytes = System.Text.Encoding.ASCII.GetBytes(pin);
  25:         int len = pin.Length;
  26:         BthSetPIN(_direccion, len, pinbytes);
  27:     }
  28:     public bool QuitarPin()
  29:     {
  30:         BthRevokePIN(_direccion);
  31:     }
  32:  
  33:     public void Emparejar(string pin)
  34:     {
  35:         ushort handle = 0;
  36:         //conectamos
  37:         BthCreateACLConnection(_direccion, ref handle);
  38:         //autenticamos
  39:         BthAuthenticate(_direccion);
  40:         //desconectamos
  41:         BthCloseConnection(handle);
  42:     }
  43: }

Una vez emparejado toca conectar mediante un servicio común entre ellos cuya conexión se puede realizar mediante Sockets a través de un EndPoint que exponga el servicio o perfil a utilizar (SOCKADDR_BTH) tal y como muestra el siguiente enlace. En modo de ejemplo a continuación se muestra el método de conexión de la libreria de desarrolloMobile.NET para WinXP.

   1: public void Conectar(Servicios.BthServicio servicio)
   2: {
   3:     clienteSck  = new BthSocket();
   4:     
   5:     BthEndPoint endPoint = new BthEndPoint(this, servicio);
   6:  
   7:     try
   8:     {
   9:         clienteSck.Connect(endPoint);
  10:     }
  11:     catch (SocketException se)
  12:     {
  13:         throw;
  14:     }
  15:     catch (Exception ex)
  16:     {
  17:         throw;
  18:     }
  19: }

¿Ahora bien, cómo averiguamos la dirección y el Guid del Servicio?

En cuanto a los servicios o perfiles, todos y cada uno tienen un Guid asociado que es universal (estandarizado). En sitio oficial de Bluetooth podeis encontrar una lista completa (NOTA: Debéis registraros).

En cuanto a la dirección del dispositivo a conectar hay que saber lo siguiente. Hablando desde el punto de vista programático las únicas formas de conocer la dirección destino es a través del descubrimiento de dispositivos cercanos o consultando los dispositivos ya emparejados (previo descubrimiento). Es aqui, en este punto, dónde la mayoria de desarrollos quedan atascados, puesto que el código de desubrimiento es complejo y se lleva a cabo a través de las clases WSALookUpServiceBegin, WSALookUpServiceNext y WSALookUpServiceEnd y cuya forma de proceder la podéis encontrar aquí. Siempre podemos conocer la dirección del dispositivo emparejandolo manualmente y por norma general, MS Bluetooth Stack almacena la dirección de todos los dispositivos previamente emparejados en el registro.

Microsoft tiene un ejemplo de uso para Bluetooth que podéis encontrar aquí. En este ejemplo, además, podéis ver el método de descubrimiento de servicios dado un dispositivo. Además muestra en la clave dónde se almacenan los dispositivos emparejados o de confianza.

Debug

Otros de los quebraderos de cabeza fue el Debug del proyecto. Si éste se realiza sobre una aplicación Windows Desktop no hay nada que decir pero si se realiza sobre Windows Mobile, entonces el emulador de poco me servía. Debía emparejar un dispositivo físico, realizar el despliegue sobre él a través de ActiveSync y depurar la aplicación sobre la misma.

Sin embargo, hace poco me topé con un artículo de codeproject que permitia emular la radio Bluetooth sobre un emulador Windows Mobile. El autor es

Dmitry Klionsky, y el enlace lo podéis encontrar aquí

Recomendaciones

  • Utiliza, en la medida de lo posible, componentes de gestión de pilas Bluetooth de terceros. No voy a decir ningún proveedor puesto que no he utilizado ninguno en especial. Pero el desarrollo de una libreria o componente propio debería ser la última alternativa.
  • Conoce la pila de tu dispositivo Bluetooth(http://en.wikipedia.org/wiki/Bluetooth_stack). Las mas comunes son Microsoft Bluetooth Stack y Widcomm y la mayoria de componentes de terceros ofrecen servicios para como mínimo ambas pilas. Recuerda que una libreria para Bluetooth desarrollada para Microsoft Bluetooth stack NO es compatible con Widcomm y viceversa. De hecho las librerias que encontrarás en desarrolloMobile.NET no son válidas para dispositivos Widcomm y demás. Encontraras un enlace con el tipo de pilas utilizas por dispositivos (modelo/marca) aqui.
  • Si te apatece profundizar sobre el tema, en desarrolloMobile.NET (sección Bluetooth) encontrarás más recursos. Otros de los sitios que no puedes dejar de visitar es el proyecto 32feet.net.

DotNetNuke con Vicenç Masanas

IMAGE_024Esta misma tarde hemos tenido la reunión mensual con el grupo de usuarios de la Cataluña Central (CatDotNet) y hemos tenido el placer de contar con Vicenç Masanas (Disgrafic), MVP en ASP.NET y miembro del Core Team de DotNetNuke, quién nos ha estado hablando tanto de las novedades y roadmap de DotNetNuke como de la forma de desarrolloar módulos y de la propia plaforma de desarrollo.

Esta comunidad OpenSource sobre ASP.NET, está dando pasos cualitativos tras cada versión, la última versión, la 5, que se prevee aparezca en el Q2 de este mismo año. Como novedades, aqui podéis encontrar una lista. Nos ha estado explicando, además, las diferencias IMAGE_023y enfoques entre la edición Professional y la Community, y el papel de la recién creada DotNetNuke Corporation.

Me ha encantado la riqueza del marco de desarrollo de DotNetNuke, -cuyo código puede ser descargado por todo el mundo- y lo que aún no acabo de ver es que pese a que este dentro de un entorno OpenSource siga siendo fiel únicamente a SQL Server –y no es que tenga nada en contra de SQL Server, al contrario- y no haya posibilidad de alternativas, aunque, esto podría cambiar en medio plazo.

En fín, de las dos horas inciales se han convertido en casi 3 horas de cháchara y esperamos volver a contar de nuevo con él. Ahora toca esperar a la aparición de la versión 5 (+/- junio) y actualizar desarrolloMobile.NET!!!

Widgets en Windows Mobile 6.5

En el pasado TechEd que tuvo lugar en Barcelona, en noviembre del año pasado, tuve la oportunidad de asistir a la sesión/presentación del Internet Explorer Mobile 6.0. En dicha presentación Anil Dhawan y Mike O’Malley, ambos Product Manager de Microsoft Corp, fueron los maestros de ceremonia.

Una de las novedades que presentó Anil fue la posibilidad de desarrollo de Widgets sobre plataforma Windows Mobile y ya que éstos se sustentan sobre IE Mobile 6 y por aquél entonces empezaban a sonar campanas sobre WiMoble 6.5 todo parecía indicar que los Widgets serían una realidad con la aparición de ésta última versión.

Durante mi estancia en el pasado MVP Summit 2009, tuve el placer de conocer a otro integrante del equipo de desarrollo junto a Anil y Mike, se trata de Jorge Peraza, natural de Guadalajara – México-, con el que pude conversar durante unos pocos minutos. Pues bien, Jorge acaba de publicar un interesantísimo post acerca de las novedades para desarroladores de WinMobile 6.5 haciendo especial hincapié en el desarrollo de Widgets.

Aquí os dejo el enlace,,,

http://blogs.msdn.com/windowsmobile/archive/2009/03/18/windows-mobile-6-5-what-s-in-for-developers.aspx

OT: La historia de Visual Basic Paradise

Llevaba tiempo con este post escrito en mi cabeza. Borrador almacenado en mi memoria perenne, cuál siempre permanecerá, por desgracia, en ese recóndito escondite de mis recuerdos.

Empecé en esto de la informática en 1996, con Borland C++ 3.51, en sistemas UNIX, en los Ciclos Formativos de Grado superior, después de que la selectividad y la pereza adolescente, me invitaran a postergar la carrera universitaria para más adelante. Digo esto puesto que tras empezar a trabajar, dos años después, me presentaron un amigo el cual me acompañaría durante la mayor parte de mi carrera profesional, se llama Visual Basic (entonces en la versión 4), y ciertamente, no conseguí entablar una amistad sincera – de transigencia mutua- durante todo ese tiempo, más fue la única hasta la aparición de .NET.

Debido a mi bagaje en C++ la adaptación a mi nuevo entorno de desarrollo hizo que fuera un asiduo preguntón en los grupos de noticias de Visual Basic y MS Access (entonces en la versión 97) y cazador de soluciones en páginas Web tales como la todopoderosa Web del amigo El Guille, entonces hospedado en CostaSol, así como La Web del programador, PortalVB –de por el todos conocido Jorge Serrano o Canal Visual Basic y de otras desaparecidas como Skull VB.

De la misma forma que hacinaba los grupos de noticias con preguntas, trataba de contestar las que advertían respuesta, con el permiso de los duchos de aquellos lares; no era cuestión de reconocimiento, más bien de compartir. De “el hoy por mí mañana por ti”. Del espíritu de comunidad. Incluso abordé mi propio espacio web, el cual hospedé en Geocities, con el nombre de Links VB bajo el pretexto de aglutinar todos los enlaces y recursos que utilizaba normalmente. Pasó con más pena que gloria. No me arrepiento. VB Paradise fue el espejo dónde trató de reflejarse. VB Paradise era un lugar dónde buscabas y encontrabas, husmeabas e instruías. Pero el tiempo se olvidó de él y a fecha de hoy, aún existe como reloj de pared con segunderos detenidos a falta de cuerda. Aún latente.

VBParadiseVB Paradise empezó su andadura por el año 1999, y lo que empezó siendo la típica página Web personal del autor, enseguida se contagió del espíritu de comunidad, añadiendo fragmentos de código para soluciones específicas, respuestas a preguntas frecuentes, enlaces a otros recursos de la red y además, ofrecía un espacio de humor, rasgo característico del autor.

VB Paradise se congeló en febrero del 2001. En su página inicial una etiqueta delata la última actualización. Aún hoy, con información referente a 8 años sigue teniendo unas visitas diarias casi constantes de unas 60-70 páginas vistas. Más de 60-70 páginas vistas diariamente sobre una Web con información de más de 8 años; si he repetido dos veces lo mismo, pues el dato, es relevante, y es que cuando creas cualquier sitio Web cuyo recuento diario de páginas vistas alcanza las casi 1400, en el año 2000, insisto, adviertes estar delante de un espacio virtual cuyo autor ha sabido mecanizar de modo que actúa, aún sin quererlo ser, como un punto lógico de conocimiento en el universo de Internet.

Mi contacto con el autor empezó a través de un simple enlace de su portal, el cual se insinúa en la página principal de bienvenida -parte superior derecha-, dónde se aprecia un texto que invita conocer la ciudad natal del autor, Igualada. Es tal etiqueta HTML el, bienaventurado, pretexto por el cual lanzo mis primeros elogios al autor, a mediados del 2000. Y es que saber que vivía a escasas manzanas de dónde lo hacía yo, era demasiado tentador para un recién confeso fascinado por la informática.

Qué decir del autor. Un tecnócrata echando mano del vocabulario clásico o un Geek haciendo lo mismo del moderno. Un profesional de la vieja escuela que vivía por y para la tecnología. Programación. Internet. Hardware. Equipos de Radiofrecuencia. Su nombre: Josep Fusté.

Y es que conocerlo a él, era dar cara a su portal. Entablar una conversación sobre aspectos técnicos me permitía estar en los ápices del conocimiento que aporta la experiencia y que no muestran los libros. Ideas, colaboraciones, trapicheos de trucos, surgieron instantáneos y firmes, pero jamás llegamos a ponerlos en práctica. El destino le jugó una mala pasada y en febrero del 2001, ahora hace 8 años, Josep nos dejó para siempre en un trágico accidente aéreo, otra de sus pasiones.

Me gustaría imaginar lo que seria VB Paradise en la era .NET. Estoy convencido que Josep seria un MVP más. Sin duda, compartiría opiniones, bocadillo y cerveza, entre carcajadas, con nosotros en CatDotNet, mientras ponemos orden a la actualidad informática  en nuestras tertulias mensuales. Desgraciadamente, eso no va a poder ser.

Actualmente, la Jove Cambra d’Igualada otorga unos premios en su memoria a la colaboración con proyectos para el tercer mundo bajo el nombre de Un món d’oportunitats.

Webcast sobre File Sync Provider

MSF Se ha publicado un nuevo Webcast de poco más de un 1 hora de duración, en el que Ashish Shah, Principal Development Lead del equipo de desarrolo de Sync Framework, habla sobre los diferentes escenarios soportados este built-in provider de Microsoft Sync Framework.

Los escenarios tratados son:

  • Sincronización de archivos multi-master entre PC de una red.
  • Sincronización de archivos entre PC fuera de una red corporativa a través de USB.
  • Mantenimiento de las copias de seguridad de archivos.

Y además sobre los aspectos más destacados sobre este proveedor en cuanto a requisitos y características del mismo…

 

Salud!!