Tengo demasiado trabajo y demasiadas cosas en la cabeza.

En general, muchas de esas excusas que los blogger más adustos suelen utilizar para defenderse a las críticas sobre lo poco que actualizan. Pero, en serio, no me olvido de mi querido blog… ¡habrá que retomarlo!

Para darle salsa al nuevo año, y dado que todo el mundo me pregunta día sí, día también, sobre dudas de todo tipo (programación, desarrollo, SEO, Internet…) he decidido crear Wikimou, una wiki que intentará solucionar muchas de esas dudas que me preguntan. Cada vez que resulva algo en desarrollo que me parezca interesante o cuando me pregunten algo importante, intentaré publicarlo aquí para que quede constancia de ello.

Por supuesto, se aceptan colaboraciones en toda su temática:

• Desarrollo
• SEO
• Trucos de programación
• Internet
• Técnicas sociales
• Problemas técnicos de todo tipo
• Google
• API

Os invito a todos a participar en el proyecto. ¡Juntemos todas nuestras proezas! ¡Aprendamos de nosotros mismos y dejemos a los demás acompañarnos!

Bookmark

enum Languages {es, @as, @in, en, zh};

Ya no hay excusas: no habrá que usar strings “a pelo” en nuestras serializaciones de datos (XmlSerialization).

Bookmark

switch(saludo)
{

case “hola”: return Saludos.Hola;
case “hello”: return Saludos.Hello;

}

¿Quién no ha hecho este tipo de aberración alguna vez durante su vida como desarrollador? Todos…

Afortunadamente me he topado con un sistema muy interesante, que prácticamente podemos definir como evidente (¿Cómo no se me pudo ocurrir antes?) para realizar la conversión sin tener que hacer uso de un switch del tamaño de 20 folios A4. Tan sencillo como ésto:

public Enum Saludos {Hola,Hello,Hi};

public Saludos GetSaludo(string saludo)
{

return (Saludos)Enum.Parse(typeof(Saludos), saludo);

}

De éste modo realizaremos la conversión de manera sencilla y práctica, con una única línea de código.

Bookmark

Algunas personas utilizarán otros métodos, pero yo os voy a sugerir mi preferido y el que más uso normalmente. Es recomendable no usarlo en situaciones donde la seguridad sea extremadamente importante, pese a que decodificar la cadena del ViewState en el resultado renderizado de la página sea un acto casi faraónico.

Mi propuesta es la siguiente: muchos queremos poder mantener el estado y contenido de nuestras variables entre un callback y el siguiente, de manera sencilla y cómoda. Para ello vamos a usar el ViewState.

Para los profanos: ¿qué es el ViewState?

Cuando uno programa en ASP.NET, comunmente utiliza eventos para controlar la interacción de los usuarios clientes en la página. Estos eventos nos permiten detectar, por ejemplo, cuándo un usuario selecciona una opción de un desplegable DropDownList. Cuando el cliente hace ésto, por arte de magia el código de lado de servidor recibe un mensaje que lanza un método señalado como capturador del evento. Por ejemplo:

Código ASP.NET:

<asp:DropDownList runat=”server” ID=”dropdownPrueba” OnSelectedIndexChanged=”procesarCambio”>
<asp:ListItem Text=”Opción 1″ Value=”1″></asp:ListItem>
<asp:ListItem Text=”Opción 2″ Value=”1″></asp:ListItem>
</asp:DropDownList>

Código C#

protected void procesarCambio(object sender, EventArgs e)
{
Response.Write(this.dropdownPrueba.SelectedItem.Text);
}

Fijaros bien en algo. En la función C# anterior, estoy recogiendo el texto contenido en el item seleccionado en el desplegable. ¿Cómo sabe ASP.NET lo que está seleccionado? ¿Cómo sabe los items que había antes en el desplegable? La pregunta tiene fácil respuesta: el ViewState.

El ViewState es el modo en que ASP.NET guarda el estado general de una aplicación web dentro del ámbito de una misma página y sus consecuentes callbacks. Automáticamente, guarda el estado de todas las variables de los controles de usuario ASP.NET (siempre y cuando tengamos activada la opción EnableViewState en el control), de manera que se conservan y son accesibles en cada callback de la página.

Pero, ¿cómo puede esto servirnos para guardar datos entre una llamada a servidor y otra? Los chicos de Redmon nos han dejado una pequeña puerta trasera para acceder al ViewState e introducir y recuperar información.

