Por desgracia, este trabajo siempre suele dejarse para el final, cuando todo el trabajo ya esta hecho y estamos al horno con la entrega por lo que cualquier cambio impacta mucho! Asique manos a la obra..

Lo primero que necesitamos es un ambiente aislado para realizar las mediciones, si es posible contar con un ambiente similar al que se contará para desplegar la aplicación mucho mejor.. y sino por lo menos contar con las mismas versiones de sistema operativo, base de datos, servidor web, etc..

También necesitaremos algunas herramientas para realizar las mediciones y poder obtener un diagnostico mas preciso sobre dónde se encuentra el problema. Algunas de las que me resultaron muy utiles son:

• Drone Profiler http://www.droneprofiler.com/index.aspx (Excelente profiler para el lado servidor que cuenta con una versión free para uso personal).
• DynaTrace AJAX Edition http://ajax.dynatrace.com/ajax/en/ (Otro excelente profiler pero esta vez para el lado cliente. Se integra con FireFox y con el innombrable cuyas iniciales son dos vocales que no son A, O, U..también es free.
• Existen otras herramientas como YSlow, FireBug, Fiddler, HttpFox, etc. que también nos pueden ser útiles.
• Y por ultimo, SQL Profiler por si alguno se anima a revisar la base de datos

Ok, y ahora ¿¿¡por donde empiezo!??

Les cuento mi experiencia con una pagina de consulta que me tocó optimizar. Dicha consulta tardaba unos 19 segundos en mostrar los resultados (10 registros). Cabe destacar que por cada uno de esos 10 registros debía validar una buena cantidad de lógica de negocio para mostrar u ocultar unos checkboxes.

Lo primero que hice fue abrir DynaTrace y ejecutar una sola vez la consulta. De los resultados obtuve que de esos 19 segundos, 14 los perdía en el servidor (llamada al WebMethod que cargaba la grilla por AJAX) y el resto en el cliente (JavaScript/jQuery no optimizado), por lo que el problema evidentemente estaba en el servidor.

Teniendo esta información cerré el DynaTrace y abrí el Drone Profiler, repitiendo la misma prueba: ejecutar una vez la consulta. Con eso logré identificar cuales métodos tardaban mas tiempo en ejecutarse.. la mayoría eran métodos de la capa de acceso a datos (basada en Entity Framework)..con SQL Profiler descarté que el problema fuese la consulta, por lo que definitivamente logré aislar el problema con Entity Framework que tardaba demasiado tiempo en generar las consultas SQL.. luego con la ayuda de Google encontré varias optimizaciones que fui probando hasta lograr un tiempo aceptable. También refactoricé un par de métodos para leer una sola vez las 10 entidades en vez de leerlas una por una.. eso también ayudó..

Luego de todas estas optimizaciones, el tiempo de la consulta bajó a un mínimo de 2,9 segundos, cifra que no pude bajar sin tener que refactorizar mas agresivamente el código..

Como verán, no hay una única forma de encarar esta problemática.. se trata de realizar un primer diagnóstico para ver donde puede estar el cuello de botella (si esta en el lado cliente, si esta en el servidor, o si es la base de datos).. luego investigar mas de cerca el código, ver si existe alguna optimización, o bien si amerita una refactorización completa.. muchas veces el código mas compacto y reutilizable no es el que mejor performa..

Algunos consejos rápidos para optimizar los tiempos de carga de la página:

• Compresión en IIS
• Cache para almacenar listas que rara vez cambian (productos, paises, provincias, etc.)
• Minificar y combinar JavaScript/CSS
• Compilar en modo Release al desplegar en un ambiente productivo
• Desactivar el ViewState para controles que no lo necesitan
• Usar con cuidado los selectores de jQuery
• No abusar de $(document).ready() y usar $(window).load()

Por ultimo, les dejo algunos enlaces que encontré sobre optimizaciones..

http://www.asp.net/web-forms/tutorials/continuing-with-ef/maximizing-performance-with-the-entity-framework-in-an-asp-net-web-application

http://blog.dynatrace.com/2009/11/09/101-on-jquery-selector-performance/?source=dae30

http://www.artzstudio.com/2009/04/jquery-performance-rules/

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true

Espero que les haya resultado útil!

Saludos y felices fiestas!!!

Hoy vamos a hablar un poco sobre el mundo de los Generics. Vamos derecho al código…

Supongamos que necesitamos un método que devuelve un objeto Persona:

public Persona GetPersonaByID(int idPersona)
{
     var persona = new Persona();
     // Aquí va el codigo para armar el objeto
     return persona;
}

Para llamar a este método lo hacemos de la forma:

Persona objeto = GetPersonaByID(5);

Hasta aquí ninguna novedad. Ahora bien, supongamos que queremos hacer que el mismo método trabaje con cualquier tipo de objetos:

//T: parámetro de tipo
public T GetEntityByID<T>(int idEntity)
{
    // Aquí va el código para armar el objeto. Veremos mas adelante qué necesitamos
    // para instanciar un objeto T
    // ahora se complica un poco mas porque no sabemos bien que tipo de objetos es T
    return entity;
}

Y ahora cuando llamamos a este método le vamos a indicar con qué tipo de objetos tiene que operar:

Persona p = GetEntityByID<Persona>(5);
Ticket t = GetEntityByID<Ticket>(8);
Auto a = GetEntityByID<Auto>(19);

Entonces, qué fue lo que paso!? Cuando le pasamos el parámetro de tipo al objeto le estamos indicando con qué tipo de objetos tiene que trabajar, y a ese parámetro de tipo lo podemos usar para instanciar clases, para indicar qué tipo de objeto devuelve el método, para pasarlo como parámetro a otras clases, etc…

En el ejemplo de arriba, el método GetEntityByID<Persona>(5); me devuelve un objeto Persona y no un object.

El mejor ejemplo que vimos de esto aplicado en la realidad es el List. Cuando nosotros hicimos:

List<Persona> lista = new List<Persona>();
lista.Add(persona1);

Lo que puede estar pasando en el framework debe ser algo como esto:

public class List<T>
{
     private System.Array list;  //Array interno que puede contener cualquier tipo de objetos

     //Constructor
     public List<T>()
     { 
     }

     public void Add(T objeto)
     {
           list.Add(objeto);
     }
}

Constraints

Ahora bien, puede ser que querramos restringir que tipos de objetos queremos que puedan usar esos métodos, sobre todo cuando vamos a llamar a determinados métodos y querémos estar seguros de que los métodos esten ahi!. Para ello tenemos los constraints que se aplican con la palabra where:

public T GetEntityByID<T>(int idObjeto) where T: EntidadBase, IOperaciones, new()
{

}

Con esto queremos decir que T tiene que heredar de EntidadBase, implementar la interface IOperaciones y tener un constructor sin parámetros. De lo contrario dará un error en tiempo de compilación.

Entonces ahora podemos estar seguros de realizar determinadas operaciones como por ejemplo:

public T GetEntityByID<T, D>(int idObjeto) where T: IOperaciones, where D: DataAccessLayer<T>, new()
{
    var objectDAL= new D<T>();  // D tiene el constraint de new()
    var object= Read(idObjeto);
    bool isEmpty = obj.IsEmpty();
    return object;
}

Ya la vamos complicando un poco mas lo que hicimos ahí fue pasarle dos parametros de tipo, T para indicar con qué tipo de entidades trabaja y D para indicarle con que tipo de DataAccessLayer.

Entonces para usar ese método tendremos que hacerlo de la siguiente manera:

Persona p = GetObjectByID<Persona, PersonaDAL>(7);

Como verán, las posibilidades son infinitas. Espero que les sirva!!

Saludos!!

Esto es Java usando la librería gráfica SWT. Lindo, ¿no?.

