Esta pregunta nos la han hecho repetidamente en el Developer Day de Madrid del mes pasado y en los WebDays por España adelante. Se trata de una pregunta lógica pero que al mismo tiempo no nos debería preocupar. Me explico y así de paso trato de responderla…

AJAX se lleva mal con los motores de búsqueda, ya que lo que hacemos es recargar, por detrás, con JAVAScript los contenidos –totales o parciales- de la página, y por lo tanto no hay enlaces que seguir ni forma fácil de determinar el nuevo contenido.

Ahora bien, todo esto es muy relativo. No vas a usar AJAX para realizar navegación simple en tu sitio Web sino para facilitar al usuario el uso de aplicaciones.

Exacto, pongo «aplicaciones» en negrita. Ya que por este motivo no debería impactar apenas nada el uso de AJAX en tu posicionamiento en buscadores puesto que, al igual que antes usabas post-backs recargando la misma página (algo que tampoco se lleva bien con los buscadores obviamente) ahora emplearás AJAX para hacer la aplicación más usable. La diferencia desde ese punto de vista es mínima.

Toda la navegación por diferentes contenidos la harás igual con enlaces, y aunque alguna parte de la página se actualice con AJAX, normalmente no será algo que quieras que se indexe.

Te pasaría lo mismo si en lugar de AJAX usas cualquier otra técnica para variar contenido dinámicamente, como por ejemplo un simple JavaScript que vaya rotando entre una lista de imágenes.

Al igual que tampoco está bien crear una Web completa, de cabo a rabo, con Flash (se lleva muuuy mal con los buscadores), menos aún se te ocurrirá hacer una web completa con AJAX, salvo que en ambos casos se trate de una aplicación que maneje datos y demás.

En fin, esta es mi opinión personal, claro está. Pero seguro que hay otras opiniones enfrentadas 🙂

Aunque esto es algo muy poco conocido por los programadores de ASP.NET, es posible mover secciones completas de la configuración a sus propios archivos independientes de web.config. Ello se consigue usando el atributo configSource en la sección correspondiente. Por ejemplo, podemos escribir en el nodo ConnectionStrings lo siguiente:

<connectionStrings configSource=»conexiones.config»/> 

y ahora tener un archivo independiente llamado conexiones.config que contenga esa sección completa:

<connectionStrings> 
   <add name=»Clientes» connectionString=»…»/>

   <add name=»Principal» connectionString=»…»/>

</connectionStrings>

Esto puede resultar útil en muchas ocasiones. Por ejemplo, podemos cambiar más fácilmente entre los ajustes de producción y de desarrollo, manteniendo en común el resto de la configuración. Otro motivo sería proteger de manera especial esa sección y otorgarle sus propios permisos de lectura y escritura.

Uno de los motivos más importantes sería el evitar que se reinicie la aplicación ante determinados cambios. Por ejemplo si sacamos a un archivo la sección AppSettings de ajustes personales, a lo mejor no necesitamos que se reinicie la aplicación sólo modificar algo en ella. Al separarla a su propio archivo conseguiremos este efecto ya que cambia el archivo externo pero no el web.config, y aunque modifiquemos algo en él no se fuerza el reinicio.

Ello es debido a que en machine.config (la configuración principal del equipo) la sección AppSettings está marcada con el atributo restartOnExternalChanges=»false». Hay otras secciones que tiene este atributo a true por lo que si se cambia el archivo externo sí que provocaremos un reinicio.

Extraido del curso de preparación del examen 70-528 de desarrollo Web de campusMVP.

O eso es lo que afirman si te vas a la galería de Windows Live para SideShow.

Sideshow es una nueva característica incorporada a Windows Vista que permite mostrar información del sistema en dispositivos accesorios como pequeñas pantallas en la tapa de un portátil, teléfonos móviles, etc… que, vinculados con Windows y sin necesidad de que el equipo esté operativo al 100% ofrecen información sobre cosas como los correos sin leer o el nivel de batería. Una buena idea pero que no está calando demasiado. Imagino que el motivo es que no hay muchos dispositivos en el mercado capaces de sacarle partido (yo al menos no conozco ninguno).

