Lanzamiento de Gente QUÉ

Tras un par de meses de desarrollo intenso, y otro par de semanas de rush final demencial (sin los lanzamientos ésto no sería tan divertido), ve la luz, por un lado, el rediseño de la web del Diario QUÉ, y por la parte que nos toca, su estrenada y flamante plataforma de comunidad, Gente QUÉ.

En un mercado con muchos medios tradicionales aferrándose a un papel que cada vez huele más a muerto, el QUÉ se lanza en bomba a la piscina con una estrategia innovadora y apostando con fuerza por el usuario.

En líneas generales, la primera fase, el core del proyecto, es una plataforma de single sign-on que permite al usuario tener su perfil en Gente QUÉ y utilizar dichas credenciales para acceder a cualquiera de los servicios que se integren con la plataforma, de manera que cuando te logueas en uno, la sesión se mantiene durante toda la navegación por el “ecosistema” que se está montando alrededor del QUÉ.

Dejando de lado el análisis pseudo-gurú, desde el punto de vista del desarrollo yo destacaría las siguientes funcionalidades:

• ID ÚNICO. Con la facilidad de uso para el usuario en mente se ha integrado el logueo a través de sistemas externos, en concreto, con Facebook, Windows Live, Yahoo y OpenID, de manera que una vez autenticado en uno de ellos se puede registrar una cuenta en Gente que quedará ligada a dicho ID, pudiendo a partir de entonces utilizar todos los servicios del QUÉ accediendo a través de tu usuario de Facebook, por ejemplo ¡no más contraseñas desperdigadas por Internet!

  Una de las mayores complicaciones de esta parte era implementarlo de forma que el usuario lo entendiera, que no se mareara cuando de repente se le redirige a una página externa, y que pudiera darse cuenta de los beneficios que tiene esta funcionalidad. Considero que lo hemos conseguido simplificando el proceso al máximo, aunque es verdad que debemos pulirlo en las fases que vendrán.

  Lidiar con las APIs de cada servicio ha sido una de cal y otra de arena. Para variar, hacer algo con Windows Live es un picor constante en busca de documentación decente e intentando resolver comportamientos demenciales. El resto chapó. También las hemos utilizado para obtener los contactos de las cuentas e invitar a nuevos amigos. En breve haré un post explicando con detalle cómo integrar cada uno de ellos.

  
• LIFESTREAMING. Tal vez la característica más diferenciadora respecto a iniciativas de otros medios sea ésta de registrar la actividad que generan los usuarios en los servicios integrados en la plataforma. Cuando se llega al punto en que hasta los de Windows Live salen del caparazón, era un paso lógico para el QUÉ, ya que tenían centralizado el login, hacer lo mismo para la actividad del usuario.

  En gran parte relacionada con esta funcionalidad está la de comunidad, con la posibilidad de seguir a usuarios y por lo tanto, su actividad. En esta primera fase las relaciones quedan limitadas a ésto, pero habrá muchas novedades en este sentido en breve.

  
• BARRA DE USUARIO. Los servicios que se integran con Gente QUÉ debían tener alguna marca que así los identificara, y también con la necesidad de ofrecer un acceso rápido a las funcionalidades de la plataforma, se desarrolló esta barra inspirada en la de Facebook. Ahora mismo ofrece simplemente eso, accesos directos, pero es una de las partes del proyecto que más añadidos y atención va a recibir en los próximos meses, estoy seguro. Podéis verla por ejemplo desde la misma portada del QUÉ.

  Para nosotros el mayor reto fue implementar todo el tinglado con javascript, con pequeñas pijaditas como los tooltip informativos y grandes brownies como controlar si hay una sesión iniciada en Gente QUÉ desde servicios externos o idear una forma de sincronizar dicha sesión con la local, pero vamos, esto es material para otro post.

  
• APIs. Desde el principio teníamos claro que estábamos haciendo una plataforma de servicio, así que todas las funcionalidades son accesibles a través de APIs propias, de manera que cualquier servicio externo se puede integrar de forma prácticamente transparente con la plataforma de forma sencilla y rápida. Un total de más de 15 APIs y 30 páginas de documentación dan fe de lo grande que es este proyecto y la casi total flexibilidad que ofrece para futuras integraciones y cambios.
  

Para nosotros ha sido un proyecto complicado, pero con el que sobre todo hemos aprendido mucho. Cuando te metes en desarrollos de este tipo, tan dinámicos y con programadores de todos los niveles, se descubren enseguida las carencias en la metodología de trabajo que puedas tener. Ahora es cuando nos vamos a plantear implantar cosas de esas que usan los profesionales con carrera (framework, subversion, gestión avanzada de bugs…), hasta ahora hemos podido pasar sin ellas, pero la cosa se pone seria!

Error en la codificación con AJAX

Pelearse con la codificación de los caracteres en una aplicación web es pan nuestro de cada día. En un desarrollo sencillo uno puede olvidarse de ese detalle y dejar el trabajo de cloacas al navegador y el PHP. Pero en el momento en que entran en juego javascript y fuentes externas de datos, es entonces cuando la posibilidades de cagarla se multiplican.

