Relativamente Simple

Tipos anónimos, Expresiones Linq y APIs fluidas

2009-07-08T17:46:00.004-04:00

Hace ya una semana a través de twitter me llegó me llego un post (Using C# 3.0 Anonymous Types as Dictionaries) que presentaba una propuesta para usar tipos anónimos como diccionarios. Para seguir les recomiendo ver el post pues asumo que se conoce el contexto del problema

El post genero muchas reacciones y comentarios, que pueden verse en el mismo post, personalmente me gustó mucho como se ve el código y me hizo recuerdo a las notaciones JSON, o bien a como se harían estas cosas en lenguajes dinámicos, pero como dije en twitter pero siempre está la duda ¿rendimiento?

Luego en la semana me puse a pensar de nuevo en esto y se me ocurrió que este caso en particular .net 3.5 tenía otra caracteristica que podía ser de ayuda Expresiones Linq (para referencia Árboles de expresiones). Las expresiones no solo nos permiten navegar en declaraciones para distintos fines sino que además nos permiten crear y compilar funciones Lambda. Esto me parecía interesante porque dado un tipo cualquiera esposible crear una función Lambda que la procesara y generará la cadena de atributos completa.

Sin embargo, por ahora lambda expressiones siempre terminan en una sola expresión y no es posible construir todo un método de esta manera. Y es aqui donde las APIs fluidas (también conocidas como interfaces fluidas, Fluent API, Fluent Interfaces) entran en juego, Las APIs Fluidas brindan, a través de patrones como encadenamiento de métodos, la posibilidad de escribir código de manera consecuente y asegurando que el contexto en la ejecución se mantenga. Por ejemplo todos los métodos Append de la clase StringBuilder, retornan el objeto StringBuilder lo que permite escribir código de este tipo:

StringBuilder sb= new StringBuilder;
sb.Append("Hola").Append(" ").Append("mundo");

Dado que en este caso el principal objetivo es generar una cadena con un StringBuilder, la interfaz Fluida es de mucha utilidad pues se puede generar una sola expresión que agregue todos los atributos al elemento. Esto podía tener un impacto positivo en el rendimiento (mi preocupación del momento).

Así que decidí hacer un ejercicio. Tomé el código de Eilon e hice dos nuevas implementaciones de GetHtmlLink.

GetHtmlLinkDictionary: Que recibe un diccionario y que utiliza inicializadores para el paso de parámeros

GetHtmlLinkLambda: Esta es la que implementa la idea que tenía en la cabeza. Esta función recibe una clase cualquier y para cada propiedad pública de la clase genera un atributo en el vínculo html que genera.

Para ello primero es necesario obtener la información de las propiedades de la clase, luego generar la expresión que agrega los atributos y finalmente compilarla. Como la idea de esta prueba es que la expresión compilada sea utilizada en distintas llamadas cree un diccionario simple para que actue como repositorio de las funciones precompiladas. Con esto en mente el flujo básico de la función es el siguiente:

Y la implementación base es la siguiente.

static IDictionary<Type, Action<StringBuilder, object>> functionCache = new Dictionary<Type, Action<StringBuilder, object>>();
public static string GetHtmlLinkLamba(string text, object properties)
{
StringBuilder sb = new StringBuilder();
sb.Append("<a");
if (!functionCache.ContainsKey(properties.GetType()))
{
 functionCache.Add(properties.GetType(), BuildFunction(properties))
}
functionCache[properties.GetType()](sb, properties);
sb.Append(">");
sb.Append(text);
sb.Append("</a>");
return sb.ToString();
}

Como notarán el delegado que se genera recibe dos parámetros la clase StringBuilder y el objeto que se utilizará. Un aspecto que no pude optimizar es el paso del objeto de manera no tipada esto debido a que para poder invocar las funciones precompiladas es necesario conocer la firma del delegado con anticipación y eso incluye el tipo del parámetro (este es un tema pendiente a resolver).

Obviamente la parte jugosa está en la función BuildFunction. Lo primero, en mi caso, fue ordenar las ideas de la construcción de la expresión. Mi primer enfoque fue construir una expresión que hiciera lo mismo que la función que carga la información del diccionario y dado que el número de propiedades es variable necesito que mi expresión vaya agrengadose. Es decir que si hay solo la propiedad class la expresión generada sea la siguiente:

sb.Append(" ").Append(“class”).Append("=\"").Append(obj.class).Append("\"")

Y si hay una propiedad adicional target la expresión pase a ser:

sb.Append(" ").Append(“class”).Append("=\"").Append(obj.class).Append("\" ").Append(“target”).Append("=\"").Append(obj.target).Append("\"")

Esta alternativa la llegué a implementar, pero luego me di cuenta, lento que fuí, que al conocer toda la infomración de la clase de antemano podía generar una expresión mucho más óptima.

sb.Append(" class =\"").Append(obj.class).Append("\"  target=\"").Append(obj.target).Append("\"")

Esta "realización" simplifico mucho mi código y ese es el que presento. Lo primero que tuve que crear fueron expresiones que representen lo parámetros que la función recibiría, para ello cree expresiones del tipo ParameterExpression:

var paramSb = ParameterExpression.Parameter(typeof(StringBuilder), "sb");
           var paramObj = ParameterExpression.Parameter(typeof(object), "obj");

Luego tuve que crear el primer elemento de mi expresión que es simplemente la referencia al objeto StringBuilder.

Expression body = paramSb;

Claramente si quería acceder a las propiedades del objeto era necesario que hiciera un cast al tipo particular del objeto, para esto cree una expresión UnaryExpression utilizando el método Convert

var convert = Expression.Convert(paramObj, anonymousType);

Con estos elementos dispuestos podía empezar a iterar a través de las propiedades de la clase. Para ello tuve que recurrir a Reflection (gulp!) y en este punto me di cuenta que para poder crear la expresión de invocación también necesitaba la información de los métodos a los que deseaba invocar. Así que estas lineas son Reflection y nada más.

MethodInfo appendString = typeof(StringBuilder).GetMethod("Append", new Type[] { typeof(string) });
           MethodInfo appendObject = typeof(StringBuilder).GetMethod("Append", new Type[] { typeof(object) });
           PropertyInfo[] props = anonymousType.GetProperties(BindingFlags.Instance | BindingFlags.Public | BindingFlags.GetProperty);

Con todo listo armé el bloque que recorre todas las propiedades y va generando la expresión

bool first = true;           
           foreach (PropertyInfo prop in props)
           {
               body =
                   Expression.Call(
                       Expression.Call(
                           body,
                           appendString,       
                           Expression.Constant((first ? " ":"\" ") + prop.Name + "=\"")),
                       appendObject,
                       Expression.Property(convert, prop));
               first=false;
           }

Paso a explicar el bloque, lo primero que hage es crear una llamada al método Append de la última expresión (que siempre es un StringBuilder gracias a la interfaz fluida) y paso como parámetro el nombre de la propiedad seguida del igual y apertura de comillas (Hay una diferenciación para la primera ejecución que solo genera el nombre). Esta acción corresponde a la expresión anidada.

Expression.Call(
                           body,
                           appendString,       
                           Expression.Constant((first ? " ":"\" ") + prop.Name + "=\""))

Luego agrego una llamada al método Append de la clase StringBuilder, pero esta vez a la implementación que recibe un objeto como parámetro, pasando como parámetro el objeto ya tipado por la conversión
(potencialmente podría optimizarse esta generación para diferenciar las propiedades que son cadena o no)

Expression.Call(
                       /*...*/,
                       appendObject,
                       Expression.Property(convert, prop))

La expresión resultante es asignada para que se la base de la próxima itearción. Una vez que se hayan procesado todas las propiedades solo queda agregar el cierre de comillas (si es que se proceso al menos un atributo)

 if (!first)
           {
               body = Expression.Call(
                           body,
                           appendString,
                           Expression.Constant("\""));
           }

Y el toque final la compilación, en este caso estoy especificando el formato del delegado a generar para que pueda incluirlo en el diccionario de funciones

return Expression.Lambda<Action<StringBuilder, object>>(body, paramSb, paramObj).Compile()

Listo, ya tenemos una función que procesa el objeto de manera tipada. luego de organizar y para evitar creaciones innecesarias la estructura final de la función es la siguiente:

        static MethodInfo appendString = typeof(StringBuilder).GetMethod("Append", new Type[] { typeof(string) });
       static MethodInfo appendObject = typeof(StringBuilder).GetMethod("Append", new Type[] { typeof(object) });

       private static Action<StringBuilder, object> BuildFunction(object properties)
       {
           Type anonymousType = properties.GetType();
           var paramSb = ParameterExpression.Parameter(typeof(StringBuilder), "sb");
           var paramObj = ParameterExpression.Parameter(typeof(object), "obj");
           var convert = Expression.Convert(paramObj, anonymousType);
           Expression body = paramSb;
           PropertyInfo[] props = anonymousType.GetProperties(BindingFlags.Instance | BindingFlags.Public | BindingFlags.GetProperty);
           bool first = true;           
           foreach (PropertyInfo prop in props)
           {
               body =
                   Expression.Call(
                       Expression.Call(
                           body,
                           appendString,       
                           Expression.Constant((first ? " ":"\" ") + prop.Name + "=\"")),
                       appendObject,
                       Expression.Property(convert, prop));
               first=false;
           }
           if (!first)
           {
               body = Expression.Call(
                           body,
                           appendString,
                           Expression.Constant("\""));
           }
           return Expression.Lambda<Action<StringBuilder, object>>(body, paramSb, paramObj).Compile();
       }

Hecha la implementación llegó el momento de medirla. Lo que hice fue medir el tiempo de la primera ejecución y el promedio de subsecuentes ejecuciones para cada implementación. La razón para medir de esta forma es que el ejemplo esta orientado a una página Web donde cada ejecución no iniciaría de nuevo la función y solo el primer acceso sería penalizado por la compilación (similar a lo que hace ASP.Net para sitios que no están precompilados).

Las llamadas ejecutadas son las siguientes

HtmlHelpers.GetHtmlLink("Ejemplo", new { @class = "style" , target ="top" });
HtmlHelpers.GetHtmlLinkDictionary("Ejemplo", new Dictionary {{"class", "style"}, {"target", "top"}});
HtmlHelpers.GetHtmlLinkLamba("Ejemplo", new { @class = "style" , target ="top" }));

He aqui los resultados.

Función	Primera Ejecución	Promedio Ejecuciones Posteriores
GetHtmlLink	15195	2
GetHtmlLinkDictionary	7561	36
GetHtmlLinkLambda	12032	2

Como era de esperarse la implementación inicial es la que menor rendimiento tiene en todos los casos así que no la revisaré. Lo que quiero rescatar es que si bien la primera ejecución del método que recibe el diccionario es más rápida (estos son ticks lo que significa que es medio segundo más rápida) posteriores ejecuciones son mucho más rápidas pues la expresión compilada no necesita hacer ningún tipo de recorrido o búsqueda.

Con esos resultado, y para un sitio web o servicio donde el proceso se mantiene en memoria para atender múltiples requerimientos, me quedaría con la opción de precompilar y generar un código más agradable a la vista

Primer día en Windows 7

2009-05-10T12:52:00.001-04:00

Bueno, finalmente instale Windows 7, lo único que puedo decir es que es altamente recomendable. A continuación hago un resumen de mi experiencia (todo esto lo hice en mi portatil Lenovo ThinkPad X61 2GB RAM)

Preparación

Antes de iniciar obviamente obtuve un backup pero a falta de uno hice tres: solo archivos, imagen de disco, windows easy transfer. El último lo hice para ver si me aceleraba el proceso de resintalación.

Instalación base

Basado en esperiencias anteriores habia destinado un par de horas para realizar la instalación básica, mi sorpresa fue enorme cuando 18 minutos después de prender la máquina para instalar Windows 7 estaba listo para instalar otras aplicaciones.

Lo primero que hice fue agregar todos los componentes que no se instalan por defecto (IIS, MSMQ, etc) y nuevamente me sorprendi pues la activación tomo 2 minutos.

Instalación Aplicativos

Lo siguiente a instalar es Office 2007 que igualmente esperaba tomará unos cuantos minutos por lo que inicie la instalación y me fui a hacer otras cosas, 8 minutos después volvi a buscar algo y vi que la instalación estaba completa.

Emocionado por el éxito decidí reinstalar todo pero tenía cosas para hacer (la vida normal que se interpone) así que durante la tarde finalmente pude sentarme a continuar con la instalación.

En general el proceso de instalación consistía en revisar la última versión de la aplicación, descarga (si es necesario), instalación. Para darles una idea de lo que esto significa listo las aplicaciones instaladas

Office

Office 2007 SP 2
Project 2007
Visio 2007
SharePoint Designar 2007
Forefront Client Security
Office Live Meeting
Office Communicator 2007 R2

Utilitarios

Desarrollo

Esto tomo unas 6 horas lo que me hace pensar que la instalación es mucho más rápida pues recuerdo que en otras ocasiones me tomaba mucho más llegar a tener todo instalado.

transferencia de preferencias

Lo primero que intente fue utilizar la imagen de Windows Easy Transfer que habia generado. Windows 7 la proceso en un tiempo que encuentro es un poco excesivo (50 minutos para 17 GB de datos) pero al ser un proceso de una única vez deje que se completará.

Al finalizar la recuperación pude observar, con alegria, que todas mis datos, personalizaciones y configuraciones se recuperaron sin ningún problema con lo que luego de 8 horas tenía todo mi entorno listo en Windows 7.

Adicionales

Una vez que termine la instalación note que había un par de cosas que extrañaba:

Utilitarios ThinkPad. Principalmente Access Connections, Presentation Director y Power Manager.

Access Connections es un utilitario de Lenovo que permite definir configuraciones de redes (IP, Proxy, impresora, seguridad, etc.) y asociarlo con puertos, MACs para facilitar el cambio de configuración. En el último año ha sido de mucha utilidad. En fin pude instalarlo y funciona, el icono de acceso rápido no se inicia, pero eso no es muy preocupante pues no lo uso habitualmente.
Power Manager: Las capacidades de optimización que brinda power manager me han ayudad mucho. Lo bunoe instalado y funcionando :)
Presentation Director: La combinación Windows+P en Windows 7 lo elimina de mi lista :)

Windows Virtual PC: windows 7 utilizará la nueva versión de Virtual PC por lo que fue necesario que descargue el beta y lo instale. Posteriormente pude abrir mis máquinas virtuales, tengo que decir que aun no estoy muy familiarizado con la nueva interfax y creo que me tomara un tiempo

Toque finales

Obviamente descargar todos mis correos con Outlook, y descargar actualizaciones necesarias. La verdad eso lo deje corriendo durante la noche por lo que no se cuanto tomó pero hoy ya tengo todo listo.

Primeras apreciaciones

Mis primeras apreciaciones son muy positivas.

El sistema tiene una respuesta mucho más adecuada en general
El proceso de reinicio es ligeramente más rápido pero el acceso al escritorio es mucho mas inmediato
El consumo de memoria es notoriamente menor, con Vista tenía deshabilitado Aero, transparencias, todos los gadgets y varios servicios de presentación y al momento de inicio de Windows (sin aplicaciones) no tenía más de 960 MB libres. En este momento estoy ejecutando outlook, IE, live writer, con todas las ventajas de UI y tengo 1015MB libres.
El trabajo del equipo de Windows en el stack de IU es sin duda muy notorio la interacción en general con Windows es mucho mejor

En resumen ha sido una experiencia muy gratificante. Desde hoy empiezo a recomendar la migración a todos :)

Alternativas de Bloqueo en .Net

2009-05-03T20:59:00.004-04:00

Recientemente pude continuar mi interrumpida lectura de Concurrent Programming on Windows y durante la misma se discuten los distintos tipos de Sincronización que se pueden usar con .Net. Como en casi toda lectura que he visto se menciona el costo adicional que puede incorporar el uso de las clases ReaderWriterLock, ReaderWriterLockSlim frente al uso de Monitor.Enter, Monitor.TryEnter (lock o syncLock), en el libro se hace un análisis del porque el impacto adicional en el rendimiento, pero como siempre me quedaban dudas respecto a cual es el verdadero margen de diferencia.

Existen varias comparaciones del impacto en rendimiento siendo casi siempre el comentario la gran diferencia que hay a favor de Monitor/lock frente a ReaderWriterLock , por ejemplo http://is.gd/wrDH, http://blogs.msdn.com/ricom/archive/2006/05/05/590955.aspx (comentarios, no el post en si mismo) sin embargo siempre he encontrado dichos números un poco vagos (espero no caer en el mismo error)

Usualmente toda tarea de sincronizacion siempre la hago con lock por ser la más fácil de implementar y porque nunca he tenido problemas de contención, sin embargo aprovechando que hoy en la tarde tenía tiempo decidí hacer una prueba muy simple para comparar las alternativas en distintos escenarios.

Componentes

Mi prueba es muy simple tengo 3 clases que exponen dos métodos uno de lectura (Shared Lock) y uno de escritura (Exclusive Lock). Ambos métodos sincronizan el acceso a través de cada uno de los mecanismos a considerar en la prueba, la clase TraditionalLock<T> utiliza el tradicional lock sobre una clase creada en el constructor de la clase, la clase ReaderWriteLock<T> utiliza una instancia de la clase del mismo nombre y finalmente ReaderWriteLockSlim<T> utiliza la clase del framework 3.5.

1:

   2:     class TraditionalLock<T> : ILockTest<T>

   3:     {

   4:         private T data;

   5:         private object sync = new object();

6:

   7:         public T  Read()

   8:         {

   9:             lock (sync)

  10:             {

  11:                 // Thread.Sleep(50);

  12:                 return this.data;

  13:             }

  14:         }

15:

  16:         public void  Write(T value)

  17:         {

  18:             lock (sync)

  19:             {

  20:                 // Thread.Sleep(50);

  21:                 this.data = value;

  22:             }

  23:         }

  24:     }

25:

  26:     class ReaderWriteLock<T> : ILockTest<T>

  27:     {

  28:         private T data;

  29:         private ReaderWriterLock sync = new ReaderWriterLock();

30:

  31:         public T Read()

  32:         {

  33:             sync.AcquireReaderLock(System.Threading.Timeout.Infinite);

  34:             try

  35:             {

  36:                 // Thread.Sleep(50);

  37:                 return this.data;

  38:             }

  39:             finally

  40:             {

  41:                 sync.ReleaseReaderLock();

  42:             }

  43:         }

44:

  45:         public void Write(T value)

  46:         {

  47:             sync.AcquireWriterLock(System.Threading.Timeout.Infinite);

  48:             try

  49:             {

  50:                 // Thread.Sleep(50);

  51:                 this.data = value;

  52:             }

  53:             finally

  54:             {

  55:                 sync.ReleaseWriterLock();

  56:             }

  57:         }

  58:     }

59:

  60:     class ReaderWriteLockSlim<T> : ILockTest<T>

  61:     {

  62:         private T data;

  63:         private ReaderWriterLockSlim sync = new ReaderWriterLockSlim();

64:

  65:         public T Read()

  66:         {

  67:             sync.EnterReadLock();

  68:             try

  69:             {

  70:                 // Thread.Sleep(50);

  71:                 return this.data;

  72:             }

  73:             finally

  74:             {

  75:                 sync.ExitReadLock();

  76:             }

  77:         }

78:

  79:         public void Write(T value)

  80:         {

  81:             sync.EnterWriteLock();

  82:             try

  83:             {

  84:                 // Thread.Sleep(50);

  85:                 this.data = value;

  86:             }

  87:             finally

  88:             {

  89:                 sync.ExitWriteLock();

  90:             }

  91:         }

  92:     }

93:

  94:     class VolatileLock : ILockTest<int>

  95:     {

  96:         private volatile int data;

97:

  98:         public int Read()

  99:         {

 100:             return this.data;

 101:         }

 102:

 103:         public void Write(int value)

 104:         {

 105:             this.data = value;

 106:         }

 107:     }

Todas estas clases son utilizadas por un controlador que utiliza el ThreadPool de .Net para solicitar la ejecucion de los métodos de escritura y lectura en una proporción de n:1 que varia desde 1:1 hasta 29:1 para estas pruebas. El tiempo total de la ejecución de todos los métodos es medido utilizando la clase StopWatch

   1: static long MeasureLockTest<T>(ILockTest<T> instance,T value, int totalExecutions, int ratio)

   2: {

   3:     Stopwatch sw = new Stopwatch();

   4:     int writerCounter = 0;

   5:     int readerCounter = 0;

6:

   7:     ratio++;

   8:     sw.Start();

   9:     for (int counter = 0; counter < totalExecutions; counter++)

  10:     {

  11:         if (counter % ratio == 0)

  12:         {

  13:             ThreadPool.QueueUserWorkItem((state) => instance.Write(value));

  14:             writerCounter++;

  15:         }

  16:         else

  17:         {

  18:             ThreadPool.QueueUserWorkItem((state) => instance.Read());

  19:             readerCounter++;

  20:         }

  21:     }

  22:     ThreadPool.QueueUserWorkItem((state) => sw.Stop());

  23:     while (sw.IsRunning) ;

24:

  25:     return sw.ElapsedMilliseconds;

  26: }

Escenarios

Claramente la prueba es muy simple pues mide actividad sobre operaciones muy simples. Sin embargo, si miran el código de todas las clases en ellas esta comentado código que hace Sleep, esta inserción es la poco imaginatica implementacion de cierto tipo de costo en uso de recursos en una operación (la elección de Sleep es intencional pues dada la carga de requerimientos en el thread obliga a evaluar la ejecución de otro thread lo que también puede jugar un factor en escenarios de concurrencia). Con esta simple linea me permitió crear cuatro escenarios de ejemplo:

Operaciones sin costo: Tipicamente son aquellas operaciones donde el bloqueo tiene por unico sentido la sincronización y brindar propiedades thread-safe. En este caso, uno de los más comunes, la operación es muy corta y con muy poco impacto. Por ello para obtener un grado de medida adecuado esta operación tuvo que realizarse 100000 veces.
Operaciones con costo en acceso exclusivo: En este escenario la operación que requiere el bloqueo exclusivo (tipicamente la escritura) tiene un costo alto en tiempo (50 milisegundos), mientras que la operación con bloqueo compartido es bastante simple y rápida. Un escenario típico de este tipo de bloqueo son los caches implementados en consultas a servicios o fuentes de datos remotas donde la búsqueda inicial tiene un costo alto pero subsecuentes accesos son de bajo costo.
Operaciones con costo en acceso compartido: En este escenario es la operación de acceso compartido la que tiene un costo alto mientras que la operación con costo exclusivo es de corta duración. Este tipo de escenario es un poco más dificil de darse y la verdad solo lo hice como un ejercicio.
Operaciones con costo: Finalmente en este escenario ambas operaciones tiene un costo alto que es igual para ambas operaciones. Ejemplos de este tipo de escenarios se refieren principalmente al acceso sincronizado a recursos externos.

Nota: En ninguno de los casos analice el uso de recursos de sistema que puede ser un factor en el cual Monitor/lock salen faavorecidos por no usar objetos de sincronización de Kernel

Resultados

A continuación se presenta los resultados de las pruebas en un grafico que muestra el tiempo promedio de las operaciones ejecutadas durante la prueba

Operaciones sin costo: 10000 iteraciones sin costo,

Como verán en este caso ReaderWriterLock es claramente un perdedor pero no en la proporción abismal que siempre leí.

Operaciones con costo en acceso exclusivo: 100 iteraciones con costo de 50 milisegundos

En este caso la diferencia entre todos los mecanismos es muy baja y en distintas ejecuciones demostró ser prácticamente nulo

Operaciones con costo en acceso compartidos: 100 iteraciones con costo de 50 milisegundos

En este escenario es muy claro que la ventaja la tienen los criterios de bloqueo compartido con una ventaja inicial a favor de la nueva clase del framework 3.5, Como dije anteriormente no se me ocurre un escenario común.

Operaciones con costo: 100 iteraciones con costo de 50 milisegundos

Al igual que en el caso anterior Monitor/lock son claros perdedores conforme mayor proporción de lecturas vs. escrituras existen. Es más en este caso la ventaja es muy notoria aún con una baja proporción de distribución (2:1).

Volatile

Al terminar la prueba se me ocurrió que para el primero de los escenarios (propiedades thread-safe) tambíen pueden utilizarse variables volatiles así que hice una prueba y aqui estan los resultados de 100000 ejecuciones (dado que volatile no es una sección protegida solo el primer escenario es aplicable)

Como muestra el gráfico sacrificar el uso del cache de thread tiene un impacto en rendimiento bastante importante por lo que a pesar de su facilidad de uso y menor uso de recursos esta opción no es válida si lo que se busca es el mejor rendimiento.

Conclusiones

Considerando solo los tiempos y sin incluir el uso de recursos (que como mencioné anteriormente brinda una ventaja a Monitor/lock) las siguientes conclusiones vienen a mi cabeza:

Para sincronización en acceso a propiedades y cache claramente no hay ganancia en rendimiento apreciable en ninguno de los casos por lo que considerando el uso de recursos y facilidad de uso y lectura Monitor/lock/SyncLock parece ser la mejor opcion.
En aquellos casos donde la sincronización se realiza sobre una sección que puede tener un costo medio o alto en tiempo es recomendable el uso de ReadWriterLockSym en Framework 3.5 o superior, o ReadWriterLock en versiones anteriores. En particular el acceso sincronizado a recursos de red puede ser un muy escenario de uso

Microsoft F# Developer Center

2008-08-30T09:24:00.003-04:00

Está disponible en MSDN un área dedicada a F# junto con el primer CTP de la integración en Visual Studio. Definitivamente algo para entretenerse

Microsoft F# Developer Center

Mi humilde opinión en F#

2008-06-22T12:15:00.001-04:00

El día de hoy después de un gran esfuerzo y de una parcial cambio en el modelo de programación terminé de leer Expert F#. Que puedo decir, este es uno de esos libros que me cambió la percepción de muchos aspectos del desarrollo de software.

Algunas opiniones en distintos aspectos

Escritura

La escritura es muy clara y a pesar de que hay temas muy complejos que son abordados de manera muy simple para este humilde mortal los ejemplos de código están muy bien elegidos para explicar el mensaje.

Es interesante que si bien no se trata de entrar en detalle en todos los aspectos clarifica muchas cosas de lenguajes funcionales, .Net framework, modelos de programación, parsers, etc.

Claramente este libro será mi libro de cabecera por un buen tiempo, aún si no estoy programando en F#

Programación

La cantidad de cosas que aprendí, recorde y corregí de mis idas es muy grande para enumerarla. Los conceptos, explocaciones y recomendaciones incluidas en el libro son generales y pueden ser aplicadas en cualquier entorno y lenguje de programación.

Otro punto alto y loable.

El lenguaje

Debo decir que si bien hay muchos lenguajes que me gustan y con los cuales tuve química desde el principio (C#, Python, Lisp, Turbo Pascal) F# no fue uno de ellos. Sin embargo una vez terminada la lectura del libro debo decir que quede muy impresionado por el mismo y con muchas ganas de programar un módulo real (no quiero ejemplos ni ejercicios). Tengo en mente un muy buen ejemplo pero por ahora lo mantengo en el misterio :)

PS: Esta lectura me ha hecho aprender y apreciar cosas de otras lenguajes y debo decir que estoy muy interesado en aprender más de los conceptos de Erlang. El lenguaje no me parece atractivo pero su diseño y conceptos es ciertamente MUY interesante

Prácticas Funcionales en desarrollos empresariales

2008-05-25T09:15:00.001-04:00

Hace unos meses que estoy trabajando, muy lentamente, en el uso de F# para ello estoy constantemente releyendo el excelente libro Expert F#. Durante este periodo empezé el desarrollo de un proveedor de ADO.Net y decidí aplicar algunos de los linemientos y conceptos de programación funcional. Para ser más exacto decidí tratar de crear objetos inmutables y funciones sin efectos colaterales y esta experiencia me deja algunos aprendizajes:

Estamos muy mal acostumbrados. Es decir que la evolución de los lenguajes nos han llevado a pensar en un modelo donde las variables pueden ser alteradas en cualquier momento sin entender las implicaciones de estos cambios. Una vez que uno empieza a pensar en concurrencia, multi.core, etc. este tipo de programación es muy nocivo.
Es muy práctico diferenciar los datos mutables e inmutables. Dado que el proveedor será usado en un entorno donde la mutabilidad es "recomendada" es necesario soportar algunos de estos aspectos pero resulta interesante que al separar aquellos aspectos mutables de los inmutables se puede ahorrar mucho esfuerzo.
Las funciones sin efecto colateral generan código que facilmente puede ser paralelizado y ejecutado de manera asincrónica.

En fin creo que el ejercicio fue muy bueno y estoy contento con los resultados obtenidos y justo cuando estaba en el proceso de detallar todos estos aspectos este post me evita el trabajo :)

Programación Paralela, Concurrencia y otros

2008-04-27T19:58:00.001-04:00

Estoy tratando de entender la tendencia en este campo y la cantidad de esfuerzos y variedad de librerias me esta volviendo loco.
En cuanto tenga una idea de algo volveré a comentar en el tema

Seguridad en Frameworks - Parte I

2008-04-27T16:40:00.001-04:00

Durante los últimos meses he estado trabajando mucho en la generación de un framework de uso no controlado. Es decir un framework que será utilizado por un conjunto variado de desarrolladores con los cuales no habrá una interacción. Esto no es una novedad para quienes desarrollan frameworks opens-source o redistribuibles, sin embargo a diferencia de ellos este framework es de uso corporativo y con un foco muy alto en la seguridad y restricción en lo que los usuarios del mismo pueden realizar. Para ser más claros la idea no es solo proveer piezas reutilizables de código y lógica sino asegurar que dichas piezas sean utilizadas obligatoriamente y limitar el código desarrollado en lo que puede realizar directamente.

Duante el desarrollo de dicho framework utilizamos muchos, sino todos, de los recursos disponibles en lo que se refiere a diseño de frameworks y librerias base pero llegó un punto donde la información disponible no era suficiente para poder lograr nuestro objetivo. Esto tenía que ver con el uso de CAS (Code Access Security). Ha sido establecido por más de uno que la documentación relacionado con el tema es bastante críptica por lo que luego de una breve investigación logramos establecer un mecanismo para lograr nuestro objetivo. Así que creo que vale la pena resumir el resultado del análisis.

¿Que es CAS?

CAS es un mecanismo que permite controlar la ejecución de porciones de código limitando de esta forma el acceso a operaciones y recursos protegidos. En el caso de un framework empresarial el uso de CAS es muy importante pues permite que los administradores puedan limitar el acceso de las aplicaciones a los recursos declarados. Algunos de los elementos que son controlados a traves de CAS son:

Acceso a red
Acceso a bases de datos
Acceso al sistema de archivos
Acceso al Registro de Windows

CAS ha sido muy poco utilizado en general debido a que la mayoria de las aplicaciones se ejecutan en FullTrust.

El Framework como Proxy

Si bien el escenario ideal permite que una aplicación pueda estar limitado a acceder a los recursos exclusivos a través de CAS esto implica que toda aplicación deberia tener un inventario de los recursos utilizados (el escenario ideal incluso para un modelo de amenazas) pero esto no es posible cuando se habla de cientos de aplicaciones modificadas varias veces por año. Por esto es que en el escenario en el que estuvimos trabajando se planteó utilizar el framework de desarrollo como proxy es decir, todo acceso a un recurso sensible es realizado por el framework y las aplicación solo tienen permiso de invocar al framework.

En este caso se da un cambio en las premisas de administración donde en lugar de buscar la mayor restricción en el acceso a recursos se favorece el control y auditoria de acceso. Con el escenario propuesto si bien las aplicaciones podrán acceder a todos los recursos el framework genera toda la información de auditoria necesaria y puede brindar mecanismos de restricción de acceso que sea configurable de manera más simple que la consola y herramientas de CAS.

En próximos posts haré un análisis básico del uso de CAS en una configuración de permisos delegados.

Recursos para el diseño de frameworks

Design Guidelines for Developing Class Libraries

LINQ Framework Design Guidelines

Framework Design Guidelines

Designing .NET Class Libraries: Security

Guardar archivos en base de datos

2008-01-22T09:35:00.001-03:00

Ayer me pasaron este enlace con relación al impacto de guardara documentos en base de datos. El análisis se focaliza en el rendimiento y considera aspectos como la fragmentación y tipo de acceso. Es más basta con decir que el autor es Jim Gray para saber la calidad del paper.

MUY RECOMENDABLE

http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45

Robocopy es oficial

2008-01-03T12:19:00.001-03:00

Hace mucho tiempo que uso robocopy como la herramienta de linea de comando por defecto en mi día a día por eso al instalar una nueva máquina es una de las herramientas que siempre copio la última versión.

Por todo esto no habia notado que en Vista ya es oficial. Hasta Xp y 2003 la herramienta de línea de comando para hacer copia de una rama de un directorio habia sido xcopy, que era bueno pero tenía muchos deficiencias comparado con Robocopy sin embargo si en vista ejecutan xcopy esto es lo que verán:

C:\Users\cristofg>xcopy /?
Copies files and directory trees.

NOTE: Xcopy is now deprecated, please use Robocopy.

XCOPY source [destination] [/A | /M] [/D[:date]] [/P] [/S [/E]] [/V] [/W]
                           [/C] [/I] [/Q] [/F] [/L] [/G] [/H] [/R] [/T] [/U]
                           [/K] [/N] [/O] [/X] [/Y] [/-Y] [/Z] [/B]
                           [/EXCLUDE:file1[+file2][+file3]...]

Así que Robocopy ya no es parte de resource kit ni nada pareido y es parte de la instalación por defecto de Vista. Esta es una gran noticia para nosotros fanáticos de Robocopy y también para los que aprenderán a usarlo

Buen Desarrollador != Buen Consultor != Buen Bombero (resolutor de problemas)

2007-12-28T10:55:00.001-03:00

En los últimos meses he estado involucrado en varios proyectos de revisión de código y aplicaciones. Este tipo de proeyctos me resultan muy entretenidos por el análisis que se debe realizar la necesidad de aplicar ingeniería reversa no solo al código sino al razonamiento asociado al mismo, pero ese no es el punto de este post.

Como parte de los proyectos pude trabajar con muchas personas distintas en un mismo tipo de entorno y esto me hizo recuerdo de las grandes diferencias entre tes términos que muchas veces son mezclados por razones erróneas, el desarrollador, el consultor y el resolutor de problemas.

En uno de los proyectos que hicimos trabajamos con un muy buen desarrollador un persona queera muy buena dise;ando y escribiendo aplicaciones, un amplio manejo de patrones, TDD, herramientas de ciclo de vida, en fin una persona que sería invaluable en cualquier equipo de desarrollo de aplicaciones o productos. Sin embargo, esta persona no tenía los skills para ser un buen consultor o revisor. Como consultor le faltaba la capacidad de presentar y exponer sus resultados de administrar los tiempos de avance y manejar la presión y riesgos de una situación complicada.

Ahora en otro proyecto teníamos un buen consultor. Alguien que podía integrarse en un equipo rapidamente podía transmitir sus hallazgos, medir el impacto de cambios y desarrollos más allá del código. Analizar riesgos y oportunidades de manero coordinada, en fin un buen consultor y además era un buen desarrollador pero aún así no era un buen resolutor ¿porque? porque no supo desenvolverse en un escenario que no era el suyo controlado. Es decir al ver código de otras personas tuvo problemas en entenderlo, asimilarlo y simplemente se perdió en el entorno donde alguien más con otros criterios desarrollo la solución y terminó frustrandose.

También en estos proyectos tuvimos la suerte de contar con buenos revisores gente que no solo supo entender rapidamente lo que el código hacía sino ademas el razonamiento detrás de la escritura de ese código y las potenciales áreas de falla. Estas personas además supieron construirse un entorno de pruebas, confirmar sus hipótesis de áreas de mejora, pudieron emitir recomendaciones e implementarlas. En fin este perfil se siente mucho más cómodo en entornos desconocidos y donde la documentación e información es escasa y no clara

Es importante que cada uno sepa cual de estos perfiles le sienta mejor para poder explotarlo al máximo

Programación Ágil

2007-11-27T08:38:00.001-03:00

Una de las razones más importantes por las cuales Dilbert se mantiene en el corazón de los profesionales de TI es que muchas veces pone en palabras lo que muchos pensamos. Últimamente hay una explosión de uso de metodología ágil y hay también una explosión de gente que bajo el título de metodología ágil se quita de encima todas las cosas que no quieren hacer.

En fin creo que este comic del día de ayer que lo refleja mejor.

Pueden ver más historias de Dilbert en http://www.dilbert.com y suscribirse para recibir en su correo la historieta del día

Otro empleado más de Microsoft trabajando en Open Source

2007-10-29T15:51:00.001-03:00

Hace ya un tiempo escribí una cuantas líneas con relación a SubSonic y ActionPack lo interesante que me parecia. En los últimos meses Rob Conery, la mente detrás de SubSonic, ha estado escribiendo mucho sobre el futuro de SubSonic dado que LINQ cumple con muchas de las necesidades que SubSonic pretendía cubrir y en ese análisis Rob empezó a ampliar su visión para incluir todo el modelo MVC que tanto admira de Ruby on Rails.

Es así que el viernes publicó un mensaje que no es sorpresivo para la gran mayoría. Rob se une al equipo de ASP.Net para trabajar en proyectos Open Source y de comunidad relacionados con el nuevo framework MVC de ASP.Net. Al mismo tiempo Rob seguirá manteniendo y encargandose de la evolución del SubSonic, que seguirá siendo un proyecto Open Source, así que asegurandose de llevarlo al mejor nivel.

SIn duda creo que fue una muy buena decisión del equipo de ScottGu y sin duda ya nos enteraremos de muchas cosas interesantes que vendrán de la mano del equipo ~~Rails~~ MVC que se está formando dentro del equipo de ASP.Net.

¡Felicitaciones a Rob y al equipo de ASP.Net!

Virtualización y MinWin

2007-10-27T21:28:00.001-03:00

Eric Traut es el Distinguished Engineer a cargo del desarrollo del core de virtualización en Microsoft. Hace un tiempo (no conozco la fecha exacta) dió una charla en una universidad. La charla esta focalizada en hipervisores y la arquitectura del hipervisor de Windows Server 2008. Es una charla muy buena que permite entender en términos generales los aspectos y razones de la virtualización y en particular de hipervisores vale la pena.

Eric Traut - Virtualización

Ah, un bonus esta sobre el final de la charla en la que Eric Traut menciona la existencia de MinWin una versión minimalista del core de Windows que sería el corazón de Windows 7, el sucesor de Vista. Obviamente este kernel no tiene interfaz gráfica y esta limitado a lo escencial peso 25 MB y solo contiene 100 archivos, gran avance frente a Windows Core ¿verdad? Si solo les interesa ver MinWin en acción el video resumido esta a continuación

Demostración de MinWin

Via: Mary Jo Foley y su blog

PD: me pareció interesante combinar youtube y soapbox :)

F# y Visual Studio

2007-10-27T10:56:00.001-03:00

F# es un lenguaje funcional tipado que esta basado en OCaml y ha sido adecuado para ser eficiente en plataforma .Net. F# fue creado hace 2 años por un equipo de investigadores de Microsoft en Cambridge y ha tenido mucha receptividad en el mundo de los lenguajes funcionales. A decir verdad, F# es utilizado en el mundo "real" por el equipo de XBox Live con buenos resultados.

F# ha ganado mucha visibilidad con algunos desarrolladores del equipo de Visual Studio y finalmente hace una semana S. Somasegar, el VP de la división de productos para desarrolladores, anunció la creación de un equipo mixto entre desarrolladores de visual studio y el equipo de investigación para llevar adelante la integración y evolución de F# .

Esta noticia es muy interesante pues complementa la visión de .Net como una plataforma para todos los desarrolladores y los lenguajes de su preferencia: lenguajes fuertemente tipados orientados a objetos (C#, VB.Net, Delphi, boo), lenguajes dinámicos (IronPython, IronRuby, JavaScript, VB, Iron*) y ahora lenguajes funcionales (F#).

Esto me plantea una gran disyuntiva respecto a cual sería mi lenguaje de hobby. Hasta ahora nunca dude que fuera C# pero dado que este lenguaje ya es mi herramienta de trabajo creo que debería buscar otra alternativa para mantener la cabeza abierta, mi primera opción era sin dudarlo IronPython pero ahora se me plantea la duda de F#. .

¿Por qué? los lenguajes dinámicos estan de moda pero no me son ajenos sin embargo no tengo ninguna experiencia con lenguajes funcionales y este es un reto interesante. En fin lo maravilloso de todo esto es que puedes elegir.

Para mas información en F# pueden recurrir a los siguientes recursos:

Sitio de investigación de F#
Blog de Don Syme - Líder del proyecto
Blog de Jomo Fisher - Desarrollador del equipo de Visual Studio que será encargado de integrar F# en VS y un seguidor de F# hace un tiempo atrás-
Manual de F#
Libros de F#

Licencias Microsoft son Open Source

2007-10-16T16:33:00.001-03:00

Source: http://opensource.org/node/207

La OSI (Open Source Initiative) ha dado por aprobadas las dos licencias que Microsoft presentó hace unos meses. Las mismas en una primera instancia fueron observadas por los términos y poca claridad de las mismas luego de una revisión y adaptación de las mismas por parte de Microsoft el viernes pasado fueron oficialmente aprobadas.

Para conocer el texto de las dos licencias pueden ingresar al sitio de OSI:

Es muy interesante este anuncio porque con esta aprobación productos como IronPython y IronRuby son certificados por la comunidad Open Source como Codigo Libre. ¡Cooool!

Notas de un fin de semana largo

2007-10-16T10:54:00.001-03:00

Este fin de semana largo tuve tiempo de revisar varios blogs y webear en general así que hago un resumen de cosas interesantes que pasaron entre el viernes y hoy:

Oracle - BEA: La compra de BEA es un movimiento que se veía venir tarde a temprano y Oracle es tan solo el actor circunstancial. Lo interesante de este movimiento es que si se completa (que dudo que no sea así) Oracle tendría aproximadamente un 40% del mercado de App Servers frente al 24% de JBoss, hasta ahora el lider. En este análisis no voy a entrar en detalle porque es relativamente complejo pero si alguien esta interesado recomiendo leer los posts que estoy leyendo o simplemente entrar al blog de Marc Fleury y leer sus posts de análisis que son muy buenos.
Beta de Net60: Net60 es una implementación de .Net CF para el sistema operativo de Symbian. Esta es una gran noticia para los desarrolladores de aplicaciones móbiles con .Net porque al ser Symbian el gran dueño del mercado de sistemas operativos de celulares esta oferta incrementa mucho el alcance de las soluciones desarrolladas. Por ahora no me queda claro el modelo de comercialización de RedFiveLabs y su implementación es compatible solo con la versión 1.0 de CF pero es definitivamente algo para tener en el radar.
Microsoft's Big Mac Sales: El jueves en el almuerzo comentabamos con mi jefe todo el mercado para la venta de Windwos a usuarios de MacBook y como mucha gente estaba comprando Mac para instalar Windows. Después me enteré que Microsoft Watch publicó un artículo al respecto. Algunos número que quiero destacar: 20% de las ventas de retail de office son de la versión Mac, se estima que el 10% de las ventas de Vista en Retail son para usuarios de Mac. Si bien hay que aclarar que el mercado de Retail no es el ingreso principal de Microsoft no deja de ser un número muy importante y confirma que cada vez más usuarios de Microsoft serán también usuarios de Mac.
MSDN Magazine: La edición de noviembre del MSDN Magazine ya esta línea y puede ser accedida en http://msdn.microsoft.com/msdnmag/issues/07/11/default.aspx. EL l foco de los artículos de este mes es seguridad y recomiendo mucho el artículo de code reviews claro que para mí un mejor nombre sería security code reviews, en fin no tenemos porque estar todos de acuerdo en todo :).

Proyecto personal

2007-10-08T15:34:00.001-04:00

Hace unas semanas que trato de definir que emprenderé como proyecto personal para poder dedicarme a escrbir código. Obviamente este proyecto debería estar en un área de interés mio, es decir: Performance o Servicios. Hablando más en términos de tecnología: WCF, BizTalk o Revisión de código .Net orientada a performance.

Con esas bases se me han venido un par de ideas a la cabeza y por ahora tengo un par de alternativas que parecen acentuarse cada vez más:

WCF.FI: FastInfoset (en wikipedia)es una especificación que viene del mundo Java para la serialización binaria de un Infoset XML. Esta serialización esta basada en ASN.1 y por ahora ya tiene unas cuantas implementaciones. En WCF tenemos un mecanismo de serialización binario propio de .Net y solo existe una implementación, hasta donde sé, de FI para .Net. Esta implementación es desarrollo de noemax y sin duda parece la alternativa para aquellos que quieran implementar una solución basada en WCF y FI, pero sería bueno implementar lo necesario para proveer este servicio en un entorno de Test.
- Pros: Permite que trabaje bastante con WCF, XML y servicios y puede ser de utilidad en muchos escenarios.
- Cons: Uno de los requerimientos base es soportar el manejo de ASN.1 que en el framework es inexistente así que hay que construir mucha plataforma antes de llegar a lo interesante.
DNN.Performance: DotNetNuke es ampliamente utilizado y recomendado en todos los ámbitos. Sin embargo, todas y cada una de mis experiencias con la plataforma me ha dejado claro que el equipo de desarrollo jamas como objetivo el performance de la aplicación. Todas las páginas y componentes que he revisado pueden mejorar sustancialmente con un poco de análisis y esfuerzo así que es una posibilidad contribuir a este equipo.
- Pros: Es un proyecto que involucra muchos aspectos del framework y que seguramente puede tener impacto en muchas instalaciones y sitios web.
- Cons: Dado el ciclo de desarrollo de DNN puede requerir mucho tiempo antes de brindar resultados terminando en un branch antiguo siendo el optimizado
Catalogo UDDI: En este caso el objetivo sería construir un catalogo de servicios (no solo un directorio) basado en UDDI 3.0.
- Pros: Me permitiría aprender UDDI y puede ser de mucha utilidad.
- Cons: El futuro de UDDI lo veo incierto en el mercado en general así que no se cuanto pueda escalara la solución.
Parallel FX: No se qué... pero me encantaría hacer algo con Parallel FX claro que aca como primer punto esta conseguir un drop del mismo y eso no pasará en un buen tiempo.

En fin como verán la decisión no es simple por ahora quien lleva las de perder es DNN pero uno nunca sabe que pasará. Cualquier sea el caso los avances y aprendizaje serán reflejados en este espacio.

La noticia corre rapido

2007-10-08T15:32:00.001-04:00

EL día de hoy por distintos gerentes de programa y producto (ScottGu por ejemplo) se dió a conocer que Microsoft hará disponible el código de las clases base de .Net. El código incluirá comentarios y estará integrado nativamente para el debug en VS 2008.

Este es un gran hito para el equipo de producto y para todos los programadores .Net. Eso sí, es muy importante aclarar los términos de la licencia que hacen esto posible, el código estará disponible bajo los términos de Microsoft Reference License. Es decir .Net NO es open source esto significa que todos aquellos que estén involucrados activamente en el desarrollo de productos open source DEBEN abstenerse de mirar estas librerias Miguel de Icaza es el primero en hacerlo saber a los colaboradores de Mono. A el ya se suman muchos responsables de proyectos Open Source para asegurarse de evitar problemas.

En fin, para todos aquellos que no son colaboradores son buenas noticias. Habrá mucho tiempo divertido y de aprendizaje revisando el código fuente de todos los componentes de las librerias base del Framework.

PS: Este post lleva días como draft y seguramente la noticia ya es vieja ... :(

Iron* para Firefox

2007-08-08T10:02:00.001-04:00

Reisando mi largamenet retrasada lista de blogs hoy me entere que Mozilla tiene un proyecto denominado IronMonkey que tiene por objetivo que se puedan ejecutar scripts escritos en IronRuby y en IronPython en firefox.

Esta notiicia es enorme porque significa que efectivamente se estaría brindando la posibilidad a los programadores Web de utilizar otros lenguajes además de ECMAScript en los dos navegadores más utilizados ... esperen si consdieramos que Silverlight estará disponible para Safari en Mac estamos por encima del 99% de los navegadores.

El objetivo del proyecto es crear un traductor de CIL a ABC que es el código intermedio de Tamarin, la maquina virtual para JavaScript desarrollada por Adobe e integrada en los productos Mozilla.

Si Mozilla logrará efectivamente construir un traductor, con rendimiento en Web aceptable, de CIL a ABC en realidad cualquier lenguaje basado en DLR podría ser ejecutado en Firefox. Esto abre la puerta a VBX, IronPHP y cualquier otros que se vea por ahí. Eso es muuuuy emocionante.

Por otro lado Miguel de Icaza pulico en su Blog una pequeña prueba del rendimiento de Tamarin comparado con Mono y resulta que aún en lenguajes nativos Mono es más rápido. Su planteamiento es "Mono podría integrarse en Firefox y ser VM de scripting".

La idea de Miguel es díficil que sea aceptada en el corto plazo por tiempos, planificación y otros aspectos, pero la idea de tener navegadores que soporten CIL assemblies nativamente, además del soporte para SilverLight, en todas las plataformas es una linda utopia.

SubSonic - ActionPack

2007-02-16T18:07:00.000-03:00

Una de las ventajas de los lenguajes dinámicos es que los ORMs o pseudo-ORMs que se utilizan pueden generarse totalmente con la información de la base de datos. El más conocido ejemplo de esto hoy en día es ActiveRecord que es una implementación del patrón ActiveRecord en Ruby, y es el más famoso por ser utilizado por Ruby on Rails(ROR). Como los que leen mi blog saben soy un seguidor de Python más que Ruby por lo que mi implementación favortia de este tipo de ORMS es SQLObject, y si quieren un framework MVC prefiero TurboGears, pero bueno no voy a desviarme del tema.

Los que me conocen saben también que no soy amigo de los ORM entonces porque lo que se preguntarán porque lo menciono en el mundo dinámico. Bueno porque en el mundo dinámico el costo de creación del objeto en sí hace que el costo del ORM sea despreciable. Además que todo el manejo de SQLObject me parece muy coherente y segundo porque todo el concepto de mapeo puede hacer que todo el proceso sea muy complicado. Pero si se pudiera tener algo efecitvo y ligero no estaría de más.

En el mundo CLR he visto varios intentos de hacer cosas similares (ActiveRecord de CastleProject por ejemplo) casi siempre asociado a proyectos de creación de frameworks MVC al estilo de ROR (MonoRail). Sin embargo en estos proyectos he encontrado el problema común de la creación de los objetos, dado que el CLR es fuertemente tipado las clases deben ser conocidas por el compilador y no pueden ser modificadas posteriormente lo que limita mucho la creación automática.

Muchos proyectos han optado por la generación de código fuente para evitarse el problema de la generación del CIL. Esta opción es muy utilizada (CodeSmith es el ejemplo del que más he oido hablar) y creo que da buenos resultados, sin embargo estas soluciones requieren que cuando cambias o agregas elementos a tu base de datos debas regenerar la solución y recompilarla, dado que muchas veces agregas elementos sin modificar lo anterior no es lo más lógico reconstruir todo al menos no desde el origen.

CastleProject trato de usar su conocimiento de generación de CIL para facilitarlo así que basandose en NHibernate obtuvieron algo interesante, pero aún así se debe declarar la clase base y su comportamiento con lo cual no ganaron mucho.

Revisando algunas cosas me encontré con Commerce Starter Kit una aplicación para la creación de sitios de comercio electrónico, el proyecto en si es interesante, pero lo que más me llamó la atención fue su enfoque MVC basado en SubSonic y ActionPack ¿porque me llamo la atención? porque no es necesario generar el código intermedio convirtiendose en una verdadera DAL sin código.

Al principio me pareció demasiado vudú por el hecho ya mencionado de ser el CLR tipado así que me dedique a ver la solución, conforme revise SubSonic (la parte de acceso a datos de ActionPack) entendí su solución y me encantó.

Lo que hace SubSonic es crear un proveedor de Build para ASP.Net lo que le permite que generen el código en demanda y sin necesidad de crear los archivos intermedios, una solución sencilla y altamente efectiva.

Este simple cambio de ubicación hace que la solución sea mucho más fácil de utilizar que otros modelos que haya visto y genera un escenario muy limpio ¿Por qué? porque las clases se generán dinámicamente y sin necesidad de crear archivos adicional y sin importar el lenguaje en el que programes.Obviamente un nivel de abstracción no es lo suficientemente bueno si no puedes modificarlo por lo que, si así lo quieres, puedes generar los archivos intermedios y/o modificar las plantillas DOM para la generación de los mismos.

Si uno lo piensa la tecnología utilizada es la misma que en los otros casos pero el enfoque y modo de combinación es lo que hace que SubSonic sea una solución muy simple y práctica para el uso en frameworks Web y estoy pensando seriamente en su validez en otros escenarios.

A veces la innovación no esta en la tecnología sino en la forma de uso de la misma. Ya les contare de mis pruebas con SubSonic y en un siguiente post hablaré de la parte de scaffolding de Action Pack.

Nota: Obviamente piensen que para usarlo tienen que tener su modelo de datos completo después de todo Active Record parte de la base de datos.

LOB Adapter SDK for WCF

2007-02-11T05:32:00.000-03:00

La semana pasada estuve en un conjunto de conferencias de distintos temas y fuera de un tema de HPC que estoy analizando lo que más me llamo la atención, y que creo que es un salto muy interesante en el concepto de integración de aplicaciones, es el LOB Adapter SDK for WCF (Kit de desarrollo de adaptadores para aplicaciones de negocio para WCF)

Este SDK, que esta en Beta junto con BizTalk R2, es una extensión a WCF para construir conectores con aplicaciones de negocio. En primera instancia debo decir que me pareció muy raro que hubiera algo de este estilo pues con lo extensible que es WCF el construir un nuevo transporte y/o encoder es bastante simple con lo que se podría crear bindings para cualquier aplicación.

Sin embargo hay un par de aspectos que son importantes para los conectores que son necesarios implementar y que los sabios pudieron explicar a este moral.

Metadata: Es necesario buscar un mecanismo para el intercambio y acceso a la metadata de la aplicación de negocios a la que se quiere acceder. Esto no es un tema simple porque a diferencia de un servicio o servicios específicos en cuyo caso se puede intercambiar toda la información relacionada con esquemas, contratos y políticas de comunicación (WS-MetadataExchange es el protocolo diseñado para este intercambio) una aplicación puede exponer una gran variedad de funciones y endpoints de distinta indoles y/o categoría de manera no organizada en servicios. Estas funciones, adempás, pueden o no estar disponibles y variar de acuerdo a la instalación o configuración del sistema.
El mejor ejemplo de este tipo de comportamiento lo dan SAP, JDE, PeopleSOft, Siebel cuyos sistemas pueden tener dependiendo de la instalación y configuración conjuntos muy distintos de funciones expuestas para el acceso por parte de los usuarios. .
Creación del proxy: Un problema derivado del anterior esta en la creación del cliente dado que la metadata no es necesariamente expuesta en términos manejables por MEX (WS-MetadataExchange) svcutil no es una herramienta que se pueda utilizar para la creación del cliente.

Anteriormente los distintos adaptadores de LOB se generaban los desarrolladores del mismo eran los encargados de crear herramientas para realizar las dos tareas anteriores por ejemplo: el SAP.Net conector de SAP tenia herramientas para la creación los proxies a ser utilizados en .Net mientras que el SAP Adapter para BizTalk tenía otra herramienta para la creación de los esquemas a ser utilizados en los endpoints y el intento de SAP data source para SSIS tenía su propio desarrollo para solucionar estos problemas.

Obviamente con el crecimiento de necesidades de integración en las distintas aplicaciones esto es una necesidad cada vez más común. Por ejemplo solo en productos de microsoft los siguientes productos necesitan conectores a sistemas de este tipo: BizTalk, SharePoint, SSIS, SSRS (Reporting), MILM (Identity Lifecycle Manager), potencialmente MOM y seguro algún otro que se me pasa de lado.

Por todo esto es que el equipo de integración de Microsoft empezó a trabajar en un framework para la creación de adaptador para aplicaciones de negocio que cumpla con los requerimientos base de todas las aplicaciones permitiendo que la conexión punto a punto pueda ser resulta una sola vez y reutilizada por todos.

El framework obviamente se basa en la plataforma de servicios y comunicación de Microsoft WCF y provee una arquitectura que ya explicaré en algún otro post. El framework provee un conjunto de elementos reutilizables que asegura que el desarrollador de un conector tenga que limitarse a lo estrictamente necesario, que es:

Emision, consulta y busqueda de Metadata: La diferencia en este punto es que el desarrollador expondrá unas cuantas interfaces comunes y que manejan las descripciones de manera abstracta. El framework brindará todo el mapeo de esos esquemas con WSDL, XSD, MEX, etc. asegurando que una aplicación que necesite de adaptadores no deba conocer a los mismos directamente y pueda hacer uso de las mismas.
Creación de conexiones: Es bastante claro que el adaptador es el que conoce como conectarse con el servidor por lo que la creación de las conexiones es netamente su responsabilidad.
Envio y recepción de mensajes: El día que nos podamos librar de esto estaremos listo para dar el siguiente y buscar otro trabajo :)

En otro post entraré en más detalle de la plataforma pero debo decir que lo que vi hasta ahora es muy bueno y vale la pena seguirle el paso

Marc Fleury deja RedHat

2007-02-11T04:10:00.000-03:00

Los que me conocen y con los que hemos hablado de Java Application Servers saben que a pesar de que no soy un fanático de Java para mi la mejor solución de ese lado es JBoss. Esta opinión se basa en muchas cosas: su enfoque respecto al stack de JEE, su visión de donde van los application servers en general y su visión de un Open Source Profesional - aún hoy considero que el paper de Marc Fleury en el tema, fundador de JBoss, es muy interesante como modelo de negocios y algo a considerar.

Hace un tiempo RedHat compro JBoss y fue todo un hito en el mundo Open Source, Marc estaba muy emocionado por tener todo el respaldo que le daba Red Hat para seguir trabajando en su modelo de Open Source profesional y fortalecer el áea de Investigación y desarrollo.

Bueno, con todo eso dicho voy al tema del post. Habitualmente sigo el curso de JEMS (Java Enterprise Middleare Suite) y hace ya unos dos meses que se corrían muchos rumores de la "infelicidad" de Marc Fleury en Red Hat, principalmente porque sus expectativas de lo que podría hacer y quería hacer no se estaban realizando. Creo que el pobre Mac no contaba con que al final del día Red Hat es una corporación y no precisamente alineada con su modelo Open Source Profesional.

Todo esto se fortalece cuando hace un mes casi Marc toma "vacaciones indefinidas" respaldado por el nacimiento de su último hijo, este aviso disparó muchos más rumores y casi aseveraciones de la inminente salida de Fleury la historia siguió por semanas pero fue recien el día de hoy se oficializó que Marc no vuelve a Red Hat. Los comentarios que leí dicen que por un tiempo se dedicará a la enseñanza y a pasar tiempo con su familia, esa es una gran noticia para Marc pero algo para pensar para los que defienden el modelo de Red Hat como un modelo de Open Source comercial.

Es bien sabido que Red Hat es la oveja negra de todos aquellos que se consideran seguidores del modelo Open Source sin embargo creo que esto es la prueba definitiva de la divergencia entre el proveedor más importante de Linux para empresas y la corriente Open Source.

Sinceramente espero que no sea lo último que escuchemos de Marc insisto que hasta la fecha su visión en relación a Open Source es la única que me ha parecido sostenible y coherente. Eso sí no puedo negar que espero que la próxima vez que se sepa de él sea en el mundo de CLI y no de JVM ;)

Windows Movie Maker y MOV

2007-01-18T01:23:00.000-03:00

Este post será muy corto y concreto hace una semana o más decidí utilizar por primera vez Windwos Movie Maker a fin de editar y adecuar unas cuantas filmaciones que se realizaron con una pequeña camara digital. Debo decir que WMM es en realidad muy fácil de usar y pude ubicarme muy rápido, lamentablemente cuando quise importar los archivos encontré que WMM no podía importar archivos MOV :S

Entonces empecé a entender, WMM importa archivos basados en Codecs de Windows o DirectShow y obviamente Apple y QuickTime no proveen los mismos. Ademas que no tenía instalado QuickTime Player (no soy muy fanático del mismo)

Estuve buscando un Codec para el formato de QuickTime y cuando estaba a punto de darme por vencido encontre QuickTime Alternative, que es un codec para Windows y un filtro para DirectShow que permite visualizar MOV. Lo instale y ahora puedo ver los videos en WIndows Media PLayer y estoy editando los videos en Windows Movie Maker.

Larga vida Community Server

2007-01-12T11:39:00.000-03:00

Bueno este post tiene por objetivo explicar mi larga ausencia y ver si puedo retomar la escritura.

Como ya comenté tuve problemas con mi portátil lo que me limitó mucho y no me permitió trabajar en varias ideas que tenía en la cabeza. Para resumir una larga historia luego de casi tres meses de esperar que el soporte técnico de HP pudiera reparar la portátil y/o que llegaran las partes HP decidió entregarme una nueva portátil, la nueva es una Compaq nx6320, es un buen equipo y por ahora el único reclamo que me hizo golpearme la cabeza contra la pared es que su LCD solo soporta hasta 1024x768 pero bueno a todo uno se acostumbra.

Para que se den una idea de cuanto tomo todo el proceso la entrega no se concretó sino hasta el 20 de diciembre por lo que después de las fiestas estuve instalando y configurando el equipo (Vista, Office 2007, Net fx3, SQL 2005 SP2, etc, etc) y estuvo listo para reiniciar actividades para fin de año.

Bueno ahora ya saben que tengo tan sólo un par de semanas con total capacidad de operación. y en dichas semanas estuve trabajando en un pequeño proyecto que es lo que da nombre a este post.

Para ponerlos en contexto a fines del año pasado me involucré en la creación de un pequeño sitio de comunidad (nada de tecnología) y por ser el que trabaja con computadoras me toco encargarme de ver el hosting, plataforma y todo aquello.

Dado que la comunidad no será manejada y en realidad tiende a ser bastante pública tenía que ser una plataforma fácil de usar y administrar por no techies. Tipicamente para este tipo de escenarios en proyectos que realizo utilizo WIndows SharePoint Services. Pero como en este caso el hosting no siempre lo provee y no necesitabamos toda la plataforma decidí evaluar dos alternativa DotNetNuke y Community Server, ¿por qué esas dos? 1)por que son las que conocía 1) habia jugado con ellas alguna vez 3) Son muy utilizadas y probadas.

Dado que el criterio de selección final iba a ser la usabilidad creí que la mejor forma de probar era bajar el último build de ambos, instalarlo, configurarlo, crear un tema y dejar un pequeño sitio de prueba funcionando.

DotNetNuke

DotNetNuke (DNN) es uno de los proyectos Open Source ASP.Net más grandes del planeta y esta enfocado en la fácil creación y mantenimiento de sitio, portales y aplicaciones Web. Los que me conocen saben que DNN no es mi plataforma favorita y esta lejos de serlo pero las razones son netamente técnicas y de rendimiento - Si bien DNN sigue prácticas altamente probadas de diseño y hace un uso muy efectivo de varios patrones, en mi opinión esta sobrediseñado y todo este sobrediseño hace que el rendimiento caiga conforme mayor su uso solo como ejemplo los invito a revisar como esta implementado el manejo de RSS - pero como en este caso no necesitamos escalar mucho y tenía ante todo la necesidad de ser fácil decidí considerarlo.

A continuación van los resultados de cada paso

Instalación

La instalación de DNN fue bastante simple, copiando los archivos en la carpeta Web y luego siguiendo los pasos del asistente DNN fue capaz de tener el sitio funcionando en un par de minutos, definitivamente fue un punto a favor.

Configuración

El proceso de configuración consiste en la limpieza de los datos de ejemplo, creación de unos cuantos foros, un par de blogs y un conjunto de galerias. Aquí es donde DNN empezó a caer en rating, limpiar los datos creados por defecto fue fácil, pero cuando empezé a buscar la creación de nuevos elementos pude ver que no toda la funcionalidad que necesita estaba incluida y necesitaba descargar varios módulos. Entonces entre al sitio de DNN e ingrese en un su buscador una simple frase Create a Forum, si no hubiera cerrado el navegador probablemente aún estaría esperando la respuesta (no el rendimiento que uno espera), bueno intentemos de nuevo :S Error inesperado. Ok DNN no me ayudará. Pero encontré un buen sitio DNN Creative que con sus tutoriales me permitió hacer un par de cosas. Ahora vamos con los blogs pero esto no soporta enclosures y así la lista seguía y bajaba otro módulo y otro módulo... basta, esto me sirve para entender el concepto.