El caso es que si vas a SideShow en Vista y pulsas el botón de «Obtener más gadgets en Internet», te manda a una página en la que no hay absolutamente ningún gadget, en ninguna de las categorías existentes.

Por eso, siendo un poco cabroncete, es posible hacer una captura como esta (pulsa para agrandar):

Que tiene muchísima gracia, la verdad. Lo mismo puedes hacer con seguridad y otras categorías, ya que como digo están todas vacías. jajajaja X-D

Una cosa que me gusta especialmente de Windows Vista es toda la información que nos proporciona si sabemos buscar de forma activa, y que supera con mucho a lo que nos ofrecía Windows XP. Aparte del mejorado administrador de tareas (pulsa CTRL+MAY+ESC para lanzarlo), hay muchas otras formas de conocer información del sistema.

Me gusta mucho el monitor de confiabilidad del sistema. Lánzalo desde el menú de inicio. Tiene la pinta que se ve a continuación:

Pulsa para agrandar

Aparte de darnos unas gráficas en tiempo real sobre cómo se está comportando la CPU, el disco la red y la memoria, en la parte inferior, si pulsamos sobre la barra correspondiente, nos ofrecerá en cada una de ellas una lista de los programas en ejecución (con su descripción incluída, lo que nos facilita su localización), con información sobre qué están haciendo en cada instante. Esto nos ayudará a localizar aplicaciones que se comportan de manera inestable, consumen mucha memoria, se «pasan» yendo a disco o están conectadas a Internet sin que lo sepamos.

La herramienta ofrece todavía algunas sorpresas más, pero por hoy me centraré en comentar cosas que tienen que ver con los programas en ejecución solamente.

Siguiendo con ese mismo tema vamos a comentar otra forma de analizar lo que se ejecuta en un equipo con Vista.

La herramienta anterior se complementa muy bien con otra nueva disponible dentro de Windows Defender. Este programa va más allá de lo que había en Windows XP y en él se centraliza la gestión de diversas utilidades relacionadas con la protección del sistema frente al Spyware.

Si entras en Windows Defender y pulsas el botón «Herramientas» de la barra superior derecha verás que aparecen varios iconos. Uno de ellos «Explorador de software» nos permite localizar todo el software en ejecución según tres criterios importantes:

· Todo el software en ejecución (o sea, sin filtrar)
· El software que está conectado a Internet actualmente: muy útil para localizar Spyware y programas no autorizados.
· Software que provee servicios de Winsock, que son programas que realizan funciones de red de bajo nivel.

Pulsa para agrandar

Como se puede observar en la captura anterior,al pulsar sobre cualquier programa de la lista se muestra un detalle del mismo, con muchos datos para poder verificar su origen y «confiabilidad».

Además de estas tres vistas mencionadas existe una cuarta (la primera de la lista desplegable en la captura) que nos ofrece una lista de programas que se lanzan al inicio de Windows, agrupada por fabricante. Con información detallada al lado también, claro. Con esto podemos identificar programas que a lo mejor son dudosos o no sabíamos que se estaban ejecutando y que podremos desactivar.

Me parecen dos programas muy útiles que debiéramos usar de vez en cuando para ver cómo va nuestro equipo.

Espero que te resulten de interés.

Hoy por la mañana, David Salgado de Microsoft y yo mismo, hemos presentado en Vigo el WebDay. A lo largo de cuatro horas maratonianas hemos hablado de todos estos temas (espero no olvidarme de ninguno):

• Accesibilidad y estándares Web
  
• Expression Web Designer
  
• ASP.NET 2.0 básico
  
• ASP.NET 2.0 avanzado
  
• AJAX Toolkit para ASP.NET 2.0
  
• Gadgets de Windows Vista y Microsoft Live
  
• Windows Presentation Foundation

Como lo prometido a los asistentes es deuda, aquí están las presentaciones y materiales del evento para que las descarguéis:

· Powerpoint con todas las transparencias de la jornada (formato PPTX) (5.244 KB)
· Ejemplo «MiBolsa» de comparador de valores, versiones AJAX y No-AJAX (2.801 KB)

Muchas gracias por asistir y esperamos que os haya resultado útil.

¡Que los disfrutes!

¡Ah! y no te olvides de apuntarte al boletín de campusMVP.