Una de las formas más sencillas de prevenir problemas con la codificación es utilizar siempre UTF-8 para el desarrollo completo de la aplicación. Ésto incluye la base de datos, una línea al principio de todo script:

header('Content-type: text/html; charset=utf-8');

También en los HTML:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Y por supuesto, que el fichero esté físicamente codificado en UTF-8, cosa que cada uno deberá hacer con el editor de código correspondiente (mi experiencia con Ultraedit en este sentido es inmejorable).

El horror comienza cuando no has hecho los deberes, y a una aplicación sencilla se le quiere empezar a meter AJAX y datos de diversas fuentes. Por defecto tu tinglado estará utilizando seguramente ISO 8859-1, la codificación del alfabeto latino, y éso es lo que va a estar esperando el navegador a no ser que le indiques lo contrario…

Estos problemas de codificación se pueden deber a múltiples razones, sería imposible cubrirlas todas en un post, así que me centraré en las dos con las que he tenido que lidiar estos días:

• API EXTERNA. Aquí no queda otra, Si la API no ofrece un parámetro para especificar la codificación, va a venir en UTF-8 prácticamente seguro y tocará hacer en el código, por ejemplo en PHP, un utf8_decode de lo que devuelva.
• AJAX. La diversión con la codificación de caracteres cuando entra en juego el javascript puede no llegar a tener límite. Si, para más inri, utilizamos AJAX para comunicar con un script pongamos de PHP, entonces tenemos todos los ingredientes para la empanada de caracteres raros.

  Obviando detalles de bajo nivel como que el objeto XMLHttpRequest que se encarga de esta comunicación utiliza siempre UTF-8, o que dependiendo de si utilizas GET o POST e Internet Explorer o Firefox se usará una codificación u otra, vemos que las combinaciones pueden marear hasta la náusea, así que hay que buscar una solución que funcione independientemente de la codificación origen-destino, el navegador o el protocolo utilizado.

  Tras varios intentos, dí con una combinación que parece comerse cualquier barbaridad que se pueda poner en un formulario (una caja de texto que acepte código de programación, textos chinos o búlgaros… es un reto). El flujo sería el siguiente:

  1. Desde el javascript mandamos los datos codificados con la función encodeURIComponent (utilizar otra nos dará problemas con los caracteres & y +), por ejemplo:

     ajax.open('get','url_script.php?datos='+encodeURIComponent(datos),true);

  2. Dependiendo del lenguaje de programación que se utilice en el script que recibe los datos habrá que hacer una decodificación o no de los mismos. PHP automáticamente lo realiza para lo que recibe por GET, como en este ejemplo.
  3. Para devolver la respuesta, con PHP utilizamos rawurlencode para codificarla (esta función lo realiza de forma más estricta que urlencode). Por ejemplo:

     echo rawurlencode($respuesta);

  4. Finalmente, de vuelta a javascript, decodificamos la respuesta con decodeURIComponent, y ya tenemos una bonita cadena de caracteres lista para utilizar sin problemas de codificación. Por ejemplo:

     var respuesta = ajax.responseText;
     div.innerHTML = decodeURIComponent(respuesta);

En definitiva, hay que utilizar UTF-8, hay que dejarle al navegador muy claro que lo estamos haciendo, y tenemos que usar una serie de métodos para que en el trasiego de la información entre distintos lenguajes y scripts no se pierda la codificación.

Advernet Somos Todos

Una pequeña muestra de contenido propio grabado en nuestras oficinas :D

Semana 2 / El Cerebro de la Bestia

Y como el último enlace a mi me trajo muy buenos recuerdos de aquellos tiempos de las primeras consolas, me puse a regodearme en la nostalgia y encontré esta joyita, yo todavía tengo el VHS y la Hobby Consolas original en casa :_)

“y porque su memoria es ¡ojo! de 256k…”

Plantilla personalizada para las Páginas de WordPress

Los que hayan utilizado WordPress para crear un blog saben que en él se pueden escribir Posts (Entradas) y Páginas. Los Posts son el núcleo del blog, y van a tener el diseño del tema que estés utilizando. Las Páginas por su parte son entidades estáticas, o más bien atemporales, que puedes añadir a la estructura de tu blog.

El tema es que si ves un Post y una Página de un blog no se puede diferenciar a simple vista qué es cada cosa. Mi problema era que quería tener Páginas que cuando estuvieran publicadas no mostraran elementos propios de los Posts, como la fecha de publicación, comentarios, tags, categoría… así como la posibilidad de tunear si fuera necesario un poco la estructura que me impone el tema que utilizo.

Indagando un poco descubrí una funcionalidad que ofrece WordPress para las Páginas, los Page Templates. Al final es todo tan sencillo como añadir la siguientes líneas al principio de un fichero php que debes tener en la carpeta del tema que utilices:

<?php
  /*
  Template Name: pagina limpia
  */
?>

Lo que yo hice fue coger el fichero page.php, que es el que se utiliza por defecto para las Páginas, renombrarlo a page-limpia.php, añadirle al principio las líneas arriba mencionadas, y quitar lo que me sobraba (comentarios, fechas…). Al ir a crear una nueva página, WordPress detectará esta nueva plantilla y aparecerá una nueva opción avanzada en el editor: