Aquí os traigo un pequeño script que he hecho para enterarme de esto. Sé que hay por ahi muchos servicios que hacen lo mismo, los he probado y todos me han parecido una chusta, publicidad, desfase en la notificación y en general nada que cumpla bien algo tan simple como esto. Por eso he acabado tirando unas líneas de código para tenerlo en mi propio servidor y hacer exáctamente lo que espero, que es muy sencillo: recibir un email cada vez que alguien deje de seguirme en Twitter. A continuación explico algunos detalles de esta mini aplicación que podéis descargar desde github.

Lo primero aclarar que obviamente no es una aplicación de uso general, por las siguientes peculiaridades:

• Aunque fácilmente modificable, hace únicamente lo que yo necesito, explicado al principio
• Está limitada a 5000 followers (por defecto el límite de la API de Twitter si no se utiliza paginación), cuando sobrepase esa cifra ya lo modificaré ;)
• Utiliza un fichero para almacenar los followers y arrays para comparar, lo cual con un número elevado de ellos no sé cómo rendirá

Al turronaco. El único requerimiento es la extensión curl de PHP, que se utiliza para llamar a las APIs de Twitter. La gestión de errores es como un martillo, si no hay curl o alguna API devuelve un error el script termina, no necesito nada más sofisticado.

La única personalización necesaria está en el fichero twitter_unfollowers.php, para los campos del email que recibiremos:

11
12
13
14
15
16
17
18

// fichero donde se guardan los followers para posteriormente compararlos con los actuales
define('FIC_GUARDADO', 'twitter_followers_{USUARIO}.db');
// poner a 0 si no quieres recibir un email con la lista de unfollowers
define('ENVIAR_EMAIL', '1');
define('EMAIL_DIRECCION', 'xxxx@yyyy.com');
define('EMAIL_ASUNTO', '[TWITTER] Te ha(n) desfollogüeado {NUM} usuario(s)');
// dirección válida en el servidor donde se ejecuta el script para que el email no se vaya al spam
define('EMAIL_REMITENTE', 'iiii@jjjj.com');

Podemos utilizar esta clase en un simple script que se pondría en el cron, como por ejemplo:

1
2
3
4
5
6
7
8
9
10
11

<?php
 
	require('twitter_unfollowers.php');
 
	$tuiter = new Twitter_unfollowers('<id_usuario_twitter>');
 
	$tuiter->check_unfollow();
 
	echo 'fin';
 
?>

Changelog

v1.0 – Desarrollo inicial
v1.1 – Eliminada la necesidad de autenticarse con OAuth para utilizar las APIs
v1.2 – Arreglados problemas de codificación y control de errores de la API

En mi caso concreto pepe.com es un dominio antiguo, y quiero que toda referencia a él acabe en el nuevo, digamos paco.com. Para ello utilizo un htaccess que hace una redirección 301 a lo bruto:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)$ http://www.paco.com [R=301,L]

Éste es mi problema concreto, pero por ejemplo es también muy común en frameworks y CMS hacer una redirección general de todas las peticiones a un único fichero. Vamos, que aquí lo importante es la reescritura general.

Ahora lo que quiero es proteger con contraseña el acceso a mi administración, por lo que utilizo otro htaccess con el contenido estándar para ésto:

# colocado en /home/web/pepe/admin/.htaccess
AuthType Basic
AuthUserFile /home/web/pepe/admin/.htpasswd
AuthName "Acceso Administrador"
Require valid-user

Y como no podía ser de otra forma el invento no funciona. Cuando intento acceder a http://www.pepe.com/admin me redirige a http://www.paco.com, luego el primer cambio es meter una excepción para que no aplique la regla de reescritura para la URL que nos interesa. Lo podemos hacer en el htaccess principal con una condición:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/admin/?RewriteRule ^(.*)$ http://www.paco.com [R=301,L]

O si no necesitamos de ninguna reescritura en el directorio hijo podemos directamente desactivar el engine:

# colocado en /home/web/pepe/admin/.htaccess
RewriteEngine offAuthType Basic
AuthUserFile /home/web/pepe/admin/.htpasswd
AuthName "Acceso Administrador"
Require valid-user

Cojonudo, pero sigue haciendo la redirección. Primera comida de cabeza importante: comento todas las reglas de reescritura y sigue redirigiendo ¿? resulta que Firefox cachea las redirecciones (al menos las 301), así que ya puedes darle a F5 y estar correctas las reglas, que no te enterarás si no borras la caché del navegador, eso o utilizar Explorer (no lo he probado en el resto).