Que se vea nativo en Linux, Mac OSX y Windows es kinda priceless.

No recuerdo de donde tomé la mala costumbre, pero lo que venía haciendo hasta ahora era:

try
{
    // Algo de código
}
catch (Exception ex)
{
    // Hago algo con ex
    throw ex;
}

Resulta que al hacer esto no estamos relanzando la excepción original, estamos iniciando un nuevo camino para la excepción usando la misma instancia de ex.

Para solucionarlo, es decir, no perder el stack trace debemos modificar el código para que quede así:

try
{
    // Algo de código
}
catch (Exception ex)
{
    // Hago algo con ex
    throw;
}

¿Soy el único pavote que lo hacía mal?

Quiero creer que no

Como siempre, vamos a empezar por lo más básico.

¿Qué es UDP?

Es un protocolo a nivel de transporte (capa 4 del modelo OSI) basado en el intercambio de datagramas. Se puede decir que no es un protocolo orientado a la conexión, a diferencia del otro hiper-archi-conocido protocolo TCP que si lo es. Las siglas vienen del inglés: User Datagram Protocol.

Lo bueno de este protocolo, que también trae ciertas desventajas, es que proporciona una forma simple para que las aplicaciones envíen datagramas IP encapsulados sin tener que establecer una conexión. Si, leyeron bien, no hace falta establecer una conexión, cada datagrama tiene información suficiente para llegar a destino. UDP transmite segmentos que consisten en un encabezado seguido por la carga útil; cuenta además (aunque es opcional) con un checksum o suma de verificación, esto permite comprobar la integridad de los datos transferidos.

Todo esta muy lindo hasta acá, pero ahora les voy a tener que pinchar el globo.

Algunas desventajas del protocolo UDP

• Volviendo al título elegido para este artículo podríamos decir que, al igual que en las batallas no todo lo que enviamos necesariamente llegara a destino. UDP no cuenta con un mecanismo de control de envíos, por lo que si no hacemos nada por nuestra cuenta podemos perder paquetes y nada nos va a alertar de ello, ni tampoco tratará de reenviarlos.
• UDP también carece de control de flujo, o mejor dicho, no nos asegura que el orden en que enviamos los paquetes va a ser el mismo en el que se recibirán.

Volviendo al tema de programación, .Net nos ofrece la opción de trabajar con Sockets directamente o a través de clases de ayuda (que simplifican bastante el trabajo), como ser UdpClient.

Voy a mostrarles utilizando ejemplos de código dos pequeños programas, uno se encarga solamente de enviar y el otro solamente de recibir. Es la forma más básica que encontré y creo que así va a ser más fácil verlo (el emisor y receptor podrían estar en el mismo programa).

El código

Vamos a usar una clase serializable a la que llamaremos Paquete. Instancias de este objeto es lo que vamos a enviar y recibir sobre el protocolo UDP.

Paquete.cs

using System;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;

[Serializable]
public class Paquete
{
    public Int32 Orden { get; set; }
    public String Mensaje { get; set; }

    public static byte[] Serializar(Paquete paquete)
    {
        using (MemoryStream memStream = new MemoryStream())
        {
            BinaryFormatter binFormatter = new BinaryFormatter();
            binFormatter.Serialize(memStream, paquete);

            return memStream.ToArray();
        }
    }

    public static Paquete Deserializar(byte[] paqueteEnBytes)
    {
        try
        {
            using (MemoryStream memStream = new MemoryStream(paqueteEnBytes))
            {
                BinaryFormatter binFormatter = new BinaryFormatter();
                memStream.Position = 0;

                return (Paquete)binFormatter.Deserialize(memStream);
            }
        }
        catch
        {
            return null;
        }
    }
}

Hasta acá no hay nada nuevo. Tenemos una clase con dos propiedades públicas, una de las cuales es un entero (orden) y la otra una cadena de caracteres (mensaje). También tenemos dos métodos estático (asi podemos llamarlos sin necesidad de referenciar una instancia de la clase) para serializar y deserializar.

