I Remote

Otro blog sobre C#

sábado 8 de enero de 2011

Mudanza

Me he mudado a WordPress a la dirección http://jmservera.wordpress.com así que no seguiré escribiendo en este. He copiado allí todos mis artículos y en unos meses daré de baja I Remote para siempre.

Seguiré hablando de temas de programación en el mundo del .Net Framework, ahora enfocado más a Surface, WP7 y Azure.

Nos leemos en WordPress.com!

lunes 11 de octubre de 2010

StackOverflow, ¿para cuándo uno en castellano?

StackOverflow.com es una web colaborativa de preguntas y respuestas sobre programación. Creada por el equipo de Joel Spolsky, empezó como un experimento y hoy en día ya se ha convertido en un punto de referencia para desarrolladores de todo el mundo.

Hace unos meses crearon un sitio (area51) donde proponer nuevas aplicaciones para el motor Stack Exchange, el usado en StackOverflow.

Crear un sitio es gratuito y el único requisito es que haya una comunidad lo suficientemente grande y activa. Hay ya más de 1000 propuestas, de las más variopintas, entre ellas una propuesta de crear un foro de programación en castellano, pero aún está en fase de definición.


Si aún no conocéis StackOverflow.com os animo a visitar el sitio y participar.
Para más referencias podéis ver el vídeo (en inglés) de Scott Hanselman en el que habla sobre StackOverflow y otras cosas interesantes.

martes 27 de abril de 2010

Código fuente de la OData Client Library

Para ayudar a la comunidad a crear sus propias librerías cliente de OData, el equipo de Project Astoria ha publicado sus librerías de cliente .Net y Silverlight en codeplex bajo licencia Apache 2.0.


viernes 23 de abril de 2010

Enterprise Library 5.0 publicada

Microsoft patterns & practices ha publicado la nueva Enterprise Library 5.0, una colección de módulos que se pueden usar a modo de bloques prefabricados y configurables para construir grandes aplicaciones.

Como desde su primera versión, incluyen el código fuente como ejemplo de buenas prácticas y también para posibilitar modificaciones que no sean posibles a través de su extenso sistema de configuración.
Al ser un sistema modular no hace falta distribuir toda la librería entera con nuestra aplicación, sino que usaremos sólo los bloques que nos convengan. Para los que aún no sepáis qué es, la colección entera incluye:
  • Caching Application Block: para almacenar datos temporalmente, tanto en memoria como en un almacen de datos intermedio.
  • Cryptography Application Block: para incorporar fácilmente hashing y encriptación simétrica a nuestras aplicaciones.
  • Data Access Application Block: simplifica el acceso a datos, normalmente basado en ADO.Net y DataSets, independizando la capa de acceso a datos del motor.
  • Exception Handling Application Block: para definir estrategias comunes de manejo de excepciones y errores a todos los niveles de las capas de la aplicación
  • Logging Application Block: los desarrolladores pueden incluir el registro de mensajes sobre un amplio abanico de fuentes de manera simple y sencilla.
  • Policy Injection Application Block: usando los mecanismos de inyección de Unity se pueden implementar políticas de captura de mensajes para canalizar la implementación de partes comunes como el manejo de excepciones o el caching.
  • Security Application Block: para incorporar autorización y funcionalidades de caché de seguridad en las aplicaciones.
  • Unity Application Block: un contenedor de inyección de dependencias, para que podamos crear aplicaciones fácilmente extensibles
  • Validation Application Block: permite crear reglas de validación para objetos que puedan ser usadas en otras capas de la aplicación.

jueves 23 de julio de 2009

Wikipedia Explorer ahora sobre Azure


DotNet Solutions ha actualizado su Wikipedia Explorer que ahora utiliza la tecnología de Windows Azure para convertir la base de datos de la Wikipedia a formato XML/XAML y así acelerar la aplicación que antes convertía los datos al vuelo.

Wikipedia Explorer es una aplicación WPF que proporciona una nueva forma de navegar por la wikipedia, visualizando las relaciones entre documentos.

Gracias a la plataforma Windows Azure han podido reducir el tiempo de proceso para la conversión de la base de datos de 6 meses a 5 días.
La aplicación está disponible en modo ClickOnce aquí.

viernes 24 de abril de 2009

Las verdaderas razones detrás de un cambio

Hoy, leyendo una entrada de Jose Fco Bonnin, me han empezado a sonar las alarmas y he sentido la necesidad de investigar un poco.

El motivo de su post es que en el VS2008 se quitaron algunas reglas del FxCop, entre ellas la "CA1818 - Do not concatenate strings inside loops".
Tal como Jose ha comprobado, no ha habido ningún cambio en el framework para que esa regla se pueda quitar y el motivo que alega el equipo de Code Analysis es que la han quitado debido a "high noise or no longer applicable analysis".