Descartado el navegador, ésto sigue sin rular. Utilizando el imprescindible HttpFox y Google descubro que la autenticación básica de Apache que queremos usar manda una cabecera 401 Unauthorized, que el navegador recibe y es cuando muestra el cuadro de usuario/contraseña. Segunda comida de cabeza importante: el servidor está buscando un mensaje de error personalizado para el 401 (en una directiva ErrorDocument), que no encuentra y por tanto lanza, adicionalmente, un 404. Y resulta que, no me preguntes por qué, este último error pasa por la reescritura general y es lo que está provocando la redirección. Acojonante. La solución es definir dicho ErrorDocument en nuestro htaccess:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/admin/?
RewriteRule ^(.*)$ http://www.paco.com [R=301,L]
ErrorDocument 401 "Acceso restringido"

¡Aparece el cuadro para meter usuario/contraseña! joder, ha costado.

El ejemplo por antonomasia es por supuesto el de Google Reader, pero hay muchos más: Facebook (fijaros que lo hace una vez cuando vas a mitad de página), Digg, Bing, Vimeo, Dropular….

Básicamente consiste en cargar más contenido dinámicamente conforme te acercas al final de la página, de forma que la navegación por el mismo no queda interrumpida en ningún momento. Viene a ser un sustitutivo de la paginación tradicional.

Luego comentaré los pros y contras que pienso tiene esta técnica. Antes contar cómo lo he implementado en mi tumblr, micro Usuario de Internet, algo que llevaba bastante tiempo queriendo hacer y que sin duda opino le va como anillo al dedo.

Aunque en principio tenía intención de remangarme, encontré un plugin, de-pagify, que lo implementa de forma muy flexible y aprovechando parte de la magia de jQuery. Utilizar un framework de javascript simplifica considerablemente la codificación del método, que de otra forma sería bastante más laboriosa, sobre todo el paso de procesar el contenido para pintarlo en pantalla.

En la página del plugin viene todo explicado muy claramente, sólo destacar dos cosas:

• Hay 4 formas de lanzar el evento para traerse más contenido. Se configura con el párametro trigger, y puede ser cuando se llegue a un % de altura de la página, a una altura determinada (pixels), cuando se vea un determinado elemento de la página (mi elección) o incluso dependiendo de la salida de una función propia. La flexibilidad es máxima.
• Como he comentado, utilizar jQuery ahorra mucho código, y una de las perlas que más me ha gustado es la siguiente línea:

  // Format url as "?page=1 div#wrapper div.post"
  var url = [next.attr('href'), options.container, options.filter].join(' ');

  El método de ajax load, que es con el que nos vamos a traer el contenido de la siguiente página para pintarlo dinámicamente, permite especificar la URL con selectores separados por espacios, de manera que podemos controlar qué elementos, qué HTML al fin y al cabo, queremos que se cargue en la capa que eligamos. Ésto nos ahorra de una tacada tener que hacer alguna modificación en el código de la aplicación (se van a ir pidiendo por ajax sucesivas páginas como si la navegación fuera la clásica) y tener que procesar el HTML que recibimos (se pinta tal cual porque ya viene filtrado con el contenido, lo único que he tenido que modificar de la página es un poco la maquetación).

En definitiva, y en mi opinión:

PROS

• Experiencia de usuario: no tengo la menor duda de que, para cierto tipo de webs y, sobre todo, de contenido, el eliminar la paginación supone una mejora muy significativa en la forma de navegar por el sitio, comportándose de la forma natural en la que uno esperaría moverse por él.
• Consumo: cuando desaparece el punto final (pie de página y paginación) pasa a ser un comportamiento natural el hacer scroll indefinidamente y por tanto seguir consumiendo el contenido de manera indefinida.

CONTRAS

• Experiencia de usuario: y no es una contradicción, la nueva forma de navegación puede confundir a muchos usuarios menos duchos en esto de Internet, acostumbrados a los puntos de ruptura (paginación), a saber por qué página del libro van y a una estructura de web más convencional.
• Implementación: no es tema trivial, ya no técnicamente, sino desde el punto de vista de la usabilidad. Por ejemplo está muy unido al dispositivo utilizado: con la rueda del ratón todo es maravilloso, con el teclado o arrastrando la barra de scroll ya pueden darse saltos incómodos. La norma aquí es que sea prácticamente imperceptible para el usuario lo que se está cociendo de fondo (aquí tengo que mejorar mi implementación).
• Monetización: en sitios que se ganan las habichuelas con la publicidad puede suponer un problema la ubicación de los bloques de anuncios. Un esquema típico de jumbobanner arriba, roba a la derecha y Adsense bajo el contenido queda bastante desvirtuado con esta navegación. Lo mismo con páginas vistas (solucionable con una buena semilla).

