moure.es – Alfonso Moure Ortega

Desde hace tiempo ya venimos escuchando la nueva ola de la Web 3.0, incluso antes si quiera de comprender el verdadero significado (si es que tiene alguno) de la Web 2.0.

Y éste nuevo significado en la era 3.0 no es otro que el semántico: dotar de significado y sentido a elementos de información dentro del HTML.

Pero como siempre, falta el apoyo de las grandes marcas. No importa que pequeños y aislados grupos de personas trabajen para crear nuevas maneras de llevar a un nuevo punto el potencial de Internet, mientras gente como Google no promocione sus creaciones, éstas tienen el peligro de caer en el olvido, o peor aun, de extinguirse para siempre.

Éste es el caso de los microformatos (o microformats), una colección de atributos que pueden ser añadidos a nuestras etiquetas tradicionales para dotar de un significado o sentido a la información que encierran. Ahora ha llegado su momento de explosión, largamente esperado: Google implanta los rich snippets, al fin de un modo oficial.

Gracias a estos cambios, podremos mejorar ya no el posicionamiento de nuestros contenidos, sino su presentación en los SERPs y el modo en que los usuarios captan el sentido de la página antes incluso de entrar. Podremos presentar a Google una información mucho más rica sobre nuestros productos o servicios que ofrecemos a los visitantes, o si lo preferimos, indicarle nuestra ubicación geográfica o interrelación entre apartados de nuestro site.

Un ejemplo sencillo: el review o artículo de opinión o revista sobre algo. A todos nos ayuda buscar opiniones de otra gente sobre un producto que queremos adquirir. Esto nos lleva su tiempo, porque aunque existen herramientas ya preparadas para localizar reviews, a veces esto lleva un buen rato, y un rato siempre se convierte en una brutal pérdida de tiempo. Y el tiempo es oro.

¿Y si permitimos que Google publique en su SERP la puntuación de nuestro review y alguna anotación en lugar del típico trozo de texto de la misma? ¿No será más util que muestre algo que realmente le inspire interés al usuario? Pues claro que sí:

<div class=”hReview”>
<span class=”item”>
<span class=”fn”>L’Amourita Pizza</span>
</span>
<span class=”rating”>3.5</span>
<span class=”reviewer”>Ulysses Grant</div>
<span class=”dtreviewed”>2009-01-06</span>
<span class=”summary”>”Delicious, tasty pizza in Eastlake.”</span>
</div>

Efectos del Google Rich Snippet

Este ejemplo está literalmente cogido de la documentación de Google para rich snippets de reviews. Soy poco original, lo sé.

Bookmark

Se escucha desde hace mucho tiempo el sonido distante de éste mismo problema: ¿afecta la existencia del ViewState de ASP.NET en el indexado de Google? La respuesta solo puede tomar dos valores: sí o no. Y cada persona, cada SEO, cada gurú de Internet, os responderá una cosa diferente. Por supuesto, yo también tengo mi teoría.

Y es la siguiente: sí, el ViewState de ASP.NET afecta al posicionamiento en Google. ¿Por qué? Os doy varias razones:

1. Por su tamaño: en páginas demasiado complejas y con una gran carga de controles ASP.NET, ocupará tanto espacio que nos arriesgamos no solo a perjudicar a los usuarios menos favorecidos en su velocidad de conexión, sino que también nos arriesgaremos a producir un timeout en las consultas de Google.
2. Por el desplazamiento de contenido: Google utiliza como criterio de posicionamiento, como todos bien sabemos, la posición de la información y metainformación dentro del documento HTML. Un ViewState demasiado grande moverá los datos realmente importantes (es decir, todo el BODY) hacia abajo.
3. Por su incoherencia como información: El contenido del ViewState es incomprensible, no solo para un humano, sino también para una máquina ajena a la aplicación ASP.NET en ejecución. Incluso a veces es incomprensible para ella misma.

¿Cómo evitar su existencia? No siempre es posible. El uso de callbacks en ASP.NET, aunque es algo muy cómodo, no es ni de lejos recomendable para atraer a Google. Todos lo sabemos. Pero a veces, se hace inevitable.