Para rematar con este asunto del almacenamiento temporal de datos de la aplicaicón y cumplir lo prometido en mi anterior post, voy a explicar el almacenamiento de página, que es bastante sencillo.

¿Qué pasa si queremos almacenar cierta información en nuestra página, que valga sólo para el usuario actual, y que esté disponible mientras dure el uso que éste hace de nuestra página?.

Podemos utilizar cualquier elemento de almacenamiento, atado al usuario como una variable de sesión, o no atado a éste (como la caché o una variable de aplicación), pero no es una buena solución puesto que tendremos que estar pendientes de liberar esa memoria cuando el usuario deje de utilizar la página y ya no lo necesitemos.

Existe un modo mejor de conseguirlo y es a través del ViewState.

Almacenamiento de página en ViewState

Como sabemos el ViewState se usa generalmente para almacenar el estado de los diferentes controles que colocamos en una página ASPX. Sin embargo esta característica es en realidad un modo de almacenar de manera codificada (que no cifrada) una jerarquía de datos. Se puede comprobar con cualquier decodificador del ViewState, como por ejemplo el de Denis Bauer.

El objeto ViewState de un control (una página ASPX no deja de ser una forma de control avanzado, ya que es una clase que deriva de System.Web.UI.Control) es un tipo especializado de colección. En concreto se trata de una clase StateBag que implementa la interfaz IDictionary. Por lo tanto se puede leer y escribir en él directamente asignando claves a cada valor que queramos almacenar. El ViewState se encarga de codificar la información y persistirla por defecto en la página actual.

Al programador un control se usa el ViewState para almacenar datos que debemos conservar entre llamadas a la misma página, y también para leerlos luego, claro está.

Para escribir o leer un valor en el ViewState sólo es necesario decidir qué nombre queremos darle. Por ejemplo:

ViewState(«MisDatos») = «Info a almacenar»

y para leerlos al volver la página:

If Page.IsPostBack Then

    Dim s As String = ViewState(«MisDatos»).ToString()

End If

Es muy fácil almacenar información aquí. No obstante debemos tener cuidado de almacenar objetos que tengan un tamaño reducido o haremos que el ViewState ocupe demasiado y por lo tanto moverlo entre el servidor y el cliente y viceversa hará que las páginas vayan muy lentas. Generalmente está bien almacenar valores sencillos como identificadores o números pequeños, pero está mal almacenar clases grandes como por ejemplo un DataSet que contenga los resultados de una consulta.

Como es sabido me encanta Expression Web Designer. Eso no significa que lo encuentre perfecto. Ni mucho menos.

De hecho hay una cosa que me irrita muchísimo y es que cuando en un párrafo tienes seleccionada una frase o una palabra y le aplicas algún formato (por ejemplo negrita o cursiva), en lugar de aplicárselo a la selección lo hace al párrafo completo. Si escribes textos largos con este editor te aseguro que es realmente irritante.

El asunto se justifica porque Expression Web es un editor CSS puro que cumple con XHTML y por lo tanto no están permitidas las etiquetas del estilo <b></b> o <i></i>, y similares para aplicar estilos. Todos deben definirse como estilos CSS en etiquetas. Lo que me pregunto es ¿por qué demonios los que hicieron la herramienta no hicieron que se metiera automáticamente un <span> rodeando la selección para luego aplicar el estilo en dicha etiqueta?.

El caso es que la única forma que he encontrado de poder aplicar estilos a subconjuntos de un párrafo es precisamente hacer eso pero a mano. Es decir, seleccionas la parte del párrafo a la que le quieres aplicar el estilo, en el menú de controles pulsas con el botón derecho en el SPAN y escoges «Wrap» (como en la figura adjunta) para rodear la selección, y acto seguido aplicas la negrita o lo que sea. Un rollo.

Imagino que se podrá conseguir lo mismo creando una macro, pero como no te deja grabarlas y no tengo tiempo de ponerme a investigar el modelo de objetos en VBA (sí, como lo oyes, VBA) de Expression Web, pues seguiré tirando así.

¿Al alguien se le ocurre una forma mejor de hacerlo? Lo agradeceré mucho 🙂

¡Actualización! (dos horas más tarde)

