Alberto hace una presentación acerca de qué son los blogs y la blogosfera, y aporta recomendaciones sobre como enfocar su uso a nivel empresarial y personal. Explica también otros temas relacionados como la importancia de los micromercados y algunas herramientas relacionadas como buscadores, estadísticas y sindicadores.

El libro se pude descargar en formato PDF bajo licencia Creative Commons o si te gusta más el formato papel puedes comprarlo por 12€.

El documento incluye referencias a las principales técnicas, como Cross Site Scripting (XSS), Inyecciones SQL, Malicious File Execution(RFI) o Cross Site Request Forgery (CSRF), por poner unos ejemplos. En el documento se explica cada una de estas vulnerabilidades mostrando también la forma en la que se pueden evitar, por lo que su lectura es más que recomendable para toda persona implicada en el desarrollo de aplicaciones web.

Portada del web --> página de sección --> página de subsección

En las siguientes líneas voy a explicar cómo realizar estos menús mediante elementos <li> y CSS.

La primera cuestión se refiere a la resolución de pantalla para la que debemos diseñar y desarrollar las páginas. Hasta hace poco era norma hacerlo para 800×600 dado que era la resolución más habitual, pero con la avalancha de monitores de gran tamaño del último año o dos años, casi siempre además TFT, esta norma ha cambiado. En estos momentos de hecho se estima que únicamente un 17% de usuarios navegan a una resolución de 800×600, mientras que un 60% lo hacen a 1024×768, e incluso un 18% a resoluciones aún mayores, como 1280×1024. Este hecho inclina la balanza de forma significativa hacia diseños basados en 1024×768, lo que puede abrir nuevas posibilidades en muchos proyectos. En cualquier caso esto no implica que haya que olvidarse de ese más de 20% de usuarios con resoluciones menores, entre 800×600 y aún menores. Para estos casos tendremos que diseñar las páginas usando varias reglas, como poner la información más importante en una zona que sea visible en diferentes resoluciones.

Además de la resolución, y relacionado con los diferentes tamaños que puede haber, es importante en un proyecto decidir que estructura de página se va a utilizar. Jakob Nielsen recomienda utilizar una estructura líquida que se amolde al tamaño de ventana utilizada por el usuario. En mi opinión esto es bueno en muchos casos, pero coharta demasiado las posibilidades de diseño en muchos otros. En lo que sí estamos de acuerdo es en que a estas alturas el diseño basado en estructuras fijas no es adecuado, principalmente por cuestiones de accesibilidad. Los usuarios deben disponer de la opción de modificar el tamaño de las fuentes para mejorar su legibilidad si así lo necesitan, sin que el diseño de la página se vea afectado. Una estructura fija no permite esto, sin embargo hay más alternativas aparte de la estructura líquida. Una posible opción es la llamada estructura elástica, que mezcla lo mejor de ambos mundos. Por un lado dispondremos de las facilidades que nos brinda una estructura fija para maquetar diseños y controlar la disposición de cada pieza, y por otro, dispondremos de mecanismos que permitan que este diseño se agrande o achique cuando el usuario modifique el tamaño de las fuentes.

El toolkit se puede utilizar sobre cualquiera de los entornos habituales de desarrollo Java, como Eclipse o Netbeans, aparte de poder utilizar las herramientas habituales como JUnit o JProfiler. Todo esto permite crear aplicaciones basadas en Ajax de una forma más eficiente y menos propensa a errores, pudiéndose incluso depurar la aplicación en el entorno Java.

El toolkit dispone de un conjunto de widgets que podemos utilizar en nuestras aplicaciones, como paneles, pestañas, árboles, menús… Merece la pena también destacar algunas características interesantes que ofrece, como la comentada capacidad de depuración, gestión de la historia del navegador para que se puedan usar los botones de adelante y atrás en nuestra aplicación ajax, compatibilidad con los navegadores actuales y por supuesto, la posibilidad de incluir código Javascript propio.

Y ahora pensando un poco más, ¿qué nos ofrece este toolkit realmente? Pues de primeras lo que se me ocurre es que pese a que los widgets ofrecidos sean pocos y no muy vistosos, aporta una nueva visión de cómo realizar aplicaciones Ajax, que puede ser muy ventajosa. Actualmente desarrollar una aplicación Ajax implica programar el lado del servidor, diseñar el html, y escribir todo el Javascript que controla el Html poniéndose en contacto con el servidor, todo ello muy entrelazado y relativamente complejo de independizar y controlar. Con este toolkit podríamos diseñar la aplicación teniendo en cuenta que vamos a hacer el lado servidor por ejemplo en PHP, definiendo un conjunto de servicios que se utilizarán posteriormente desde el navegador de los usuarios. De forma independiente podríamos diseñar el interfaz de usuario en Html y la lógica que lo controla mediante Java (o cualquier otro lenguaje llegado el caso), depurarlo, y una vez testeado compilarlo a Javascript. Habríamos conseguido principalmente simplificar el desarrollo del interfaz reutilizando componentes existentes, habríamos simplificado las comunicaciones con el servidor usando las capacidades RPC del toolkit, y tendríamos una aplicación mucho más estructurada y mantenible, a la vez que menos propensa a errores.

En realidad este mensaje es una muestra más de hasta donde puede llegar a ser pernicioso el tema de las patentes de software. Resulta que Microsoft llevaba bastante tiempo en juicios con una empresa llamada Eolas, que tiene la única licencia de utilización de una patente registrada por la Universidad de California, referente a la inclusión de plugins dentro de páginas web. Finalmente Microsoft ha sido condenada a pagar la friolera de 560 millones de dolares y se ha visto obligada a crear un parche para el explorer que modifica la carga de los plugin, entre ellos flash, de forma que el usuario no pueda interactuar con ellos hasta hacer click voluntariamente.