De todas maneras, si podéis evitar el uso de ViewState (y por favor, no uséis variables de sesión, porque os volveréis majaras trabajando con ellas), os digo un modo bien sencillo de desactivarlo: en la etiqueta inicial de vuestra página ASP.NET, no hay más que activar EnableViewState como false:

<%@ Page Language=”C#” EnableViewState=”False” %>

Lógicamente podéis usar este mismo atributo en cualquier control de vuestra página, pero gracias a realizarlo a nivel de Page, os aseguraréis de que se extiende como es debído y que nada se os pase por alto. Recordad así mismo que podéis establecer EnableViewState como false a nivel de página, pero como true a nivel de control, simplemente indicandolo en la etiqueta propia del elemento que queréis que pueda usar nuestro valioso espacio de control de estado.

¿Dudas? Dejad un comentario y gustoso os echaré una mano.

Bookmark

Bueno, tengo esto bastante abandonado la verdad…

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

A veces queremos utilizar palabras reservadas dentro de un listado de valores de un enumerado (enum) dentro de nuestro código C#. Hoy un compañero me ha preguntado cómo hacerlo, y tras repasar mis chuletas mentales, almacenadas en memoria secundaria en lo más profundo de mis sesos, recordé la forma: poniendo el modificador @ delante del valor igual a la palabra reservada. Por ejemplo:

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

Adiós al tradicional método de convertir un string en enum utilizando un eterno switch en C#… Viejos tiempos en los que debíamos hacer algo similar a…

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

Desde pasar variables en campos ocultos (hidden fields) hasta guardarlas como variables de sesión, pasando por enviar QueryStrings absurdamente largos. Estas son algunas de las salidas que muchos programadores utilizan para poder pasarse información entre diferentes callbacks en ASP.NET, para conservar valores de variables o datos de los usuarios. ¿Os imagináis guardar datos personales de los usuarios en campos ocultos HTML? Aberrante.

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

Existen muchos paradigmas diferentes que pueden ser aplicados a la hora de diseñar la arquitectura de un producto software, al igual que muchas maneras de afrontarlo y subsanar sus problemas. Igualmente, hay multiples modos de enfocar las diferentes fases del desarrollo.

Personalmente tiendo a clasificar a las empresas de desarrollo en determinados grupos:

1. Desarrollo heróico :: aunque el término ya existe, usado para denominar a aquel grupo de desarrollo que intenta solucionar los problemas informáticos de manera individual y sin un planteamiento previo claro, donde el hecho de alcanzar el éxito estará marcado por la calidad de sus programadores a nivel individual y no colectivo. Este tipo de equipos suelen, por estadistica, tener una vida relativamente corta y bien sufrida, muy posiblemente por despreciar la calidad del equipo como un conjunto capaz de colaborar y trabajar como un ente único.
2. Desarrollo organizado sin calidad :: empresas donde existe una buena organización y cohesión interna pero un nivel tecnológico o formativo demasiado bajo como para sacarle un buen rendimiento. En este tipo de mercados quedarse atrás es peor que letal.
3. Desarrollo organizado de calidad :: empresas que lo tienen todo, desde buena organización hasta profesionales capaces de explotarla y sacarla partido.

Esto desde luego es únicamente referente a su capacidad de organizarse y aprovechar sus recursos humanos. Pero, ¿qué hay de las empresas que no aprovechan en absoluto sus virtudes técnicas? ¿Qué sucede con las empresas que alardean de utilizar .NET Framework pero no aprovechan ninguna de sus capacidades únicas?

Bookmark

En mi post anterior dedicado a las conexiones a base de datos desde ASP.NET comenté algunos de los problemas más comunes durante el diseño de arquitecturas software en ASP.NET y la gestión de conexiones con bases de datos, especialmente con Microsoft SQL Server.

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

Existen muchas maneras de gestionar el acceso a bases de datos desde ASP.NET, unos mejores que otros, y sin duda cada uno tenemos nuestro propio sistema (“Cada maestrillo tiene su librillo“, como siempre me han dicho en mi casa). ¿Cuál creeis que puede ser el mejor?

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