Resulta que, como no, la culpa es aparentemente mia: si tienes el modo de aplicación de los estilos en «Manual» en lugar de «Auto» que es lo que tiene por defecto (fíjate en la parte de abajo del editor), funciona como yo describo, es decir, le aplica el estilo a todo el párrafo. Si lo pones en «Auto» es cuando lo hace bien. De todos modos no me parece normal esta diferencia ¿o quizá sí?.

Bueno, el caso es que ya me gusta un poco más todavía el producto 🙂

Siempre que se habla de la caché suele hacerse refiriéndose a la caché persistente que todos estamos acostumbrados a conocer y usar, bien la caché de salida de las páginas o bien la caché programática usando la clase System.Web.Caching.Cache.

Sin embargo hay ocasiones en las que probablemente nos interesaría más hacer una caché mucho menos persistente. Algo que nos dure lo justo para el propósito de un momento determinado y luego no nos tengamos que preocupar siquiera de deshacernos de ella. En concreto me estoy refiriendo a la caché de contexto o caché de una sola petición.

Imaginemos el caso: en una petición usamos un manejador propio para interceptarla y hacer algo antes de ser procesada la página o bien obtenemos alguna información más o menos costosa durante un evento de global.asax (en BeginRequest o durante la autenticación de la petición). El caso es que esa información la necesitamos usar de nuevo varias veces durante lo que dura la petición actual: en otros módulos o en diversas partes de la página.

Si sólo debemos reutilizar la información en la propia página es muy fácil pues sólo debemos almacenarla en un miembro privado común de la clase que representa a la página y ya está. Pero si tenemos que conservar una serie de valores entre diferentes partes de la misma petición o compartirlos con clases de las que hacemos uso en la página, entonces la cosa no es tan directa.

La pregunta es entonces: ¿qué tenemos en común entre todas las partes (manejadores varios, módulos y nuestra página)? Algo que siempre esté presente… El contexto de la llamada, representado por la clase HttpContext.

A este objeto podemos acceder mediante la propiedad Context de la página actual o, en cualquier lugar del código que esté siendo usado desde una petición HTTP mediante la propiedad Current del propio objeto Httpcontext, así:

HttpContext contexto = HttpContext.Current;

Esta clase tiene una colección de elementos que podemos usar para almacenar con claves los valores que queramos guardar entre partes de esa petición, es decir, mientras dure el contexto. Para ello sólo tenemos que escribir y leer la colección Items que también es la colección por defecto:

HttpContext contexto = HttpContext.Current;
contexto.Items(«MiDato») = «lo que sea»;
string dato = contexto(«MiDato»).ToString();

Con esto podemos conservar la información mientras dure la llamada. Cuando ésta termina el objeto HttpContext se destruye (o se marca para que lo recoja el recolector de basura si queremos hablar con propiedad, antes de que «alguien» (y no miro a nadie) me venga a apuntillar) y la información desaparece, pero hemos tenido una caché de información en la que almacenar datos importantes mientras duraba toda la llamada.

En un siguiente post voy a comentar cómo podemos hacer una caché que valga sólo para un usuario y que nos dure automáticamente mientras el usuario esté utilizando la página actual y no otra. Es simple pero muy interesante. Hasta entonces.

Bueno, es obvio que útlimamente se me da por la caché. El motivo es que he trabajado bastante con ella en los últimos meses por motivos de trabajo en la empresa, por un curso que he estado haciendo para campusMVP, y ya finalmente por parte de la charla que impartí en el developer Day, si bien en este caso por el tiempo que había apenas pude rozar la superficie del asunto… En fin..

El caso es que ya he mencionado alguna vez en posts anteriores que si movemos nuestra aplicación a Windows Server 2003 con Internet Information Server 6.0, podremos sacar partido de la nueva caché en modo núcleo que éste implementa a través de HTTP.sys. Esta caché de modo núcleo se comunica directamente con los componentes de E/S del kernel del sistema, sin pasar por el modo de ejecución usuario, e incrementa el rendimiento de la caché una barbaridad. Como ejemplo podemos ver los resultados del procesamiento de una página ASP.NET cuyo resultado ocupa 4KB de tamaño, usando una caché en modo núcleo y una caché «normal» en modo usuario (obtenido en este documento):