Marcamos la clase como [Serializable] para que la podamos convertir a un arreglo de bytes con los métodos que mencione anteriormente. Vale la pena aclarar que todos los métodos que manejan sockets en .net, envian y reciben arreglos de bytes, por eso es tan importante la serialización en esto.

Ahora veamos el código para enviar un paquete:

EmisorUDP.cs

using System;
using System.Net;
using System.Net.Sockets;

class EmisorUDP
{
    static void Main(string[] args)
    {
        using (UdpClient cliente = new UdpClient())
        {
            byte[] bytesParaEnviar;
            String strPaquete = String.Empty;
            int contador = 0;

            while (true)
            {
                Console.Write("Escribe un mensaje y luego presiona [enter]: ");
                strPaquete = Console.ReadLine();

                if (String.IsNullOrEmpty(strPaquete))
                    return;

                Paquete paquete = new Paquete()
                {
                    Orden = contador,
                    Mensaje = strPaquete
                };

                bytesParaEnviar = Paquete.Serializar(paquete);
                cliente.Send(bytesParaEnviar, bytesParaEnviar.Length, new IPEndPoint(IPAddress.Broadcast, 9998));

                contador++;
            }
        }
    }
}

Bastante descriptivo en si, pero vamos a explicar un poco. Dentro de un ciclo while pedimos al usuario que ingrese un mensaje para enviar, si no escribe nada y solo presiona la tecla enter, entonces salimos del programa.

Si el usuario escribió algo lo guardamos en una nueva instancia de Paquete y además asignamos el número del mensaje (tomado desde el contador). Para poder enviar este paquete vamos a tener que, primero, obtener la representación en bytes y, segundo, especificar un destino. Para cumplir con lo primero serializamos la instancia que acabamos de crear; para lo segundo vamos a optar por enviar un mensaje del tipo broadcast en el puerto 9998, es decir, es un paquete que se va a enviar a todos los dispositivos de nuestra red.

Como ya dije antes, este proceso se va a repetir hasta que no se ingrese ningún caracter más, solo la tecla enter.

ReceptorUDP.cs

using System;
using System.Net;
using System.Net.Sockets;

class ReceptorUDP
{
    static void Main(string[] args)
    {
        using (UdpClient cliente = new UdpClient(9998))
        {
            while (true)
            {
                IPEndPoint emisor = null;
                byte[] bytesRecibidos = cliente.Receive(ref emisor);
                Paquete paquete = Paquete.Deserializar(bytesRecibidos);

                Console.WriteLine("Paquete enviado por {0}:", emisor);
                Console.WriteLine("-- Orden: {0}", paquete.Orden);
                Console.WriteLine("-- Mensaje: {0}", paquete.Mensaje);
            }
        }
    }
}

En el receptor tenemos que registrar el puerto en el que vamos a escuchar, en este caso es el 9998 (el que usamos al enviar), tarea que podemos realizar pasando el número de puerto en el constructor de UdpClient.

Notese que necesitaremos crear un objeto de la clase IPEndPoint para pasarlo por referencia, como parametro, al método Receive de UdpClient. Éste último se encargara de guardar ahí la información del emisor (como ser la dirección IP y el puerto remoto).

Otra cosa importante, tanto UdpClient.Send como UdpClient.Receive son métodos sincronicos, es decir, se van a bloquear hasta que envíen o reciban un paquete. Cuando empiecen a trabajar “en serio” con UDP (o TCP) van a tener que usar Threads (Hilos) independientes para no congelar la interfaz del usuario o probar con los métodos asíncronos tales como UdpClient.BeginSend, UdpClient.BeginReceive.

Volviendo al código de ejemplo, una vez que recibimos un paquete (en realidad, la representación en un arreglo de bytes) vamos a poder deserializarlo para finalmente acceder a las propiedades Orden y Mensaje; imprimimos en pantalla esos datos y esperamos el siguiente paquete.