Entradas relacionadas:

1. Error en la codificación con AJAX
2. Internacionalización con Smarty

El temita de la internacionalización (i18n para los amigos) en una aplicación web puede dar para largo y tendido, yo voy a hablar aquí concretamente de la forma de guardar y utilizar las cadenas de texto del site en varios idiomas utilizando el framework de templates Smarty.

Hay muchas formas de hacerlo, se pueden encontrar varias alternativas en este post de best way to build a multi-language site with smarty, que empezó en el ¡2003! (el frenético ritmo que lleva la tecnología hace que no me crea nada que no sea de ayer…). Todas tienen sus ventajas e inconvenientes, y dado que no hay nada en el core de Smarty para ésto ni una solución popularmente aceptada como la estándar, cada uno debe analizar lo que necesita para su proyecto y tener unas preferencias subjetivas, que en mi caso son:

• Que no implique PHP: obviamente hay opciones mucho más sofisticadas, eficientes, etc… para solucionar el tema del i18n con programación (por ejemplo smarty-gettext), pero precisamente el uso de Smarty es para separar la lógica de la aplicación de la de presentación, y dado que considero que ésto es problema de front-end puro, yo quiero resolverlo únicamente con Smarty.
• Que sea sencillo y eficiente: con el tiempo me estoy conviertiendo en un talibán del código, en el sentido bueno (creo) de intentar que las cosas se hagan de la forma más clara posible (KISS power!) y que note un pinchazo en el corazón con cada ciclo de reloj que se consume en código prescindible.

Por ejemplo, hay una solución muy buena y que he utilizado en otros proyectos, SmartyML, pero es una clase más en PHP (una capa más para procesar) y viendo tanto código pienso que debe haber una forma mejor de hacerlo.

Pero vamos al turrón. Al final encontré en el foro antes mencionado la solución que me parece más sencilla y adecuada para lo que necesito. Se trata de utilizar archivos de configuración (1ª ventaja: es una funcionalidad core de Smarty, con lo que no hay que añadir más complejidad). En estos ficheros se definen variables globales para los templates y se pueden aplicar de varias formas:

// desde el PHP
$smarty->config_load('fichero.conf');
 
// desde el template
{config_load file='fichero.conf'}

Yo prefiero hacerlo desde PHP porque la gestión del idioma de la web es lógica de aplicación y hay que poner cada cosa en su sitio. El directorio donde se almacenan estos ficheros debe ser definido en el código:

$smarty = new Smarty();
$smarty->config_dir   = '/path/al/directorio/';

Crearemos un archivo por idioma, en los que tendremos todas las cadenas de texto que vamos a utilizar traducidas, por ejemplo:

# /path/al/directorio/es.conf (español)
saludo = hola!
enviar = Enviar
cancelar = Cancelar

# /path/al/directorio/en.conf (inglés)
saludo = hi!
enviar = Send
cancelar = Cancel