¡Espectacular la diferencia! ¿no?

¿Significa eso que sólo con trasladar una aplicacón a IIS 6.0 ya va a sacar partido a la caché en modo núcleo?. Repeat after me: «Nooo, padre».

¿Cuando entra en acción la caché en modo núcleo?

En condiciones normales los archivos que estén asociados con el manejador de archivos estáticos de IIS (por ejemplo imágenes, hojas de estilo .css, etc..) se almacenarán en la caché de modo núcleo. Está claro que sólo esto ya ayudará bastante porque este tipo de contenidos se obtendrán con mayor rapidez desde el servidor, si bien muchos de ellos realmente ya se «cachean» en el cliente/navegador generalmente por lo que ni siquiera se realiza una llamada al servidor para obtenerlos en sucesivas ocasiones.

¿Y qué pasa con las páginas ASPX? ¿Llega con usar unadirectiva VarBy… o similar en la cabecera para que entre en juego la caché en modo núcleo?

Pues tampoco. Las páginas ASPX deben cumplir una serie de condiciones, a saber:

· Sólo funcionan con la directiva VaryByParam=»None». Si usamos cualquier otra variante de VaryBy o si en VaryByparam establecemos algunos parémetros con los que variar la caché, ésta se hará en modo usuario.

· No puede haber parte «QueryString» en la URL, es decir, no puede haber una interrogación seguida de parámetros para la página.

· Se trata de una petición no autenticada. Es decir, sirve en páginas públicas pero no se cachean páginas para las que primeramente es necesaria una autorización para acceder.

· No se puede estar usando compresión dinámica de las respuestas.

· El tamaño total de la respuesta no puede superar los 256 Kb (que también le llega bien), ni tampoco ser cero (es decir, no devolver nada, lo cual tampoco tendría mucho sentido). Este tamño máximo se puede cambiar tocando la clave del registro: HKLMSYSTEMCurrentControlSetServicesHTTPParametersUriMaxUriBytes.

· No se puede usar un «pie de página» de los que se ajustan directamente en IIS (hace poco alguien me preguntó sobre esto y creo que fue en este blog).

· La petición se realiza a través del protocolo HTTP 1.0 o superior (esta es fácil de cumplir pues todos los navegadores modernos suelen usar 1.1).

· Hay una serie de encabezados que no pueden estar presentes en la petición:

· «Translate: f»: que indica al servidor que no debe procesar la página sino devolver su código. Usado en WebDaV.

· «Expect: 100-Continue»: cabecera de HTTP 1.1 para envío de datos de formularios en dos tiempos: primero se solicita la página y si el servidor responde con el código 100 se envían los datos codificados en Base64

· «Range» y «If-Range»: cabeceras HTTP 1.1 que sirven para indicar al servidor que, en determinadas condiciones, devuelva la última versión de algo que hay en caché parcialmente en el cliente.

Es decir, que no siempre entra en juego esta caché de modo núcleo, en contra de lo que se puede leer en multitud de sitios de Internet que juzgaron a la ligera esta capacidad cuando apareción Windows Server 2003 e IIS 6.0.

¿Alguna cosa más que deba saber?

De hecho hay un montón de condiciones más que se deben cumplir en otras circunstancias y que impiden que actúe la caché en modo núcleo, así que no nos sorprendamos si no nos funciona muchas veces. Ahora bien, todas las importantes están descritas en el apartado anterior. De hecho la mayoría las podemos cumplir en condiciones normales sin mucho problema así que tengámoslas en cuenta para mejorar el rendimiento de nuestras aplicaciones ASP.NET. Si realmente te interesa conocerlas todas al detalle puedes consultar este artículo de la Knowledge Base de Microsoft cuyo título es bien claro: Reasons content is not cached by HTTP.sys in kernel.

Además ten en cuenta lo siguiente:

1.- Si se hace caché en modo usuario (la más común) se anulan los eventos de la petición excepto Application_BeginRequest y Application_EndRequest de global.asax.

2.- Si la caché se está haciendo en modo núcleo no salta ningún evento, ni siquiera los dos anteriores. Así que mucho ojo con esto si queremos hacer una especie de ‘logging’ propio de la aplicación.

Espero que encuentres todo esto útil.