Recuerden las desventajas de las que hablamos, UDP no nos asegura que todo lo enviado sea recibido, ni que esten en el orden correcto.

Si todo ha salido bien, deberían ver algo así:

Bueno, esto es todo por ahora, en el próximo artículo vamos a hacer lo mismo pero utilizando el protocolo TCP.

Volviendo al tema en sí, como ustedes saben, al disparar un evento en nuestra aplicación debemos primero comprobar que no sea null, lo cual indica que no hay ningún suscriptor para ese evento en particular. En caso de no realizar ésta comprobación, no podríamos disparar el evento sin luego recibir una excepción del tipo System.NullReferenceException.

Una forma alternativa que plantearon en StackOverflow, consiste en simplemente asignarle un delegado anónimo vacío al evento en el momento de su creación.

¿Cómo se hace?

Así:

public event EventHandler NombreDeNuestroEvento = delegate {};

¿Hay alguna contraindicación?

Aparentemente el costo, en performance, es muy pequeño … demasiado pequeño, a menos que estén realizando un sistema crítico que hace una utilización realmente importante de eventos. Hay una prueba de performance que pueden hacer para ver efectivamente el costo de utilizar un delegado anónimo vacío.

using System;
using System.Diagnostics;

class Program
{
    public event EventHandler<EventArgs> EventWithDelegate = delegate { };
    public event EventHandler<EventArgs> EventWithoutDelegate;

    static void Main(string[] args)
    {
        //warm up
        new Program().DoTimings(false);
        //do it for real
        new Program().DoTimings(true);

        Console.WriteLine("Done");
        Console.ReadKey();
    }

    private void DoTimings(bool output)
    {
        const int iterations = 50000000;

        if (output)
        {
            Console.WriteLine("For {0} iterations . . .", iterations);
        }

        //with anonymous delegate attached to avoid null checks
        var stopWatch = Stopwatch.StartNew();

        for (var i = 0; i < iterations; ++i)
        {
            RaiseWithAnonDelegate();
        }

        stopWatch.Stop();

        if (output)
        {
            Console.WriteLine("No null check (empty delegate attached): {0}ms", stopWatch.ElapsedMilliseconds);
        }

        //without any delegates attached (null check required)
        stopWatch = Stopwatch.StartNew();

        for (var i = 0; i < iterations; ++i)
        {
            RaiseWithoutAnonDelegate();
        }

        stopWatch.Stop();

        if (output)
        {
            Console.WriteLine("With null check (no delegates attached): {0}ms", stopWatch.ElapsedMilliseconds);
        }

        //attach delegate
        EventWithoutDelegate += delegate { };

        //with delegate attached (null check still performed)
        stopWatch = Stopwatch.StartNew();

        for (var i = 0; i < iterations; ++i)
        {
            RaiseWithoutAnonDelegate();
        }

        stopWatch.Stop();

        if (output)
        {
            Console.WriteLine("With null check (with delegate attached): {0}ms", stopWatch.ElapsedMilliseconds);
        }
    }

    private void RaiseWithAnonDelegate()
    {
        EventWithDelegate(this, EventArgs.Empty);
    }

    private void RaiseWithoutAnonDelegate()
    {
        var handler = EventWithoutDelegate;

        if (handler != null)
        {
            handler(this, EventArgs.Empty);
        }
    }
}

Quedará en ustedes decidir si vale la pena o no utilizar este método. La diferencia es infinitesimal, unos pocos nanosegundos no van a matar a nadie … quiero creer.
Interesante, ¿no les parece?.

Hasta la próxima.

Generalmente cuando empezamos a programar aplicaciones que deben interactuar remotamente con otras (o con ella misma) es ahí cuando deberemos invertir unos minutos en comprender este concepto, muy importante por cierto y de extrema utilidad.

Veamos que dice la Wikipedia sobre serialización:

En ciencias de la computación, la serialización (o marshalling en inglés) consiste en un proceso de codificación de un Objeto (programación orientada a objetos) en un medio de almacenamiento (como puede ser un archivo, o un buffer de memoria) con el fin de transmitirlo a través de una conexión en red como una serie de bytes o en un formato humanamente más legible como XML o JSON, entre otros. La serie de bytes o el formato pueden ser usados para crear un nuevo objeto que es idéntico en todo al original, incluido su estado interno (por tanto, el nuevo objeto es un clon del original). La serialización es un mecanismo ampliamente usado para transportar objetos a través de una red, para hacer persistente un objeto en un archivo o base de datos, o para distribuir objetos idénticos a varias aplicaciones o localizaciones.

Bien, entonces es básicamente un mecanismo que nos permite representar un objeto como un arreglo de bytes. Por simple deducción, la deserialización es el proceso inverso, convertir un arreglo de bytes en un objeto.

¿Cuales son las ventajas del proceso de serialización?

Los datos serializados son fáciles de representar, transportar y almacenar. En .Net tenemos el tipo de datos byte, así como también podemos crear arreglos de ellos: byte[]. La mayoría, si no todos, los métodos para transmisión y recepción de datos tanto en Sockets como clases que simplifican un poco el trabajo (TcpClient) en red, envían y reciben arreglos de bytes. Podemos decir lo mismo con los métodos de almacenamiento de datos, el manejo de bytes es la forma más directa.

Para entender un poco más lo que hemos dicho hasta ahora, veamos un ejemplo:

public static byte[] Serialize(object objToSerialize)
{
    using (MemoryStream memStream = new MemoryStream())
    {
        BinaryFormatter binFormatter = new BinaryFormatter();
        binFormatter.Serialize(memStream, objToSerialize);

        return memStream.ToArray();
    }
}

¿Se nota? Es realmente fácil serializar objetos en .Net.
Para realizar el camino inverso, es decir, deserializar un objeto:

public static object Deserialize(byte[] objToDeserialize)
{
    using (MemoryStream memStream = new MemoryStream(objToDeserialize))
    {
        BinaryFormatter binFormatter = new BinaryFormatter();
        memStream.Position = 0;

        return binFormatter.Deserialize(memStream);
    }
}

Casi me olvido, para poder serializar una clase debemos marcarla con el atributo [Serializable], el cual no se puede heredar.

Más adelante veremos como enviar y recibir objetos serializados sobre internet (o una LAN).

Cuando empezamos con Matías, jamas nos imaginamos que ibamos a lograr algo así! Si bien pueden parecer pocas comparado con otros blogs mucho mas grosos, para nosotros es todo un logro! Y todo gracias a ustedes!

Esperamos seguir creciendo! Vamos a ver si llegamos a las 20.000! trataremos de seguir posteando cosas interesantes y de servirles de ayuda!

Un abrazo a todos!

The version of SQL Server in use does not support datatype ‘datetime2′.

Googleando un poco encontré el siguiente artículo el cual voy a resumir y traducir:

Éste error se produce cuando generamos el Modelo a partir de SQL 2008 y luego utilizamos SQL 2005… es decir, Visual Studio genera el modelo por única vez basándose en los tipos de datos de SQL 2008 (que incorpora date y datetime2). Al cambiar el conection string de la conexión a SQL se produce éste error ya que el modelo no se actualiza solo.

Para actualizarlo a mano es sencillo:

1. Dentro de la solución de Visual Studio hacer click derecho sobre el archivo EDMX y hacer click en “Open with…”
2. Seleccionar la opción XML Editor
3. Modificar el valor del atributo ProviderManifestToken de 2008 a 2005
4. Volver a compilar y listo

De todas formas es siempre recomendable utilizar la misma configuración en todos los entornos (desarrollo, testing y producción) pero hay casos en que no es posible…

Espero que les haya servido…saludos!