Interesante, y en castellano.
https://www.google.es/webmasters/
Saludos.
Miguel.
Category: Web
Ejemplo de Maquetación con Capas
A continuación os dejo un pequeño ejemplo de una web que ha sido maquetada usando capas en lugar de tablas.
Como podréis observar, los diferentes elementos, además de ciertos cambios básicos de estilos obtenidos mediante CSS, han cambiado su posicionamiento totalmente, algo que mediante una maquetación por tablas hubiera sido imposible.
Cada página cuenta exactamente con el mismo contenido y esta enlazada a un CSS diferente, los cuales si supervisáis, podréis ver que cada una de las capas utilizadas explota los atributos de CSS “clear” y “float” para lograr el cambio en el posicionamiento de los objetos.
Se ha preparado la maquetación solo para Internet Explorer, compreded que se introducen los conceptos a modo didáctivo y que tampoco voy sobrado de tiempo 🙂
Página 1 — CSS 1
Página 2 — CSS 2
Página 3 — CSS 3
Un saludo.
Miguel.
Variables de Sesión en Memoria, Balanceos y Alta Disponibilidad
Una de las herramientas más comunes a la hora de trabajar con aplicaciones web son las variables de sesión.
Dejando de lado en este capítulo las recomendaciones de arquitectura en el uso de las sesiones, simplemente plantear una solución a uno de los típicos problemas que se encuentran los arquitectos de software a la hora de definir el uso de sesiones, que son las limitaciones al uso relacionadas a entornos donde se cuente con una infraestructura que ofrezca alta disponibilidad cuando estamos trabajando con variables de sesión almacenadas en la memoria del servidor.
Para solucionar este problema, existen productos disponibles en el mercado, que lo que hacen es mantener también balanceado el contenido de la sesión de todos los servidores existentes en una granja, por lo que, aunque un usuario a medida que va lanzando peticiones, el balanceador lo vaya dirigiendo a servidores diferentes, podrá seguir trabajando con la información de sesión que haya generado, en memoria, en un servidor diferente.
Os dejo el link a uno de los productos que solventa este problema en entornos .NET: NCache
https://www.alachisoft.com/ncache/
Saludos.
Miguel.
Web, Colas de Mensajería y Experiencia de Usuario
Estrenando en el blog el mundo de las Colas de Mensajería, y la categoría recién inaugurada a tal efecto, hoy vamos a hablar cómo se está explotando en la actualidad las capacidades que ofrecen estos sistemas en entornos web.
A priori, y conociéndo íºnicamente las características básicas de funcionamiento de las aplicaciones cliente-servidor web y los sistemas de colas de mensajería, resulta de extrañar que pueda sacarse algíºn tipo de partido combinándolas, ya que:
- La relación entre un cliente web y el servidor es síncrona y uni-direccional. El cliente solicita la comunicación con el servidor, quedando a la espera de respuesta antes de poder seguir el hilo de ejecución, de forma, insisto, totalmente síncrona.
- En cambio un sistema de gestión de colas es en esencia asíncrono, ya que, a grandes rasgos, consiste en un punto de entrada que va almacenando peticiones en un determinado órden, y que garantiza que las peticiones van a llegar al destino, pero por defecto no garantiza cuándo. En cuanto la petición ha sido procesada, la respuesta se asocia a un punto de salida, el cual la aplicación llamante debe consultar para conocer el resultado del procesamiento.
Entonces, si el trabajo en web es síncrono, y los sistemas de colas de mensajería asíncronos, ¿como podemos obtener algíºn tipo de beneficio? Paso a enumerar escenarios:
- Se debe realizar un cálculo que requiere de tiempos no manejables en entornos web de manera síncrona (más de 1 minuto se podría considerar como inmanejable).
- La petición que se recibe en el servidor sólo es ejecutable en algunas ventanas de tiempo.
- No es necesaria la notificación de ejecución completa al usuario una vez lanzado un proceso, por lo que podemos gestionar internamente cuándo lanzararemos el proceso demandando para optimizar así el consumo de cpu y memoria.
Se pueden encontrar muchos ejemplos de estos usos por ejemplo en redes sociales como Facebook, donde en muchas ocasiones se proponen envíos masivos de notificaciones, invitaciones y noticias a un grupo muy grande de usuarios. Una vez realizada la petición, esta es encolada y ejecutada a posteriori.El usuario no tiene necesidad de conocer a ciencia cierta que la petición se ha ejecutado en el momento, se conformo en saber que los avisos, llegarán. Lo mismo ocurre con otros sistemas muy habituales como son los envíos de SMS a través de teléfono móvil.
La ventaja y moraleja del artículo respecto a todo esto, es que el uso sistemas basados en colas de mensajería ayudan a maximizar la experiencia de usuario en entornos web, ya que tras una petición que podría resultar en una larga espera síncrona hasta que el servidor haya terminado de ejecutar la petición, esta termina al momento (desde el punto de vista del usuario), y el usuario puede seguir utilizando la aplicación sin problemas. Mientras tanto, por detrás, el gestor de mensajes ha encolado la petición, la cual, en su momento, será ejecutada.
Si vuestro escenario es similar al aquí planteado, emplear una solución basada en sistemas de colas de mensajería, podría ser una buena solución de arquitectura.
Saludos.
Miguel.
Consideraciones de Arquitectura respecto al uso de Variables de Sesión
A continuación paso a enumera una serie de consideraciones a tener en cuenta y que os pueden ser íºtiles a la hora de tomar ciertas decisiones de arquitectura al respecto del uso de variables de sesión. Como veréis algunas de ellas tienen que ver con entornos .NET, ya que es la plataforma con la que suelo trabajar, pero la mayoría son aplicables a otros entornos tecnológicos no Microsoft.
Sesión en Memoria vs Sesión en Sistemas Persistidos (Base de Datos o Servicios del Sistema Operativo)
La forma más eficiente de trabajar con sesiones es manteniendo su contenido en memoria. En el caso de estar trabajando con una granja de servidores, pueden utilizarse soluciones existentes en el mercado como es NCache, para balancear el contenido de las sesiones en memoria entre todos los servidores de la granja.
En caso de no poder barajar esta alternativa existen soluciones que permiten almacenar el contenido de la sesión sobre sistemas persistidos. Esta solución es más lenta, pero permite compartir la información de sesión sobre diferentes servidores, además de garantizar que aunque se reinicie el servidor de aplicaciones, la información de sesión va a permanecer disponible cuando la aplicación vuelva a arrancarse.
Cantidad de Memoria en Uso
El uso de sesión afecta directamente al consumo de memoria del servidor que está ejecutando las llamadas del cliente, por lo que deberá almacenarse en sesión íºnicamente la información que se considera imprescindible y que, se recomienda, esté relacionada con alguna de las siguientes características:
- Información básica relacionada con la autenticación o la seguridad del usuario y que es necesario comprobar en las llamadas o peticiones que realiza el usuario contra la aplicación.
- Otro tipo de información funcional asociada al usuario, que va a permanecer estática a lo largo de toda la vida de la sesión y que es requerida de forma constante en las peticiones que realiza el usuario a la aplicación. El objetivo de este punto sería minimizar el níºmero de llamadas a base de datos.
Tipos de Objetos en Memoria
Los objetos almacenados en la sesión deben ser en todo caso de poco peso, minimizando así la cantidad de información almacenada por sesión por cada objeto. Se recomienda el uso de objetos de negocio que incluyan tipos de datos básicos. No se recomienda el almacenamiento de objetos propietarios de .NET del tipo Dataset ó DataTable debido al tamaño asociado a los mismos.
Manejando Información Sensible
Si el contenido almacenado en la sesión contiene información sensible, como podrían ser contraseñas o información personal del usuario activo, ésta deberá permanecer encriptada durante todo el ciclo de vida de la sesión.
Usando Sesión a modo de Caché
No debe emplearse la sesión para almacenar catálogos de datos comunes de la aplicación, como podrían ser listados de países, regiones, provincias, etc, ya que éste no es el objetivo de este tipo de objeto. Para estos casos se deberá recurrir a un objeto de tipo caché.
Usando Sesión a modo de Viewstate (específico .NET)
No se recomienda emplear la sesión para almacenar información que será necesaria explotar entre llamadas a la misma página, ya que para ello existe un objeto preparado específicamente para resolver esta problemática como es el Viewstate de ASP.NET.
Usando Sesión a modo de POST y GET
No debe emplearse la sesión para transportar información entre páginas de la misma aplicación, ya que para ello se deberá recurrir a los objetos POST y GET.
Liberando Información de Sesión
Siempre y cuando se detecte que la información almacenada en sesión deje de ser necesaria para la sesión de usuario actual, se debe solicitar la liberación de la memoria asociada al servidor.
Saludos.
Miguel.
ASP.NET Report Viewer y Reserved.ReportViewerWebControl.axd
Hace unos días se incorporó un artículo muy similar que hablaba de problemas de autorización de recursos al utilizar AjaxControlToolkit.
Hoy solventamos un problema muy similar, cuando estamos utilizando el control de ASP.NET Report Viewer en una aplicación que utiliza la seguridad de ASP.NET
En este caso el location que deberéis añadir es el siguiente:
<location path=”Reserved.ReportViewerWebControl.axd”>
<authorization>
<allow users =”*” />
</authorization>
</location>
Saludos.
Miguel.
Migrando de Escritorio a Web, el Problema de lo "static"
Paso a describir uno de los típicos problemas que suele aparecer a las personas que desarrollan normalmente aplicaciones de escritorio y que entrar a participar en un proyecto en el que se requiere desarrollos web.
En escritorio, es algo muy comíºn el utilizar propiedades estáticas (shared en VB.NET, static en C# y Java) para almacenar información que la aplicación necesita desde que arranca hasta que se cierra, o en algíºn formulario específico donde se esté trabajando de manera desconectada de la base de datos. Por ejemplo, la información del usuario activo, o el listado de facturas que se están presentando en un formulario en concreto. En este ámbito el uso de propiedades estáticas funciona a las mil maravillas ya que la aplicación se ejecuta en el contexto del usuario y hay un íºnico usuario accediendo a la posición de memoria reservada por la propiedad estática.
El problema viene cuando intentamos hacer lo mismo en web, por ejemplo en la capa de presentación web, donde tenemos una página (aspx, php, jsp, jsf…) que muestra las facturas relacionadas a un determinado cliente, facturas que además, tras cada transacción que realizamos contra el formulario, van modificando su información. Si en este ámbito utilizamos una propiedad estática para almacenar las facturas, de igual manera que con la aplicación de escritorio, estamos compartiendo una íºnica instancia de la lista, pero esta vez con una pequeña diferencia, aunque tengamos 1 o 100 usuarios accediendo al formulario, todos están trabajando contra la misma aplicación, por lo que todos están trabajando con la misma lista de facturas. La consecuencia de esto es obvia, ante las modificaciones que realicen cualquiera de los usuarios sobre la lista (al ser la misma para todos), afectará al trabajo del resto de usuarios.
¿Soluciones? Para la web existen otro tipo de soluciones dependiendo del tipo de información a almacenar y del rendimiento que queráis obtener: Sesión, Caché, Viewstate (para aplicaciones ASP.NET), campos Hidden (vale, vale, se está liando mucho la cosa, pero funcionar funciona, aunque le tengas que meter muchas horas), y, por supuesto, guardando en base de datos, que viene siento lo habitual y más recomendable en la mayoría de los casos.
Cualquier duda sobre algíºn problema en particular, dejad vuestro caso en los comentarios e intentaremos encontrar la solución más eficiente para vuestro contexto. Por favor, indicad problema y requerimientos de sistema.
Saludos!
Miguel.
AjaxControlToolkit y WebResource.axd
AjaxControlToolkit es el conjunto de controles web ajax provistos por el propio Microsoft y totalmente compatibles con Visual Studio 2008 y Framework 3.5 de .NET.
Hoy hablaremos brevemente cómo resolver la problemática que nos podemos encontrar si combinamos el uso de dicho Toolkit con la seguridad básica de ASP.NET.
Ante claíºsulas como la descrita en la parte inferior:
<authorization>
<deny users=”*” />
</authorization>
estamos denegando el acceso a cualquiera de los recursos de la aplicación, a todos los usuarios que no cuenten con cierto tipo de autenticación. Cuando hablamos de recursos estamos hablando de recursos de cualquier tipo, entre los cuales estamos incorporando páginas aspx, javascript, imágenes, hojas de estilo, themes…
Para resolver el acceso total a recursos necesarios a nivel de aplicación como por ejemplo hojas de estilo, imágenes y javascript podemos combiar el anterior tag con el siguiente:
<location path=”images”>
<authorization>
<allow users =”*” />
</authorization>
</location>
donde podemos apreciar cómo para todos los usuarios estamos dando acceso a la carpeta donde estamos almacenando las imágenes. Si no hiciéramos esto, las páginas aspx se cargarían, pero no podríamos ver las imágenes que tuviéramos contenidas.
Algo muy similar pasa cuando utilizamos Ajax Control Toolkit, vamos a necesitar indicar la visibilidad de sus recursos a los usuarios para que puedan ejecutar los controles ajax, tanto la funcionalidad javascript que incorporan como sus imágenes y estilos relacionados. Para ello, no tenemos que dar permisos a una carpeta concreta, si no a un fichero que no es visible en tiempo de diseño, pero que sí podremos observar si lanzamos la aplicación. Se trata del archivo WebResource.axd.
Añadiendo el nuevo location
<location path=”WebResource.axd”>
<authorization>
<allow users =”*” />
</authorization>
</location>
conseguiremos nuestro objetivo. Nuestros controles ajax volverán a funcionar correctamente, veremos las imágenes relacionadas a los controles, así como sus estilos.
Saludos.
Miguel.
Ejemplo de Guía de Estilos
Dando una vuelta por la red, me he encontrado una muy completa Guía de Estilo Web que puede servir como referencia a muchos de nosotros.
Me ha llamado la atención, ya que a parte de definir cosas típicas como tipos de letras, organización de los meníºs, tamaños de las fuentes, tipos de maquetaciones, etc; al ser una guía pensada para una institución píºblica hace mucho énfasis en temas de accesibilidad (nunca viene mal conocer detalles al respecto), así como en las íºltimas posibilidades incorporadas en las íºltimas versiones de HTML y CSS.
Realmente os recomiendo echarle una ojeada.
Descargar Guía de Estilo Web
Saludos.
Miguel.
Google PageRank = 4
Hola a todos,
Interesantísima buena noticia, esta semana el blog ha pasado de estar valorado con un PageRank 3 a estarlo con 4.
Muchísimas gracias a todos por visitar los artículos, la mejor noticia para mi es saber que a alguien le puedan ser íºtiles todas las referencias que se van incluyendo, y a cuantos más sea, mejor 🙂
Abrazos!
Miguel.