Creando un tema

Asumiendo que mi sitio estaba listo (solo asumiendo) me puse a trabajar en crear un tema. Los temas de DNN se basán en archivos HTML y ASCX que definen las zonas de trabajo para que luego DNN ponga el contenido. Me baje la guía de creación de temas del sitio y empezé a trabajar en ello parar resumir estuve un par de horas cambiando cosas y jamas pude hacer que DNN luciera como quería. Es cierto que es muy flexible y con unos días más de trabajo lo hubiera logrado pero esto era solo una prueba y no tenía días de trabajo.

Conclusión

Al final mi sitio no tenía todo lo que quería y tenía un tema a medias :S.

Antes de seguir tengo que reconocer que DNN tiene como gran ventaja el gran número de módulos disponibles si quieren crear un sitio o aplicación que vaya más allá de una comunidad la funcionalidad es accesible, completamente integrada y definitivamente es una buena alternativa que requiere una inversión importante de tiempo.

Community Server

Community Server (CS) es un producto de Telligent una empresa de desarrollo .Net que construyo la plataforma para su uso y luego la comercializó siendo la versión Personal gratuita para uso no comercial y en un solo dominio. Además que no está activa toda la funcionalidad de CS, ah y requiere que el logo de Powered By este en todas las páginas.

Antes de seguir hay que aclarar que dado que este es un producto específico para comunidades lo que le da cierta ventaja sobre DNN, también debo decir que tecnológicamente me parece una plataforma mucho más interesante que DNN.

Instalación

La instalación de CS fue también muy simple, copiando los archivos en la carpeta Web y luego siguiendo los pasos del asistente la comunidad estaba lista en un abrir y cerra de ojos.

Configuración

Dado que al momento de instalar CS pregunta si se incluirán datos de ejemplo no fue necesario realizar una limpieza y pude empezar directamente con la creación de los blogs, foros y galerías. La verdad que la tarea fue muy simple (el panel de control es muy claro) y en menos de media hora tenía creado todo mi contenido de ejemplo. Tuve algunos problemas habilitando la publicación de usuarios anónimos pero una búsqueda en el sitio de CS permitió que un CS MVP me diera la respuesta. Punto a favor.

Creando un tema

La creación de temas fue un poco más compleja porque al principio me costó entender el modelo de skinning de CS pero de nuevo un par de búsquedas en el sitio me dieron la pauta y resulto mucho más simple de lo que pensaba. CS basa sus plantillas en Contenidos y regiones (muy similar a los conceptos de master pages de ASP.Net 2.0) así que una vez comprendido pude crear un tema de blog en un par de horas.

El tema de sitio tomaría más pero el concepto era el mismo

Conclusión

Al final mi sitio lucía como una comunidad, tenía el funcionamiento de una comunidad y tenía blogs y galerias con temas propios.

Claramente las ventajas de CS para el manejo de comunidades superan por mucho a las de DNN pero tienen la contra de las limitaciones por licenciamiento y que no es tan fácil integrar nuevas aplicaciones (bueno si es fácil pero los add-ons no están disponibles en la versión Personal).

Como el título ya denotaba al final me quede con CS Personal y no me arrepiento luego de dos semanas de trabajo (donde el mayor trabajo fue el diseño del tema y del contenidodel sitio) hoy la comunidad esta en línea y pronta a hacerse pública.

Como siempre no faltará quien diga que soy un ignorante en DNN o que si quiero otro dominio CS Personal no me sirve o ...[insertar razones por las que DNN es el mejor software del plante], es probable que todo sea cierto pero CS Personal resolvió mis necesidades actuales de manera más simple, rápida y adecuada, al final ¿no es eso lo que importa?

Finalmente...

2006-12-15T07:58:00.000-03:00

Finalmente tengo un máquina en la que puedo hacer muchas de las cosas que tenía planificadas, lamentablemente aún no es la mía pero sirve. Que significa esto que con suerte en poco tiempo estaré publicando un par de posts largamente olvidados, mientras tanto quería comentar un par de cosas:

SIF Hace poco más de una semana un amigo me comentó que habían publicado SIF en codeplex. SIF es la abreviatura de Service Invocation Framework que es un framework pensado para facilitar la vida de aquellos que trabajan con aplicaciones que consumen servicios. Si, y ase que WCF está listo y muchas cosas pero SIF les permite que sin instalar .Net 3.0 tengas funcionalidades tales como: Proxy dinámico de servicios (este por si solo vale oro), consumo de servicios independiente de transporte (WCF, ASMX, Remoting, etc.) diagnóstico, tracing y la posibilidad de tener un pipeline de proceso en el cliente. Altamente recomendado, ah si el link es http://codeplex.com/SIF
Robotics Studio. Si señor la semana pasada finalmente se liberó Microsoft Robotics Studio que es libre para su descarga en uso no comercial. Sinceramente creo que esta herramienta es uno de esos productos que cambiará la vida de muchos. http://msdn.microsoft.com/robotics

Como ven eran literalmente un par de cosas. Espero que el próximo post incluya código.

¿Quieres hacer pan? utiliza AJAX

2006-11-30T16:02:00.000-03:00

Esta parece ser la premisa en todo lugar donde hablan de desarrollo Web. Al igual que ha pasado muchas otras veces con otras tantas propuestas y tecnologías AJAX se ha vuelto la palabra de moda y su uso un símbolo de status. SIn embargo no siempre AJAX es la mejor opción en muchas ocasiones en realidad estas generando tráfico y carga adicional todo por usar lo que esta de moda.

Como toda tecnología y herramienta en general AJAX tiene un lugar y uso adecuado por ello cito algunos escenarios donde AJAX no creo que se conveniente:

AJAX NO debe ser usado en sitios donde se redibuja toda la página. Piensen que si fuera un link seria solo una llamada en cambio con ajax tendrán la llamada, cambio de estilos y despliegue y el usuario no habrá ganado nada.
AJAX NO debe usarse para traer imagenes, un uso común es cambiar las imagenes pero si traen la imagen con AJAX y luego le piden al navegador desplegarla están agregando pasos innecesarios.
AJAX NO debe usarse para no tener que cambiar nunca de página. En este caso tus archivos JS se volveran enormes y todo el tiempo que podrías ahorrar entre llamadas lo utilizaras en descargar tus archivos. Los enlaces no son tus enemigos.
AJAX NO debe complicar la navegación. Tipicamente cuando alguien encuentra algo interesante lo que hace es mandar el link a otros por lo tanto un link javascript:Ejecutar('2sdfasdfasdf') no servira de nada. Este enfatiza el anterior los enlaces no son tus enemigos
AJAX NO debe asumir que todos los navegadores soportan Javascript habemos muchos que tenemos deshabilitadas varias opciones o incluso todo javascript así que siempre piensa en un método alterno.
AJAX NO debe ser usados para correr procesos Batch. Por muy tentador que parezca esto no es una buena idea. ¿Porque? porque simplemente pierdes totalmente el control del proceso al enviarlo al servidor. Es posible mantener un control pero para eso necesitarías crear al menos 4 servicios ajax Inicio, Estado, Cancelacion, Resultado. Mientras que una página de servidor puede refrescarse y mantener al tanto al usuario con un mayor control de proceso en el servidor.

En fin todo esto solo es para decir un viejo y conocido dicho la mejor solución es la más simple y recuerda AJAX no siempre lo es.

PS quiero hacer un reconocimiento al equipo de MS Visual Interdev e Internet Explorer que hace 7 años plantearon el uso de RemoteScripting y DHTML, ideas que evolucionaron en XmlHttpRequest y que hoy son base de AJAX, si tan solo todos los hubieran escuchado entonces...

Semanas ocupadas...

2006-11-14T11:16:00.000-03:00

Para los equipos de producto, los mismos nos han dado muchas novedades y esperé a que estuvieran todas acumuladas para comentarlas.

.Net Fx3 RTM. Así es el lunes pasado se hizo oficial la comunicación y hoy WPF,WCF,WF y CardSpace estan disponibles para todos. Junto con el runtime también esta disponible el SDK de Windows Vista. Más info en http://www.netfx3.com
PowerShell RTM, En el blog del equipo de producto hoy anunciaron que finalmente el nuevo shell de Windows esta listo. Para los administradores de redes y servidores y para los amantes de la linea de comando es obligatorio descargarlo. Más info http://support.microsoft.com/kb/926139 (por si acaso los enlaces de descarga son nuevos así que puede que tarden un poco en estar disponibles)
Office 2007 RTM. También el lunes pasado el equipo de producto entrego el build que fue llevado a las fabricas. Lamentablemente este producto no se puede descargar, pero si esperan hasta el primero de diciembre ya se podrá descargar un trial. Por ahora habrá que conformarse con probarlo en línea. Más info http://office.microsoft.com
Vista RTM. El WIndows con el nombre más raro también llegó al final de su etapa de pruebas y fue entregado a linea de ensamblaje. Al igual que con Office habrá que esperar antes de tener un instalador de Vista y la fecha estimada de disponibilidad "en tiendas" es fines de Enero del 2007, pero para las empresas con acuerdos con MS deberían tenerlo en Diciembre. Más info http://www.microsoft.com/windowsvista/

Bueno todo esto se traduce en... MUUUUUUUUUUUCHO por aprender y estudiar. Si bien he seguido a WCF y algo de WF tengo mucho que aprender en WPF; CardSpace. Vista API, Office Server, etc., etc. etc.

Pendientes

2006-11-12T12:55:00.000-03:00

Al publicar el post incompleto de hoy (incompleto por que se suponía debía incluir un ejemplo) me dí cuenta que hace más de un més que estoy con la máquina de reemplazo. Definitivamente es un perjuicio pues en este mes han salido muchas ideas sobre las cuales escribir y que no he podido hacerlo por no tener donde probarlas. A continuación algunas de las ideas:

Completar el ejemplo del post de Http Handlers. Mi idea es construir un handler de WebDAV muy basico (no PROP solo listado, GET y PUT)
Análisis de estático de código en base de datos. Sip hay mil y un razones para hacerlo y estoy pensando en como automatizarlo (parece simple pero lo veremos)
Diseño físico de bases de datos en SQL 2005. El artículo que referencié hace unas dos semanas es muy bueno pero quiero incluir un par de comentarios que son importantes y que no se mencionan a detalle

Bueno, esas son las idea por ahora, además de las revisiones de los nuevos drops del service factory y del Web Client Factory.

Hay mucho que hacer espero que mi portátil vuelva pronto.

Http Handlers

2006-11-12T12:29:00.000-03:00

Ha pasado mucho tiempo desde que escribí un post. Esto se debe principalmente a que como comente anteriormente mi portátil estuvo en reparaciones y la máquina de reemplazo no tenía los recursos para poder hacer las pruebas que debían acompañar al post. Sin embargo, este post estuvo en trabajo por mucho tiempo.

¿Qué es un HTTP handler?

Veamos para entenderlo creo que es mejor mostrar un diagrama del flujo que sigue un requerimiento que llega a un servidor IIS ejecutando ASP.Net

Antes de seguir debo aclarar que este diagrama es reducido al proceso en ASP.Net y no considera el proceso propio de IIS.

Ahora si, en materia, como se ve en el diagrama ASP.Net procesa todos los requerimientos a través de un Http Handler que es configurado por path y requerimiento Http (GET; POST; PUT; etc).

El Http Handler recibe el requerimiento en bruto y es el encargo de procesarlo para enviar una respuesta. Por ejemplo .Net utiliza el "forbidden Http Handler" para proteger archivos de configuración, código fuente, base de datos, etc., este Http Handler lo único que hace es responder que el acceso a los recursos solicitados esta denegado.

Las páginas web, los eventos y todo el manejo que tantos usuarios queremos es provisto por por el PageHandlerFactory, así como el manejo de los serviciso Web es provisto por el WebServiceHandlerFactory.

¿Porque necesito saber de los handlers?

Esta es una tipica pregunta, bueno las respuesta son variadas pero yo enumero algunos ejemplos:

Seguridad. Es de conocimiento de todos que un sitio web que maneja información crítica debe ser protegido adecuadamente y una de las principales prácticas en temas de seguridad es la reducción de la superficie de ataque. Es decir deshabilitar todos aquellos componentes que no utilicemos. Por ejemplo en un sitio de servicios Web es recomendable deshabiltiar el PageHandlerFactory y de ser posible incluir la extensión aspx en la sección de forbiden. También deberían incluirse en forbidden extensiones como ser cgi, asp, etc.
Reutilización. Un handler es una herramienta muy poderosa para lograr grandes niveles de reutilización. Por ejemplo se podría crear un handler que lea un xml y con eso genere un feed en un formato especifico (RSS, ATOM u algún otro). Esto hace que todas mis aplicaciones solo tengan que generar un XML interno y cualquier cambio en la salida lo define en el Handler.
Performance. Hoy casi todas las aplicaciones necesitan almacenar algún tipo de archivo en la base de datos y para recuperarlo se crea una página que en base a los parámetros limpia el response y manda el resultado. SI bien esto no es malo (y muchos proyectos públicos muy grandes lo usan) es muy ineficiente y resta gran escalabilidad a la solución. ¿Por qué? pues porque para atender el requerimiento se creo una instancia del PageHandlerFactory una instancia de una página, se hizo manejo de eventos y muchas otras cosas innecesarias, en este escenario un handler evita toda esta maquinaría y es más directo en el envío de la respuesta resultando en ganancia de performance y escalabilidad. Para que quede claro esta recomendación no solo es valida para la carga y descarga de imágenes, sino para: Feeds, documentos, páginas Html estáticas ensambladas, Filtro de contenido, etc.