Su uso es bien sencillo: podemos acceder al ViewState como una variable estática global, de la siguiente manera y desde cualquier punto de nuestro proyecto web:

Código C#

//Introducimos un dato en el ViewState…

ViewState["midato"] = “vamos a guardar esto en el ViewState de la página”;

//y ahora lo recuperamos

string este_era_el_dato = ViewState["midato"];

Por supuesto, podéis probar esto y añadir cada línea en callbacks diferentes para poder comprobar su correcto funcionamiento.

Mi sugerencia

Cada desarrollador tiene sus propias manías, y yo no soy una excepción. Por ello, conservo determinados valores entre diferentes llamadas del servidor cuando es necesario y apropiado. Aquí os dejo un ejemplo:

private string __variable;

public string Variable
{
get { if (ViewState["variable"] != null) return ViewState["variable"].ToString(); else return this.__variable; }
set { ViewState["variable"] = value; this.__variable = value; }
}

De esta manera, si haceis uso de la propiedad llamada Variable en cualquier punto de la clase, ésta se conservará entre callbacks. Recordad que, aunque la propiedad Variable, aunque la haya definido como pública, podeis usarla como prefiráis (private, protected…). No useis la variable __variable, pues será sobreescrita por la propiedad cada vez que la llaméis, no es más que un punto de control.

Como nota personal, siempre tiendo a encerrar este tipo de composiciones en una misma región, quedando mucho más organizado y ordenado.

Bookmark

¿Qué es un método anónimo? A veces hay situaciones donde debemos utilizar determinados pedazos de código que no vamos a usar más adelante en nuestro programa a modo de método o función, por lo que no es necesario realizar un esfuerzo extra para refactorizar nuestro código o crear zonas reutilizables. Una clara situación: el envío de un método delegado como parámetro para una función.

Tradicionalmente, para poder pasar un método como parámetro, debíamos primero definir un tipo de delegado, crear dicho método, y enviarlo como parámetro:

public delegate void MiDelegado(int x);

/* … */

public bool ProbarMetodo(MiDelegado metodo) { int i = 5; /* … */ return metodo(i); }

void MiFuncion(int x) { return x*2; }

/* ..  */

//Llamamos al método pasando como parámetro un delegado
this.ProbarMetodo(this.MiFuncion);

Vamos… un completo engorro. Es entonces cuando entran en juego nuestros amigos los métodos anónimos, donde en lugar de crear un tipo de delegado e ir pasandolo engorrosamente, introducimos la implementación del método directamente en la llamada:

this.ProbarMetodo(delegate (int x) { return x*2; });

Como veis, esto nos facilita mucho la existencia: es algo más complicado de leer y comprender (pese a que este ejemplo es bien sencillo) pero ganamos a la hora de simplificar la estructura de métodos de nuestra clase. Todo un logro de los creadores de C# 2.0, y un gran punto donde C# 3.0 tiene uno de sus pilares de soporte centrales para la creación de la API de LINQ y su nueva sintaxis, y muy útil para las nuevas funciones lambda que nos alegran la vida con la nueva versión del lenguaje.

Bookmark

Por lo tanto, para cualquier uso que queramos realizar de las API de YouTube para tomar datos de videos, usuarios y temáticas, podremos hacer uso de la gran colección de herramientas y clases del framework de Microsoft para comunicarnos con la aplicación de Google.

Como siempre, cada uno tiene su sistema, y yo tengo el mio propio. Como ya sabreis, soy una persona muy purista y tengo por tendencia utilizar sistemas del más bajo nivel siempre que está en mi mano, por lo que no es dificil intuir la manera en que consumo y exploto las API de Google basadas en XML.

Para empezar, comienzo por descargarme el mensaje XML desde su origen. Tomemos como ejemplo la petición de datos de un video concreto:

using System.Net;

/* ############ */

string url = “http://gdata.youtube.com/feeds/api/videos/[codigo youtube del video]“;
WebClient wc = new WebClient();
string xml_file_stream = wc.DownloadString(url);

XmlDocument xdoc = new XmlDocument();
xdoc.LoadXml(xml_file_stream);

De este modo descargamos el fichero XML que contiene la información referente al video del que queremos recuperar sus datos y lo cargamos en un objeto de tipo XmlDocument, estructura que podremos manipular a nuestro libre antojo.

En otro post, analizaré y mostraré los diferentes campos de la secuencia devuelta como XML y la utilidad que podemos sacarle para neustras aplicaciones tanto en ASP.NET como Windows Forms.

Personalmente, lo veo muy interesante para realizar integraciones de contenidos entre diferentes temas, usuarios o localizaciones geográficas, que podremos facilmente compartir en nuestras aplicaciones y dar servicios extra a neustros clientes y usuarios finales.

Pero, como siempre, el uso final estará en manos de todos nosotros: los desarrolladores, programadores y diseñadores software.

Bookmark

Vimos que la solución final necesaria para poder utilizar conexiones en ASP.NET sin meternos en lios de memoria o conexiones compartidas, debíamos abrir y cerrar la conexión con la base de datos para cada consulta, pese a que pudiera parecer redundante o molesto.

Pero, si aplicais lo planteado en un proyecto a gran escala y con un buen tráfico de usuarios, notareis que no se sufre un impácto demasiado grande en el rendimiento de la aplicación pese a utilizar esta técnica, y esto se debe a una gran capacidad con la que cuenta SQL Server: el connection pooling: cuando llamamos a Close() para cerrar la conexión a la base de datos, ésta no se cierra, sino que queda almacenada en un listado de conexiones inactivas a las que puede recurrirse en cualquier momento.

Más adelante en nuestra misma aplicación, cuando llamemos a Open() para volver a conectarnos, ASP.NET y SQL Server colaborarán para localizar una conexión marcada como inactiva pero cuyo connection string coincida con la conexión que intentamos crear y activar. En el momento en que es localizada, esta es invocada y reactivada, evidanto de esta manera un malgasto de recursos extra al crear y abrir una conexión.

Una cosa debe quedarnos bien clara en cualquier caso: cualquier tipo de movimiento o trabajo con la base de datos, apertura o cierre de conexión con un proveedor, petición o inserción de datos, consume recursos temporales y de memoria del sistema, por lo que es de vital importancia el localizar nuevas vias de trabajo con datos y mejoras  en sus algoritmos como puntos clave para potenciar la eficiencia de nuestras aplicaciones.

Bookmark

Por supuesto a la hora de elegir el sistema más apropiado tendremos que tener en cuenta toda una serie de factores, ventajas y desventajas, de cada uno de los diferentes modos existentes:

