Poco a poco estamos viendo Backbone.js por todos lados, por su capacidad de vincular eventos de diferentes elementos de la interfaz web, la facilidad que ofrece a los programadores de organizar aplicaciones grandes con Javascript siguiendo una arquitectura con modelos y Vistas y la flexibilidad para elegir cualquier sistema de templates.

Revisando en mis bookmarks he decidido hacer una lista de recursos para aprender sobre Backbone.js y algunos temas relacionados. Todo comienza con Understanding MVC And MVP (For JavaScript And Backbone Developers)

• Backbone.js Tutorial – by noob for noobs
• Backbone Fundamentals (Libro)
• Backbone.js by example – Part 1
• The Responsibilities Of The Various Pieces Of Backbone.js
• Backbone Patterns
• Two headaches explained when you’re getting started with backbone.js
• BackboneFu

Aparte de los enlaces superiores que solo están dedicados a Backbone.js también quise poner algunos enlaces que tratan de temas relacionados muy estrechamente.

• Understanding JavaScript OOP
• The Single Page Interface Manifesto
• Seven JavaScript Things I Wish I Knew Much Earlier In My Career

Creo que esta lista vá a ir creciendo con el tiempo y según mis bookmarks, no es que haya buscado, pero me gustaría encontrar tambien posts sobre Backbone.js en español.

Si tienes algún enlace que pueda agregar en la lista escríbelo en un comentario.

El referrer es la URL de procedencia de un visitante a una página. Esta URL es tomada de header HTTP que envía el servidor con cada request. El referer puede ser tanto una URL externa, como una URL interna en el sitio. HTML5 ofrece la posibilidad de suprimir esta información directamente a nivel de HTML. El atributo rel=noreferrer Le dice al enlace que no pase información del referrer a la página de destino.

El problema con Analytics

Por ejemplo un enlace desde retrorock.info a tu website presentaría “retrorock.info / referal” como source y medium en Google Analytics, sin embargo si retrorock.info usara el atributo rel=noreferrer en sus enlaces no obtendrías ninguna información de referrer y el link contara como un visitante directo “direct / (none)”.

Como esto es un problema? El proposito real de rel=noreferrer es proteger recursos privados. Por ejemplo, imagina el caso de que un enlace venga desde un correo de Gmail o de un Wiki interno de alguna compañía o algo por el estilo. Existe la probabilidad de que al pasar la URL desde donde vino la visita pueda revelar información privada o presentar un riesgo de seguridad, que es por lo cual rel=noreferrer fué introducido. Presenta un problema potencial en cuanto a los analytics, especialmente si es utilizado para razones para las que no fué diseñado.

Como se usa?

La relación noreferrer se puede agregar a los links, igual que la relación nofollow.

Para el usuario final (los visitantes de nuestro sitio) no va a haber ningún cambio aparente, sin embargo, nosotros si podemos tener un interes en marcar nuestros links de esta manera:

• Links despues de una interfaz de administración: Por ejemplo, despues de validar un comentario en un blog o despues de revisar la calidad de un articulo, se tiende a redireccionar al usuario al enlace de destino. Pero en estos casos la información de la referencia no continuará siendo precisa o no es interesante para nada.
• Enlaces desde paginas con identificadores de session en el URL: No es raro ver páginas que utilizan información de la sesión en la URL. Enviar un referer inutilizable no tiene ningún sentido. ahora podemos simplemente desactivar esta información.

Soporte en los browsers

En este momento solo los browsers que utilizan el webkit web browser engine (Google Chrome, Safari) pueden dar uso a esta funcionalidad, pero podemos esperar que emerga su soporte eventualmente y debemos estar atentos.

Leyendo la documentación del API de Tumblr se me ocurrio utilizar esta herramienta de microblogging para hacer algo un poco más personalizado.

El resultado es Tombler. Es una galería de imagenes utilizando los posts tipo picture de mi blog de tumblr.

Es un ejemplo sencillo, pero me da unas cuantas idéas para implementaciones cada vez mas personalizadas.

Highlights

Entre los parametros que podemos utilizar para leer las entradas de un blog hay dos que considero especialmente útiles:

1. Type: Retorna los posts de este tipo, si no se especifica, el llamado devuelve todos los tipos de posts. Puede ser uno de estos tipos text, quote, photo, link, chat, video, o audio.
2. Tagged: Retorna los posts con este tag. Lo encuentro especialmente util junto a la funcionalidad de permitir a cualquiera publicar un post en tu blog y etiquetar los posts de los visitantes con un tag predeterminado.

Como está hecho?

Aunque esto pudo haberse hecho en dos lineas usando simplexml_load_file yo opté por usar CURL, ya que quise seguir experimentando con las opciones de publicación y mandar request POST.

Lo próximo es navegar por nuestra lista de posts:

Alguna parte del contenido de algunos sitios es para uso estricto del webmaster, de los managers, autores, moderadores, etc. Los roles de Drupal restringen acciones específicas, pero no contenido específico. Para eso necesitas ajustar configuraciones e instalar algunos módulos.

No confíes en que no se puede acceder al contenido de Drupal no publicado

Los nodos y comentarios no publicados aún son accesibles. Si te sabes la URL, o la puedes adivinar, los nodos no publicados pueden ser servidos. Como todos los nodos de Drupal tienen una URL en el formato http://TUSITIO/node/ID, no es difícil navegar utilizando valores numéricos consecutivos  para obtener cada nodo de tu sitio, publicado o no.

Drupal no provee restricciones para los nodos individualmente o para los tipos de contenido. Hay varios módulos que pueden agregar esa funcionalidad, incluyendo: Nodeaccess, Node Access, y Content Access.

Restringe el acceso a menús específicos

Drupal no tiene restricciones para los menús o los elementos de un menú específico. Los bloques de menus pueden registringirse por roles en Administer > Site building > Blocks.Para obtener más control hay algunos módulos disponibles, como Menu Access.

Restringe el acceso a bloques específicos

Esconde los bloques privados configurando los permisos para cada bloque en Administer > Site building > Blocks.

Este domingo voy a compartir junto a Bismarck Carreras una ponencia sobre los web standards en el Barcamp de Twitt.do 2010, donde vamos a hablar sobre la importancia de usar web standards hoy para ser compatibles con el futuro, como optimizar el código HTML hasta usar siempre la etiqueta correcta y la estructura correcta, un poco de compatibilidad entre buscadores y de javascript.

El nombre de la charla es Diseñando con Web Standards, vamos a estar en el salón 3 a las 3:30pm.

A medida que Drupal se va haciendo más famoso, inevitablemente surgen interesados en hackearlo, ya sea por información, desacreditar una marca o algunas otras razones. Lo hemos visto pasar con otros proyectos como WordPress y Joomla. Las amenazas a la seguridad de un sitio web siempre van a existir, así que debemos tomar todas las precauciones necesarias para mantener nuestro sitio seguro.

La configuración de seguridad que tiene una instalación nueva de Drupal es muy floja. por lo tanto debemos dar algunos pasos adicionales para que nuestro sistema tenga una seguridad cada vez más estricta.

El primer paso para mejorar la seguridad de una instalación de Drupal es configurar permisos, roles y cuentas de usuario. En otras palabras, controlar como los usuarios crean sus cuentas y que pueden hacer con ellas.

• Deshabilita las creaciones de cuentas de usuarios anonimos. Por defecto Drupal deja que los usuarios anónimos creen cuentas sin preguntar. Esto es una muy buena idea si estás creando un foro o un sitio donde una comunidad va a compartir contenido. Pero si estás creando un blog o un sitio web corporativo vás a necesitar un control de acceso más estricto. Deshabilita la creacián de cuentas no aprobadas en Administer > User management > User settings
• Crea Roles de usuarios. Los roles en Drupal son nombres que se le dan a una serie de permisos que se pueden asignar a los usuarios. Los roles con los que Drupal viene por defecto son Usuario anónimo y Usuario autenticado (que inicio sesión). Evidentemente solo estos dos roles no ofrecen la suficiente granularidad  a la hora de definir permisos. Considera crear un rol Autor para el grupo de usuarios que va a insertar y editar el contenido, Moderador para los usuarios que van a administrar los comentarios y a borrar los comentarios ofensivos y un rol Administrador para los usuarios que puedan hacer modificaciones a la configuración del sitio. Puedes crear los roles en Administer > User management > Roles
• Asigna los roles a los usuarios. Con los roles creados, edita cada una de las cuentas de los usuarios y asignales su rol. Las cuentas de los usuarios estan en Administer > User management > Users
• Configura los permisos. Aunque no hayas creado ningún rol, asegúrate de configurar los permisos. Dirígete a Administer > User management > Access control y comienza por deseleccionar todo. Ahora vuelve y permite que los usuarios anónimos puedan ver algo o todo el contenido, pero nunca lo dejes agregar contenido o administrar tu sitio. Si planeas dejar que otras personas tengan cuentas en tu sitio, restringe los permisos a lo mínimo necesario. No asignes un permiso a menos que sepas que un rol lo necesita.

Con estos pasos comenzamos por definir las politicas de creación de cuentas y controlamos el acceso al contenido en los casos que lo consideramos necesario. Luego de haber ajustado la configuración de las cuentas y los permisos, vamos a restringir el contenido que ven nuestros usuarios (próximamente).

Navegando por el blog de mi amigo Dany me he encontrado con una impresionante charla sobre los fundamentos del desarrollo web.

El expositor (José Carlos Palencia Sanchez) abarca desde temas básicos como los estandares web, sus beneficios y los problemas que podrían representar, la accesibilidad, hasta los Microformats, los principios de la Web semántica. Todo esto desde un punto de vista muy realista.

Hay que verla obligatoriamente!

Estandares Web, Microformats y Mas from dany paredes on Vimeo.

Siguiendo con el tema de OpenID surgen algunas preguntas …

Porqué es útil OpenID? y si ya no creo en mi proveedor de OpenID? que tanta seguridad ofrece OpenID?

La respuesta a todos los problemas es el soporte de OpenID en los browsers? Es OpenID el primer paso para las redes sociales descentralizadas?

Respuestas a estas y otras preguntas en esta presentación de Simon Willison

Una de las ventajas de OpenID es la delegación. Esto significa que en vez de tener tu dirección de OpenID como:

tunombre.myopenid.com

puede ser:

tudominio.com

Un OpenId es simplemente una dirección. Mi OpenID es retrorock.info la dirección de este blog. Puedo usarlo para loguearme en cualquier sitio que soporte OpenID y como soy el único que tiene control sobre el homepage de mi blog, soy la única persona que puede usar esta identidad.

Lo primero es crear una cuenta OpenID, lo mas probable ya tengas una. (más…)