Cualquier desarrollador de .Net que se haya preocupado un mínimo por el rendimiento una de las primeras cosas que suele mirar es si la aplicación está generando demasiados strings; así que debe haber alguna otra razón para quitar esa regla del motor.

Tras buscar un poco he encontrado unas entradas que nos dan alguna una pista: tanto en una conversación en el foro de fxcop beta como en una nota de su blog comentan que el "data flow analysis engine", el encargado de comprobar esa regla, ha sido eliminado porque no funcionaba bien, era muy lento y además indeterminista.
Es una opinión/deducción personal, pero creo que nos han contado una verdad a medias y el impacto de haber quitado esa regla puede ser verdaderamente alto en aplicaciones grandes.

Teóricamente Phoenix iba a arreglar el desaguisado pero no parece que tenga continuidad, así que habrá que ver si en vs2010, que vuelve a tener un data flow engine, las reglas se han vuelto a activar. ¿Alguien lo ha probado ya?

lunes 23 de febrero de 2009

Serialización dinámica con el XmlSerializer

Para acabar con esta espontanea serie de posts sobre el XmlSerializer os cuento un par de trucos no demasiado bien documentados para controlar la serialización.

En algunas ocasiones podemos necesitar que una clase hija no persista algunas de las propiedades del base, pero, como ya hemos visto antes, si la propiedad no es virtual se complica un poco el asunto. En estos casos podemos añadir un miembro público a la clase base con el mismo nombre de la propiedad + Specified con el valor a true:

public class C1
{
	public string MyProperty { get; set; }
	[XmlIgnore]
	public bool MyPropertySpecified = true;
}


De esta manera al heredar de la clase podremos especificar su valor a false, lo que hará que no se persista dicha propiedad:



public class C2:C1
{
	public string MyOtherProperty { get; set; }
	public C2()
	{
		MyPropertySpecified = false;
	}
}


En otras ocasiones, lo que querremos es decidir cuando se debe persistir el valor y cuando no. Por ejemplo, si una lista no tiene valores o si un string es null puede que no nos interese que aparezca el valor vacío en el xml. Eso se consigue con un método público llamado ShouldSerialize + el nombre de la propiedad y que devuelva un bool indicando si la propiedad debe persistirse:



public class C3 : C2
{
	public string MyThirdProperty { get; set; }
	public bool ShouldSerializeMyThirdProperty()
	{
		return false;
	}
}


Ahora podéis probar las clases, adivinad qué mostrará cada llamada:



XmlSerializer ser = new XmlSerializer(typeof(C1), 
	new Type[] { typeof(C2), typeof(C3) });
ser.Serialize(Console.Out, new C1() { MyProperty = "test"});
Console.WriteLine();
ser.Serialize(Console.Out, new C2() { MyProperty = "test", 
	MyOtherProperty = "test 2" });
Console.WriteLine();
ser.Serialize(Console.Out, new C3() { MyProperty = "test", 
	MyOtherProperty = "test 2", MyThirdProperty="test 3" });
Console.ReadLine();

viernes 20 de febrero de 2009

XmlSerializer y ocultación de propiedades

Esta mañana tras responder a un post de Eduard Tomàs i Avellana me ha dado por investigar un poco más sobre el tema...

En su caso el problema tenía solución pues podía modificar ambas clases, pero ¿qué pasaría si estamos heredando de una clase que no podemos modificar? Hay múltiples soluciones, desde el uso de un patrón Adapter hasta la implementación del interface IXmlSerializable, pero todas ellas requieren escribir una cantidad considerable de código.
Pero... en algunos casos nos podría servir una sobrecarga del XmlSerializer que admite como argumento una instancia del XmlAttributeOverrides, que, como su propio nombre indica, nos permite sobrecargar los atributos que usa el XmlSerializer sobre una clase para generar el código de serialización. Aunque tiene sus peligros podremos influir en cómo se serializa la clase base sin tener que modificarla.
Por ejemplo, si tuviéramos la siguiente definición de clases:

public class C1
{
 List<C1> _myList = new List<C1>();
 public List<C1> MyList { get { return _myList; } }
}

public class C2:C1
{
 List<C2> _myList = new List<C2>();
 public new List<C2> MyList { get { return _myList; } }
}

Al crear el XmlSerializer nos daría un error de reflexión como pasaba en el caso de Eduard. Pero podemos obligar al serializador que ignore la propiedad de la clase base mediante el siguiente código:


XmlAttributeOverrides xOver = new XmlAttributeOverrides();
XmlAttributes atts = new XmlAttributes(){ XmlIgnore=true};
xOver.Add(typeof(C1), "MyList", atts);
XmlSerializer ser = new XmlSerializer(typeof(C2),xOver);
ser.Serialize(Console.Out, new C2());

Aunque hay que usarlo con extremo cuidado, pues cualquier otra instancia del tipo C1 o derivados no serializará la propiedad MyList con ese serializador.

¿Alguien más se anima a encontrar otra solución?