1. Gestión centralizada :: las conexiones a la base de datos son administradas en una clase común accesible desde cualquier punto de la aplicación (ahorro de recursos a la hora de abrir y cerrar conexiones y realizar consultas ligeras o atómicas.
2. Gestión individual :: abrir y cerrar la conexión cada vez que sea necesario lanzar comandos hacia la base de datos.

Desde un punto de vista organizativo, no hay duda que la centralización es la mejor opción: atomización del control de base de datos, administración localizada en un punto de todo el tráfico de datos, y disminución de la complejidad del código. Ahora bien, el diseño de un sistema que permita este tipo de trabajo, aunque no imposible, es relativamente complicado: debemos tener en cuenta que toda aplicación web, al menos en la mayor parte de los casos, deberá soportar un cierto grado de concurrencia de usuarios de manera simultánea, por lo que podemos descartar el uso de variables static (o shared en VisualBasic), ya que estas son compartidas en todas las instancias de la aplicación web en ejecución.

Analicemos la posible solución como conexión común en una variable static:

class ClaseComun { private static SqlConnection __connection; }

Vemos que definimos una clase que contiene la variable privada estática que almacena una conexión de tipo SqlConnection (proveedor de conexión para SQL Server integrado en Microsoft .NET). Vamos a añadir una propiedad a la clase:

public static SqlConnection Connection
{

get { if (__connection == null) { __connection = new SqlConnection(connection_string); __connection.Open(); }

}

Como podemos apreciar, la propiedad creada es de solo lectura: queremos que la conexión quede solo definida por el interior de nuestra clase, aislandola del resto de la aplicación.

Por el momento, todo parece correcto, especialmente para aquellos que estén familiarizados con aplicaciones basadas en Windows Forms, donde este tipo de trabajo es oportuno y francamente útil.

El problema viene cuando lo utilizamos en una aplicación ASP.NET: imaginemos un usuario que entra por primera vez en la página. Al realizar su petición al servidor, ésta será ejecutada, y de no existir una instancia para la variable estática, se creará un objeto SqlConnection y se abrirá la conexión con la base de datos SQL Server.

Ahora bien… Otro usuario, casi de manera simultánea pero unos microsegundos después, solicita al servidor otro acceso. El código ASP.NET, volverá a comprobar la existencia de la variable de conexión, que ya estará instanciada y por tanto no realizará ninguna otra gestión sobre la conexión. Ahora bien… el código ejecutará sus consecuentes peticiones de datos y… ¡peligro! Dos usuarios están usando la misma conexión con la base de datos.

Pese a ser un modo bastante elegante de centralizar la gestión de conexiones, es mortalmente peligroso para aplicaciones web concurrentes. Por lo tanto, pasaremos a la siguiente opción.

Aunque pueda parecer una opción menos eficiente frente a la anterior, la mejor opción bajo mi punto de vista es crear una instancia de la conexión SqlConnection para cada consulta que vayamos a realizar, la abramos, ejecutemos la petición a la base de datos, y luego la cerremos:

SqlConnection cnx = new SqlConnection(connection_string);
cnx.Open();
SqlCommand cmd = new SqlCommand(“SELECT COUNT(*) FROM table_of_clients”, cnx);
object obj = cmd.ExecuteScalar();
/* … */
cnx.Close();

Como vemos, estamos creando una instancia de la conexión para realizar una consulta por lo demás simple, que se abre y se cierra para lanzar la petición a la base de datos. Puede parecer redundante y una pérdida letal de recursos, con una inclusión indiscriminada de líneas extra en el código fuente de nuestra aplicación.

Pero, en el caso de una aplicación web de cierta complejidad donde deban lanzarse varias consultas en una misma petición del usuario al servidor web, ¿es una buena práctica abrir y cerrar la conexión tantas veces? ¿es eficiente?

La respuesta es si. Gracias a las capacidades de connection pooling de ASP.NET y SQL Server ganaremos en eficacia y calidad sin perder recursos por el camino. ¿En qué consiste el connection pooling? Lo explicaré en el próximo post de mi blog, donde podreis comprobar su funcionamiento con algunos ejemplos sencillos que espero os sean de utilidad.

Una cosa os aseguro: ganareis, de lejos, numerosas ventajas frente a otros métodos tradicionales de trabajo.

Bookmark

Podemos diferenciar varios tipos de errores:

1. Errores sintácticos de programación. Estos son detectados por el compilador como situaciones que violan las reglas de implementación del lenguaje que estemos utilizando.
2. Errores conceptuales de programación. Errores cometidos en la definición de algoritmos que llevan a situaciones no previstas.
3. Errores en tiempo de ejecución. Derivados de los errores conceptuales, son los que nacen de resultados no previstos.
4. Errores de planificación. Suceden cuando se pone poco empeño durante la fase de análisis y definición de un proyecto, y es especialmente visible en proyectos web, donde (generalmente) el número de archivos de código es mayor que en una aplicación de escritorio y son más dificiles de depurar.

Por suerte, hoy en día cualquier lenguaje que utilicemos cuenta con las herramientas necesarias para poder detectar los errores de los puntos 1, 2 y 3.

El más clásico es, por supuesto, la estructura try. Un ejemplo en C#:

try
{ /* Código que está siendo probado */ }
catch (Exception ex)
{ /* Código ejecutado si se produce una excepción */ }

Ahora bien, cuando estamos trabajando en una aplicación web con ASP.NET 2.0, puede que queramos realizar una gestión de errores a nivel de aplicación sin necesidad de tener que controlar cada zona del código mediante estructuras de control de excepciones.

Aquí voy a presentar el modo que yo prefiero utilizar, y que bajo mi experiencia, es el más cómodo y útil.

Para capturar los errores que se produzcan dentro de nuestr apalicación, utilizaremos el fichero Global.asax, que si no lo teneis en vuestro proyecto, podeis añadirlo en el propio directorio raíz. En él, si no lo tenemos ya, añadiremos una función de la siguiente forma:

void Application_Error(object sender, EventArgs e)   { }

Cada vez que se produce una excepción no controlada dentro de nuestra aplicación web se llama a este evento de manera automática. Hay que tener en cuenta que si bien de esta manera capturamos el momento en que se produce un error, no tenemos una manera directa de acceder a la información del mismo, por lo que usaremos esta otra secuencia para recoger el objeto de excepción:

Exception ex = Server.GetLastError().GetBaseException();

Como podeis ver, ahora ya podemos acceder a toda la información que nos trae el objeto de excepción en su instancia, que hemos llamado ex.

Ahora podemos tomar varios caminos:

1. Mostrar un mensaje de error al usuario.
   1. Genérico: configurable desde el fichero web.config, como veremos a continuación.
   2. Detallado con el error: no es recomendable, pero podemos imprimir en pantalla los datos del error (procedencia, mensaje, seguimiento de pila de llamadas…)
2. Registrar el error en Windows.
3. Enviar un correo electrónico al administrador.

Primero veamos el caso 1. Para poder activar una página genérica donde acudan los navegadores de nuestros usuarios cuando se produzca un error, modificaremos una serie de parámetros en el fichero web.config, en concreto los referentes a la etiqueta customErrors:

<customErrors mode=”RemoteOnly” defaultRedirect=”~/pagina-no-encontrada.aspx”>
<error statusCode=”404″ redirect=”~/pagina-no-encontrada.aspx”/>
<error statusCode=”500″ redirect=”~/error.aspx”/>
</customErrors>

El este pequeño ejemplo, estamos indicando al servidor IIS el modo en que debe atender las diferentes situaciones que puedan darse, concretamente para dos casos muy comunes: no localizar una dirección (código 404) o detectar un error en tiempo de ejecución (código 500).

• customErrors: permite configurar el modo en que se atiende un error.
  • mode: modo en que debe comportarse el servidor de cara al error a la hora de mostrarlo
    • on: mostrar una página de error genérica (o la indicada como por defecto para el error sucedido)
    • off: mostrar cascada de error completa (PELIGRO DE SEGURIDAD, usar solo durante depuración y desarrollo), donde veremos una descripción detallada de lo sucedido
    • RemoteOnly: mostrará una página de error genérica (o la indicada)
  • defaultRedirect: lugar al que será enviado el usuario si no se indica nada para el suceso acontecido
• error: condición para un error concreto
  • statuCode: código del error acontecido (po ejemplo… 200=OK; 301=movido; 404=no encontrado; 500=error de ejecución)
  • redirect: página donde deberá ser llevado el usuario cuando suceda ese tipo de error

Ahora bien, si lo que queremos es poder realizar un tratamiento propio del error desde el fichero global, debemos tener en cuenta que lo anteriormente explicado, es decir, las instrucciones insertadas en el fichero de configuración web.config, se ejecutarán inmediatamente después de lo indicado en la función Application_Error salvo que le indiquemos lo contrario con la llamada a Server.ClearError(); , que retirará el error de la aplicación e ignorará lo aparecido en el fichero de configuración.

Tratemos ahora los otros dos casos: registro en Windows y envío por email.

Para registrar una excepción en el registro de Windows, podemos usar: (comprobando antes de nada que hayamos añadido al fichero System.Diagnostics)

EventLog.WriteEntry(“Test Web”,
“MESSAGE: ” + ex.Message +
“\nSOURCE: ” + ex.Source +
“\nFORM: ” + Request.Form.ToString() +
“\nQUERYSTRING: ” + Request.QueryString.ToString() +
“\nTARGETSITE: ” + ex.TargetSite +
“\nSTACKTRACE: ” + ex.StackTrace,
EventLogEntryType.Error);

Pero una cosa nos debe quedar muy clara: tras usar esto, la función en la que estamos será anulada instantáneamente, por lo que si queremos realizar cualquier otro tipo de atención a la excepción en la función Application_Error deberemos de hacerlo antes de llamar a EventLog.WriteEntry.

Si lo que deseamos es enviarnos el error por email, cosa que yo personalmente encuentro soberanamente útil, podremos usar: (haciendo uso de System.Net y System.Net.Mail)

string origen = “direccion@origen-de-aplicacion.com”;
string destino = “correo@electronicodedestino.com”;
string titulo = “Error de ejecución”;

string cuerpo = “<h2>Informe de error</h2>Fecha-hora: ” + DateTime.Now.ToString(“dd/MM/yyyy – HH:mm:ss”);

cuerpo += “<h3>Mensaje</h3>” + ex.Message + “<h3>StackTrace:</h3>” + ex.StackTrace + “<h3>TargetSite:</h3>” + ex.TargetSite;

MailMessage mensaje = new MailMessage(origen, destino, titulo, cuerpo);
mensaje.IsBodyHtml = true;   //Si hemos añadido etiquetas HTML
SmtpClient smtp = new SmtpClient(“mismtp.midireccion.com”);
smtp.Timeout = 6000;
smtp.Send(mensaje);

Si teneis alguna duda o pega, no dudeis en comunicarmelo. Intentaré extender más este tipo de minitutoriales de ASP.NET y C#.

Bookmark