Utilizar estas variables en los templates es tan sencillo como usar la sintaxis {#variable#}, por ejemplo:

<strong>{#saludo#}</strong>
<input type="button" name="enviar" value="{#enviar#}" />
<input type="button" name="cancelar" value="{#cancelar#}" />

¡Y ya está! desde el PHP se puede controlar qué archivo de configuración de idioma cargar y de esta manera tener montada nuestra web multilenguaje. Unos últimos apuntes:

• Las cadenas también pueden llevar texto variable, como por ejemplo un saludo del tipo Hola Fernando, bienvenido! Ésto se puede solucionar de dos formas:

  # forma CUTRE: en el tpl
  <strong>{#saludo1#}{$nombre_usuario}{#saludo2#}</strong>
   
  # en el archivo de configuración de idioma
  saludo1 = Hola
  saludo2 = bienvenido!

  # forma CORRECTA: en el tpl
  <strong>{eval var=#saludo#}</strong>
   
  # en el archivo de configuración de idioma
  saludo = Hola {$nombre_usuario}, bienvenido!

• En lo que entiendo es una optimizacion (supongo que a nivel interno se controlará), se pueden utilizar secciones (referenciadas así [seccion]) en el archivo de configuración, de manera que si se especifica una en el config_load sólo esas variables se cargarán (la que estén fuera de una sección estarán siempre disponibles). Ésto nos puede servir para organizar las cadenas de texto por página y suponer que Smarty lo manejará mejor que el chorro completo de variables. Quedaría así:

  # cadenas globales
  saludo = Hola!
  enviar = Enviar
   
  # página de login
  [login]
  titulo = Introduce tu usuario y contraseña

  Y desde el PHP:

  $smarty->config_load('es.conf','login');
  $smarty->display('login.tpl');

• Una desventaja es que no maneja de manera nativa los plurales como otras soluciones, de forma que hay que controlarlo a manubrio, por ejemplo:

  # en el tpl
  {eval var=#subida_fotos#}{if $num_fotos > 1}s{/if}
   
  # en el archivo de configuración de idioma
  subida_fotos = Has subido {$num_fotos} foto

Entradas relacionadas:

1. Error en la codificación con AJAX
2. Scroll infinito con jQuery

La filosofía del single sign-on ha terminado imponiéndose por pura lógica de saturamiento 2.0, con los grandes jugadores vendiendo sus nuevas propuestas (OpenID lo intentó y no lo consiguió…) y los usuarios cansados de procesos de registro y contraseñas varias. Darles a éstos la oportunidad de usar sus credenciales de alguno de los servicios top para utilizar tu sitio debería ser ya a estas alturas planteado como una funcionalidad primaria de cualquier proyecto web.

Lo que viene a continuación es una guía para implementar en tu web la funcionalidad de “login externo” usando las APIs de tres de los grandes: Facebook, Yahoo y Windows Live (Google y OpenID vendrán en otro post). El proceso es similar en todos los casos, y el objetivo es acabar teniendo para utilizar en nuestro código el id único externo (la variable $id_unico en los ejemplos) que nos sirva para identificar y validar al usuario en nuestro sistema local.

Facebook

La integración más sencilla de todas ¡5 líneas de código!

La documentación para desarrolladores de Facebook es de las mejores, con muchos ejemplos prácticos y una comunidad muy activa. Vamos a hacer la implementación más sencilla, sin meternos en Facebook Connect, que será chicha para otro post. Los pasos serían los siguientes:

1. Logueado en tu cuenta de Facebook debes añadirte la aplicación para desarrolladores.
2. Creamos una nueva aplicación, y rellenamos lo básico para que funcione (el resto es para configuraciones más avanzadas)

   

3. Nos bajamos la librería cliente de PHP.
4. ¡Y a picar!

Resumiendo, tenemos una api key, otra key privada, hemos especificado una URL propia de retorno de Facebook, y tenemos su clase de PHP (nos sobraría con los ficheros facebook.php y facebookapi_php5_restlib.php). Pues el script para loguearse con Facebook sería tan sencillo como esto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
 
	// cargamos la clase que nos proporcionan
	require_once('apis_externas/facebook/class_facebook.php');
 
	// datos de la aplicación que se nos facilitan cuando la registramos en Facebook 
	$appapikey = '000000000000';
	$appsecret = '111111111111';
 
	// inicializamos el objeto de la clase
	$facebook = new Facebook($appapikey,$appsecret);
 
	// si el usuario no está logueado en Facebook le redirigirá allí
	$id_unico = $facebook->require_login();
 
	if(empty($id_unico))
	{
		// si a estas alturas no tenemos el id único algo ha salido mal
		$error_api = true;
	}
 
?>

Hay varias formas de hacer esto en Facebook, y no digo que esta sea la más correcta, pero seguro que la más sencilla. La importante es la línea 14, en la que si el usuario está logueado nos devolverá su id único, y sino le enviará a la página de login de Facebook.

Yahoo

Otra API con integración no traumática gracias a la tecnología BBAuth de Yahoo. Aquí también se pueden elegir varias implementaciones (OAuth, OpenID), pero de nuevo vamos a optar por la más sencilla y rápida de desarrollar. Los pasos son los siguientes:

1. Vamos a la página de alta de aplicaciones (se necesita usuario de Yahoo).
2. Creamos una nueva Browser-Based Authentication Protected Application

   

3. Nos pedirán confirmar el dominio subiendo un fichero determinado a nuestra web.
4. Nos bajamos la librería cliente de PHP.
5. ¡Y a picar!

Resumiendo de nuevo, tenemos la aplicación creada, apuntadas las dos keys que necesitamos y la clase para comunicarnos con Yahoo (usaremos el fichero ybrowserauth.class.php4 o ybrowserauth.class.php5 dependiendo de nuestra versión de PHP). El código final quedará así:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?php
 
	// datos de la aplicación que se nos facilitan cuando la registramos en Yahoo
	define('APPID','000000000000');
	define('SECRET','111111111111');	
 
	// cargamos la clase que nos proporcionan (en este caso tenemos PHP 5 en el servidor)
	require_once('apis_externas/yahoo/ybrowserauth.class.php5');
 
	// inicializamos el objeto de la clase
	$authObj = new YBBauthREST(APPID,SECRET);
 
	if(empty($_GET['token'])) 
	{
		// si no tenemos token mandamos a la página de login
		$url = $authObj->getAuthURL('',true);
		header('Location: '.$url);
		exit;
	}
 
	if($authObj->validate_sig()) 
	{
		// si validamos el token ya podemos sacar el id único
		$id_unico = $authObj->userhash;
	}
	else
	{
		// el token recibido no es correcto
		$error_api = true;
	}
 
?>

Es muy importante recordar que esta API es especial en el sentido que el id que se recibe finalmente es un hash del id único real del usuario en Yahoo y el id de la aplicación, es decir, si el mismo usuario de loguea con otra aplicación recibiremos un hash distinto, por lo que tenemos que tener en cuenta qué significa exactamente este id único que recibimos de la API.

Windows Live

Haciendo honor a su fama, y con mucha diferencia, la API de Windows Live es la más complicada de implementar, tanto por su horrenda documentación (lo de msdn es terminal…) como por el engorro general que supone lidiar con sus múltiples archivos y su extraño flujo de información.

Los pasos iniciales son similares a las anteriores APIs, la diversión viene después…

1. Vamos a la página de alta de aplicaciones (se necesita usuario de Windows Live).
2. Creamos un proyecto de Live Services: Existing APIs

   

   Es en este formulario cuando nos enfrentamos al primer problema absurdo, y es que el campo Return URL permite un máximo de 50 caracteres wtf?? cualquier ruta que no vaya a la raíz va a tener más de 50 letras! la única solución es tener una herramienta tipo firebug para poder editar online el HTML y cambiar el atributo maxlength del campo para poder enviar una URL en condiciones (lo que confirma lo absurdo de la limitación es que la página no te comprueba si has escrito más de esos 50 caracteres, se envía sin problemas…)
   Y atención también que la URL de retorno no es la misma que el resto de las APIs, es a un script que nos bajaremos luego con el SDK.

3. Nos bajamos el Web Authentication SDK para el lenguaje que vayamos a utilizar.
4. ¡Y a picar!

De nuevo tenemos una api key, otra key privada, hemos especificado una URL de retorno nueva, y tenemos su SDK con varios archivos. Lo primero es poner las keys en el fichero Application-Key.xml (debe ser innaccesible desde internet, bien limitándolo con un htaccess o colocándolo fuera del document root):

1
2
3
4
5

<windowslivelogin>
	<appid>000000000000</appid>
	<secret>111111111111</secret>
	<securityalgorithm>wsignin1.0</securityalgorithm>
</windowslivelogin>

Ahora en el directorio sample tenemos una implementación de ejemplo a la que podemos quitarle bastante paja. Lo primero es editar el fichero settings.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
 
	// por si las cosas no salen y se necesita consultar logs de errores 
	$DEBUG = false;
 
	// path completo al XML de configuración de la aplicación
	$KEYFILE = '/home/usuario/Application-Key.xml';
 
	// nombre de la cookie que almacena el token de usuario que manda la API
	$COOKIE = 'webauthtoken';
 
	// URL a la que tiene que redirigir cuando todo termine
	$INDEX = '/login_externo.php';
 
	// páginas a las que tiene que llevar cuanto se haga login o logout
	$LOGIN = $INDEX;
	$LOGOUT = $INDEX;
 
	// la URL de la API ¡no tocar!
	$CONTROLURL = 'http://login.live.com/controls/WebAuth.htm';
 
?>

En el fichero webauth-handler.php (recordar que es éste el que hemos puesto como URL de retorno al crear la aplicación) tenemos que poner la rutas correcta al fichero de configuración y a la librería de la API (el fichero windowslivelogin.php en el directorio lib):

1
2
3
4
5
6
7
8
9

<?php
 
	require('/home/usuario/dominio/windows_live/settings.php');
 
	require('/home/usuario/dominio/windows_live/lib/windowslivelogin.php');
 
	....
 
?>

Y finalmente el código que implementa la autenticación con Windows Live:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<?php
 
	// el fichero de configuración de la API
	require('/home/usuario/dominio/windows_live/settings.php');
 
	// la librería del SDK
	require('/home/usuario/dominio/windows_live/lib/windowslivelogin.php');
 
	// inicializamos las variables
	$wll = WindowsLiveLogin::initFromXml($KEYFILE);
	$wll->setDebug($DEBUG);
	$APPID = $wll->getAppId();
	$userid = null;
 
	// comprobamos si el token de usuario está en la cookie
	$token = @$_COOKIE[$COOKIE];
	if(!empty($token))
	{
		$user = $wll->processToken($token);
		// tenemos token, intentamos sacar de él el id único del usuario
		if(!empty($user))
		{
			$userid = $user->getId();
		}
	}
 
	if(!empty($userid))
	{
		// guardamos el id único
		$id_unico = $userid;
	}
	else
	{
		// si no tenemos token, redirigimos al usuario a la página de login de Windows Live
		header('Location: http://login.live.com/wlogin.srf?appid=0000000040009631&alg=wsignin1.0');
		exit;
	}
 
?>

Quedaría, como en el resto de APIs, hacer una gestión eficiente de los errores que se pueden dar, aunque eso ya son detalles de implementación de cada aplicación.

Tampoco comento nada sobre los módulos de PHP que es necesario tener activados en el servidor para hacer funcionar las APIs. En principio los únicos que considero pudieran salirse de una configuración básica son curl y mhash. Curl se utiliza en la librería de Yahoo y es complicado buscarle una alternativa. Mhash se utiliza en la de Windows Live, y en este caso, siendo una extensión mucho menos común, se puede puentear su uso parcheando el fichero windowslivelogin.php, en concreto la línea:

1515

$key = mhash(MHASH_SHA256, $key);

Cambiándola para utilizar funciones del core de PHP5 que también realizan el hash binario SHA256:

1515

$key = pack("H*", hash('sha256', $key));

Entradas relacionadas:

1. Windows Live Maps: Sé un Pájaro
2. Segundo Facebook Developer Garage en Madrid
3. Nuevas APIs de Google

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.

Entradas relacionadas:

1. Scroll infinito con jQuery

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:

Entradas relacionadas:

1. Integrar las APIs de login de Facebook, Yahoo y Windows Live

Soy de los que les gusta probar extensiones, y como lo suelo hacer en horario laboral (en mi tiempo de productividad leve), acabo desechando la gran mayoría y quedándome sólo con las que me ayudan en mi trabajo de desarrollador web. Muchas se han convertido para mi por su utilidad en complementos básicos del Firefox en cualquier ordenador que utilice.

Por lo tanto la selección que pongo a continuación va enfocada a ayudar a ese programador web total, el que necesita tener herramientas y control sobre todos los aspectos del desarrollo.

DESARROLLO

• Console²: un básico antes del descubrimiento del Firebug, ya que hacía útil la consola de errores del Firefox añadiendo mucho más detalle en sus mensajes.
• Firebug: la única que es sencillamente BÁSICA para cualquier programador web. Monitor de llamadas AJAX, inspección/edición inline del DOM, debugger javascript, análisis de tráfico de red…
• Web Developer: otra A MUST, con más funcionalidades que una minipimer. Yo la verdad la utilizo poco por Firebug, pero tiene muchas posibilidades para jugar con los elementos de la página.
• Yellowpipe Lynx Viewer Tool: muestra la página como un navegador de texto, o lo que es lo mismo, como la indexarán las arañas de los buscadores. Muy útil para tareas de SEO.
• YSlow: extensión oficial de Yahoo que se basa en 13 parámetros de optimización para dar notas de rendimiento a una página. Necesita tener instalado Firebug. Muy útil para llegar al detalle máximo y sacarle punta a páginas de carga masiva.

PRODUCTIVIDAD

• Download Statusbar: el gestor de descargas por defecto de Firefox es bastante incómodo. Con esta extensión tendrás una indicador de progreso integrado en la barra de estado.
• DownloadHelper: para bajarse FLVs (entre otras cosas) con un click de ratón y sin tener que utilizar servicios de terceros.
• FireShot: permite crear capturas de la página que estás viendo, incluso utilizar un editor gráfico básico con ellas. Muy útil la opción de crear la captura de la página ENTERA, no más capturas múltiples moviendo el scroll vertical.
• PDF Download: lo mio con los PDFs es personal, siempre me ha supuesto un coñazo lo mucho que tarda en cargar el programa (sí, utilizo el Acrobat de Adobe…) y más de una vez me ha colgado el Firefox. Con esta extensión al acceder a un PDF te da la opción de visualizarlo, descargarlo o convertirlo a HTML.
• Google Bloc de Notas: para poder añadir notas a tu cuenta de Google Notes directamente desde Firefox. Muy útil para copiar cachos de código o ideas que convenientemente luego plagiarás en tu blog.
• ShowIP: esta es básica en mi trabajo, donde tenemos una docena de servidores entre los que se reparten muchos servicios. Antes quemábamos el ping para adivinar la IP del servidor al que debíamos acceder para modificar algo de un canal, pero con esta extensión es inmediato ya que aparece dicha IP en la barra de estado según visitas la página.
• Remember The Milk for Gmail: necesitaba un gestor de tareas MUY BÁSICO para servir de apoyo a mi memoria de pez y poder recordar mis proyectos del trabajo. Ya había oído hablar de la web rememberthemilk.com, y descubrí en su propia web esta extensión que se integra perfectamente en Gmail, añadiendo un bloque a la derecha de los mensajes con tu lista de tareas pendientes, permitiendo añadir/modificarlas. Los problemas: sigo necesitando entrar a Gmail (a un click con las extensión Gmail Notifier) y que sólo funciona poniendo el idioma en inglés (al menos la versión que yo tengo instalada).

MARCADORES

• Bookmark Duplicate Detector: soy de los que guarda una cantidad ingente de favoritos y tengo una memoria de pez, así que necesito esta extensión que te avisa si vas a añadir un marcador duplicado.
• Foxmarks Bookmark Synchronizer: sincroniza automáticamente tus favoritos desde cualquier ordenador que la instales. Prefiero utilizar una extensión a servicios web como delicious porque mi objetivo es tenerlo todo integrado en el navegador, ya tengo cien pestañas abiertas y no puedo tener otra más siempre ahí. Pierdo accesibilidad desde donde quiera pero gano comodidad y rapidez.
• Taboo: esta extensión se convierte es una capa intermedia entre la navegación y los favoritos. Sirve para marcar esas páginas que pintan interesantes y que te quieres guardar para leerlas después de comer, manteniendo tus favoritos limpios de webs de “leer y tirar”. Taboo gestiona ese listado de forma local.

DISEÑO

• ColorZilla: entre otras funcionalidades, la que más uso es el práctico cursor que te muestra el color en hexadecimal que selecciones en pantalla, muy útil para el berrido del diseñador “¿de qué color es el fondooooo?“
• MeasureIt: Permite de forma rápida medir en pixeles zonas en la pantalla. Esencial para otro de los grandes desafíos de los diseñadores: “¿de qué tamaño quieres la imagen?“

PIJADITAS

• PicLens: la pijadita de la lista. Muestra con efectos bastante chulos el listado de las imágenes que hay en una web. Yo lo uso sobre todo para la búsqueda de imágenes en Google, es más rápido que la paginación.
• Gmail Notifier: muestra un pequeño popup cuando recibes un mail en la cuenta de gmail asociada. Sólo apto para la cuenta que pones en tu CV…
• SearchStatus: entre otras funcionalidades relacionadas con SEO, la que a mi me resulta más interesante, aunque sin mucha aplicación útil, son unos pequeños indicadores en la barra de estado que te muestran el pagerank de Google y el rank en Alexa de la página que estás visitando.
• StumbleUpon: la productivity killer de la lista. Es una comunidad enorme de usuarios que recomiendan contenido de internet y lo catalogan para uso y disfrute del personal. Empieza simplemente por la categoría de Juegos y di adiós… (decir que yo la uso para buscar contenido para humor.ozu.es…)
• TwitterFox: yo soy de los que están todavía en el estado de “¿para qué mierdas sirve el twitter este?” del que no se si saldré, pero espero que esta extensión, que avisa de nuevos mensajes de mis contactos y permite mandarlos, me ayude.

Huelga decir que el Firefox no será el navegador más liviano con todas estas extensiones instaladas. Yo con Windows XP y 1gb de RAM no he tenido nunca problemas, teniendo simultáneamente abiertas múltiples pestañas, un editor de código, el cliente FTP, telnet, messenger, reproductor de audio… ya sabéis ;)

Os pongo unas capturas de cómo quedan integradas el mogollón de extensiones en mi navegador:

Información Relacionada

Página principal del navegador Firefox: Mozilla Firefox
Directorio de extensiones/addons de Firefox: Firefox Add-ons

Entradas relacionadas:

1. Pon un Messenger o Google Talk en tu web
2. Plantilla personalizada para las Páginas de WordPress

Al final, antes de verme tentando de probar servicios que daban miedito por pedirte tu usuario y contraseña demasiado pronto, me he dado cuenta de que la solución estaba en casa! He encontrado sendas páginas oficiales para dos de los clientes de mensajería instantánea más populares que ofrecen una interfaz para mostrar tu estado online en tu web y lo que es más importante, para poder iniciar una conversación desde la misma web sin la más mínima complicación y sin requerimientos previos:

• Windows Live Messenger: http://msdn2.microsoft.com/en-us/library/bb936683.aspx
  Logueándote en tu cuenta de Passport podrás configurar un icono o directamente una ventana como ésta para mostrar tu estado online y permitir que los usuarios inicien una conversación directamente desde tu web:

• Google Talk: http://www.google.com/talk/service/badge/New
  Con un diseño más sencillo, pero las mismas funcionalidades que el anterior, Google proporciona un iframe tal que así:

Entradas relacionadas:

1. Nuevas APIs de Google
2. Propaganda de Google Chrome
3. Extensiones de Firefox para Programadores Web

Mapas Estáticos con Google Maps

Esta nueva API de Google viene a ser una “involución” lógica de la archifamosa Google Maps API. Ya todos sabemos el partido que se le pueden sacar a esos mapas, pero muchas veces se usan para fines muy concretos y poco sofisticados. En esos casos sobra toda la interactividad que nos ofrece la API, y es precisamento éso lo que han venido a cubrir los nuevos mapas estáticos. Su uso es insultántemente sencillo, y se reduce a utilizar la etiqueta <img> de HTML con un src determinado, limpio y fácil:

<img src=“http://maps.google.com/staticmap?center=<coor1>,<coor2>&zoom=<nivel de zoom>&size=<ancho>x<alto>&key=<API key>” />

Esta llamada te devuelve una imagen de los servidores de Google con un bonito mapa centrado en las coordenadas dadas. Las diferencias en cuanto a rendimiento son muy claras, pongo a continuación dos capturas del análisis de la carga de dos páginas hecha con la extensión Firebug, ambas mostrando exáctamente el mismo punto del mapa:

Google Maps API – ejem: http://www.desfasetotal.com/gmaps.html

Google Maps Estáticos API – ejem: http://www.desfasetotal.com/gmaps_static.html

Las cifras cantan:

Quedan muy a las claras las ventajas de esta nueva API. Cuando el uso de los mapas se reduce a colocar un marcador en un sitio determinado, como en una web de bares para situar los locales (se pueden crear pines en las imágenes generadas añadiendo otro campo con las coordenadas en la llamada), es de uso obligatorio este nuevo método, primero por las diferencias en tiempos/peso de carga, y segundo por la sencillez de uso de la nueva llamada. Otra ventaja que puede resultar útil es la posibilidad de guardar la imagen del mapa, cosa que con la API normal de Google Maps no se puede hacer de forma directa.

Supongo que las dos APIs van a convivir perfectamente en muchas webs, por ejemplo un perfil de usuario que permita geolocalización utilizará la API dinámica cuando lo esté editando, y la API estática en el front para mostrar el mapa de donde me encuentro. Un servicio muy útil, sí señor.

Anuncio en español: Mapas estáticos con Google Maps

Web oficial de la API: Google Static Maps API

API de Gráfico Social

Sería la traducción literal de esta API “social” que cuesta entender. Google se lanza a la búsqueda de relaciones en el apogeo de las redes sociales.

Basándose en los estándares XFN (Xhtml Friends Network) y FOAF (The Friend of a Friend), de forma simplificada se trata de analizar la etiqueta rel (en el caso de XFN) que se puede añadir a los enlaces de una web y los documentos FOAF para formar un gráfico social a nivel global que permita, usando la API, establecer relaciones entre las personas a través de su presencia pública en Internet.

En la página oficial hay un video con un ejemplo muy bueno que viene a sugerir la utilidad que puede tener ésto. Pongamos que tengo un blog con una serie de enlaces a páginas de amigos a los que añado la etiqueta rel=”friend”. Un día me apunto a Twitter y me encuentro hablando con la pared porque no tengo añadido a nadie. Si he puesto mi blog en mi perfil público, automáticamente el enlace aparece con la etiqueta rel=”me”. Pues bien, Twitter puede desarrollar una aplicación utilizando la API de Google de manera que me pueda sugerir añadir a gente de mi “red social” que ya están registrados en el portal. Google sabe por la etiqueta rel=”me” que tengo un blog y desde él ve que tengo también una serie de amigos por la etiqueta rel=”friends”. Al final aquellos que estén registrados en Twitter y hayan puesto la dirección de su página en su perfil cerrarán el círculo de mi minigrafo social aplicado a Twitter.

Es lioso y a mi por ahora no se me ocurre una aplicación realmente útil que pueda usar en nuestros proyectos, aparte del hecho de depender de que se adopte algunos de los estándares citados para poder establecer las relaciones, pero estoy seguro que en este panorama de Red Social esta API dará que hablar.

Web oficial de la API: Social Graph API

Entradas relacionadas:

1. Pon un Messenger o Google Talk en tu web
2. Windows Live Maps: Sé un Pájaro
3. Propaganda de Google Chrome