Creo que estas son muy buenas razones para que los desarrolladores presten atención a los Http Handlers y piensen mejor cuando podrían utilizarlas.

En un próximo post haré un ejemplo más concreto en el cual trataré de mostrar la ganancia en seguridad y performance. Eso si tendrán que esperar a que retorne mi portátil.

Diseño físico de base de datos

2006-10-30T11:26:00.000-03:00

Este tema es una de los que personalmente ha estado en mi cabeza los últimos años pues es una de las áreas más descuidadas a la hora de implementar soluciones medianas y grandes, por eso es que cuando encontre este artículo me parecio que vale la pane difundirlo.

http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx

PS: Estoy con problemas que me impiden hacer pruebas y documentar lo que tengo en la cabeza para poder publicar más a menudo, espero que en unos 10 días esto estará solucionado.

Lo que debo tener instalado si o si

2006-10-12T17:09:00.000-04:00

El día lunes sin previo aviso mi laptop paso a mejor vida, si ya se que no es nada raro . El tema es que esta vez lo que paso a mejor vida fue el hardware en general. No la instalación, no el disco duro, sino todos lo demás.
Bueno mientras mi laptop es revisada por la gente de servicio técnico me fue entregada una de respaldo con lo básico (Windows y Office) y sin los permisos para instalar nada más.
Después de usarla menos un día lo que me queda claro son las cosas que se han vuelto imperativas en mi modo de uso de la PC

Resolución de 1400. El tamaño de esta pantalla me esta matando...
Total Commander. Mucho más que un simple manejador de archivos, manejo de servicios, procesos, event log, compresión, etc.
PowerShell. El futuro del shell en la para Windows se volvió casi imprescindible en muy poco tiempo (como extraño esa orientación a objetos y dinamismo).
SharpReader. Este fue el primer agregador que usé y que luego deje de usar por un tiempo pero que al final siempre vuelve por su interfaz simple y clara y además por su bajo consumo de recursos.
Tarjeta Wireless Si, ya se que esta no tiene que ver con software pero cuando no eres administrador no puedes conectar ningún hardware adicional.

Muchas otras cosas seguro vendrían a mi cabeza si supiera que esta es mi máquina definitiva. Pero estas se que son las que extrañaré aún si esta máquina la tengo solo una semana.

Fx-> CF -> MF

2006-10-03T15:40:00.000-04:00

Estoy muy retrasado con esta noticia pero la semana pasada no estuve muy conectado para verlo con anticipación. El día 26 de septiembre en el Embedded Conference de Boston se liberó el beta de .Net Micro Framework.

.Net MF es la implementación del framework para aquellos dispositivos que están restringidos en memoria y recursos de hardware y surge del viejo proyecto de research Smart Personal Objects que mostró hace unos años un reloj que corría .Net en 64KBs y luego derivo en la comercialización del smart watch y su integración con msn a través de Direct MSN utilizando bandas de FM para la comunicación.

Pero no quiero desviarme de la historia la idea es que el equipo siguió trabajando y logró obtener una versión "genérica" que esta siendo probada por varias empresas que construyen dispositivos inteligentes. Lo interesante de esta versión del framework es que a diferencia de las anteriores que se ejecutan sobre un sistema operativo .Net MF trata de ejecutar directamente en procesador (bueno una HAL ligera para facilitar el cambio de componentes), es decir que todo el código que se genera es manejado. Si, leyeron bien código 100% manejado no Interop, no marshalling no nada. Esto quiere decir que incluso los drivers de hardware que si son escritos en C o similar por rendimiento son expuestos en interfaces de código manejado, esto es simplemente impresionante.

El grupo además ha hecho leverage de todo el trabajo de VS2005 y el .Net CF por lo que se dispone de emuladores para probar el código, se puede hacer debug de mismo en el emulador o en el dispositivo como tal. Estas cosas que para los desarrolladores de aplicaciones Windows y Web son algo comunes para los desarrolladores de dispositivos inteligentes son en algunos casos impactantes y en casi todos innovadoras.

Obviamente que el .Net MF no está disponible al público por el nivel acoplamiento que hay entre el dispositivo y el framework como tal (aunque el código que corra en hardware similar debería ser el mismo) pero se puede obtener algo de información básica en http://www.aboutnetmf.com

Ahora solo me pregunto si la gente de Robotics esta al tanto para que podamos contar con el manejo de servicios, estado, CCR e incluso el lenguaje de modelado en estos dispositivos. En fin, el futuro de los dispositivos inteligentes y robots se ve brillante en el mundo .Net

Compresión y Servicios (Parte 2)

2006-09-25T21:31:00.000-04:00

En el anterior post traté de explicar la necesidad de un mecanismo de compresión que pueda ser con los servicios. COn esto en mente veamos algunos de los mecanismos que se han estado utilizando.

Compresión en transporte

Este camino es el que tipicamente se ha encarado y principalmente por que Http 1.1 incluye en su especificación la posibilidad de utilizar la cabecera Content-Encoding para comprimir el contenido. Esta especificación es de mucha utilidad pues las razones que llevaron a la implementación de esta parte de la especificación son las mismas que discutí en el anterior artículo (no olvidemos que XML y HTML son substes de SGML). Es así que cuando el transporte era Http era la opción ideal para compresión.

Hablando especificamente de Windows IIS es capaz de comprimir el contenido generado por cualquier página o servicio que se ejecute en su contexto. Los pasos para habilitarlo están aquí. Y en lo que se refiere al cliente .net en la versión 1.0 y 1.1 soporte para Content-Encoding: gzip por lo cual era necesario algo de magia para que funcionara. Pero en la versión 2.0 solo es necesario hacer uso de la opción EnableDecompression.

Pero en lugar de seguir con Http Compression exclusivamente, entendamos el concepto si utilizaba Colas, SMTP, FTP o el transporte que fuera la tarea de compresión era responsabilidad del mismo y no así de la capa de manejo de SOAP y otros.

Lamentablemente WCF no provee soporte nativo para Http Compression y sus otros transportes tampoco lo implementan por defecto.

Serialización optimizada

Esta idea surge como contrapartida de la necesidad de compresión y su objetivo no es comprimir un mensaje sino generar un mejor mensaje, este enfoque en teoria evita todos las sobrecargas descritas en el anterior post. Casi todas las iniciativas se han denominado Serialización binaria o alguna otra variante. La desventaja de este tipo de escenarios es que ninguna se ha impuesto como un estándar y su nivel de compatibilidad es muy limitado.

Actualmente hay un par de ideas alrededor que han extendido este concepto. Estos conceptos se basan en que la serialización no debería modificarse y debería seguir serializandose el mensaje a XML Infoset, en cambio estos deberían codificarse (encode) en binario y no en documentos XML, WCF utiliza este concepto en su encoding binario que es, en palabras de Clemens Vasters en su blog, el nieto moderno y bajamente acoplado de NDR. Otro proyecto que esta tomando cuerpo es Fast Infoset , este proyecto impulsado por Sun y que basa su mecanismo de codificación en ASN.1 pretende ser la alternativa en escenarios Java. De nuevo estos mecanismos no aseguran interoperabilidad (aunque ya hay muchos trabajando en tener FI para WCF) y a pesar de que el tamaño del mensaje es mucho mejor no es comparable con un mensaje compreso.

Doble codificación

Este mecanismo lo han utilizado algunos en distintos transportes y consiste en que el generador del mensaje luego de serializarlo y codificarlo en XML lo vuelva a codificar esta vez utilizando un mecanismo de compresión, si queremos plantearlo así es llegar el concepto del content-encoding a la capa de codificación.

Esto no había sido utilizado mucho anteriormente pero me imagino que esta situación cambiará mucho al incluir los nuveos frameworks de servicios la facilidad de reemplazar o extender los codiicadores (encoders).

En el SDK de WCF podrán encontrar un ejemplo de un encoder que comprime utilizando GZip. Lo bueno de este encoder es que puede utilizarse en cualquier transporte. Lo malo es que no hay interoperabilidad

WS-Compression

Tengo que reconocer que no se exactamente donde surge esta especificación pero se que la primera mención de la misma se de en el proyecto PlumbOrange de Christian Weyer y cia y que fue implementado por gente de Lagash (Rodolfo y Pablo) para las distintas versiones de Web Services Enhancements y siendo la última disponible la creada para WCF RC1 por Pablo.

Bueno, esta es una especificación que siguiendo el ejemplo de XML Encryption reemplaza el contenido de un infoset XML con un elemento que contiene el binario (en base64) que cooresponde a la versión compresa. Y luego modifica el infoset para incluir información de referencia para descomprimir el elemento.

Este mecanismo tiene la ventaja de que puede ser más interoperable que la doble codificación y la codificación binaria, pero tiene la deventaja que al ser el resultado aún un documento XML no se obtiene el mejor resultado de compresión.

Conclusión

De las alternativas mencionadas casi todas ya están disponibles en WCF y/o WSE por lo cual es recomendable que se evalúe cuando puede ser beneficioso implementar estos mecanismos.

los lenguajes pasan, la lógica se mantiene

2006-09-18T21:52:00.000-04:00

Robo un tiempo a la escritura de la segunda parte de serviciosy compresión para comentar en los lenguajes de programación. Esto surge porque el día de hoy recibi uchos mensajes relacionados con lenguajes, primero el anuncio de que las presentaciones de Lang.NET estan disponibles. Luego me envían el link de un artículo en el que se recomiendan los lenguajes de programación que uno debe aprender para estar a la par del mercado (el orden sigue sin convencerme pero los lenguajes me parece que son los encaminados) y finalmente leo varios comentarios respecto a IronPython.

En fin si analizo cada tema por separado cada uno me trae muchas ideas y en este momento solo comentare algunas:

Lang.NET: Cuando uno lee el temario de este simposio queda claro que hay mucho trabajo alrededor de los lenguajes dinámicos, Aún recuerdo que en mis primeras interacciones con JavaScript lo que más me atrajo del lenguaje fueron las características que lo hacen dinámico y con el tiempo descubrí muchas ventajas y llegué a establecer cariño con algunos lenguajes dinámicos. La principal ventaja de este tipo de lenguajes radica en la extensibilidad y capacidad de adaptación que brindan estos lenguajes a sus soluciones. Por ejemplo permiten que interfaces gráficas sean fáciles de crear y embeber en soluciones empaquetadas, otro ejemplo es la generación de objetos totalmente consistentes sobre la marcha (para ejemplo basta un botón TurboGears o Ruby on Rails.
Sin embargo también hay que recordar que los lenguajes adolecen de una gran contra que es el impacto en rendimiento tipicamente los lenguajes dinámicos son interpretados y debido a que son dinámicos se hace un manejo muy complejo de las declaraciones y tipos.
Bueno creo que hablaré más de esto en el punto 3, pero sigo con el simposio. Más allá de los lenguajes dinámicos es interesante ver como el CLI se vuelve objeto de todos tipo de lenguajes funcionales, dinámicos, etc. y ver que los distintos esfuerzos alrededor están demostrando que es una plataforma viable para realizar implementaciones optimizadas.
Creo que es importante que los equipos de desarrollo involucrados con el CLI (en Microsoft y en Mono) empiecen a considerar algunas mejoras que surjan como recomendación de estas iniciativas y aseguren que la implementación de estas esten disponibles para todos los lenguajes generando una plataforma común y evitando que se dupliquen esfuerzos. Y si se puede finalmente incluirlo en el CLI. Hay que entender que muchos requerimientos de otros lenguajes pueden afectarse entre sí y allí es donde nosotros los mortales confiaremos en la sapiencia de los gurús.

Los lengaujes a aprender: Hace unos 8 años cualquiera que salía de la universidad había escuchado al menos una vez de Delphi y lo importante que era aprenderlo, es más yo era uno de sus defensores (lo que no quita que también usara Visual Basic). Y hoy no existe ninguna variante o descendiente que haya logrado ingresar en el top ten de e-Week. Personalmente creo que un programador debe poder adecuarse a cualquier sintaxis, pero también creo que no cualquier sintaxis se adecúa a cualquier problema. Por ello es muy importante que un buen programador conozca al menos 3 lenguajes de desarrollo, y en el caso de un arquitecto ... bueno un arquitecto tiene tiempo para leer mucho, ¿verdad?.
Así que empecemos a hacer una revisión de como estoy yo con respecto a la lista:

Lenguaje	Lectura	Escritura
PHP	Media	Básica, ha pasado mucho tiempo
C#	OK	OK
AJAX	OK	OK
JavaScript/ECMAScript	OK	OK
Perl	Básica casi :S	:S
C	OK	Basica - Media
Ruby	Básica	Básica, muy básica
Java	Media	:S
Python	OK	Media - OK
VB.Net	OK	Media -OK

Primero tengo que aclarar mi escala: OK significa que siento que puedo leer/escribir una aplicación completa sin mayores sobresaltos, Media significa que podría leer/escribir una aplicación con algunas consultas a fuentes de documentación del lenguaje, Básica es mi entendido de que puedo darme una idea pero requiero de actualizar mis conocimientos o de tener la referencia del lenguaje a mi lado y finalmente :S significa que tendría que pedir ayuda a alguien que si sepa.
No esta mal, solo tengo dos en los que no podría escribir código y en ambos casos es un tema de afinidad con el lenguaje, en este punto tengo que aclarar que nunca me han gustado ni Perl, ni Java ni su sintaxis. Es cierto que he escrito código en Java pero no fue una sensación agradable.
Si ya se que me dirán si escribo ECMAScript y C# no debería tener problema con Java, pero esa no es la verdad.
En fin, creo que es importante revisar al menos 5 de estos lenguajes y tenerlos en un nivel medio o superior para lectura y al menos 3 en medio o superior para escritura. Para cerrar quiero decir que en la lista falta una variante de lenguaje que para mi esta dando y dará mucho que hablar y que toca varios puntos importantes de la lista: IronPython y con esto paso al punto 3.

IronPython Como habrán visto de mi lista anterior Python es un lenguaje con el que me siente comodo, esto viene de hace unos años cuando necesitando una aplicación que permitiera que una aplicación cualquiera se coenctara a un sitio que autenticaba con NTLM y encontré NTLMAPS viendo la aplicación encontré muchas cosas de Python que nunca habia visto así que me involucre y estuve mucho tiempo jugando con Python y llegó a posicionarse como uno de mis lenguajes favoritos.
Luego por razones de falta de tiempo deje de verlo y hace dos años o poco más vi en listas que había algo llamado IronPython que era un compilador de Python para .Net al ver el sitio de proyecto quede encantado porque Jim no solo estaba portando Python, sino creando un derivado que le permitiera utilizar las ventajas de Python y las ventajas de .Net.
Durante mucho tiempo seguí el proyecto, me alegré cuando me enteré que Jim ingresaa a Microsoft y mucho más cuando supe que IronPython contaría con el apoyo de Microsoft. Bueno con esos antecedentes les contaré que hace un par de semanas Jim Hugunin anunció en su blog la liberación de la versión 1.0 de IronPython y no tarde en descargarlo. La verdad me parece un gran trabajo y el hecho de que pueda pasar un 90% de las pruebas de la libreria estándar de Python es áun más sorprendente (el 10% que falta utiliza extensiones compiladas en C so..).
Bueno desde la liberación estuve haciendo un par de cosas y la verdad me encanta IronPython. Me queda pendiente probar el add-in para visual studio pero Python es un lenguaje para trabajar en archivos y consola :)

Para finalizar este post que se extendió un poco solo quiero recalcar que si bien como desarrolladores podemos comulgar con un lenguaje u otro y que gracias a los servicios podemos comunicarnos facilmente con soluciones en otros lenguajes, no debemos olvidar que en un mundo de desarrolladores libres siempre habrán otros lenguajes y que cada uno tendrá un lugar para ser y crecer (yo creo que ya veremos algún lenguaje tipo pascal darnos una sorpresa).
Los lenguajes van y vienen pero mientras tu lógica, deseos de aprender y capacidad de análisis se desarrollen puedes estar seguro que siempre habrá uno que te satisfaga.

Presentaciones Lang.NET

2006-09-18T11:34:00.000-04:00

Para los que no saben Lang.Net es un simposio que se llevo a cabo en Redmond a fines de Julio. Las sesiones están orientadas exclusivamente a tem[as como ser compiladores, CLI, virtual machines, lenguajes. En fin sesiones de bajo nivel pero definitivamente muy interesantes. Recientemente se publicaron en video las presentaciones así que para quienes esten interesados este es el link

http://www.langnetsymposium.com/speakers.asp

Compresión y servicios (Parte 1)

2006-09-16T11:18:00.000-04:00

Una de las principales dudas que tuvimos todos cuando SOAP y todos sus parientes hicieron aparición en escena fue el impacto en el rendimiento de estos protocolos tan pesados, XML era basicamente un formato de serialización muy chatty y no se comparaba con serializaciones binarias altamente optimizadas que utilizaban los protocolos de objetos distrbuidos (DCOM, CORBA).

Con el tiempo y entendiendo los conceptos que hoy conforman SOA se entendió que esto no impactaría tanto como se esperaba por el cambio en la programación de interfaces y contratos.

Sin embargo esto no quita que aún así XML sea una serialización muy cara, si hablamos de una red corporativa con LAN de 100 Mbps es manejable pero cuando se empiezan a construir soluciones que se se ejecutarán en enlaces bajos (dial-up, satelital, etc) y es en este punto donde mucha discusión se ha dado en el uso de compresión para la comunicación con servicios.

Si consideramos que las respuestas grandes de servicios serializados en XML son documentos con un conjunto de registros similares cualquier algoritmo de compresión puede hacer un muy buen trabajo para disminuir el tamaño de un archivo. Tomemos por ejemplo un servicio de búsqueda que devuelve un documento con los resultados de búsqueda. La estructura del mensaje sería la siguiente.

<resultados registros="100" inicio="0" total="1054">
<resultado>
<Titulo>Sitio 1</Titulo>
<Descripcion>Breve descripción del sitio</Descripcion>
<Url>http://sitio/</Url>
</resultado>
...
<resultado>
<Titulo>Sitio 100</Titulo>
<Descripcion>Breve descripción del sitio</Descripcion>
<Url>http://sitio34131</Url>
</resultado>
</resultados>

En este caso al existir tanto texto similar el grado de compresión puede ser muy alto, por ejemplo un archivo XML de 1.5 MB utilizando gzip como algoritmo de compresión (RFC 1952) se convierte en 120 KB es decir un 8% del archivo original. Es cierto que el archivo que utilice como ejemplo tiene otros textos repetidos pero sirve como referencia.

Obviamente nunca deberíamos retornar 1.5 MB como resultado de un servicio pero tomando la estructura de ejemplo al retornar 100 registros tenemos un archivo de 13750 bytes. la transmisión de este resultado a través de una linea de 56Kbps( aproximadamente 7KBps) sería de 1.91 segundos (tiempo ideal sin ruido y confiabilidad de 100%). Si se que suena a que no es nada pero siguamos analizando. Si este mismo archivo lo comprimimos con gzip nivel 3 se convierten en 327 bytes con un tiempo ideal de 0.04 segundos. SI se considera que este tiempo es uso de ancho de banda y red esto podría significar atender a unos cuantos cientos de usuarios más con el mismo ancho de banda.

Como siempre no todo puede ser miel y en este caso el costo es un tiempo adicional para la compresión, el uso de procesador y memoria del servidor. entonces el tiempo adicional de proceso debe sumarse para ver cual sería el tiempo real de proceso.

En nuestro caso el tiempo de compresión es de no más de 10 milisegundos (utilizando la clase GZipStream del .Net Framework 2.0), si sumamos este tiempo al tiempo de transmisión tenemos un total 0.05 segundos lo cual es aún un muy buen resultado.

Otro aspecto a considerar es el uso de procesador, tipicamente todos los algoritmos de compresión tienen niveles que permiten definir la carga en procesador y memoria de la tarea de compresión. En el ejemplo se ha utilizado gzip nivel 3 (el que provee el framework) que no tiene impacto mayor al de un proceso de servicio por lo cual es una extensión solo en tiempo

El último aspecto es el uso de memoria, dado que la mayoría de las especificaciones WS-* requieren el Infoset de respuesta completo para su proceso actualmente casi todas las soluciones de publicación y consumo de servicios manejan los mensajes en buffer por lo que el consumo de memoria adicional es el relacionado al tamaño de la versión compresa de los datos. De nuevo en nuestro ejemplo es un 2%. Este dato no es despreciable en servidores de muy alto uso porque puede llegar a convertirse en punto de contención.

Con todo lo anteriormente dicho cual sería el criterio para decidir si utilizar compresión en la publicación de servicios:

1. Si se conoce que los clientes disponen de bajo ancho de banda y el nivel de concurrencia no estima que la memoria de servidor sea saturada es recomendado utilizar compresión, el nivel de compresión será determinado por la capacidad de procesador del servidor.

2. Si en cambio tenemos mucha concurrencia y anchos de banda aceptables es mejor no utilizar mecanismos de compresión de datos.

Con este pseudo-análisis (si ya se que tiene muchos vacios y que no puede llamarse un análisis serio) veamos cuales son las alternativas que se han manejado para la compresión de datos en servicios.

Nueva distribución de contenido

2006-09-12T19:24:00.000-04:00

Como mencioné en un post anterior ya tengo dos blogs es por eso que he tomado la decisión de utilizar cada uno de ellos para un fin distinto, el Space de Live seguirá siendo el lugar donde ponga mis pensamientos, divagues, cuando sea que ellos desean llegar, y comentarios de indole familiar y de amistad.

El relativamente simple de blogger en cambio lo utilizaré para publicar datos y comunicación de orden laboral y técnico. De esta manera cada quien podrá visitar o suscribirse al contenido que desee.

Solo por si alguien se lo preguntaba el sitio técnico estará en castellano y estará abierto a que puedan enviarme preguntas para que en aquellos casos que pueda ayudar así lo haga.

Obviamente esto no significa que estaré escribiendo más a menudo pero es solo una decisión tomada hoy.

No todo en los iPod es color de rosa

2006-09-07T23:04:00.000-04:00

Dejenme empezar diciendo que hasta el día de hoy habia tenido la mejor de las experiencias con mi iPod. Tengo un iPod Nano de 4GB en el que tengo casi toda la música que poseo (obviamente mi colección de CDs es algo limitada)

En fin, el día de hoy cuando me disponía a ir a una reunión prendí mi IPod y me vi con la maravillosa pantalla de diagnóstico. "Bueno", me dije, "sin duda hice reset sin querer" (es raro desbloquear, bloquear y presionar acción y menu por 6 segundos sin querer y luego presionar acción y prev otros seis, pero...) es así que por los próximos 40 minutos corri una variedad de pruebas en las que afortunadamente mi iPod aprobó.

El último punto Reset. Bueno llegando a casa lo sincronizo de nuevo. Y así paso el resto del día. Sin embargo llegue a casa y cuando conecto el iPod solo obtengo el nefasto

Para los que no conocen la simbología de los IPod esto significa que necesitas reinicializar tu IPod. Bueno habramos iTunes

:S ¿qué no esta conectado mi iPod?
Si tu lo dices... probemos con el iPod Updater
"Can't mount iPod" (perdón pero no estaba de humor para sacar copia de las ventanas)

Bueno, veamos que nos dice el sitio de Apple... reintente con ITunes, Updater, yadda, yadda, yadda. Ah, pruebe moviendose a disk mode

Probemos... nop sigo viendo el condenado folder y aunque esta vez el iPod Updater se bloquea

Revisemos otros pasos, y encontre este artículo iPod shows up in Windows but not in iTumes.

Es decir que tengo que eliminar todo y reinstalar, bueno vamos por ello y para estar seguros descargo de nuevo iTunes y el iPod Updater. Finalizado, llego el momento cumbre conecto de nuevo mi iPod y ... nada "can't mount ipod"

Me estoy preocupando, ¿y si corro de nuevo el diagnóstico? aqui voy bloquear, desbloquear, presionar acción y menu por 6 segundos, presionar acción y prev otros seis si ya estoy en el menu corramos el diagnostico de scan (prueba del disco)..... Como diría mi amiga Paula ¡rayos!

Este icono significa que el sistema de iPod no pudo recuperar datos del disco duro, la documentación dice que si no puedo llevarlo a disk mode esto es historia. Cruzo los dedos y hago todos los pasos Check estoy en disk mode fiu....

Esperen iPod Updater lo detecto y pudo montarlo, Restore si... esta restaurado. En este momento estoy sincronizando de nuevo toda mi música pero esta vivo. Todo producto de software es susceptible a este azares.

Contigo Avanzar en Santa Cruz

2006-09-06T13:54:00.000-04:00

Bueno esa era la idea pero debido al problema del paro civico es probable que hayan cambios en las fechas. El día viernes estaba planificada la realización de la jornada de trabajo, sin embargo con el paro convocado esta en duda y no se exactamente cuando se realizaría.

El concierto sería el sábado 9 de septiembre a partir de las 19:00 en la casa de la cultura. Esta vez son cuatro los participantes:

Como siempre la entrada será libre así que estan todos invitados

Inicio en Blogger

2006-09-06T13:32:00.000-04:00

Por un proyecto que en un futuro próximo espero se de a conocer (proyecto.. bueno una idea) es necesario que habilite una cuenta en blogger por ello hoy debuta http://relativamentesimple.blogspot.com . Esto no significa que dejare de user mi space en Live, esta cuenta es complementaria y esta versión del blog será una replica de la que se encuentre en spaces.

Si ya se que no he escrito mucho pero espero que esto cambie en el curso de la próxima semana.