Categoría: Cómo hacer para…

Un caso interesante en el que me tocó trabajar fue la implementación de un sistema de gamification para una red social de viajeros en la que trabajaba.

Los responsables del producto estaban muy interesados en fomentar la generación de contenido por parte de los usuarios del sitio y se les ocurrió que ofrecer «galardones» a quienes más contenido subían a la plataforma era una buena forma de lograrlo.

Dejando de lado la discusión sobre la viabilidad de la estrategia, hay unas cuantas lecciones interesantes desde el punto de vista de la implementación técnica.

Algo de información de contexto:

1. Las reglas de obtención de los galardones no eran triviales (Tampoco eran super complejas, básicamente, según el tipo de contenido de que se trataba había un número mínimo de aportes que permitían alcanzar el siguiente nivel y ese número iba aumentando, haciendo que alcanzar los niveles más elevados fuera mucho más difícil que los primeros).
2. Era muy importante dar satisfacción inmediata al usuario que hiciera aportes.

Dimos muchas vueltas respecto de cómo lograr esto, que implicaba la actualización de contadores en una base de datos relativamente grande, la evaluación de las reglas y el rendering del mensaje adecuado para la situación que el usuario acababa de generar.

La solución que encontramos fue hacer un pequeño truco: hicimos el cálculo en el FrontEnd y en el BackEnd:

Lo primero que hacíamos era enviar la información que el cliente necesitaría para galardonar al usuario en caso de ser necesario (las reglas de cálculo de los galardones y el estado actual de la cuenta del usuario) y luego asentábamos ese cambio en la base de datos.

De esta forma logramos que el usuario tuviera su cucarda al momento exacto en que cruzaba el umbral y, a la vez, que el resultado no se perdiera.

Esta es una forma más de tratar con procesos largos que, en un entorno de usuarios impacientes (como es una red social), funciona muy bien :).

Un tiempo más tarde leí que Apple había usado un truco similar para lograr que el IPhone mostrara la lista de aplicaciones disponibles al momento en que el teléfono se encendía: tenían pre-calculada una imagen estática que se mostraba mientras la aplicación terminaba de cargar.

Siempre me gustaron estos ejemplos de combinación de ingeniería con cierta picardía (como el de los espejos en el hotel de ascensores lentos).

¿Tenés algún otro ejemplo de cómo tratar con este tipo de situación?

Cuando se requiere tratar con un proceso largo se presenta un problema. Existen varias alternativas (algunas las discutíamos acá).

Idependientemente de cuál sea la estrategia elegida, el objetivo es siempre el mismo: evitar que el visitante se aburra (o piense que la aplicación se colgó o algo parecido).

Algo que hasta hace un tiempo era impensable (o al menos muy poco práctico) era la posibilidad de ir mostrando progreso a medida que el procesamiento avanza.

El truco se compone de tres partes:

1. El front end
2. El script del lado del servidor que ejecuta el proceso
3. El script que reporta el progreso obtenido hasta el momento

Del lado del frontend se usa Ajax (y probablemente jQuery o algún otro framework JavaScript) para disparar la acción, algo como:

<input type="button" id="trigger" />
<div id="progreso" style="visibility: hidden">
  <p id="mensaje"></p>
</div>
<script type="text/javascript">
$('#trigger').click(function(){
 $.post(
  'iniciarProceso.php',
  {
    param: value
  },
  function( data ) {
   $('#mensaje').text('Proceso iniciado...');
   $('#progreso').show();
  }
 );
})
</script>

Con esto hemos logrado que el proceso se inicie (y que al visitante se le muestre un mensaje indicador).

Para completar nuestro cometido necesitamos contar con algún mecanismo que consulte periódicamente en qué estado está el proceso (lo que se conoce como polling) y un servicio (del lado del servidor) que pueda brindar la información requerida:

Del lado del cliente será algo como:

<script type="text/javascript">
function pollServer()
{
 $.get(
  'processStatus.php',
  {
    param: value
  },
  function( data ) {
   $('#mensaje').text( 'Porcentaje de avance: ' + data.percent );
  } 
 );
}

setTimeOut( pollServer, 2000 );
</script>

Con este código se está solicitando una actualización de progreso al servidor cada 2 segundos (y mostrando el resultado al usuario).

Veamos ahora cómo debería ser el código de processStatus.php:

<?php
header('Content-Type: text/javascript');
$percent = calculateProgress(); // Probablemente esto consultara a la BD o a algun otro registro de progreso

echo json_encode($percent);
?>

La clave de este sencillo proceso es la definición del header (De modo que el cliente entienda que recibe datos en un formato compatible con el request realizado vía Ajax).

Obviamente, se pueden hacer implementaciones mucho más vistosas (Por ejemplo usando Bootstrap o mostrando imágenes en lugar de mensajes) pero la base de este mecanismo es esta.

¿En qué casos creés que te serviría usar esta técnica?

Antes de meternos en los detalles distingamos dos escenarios:

1. PHP dentro del contexto de un WebServer
2. PHP como lenguaje de scripting de algún proceso off-line.

Cuando se trata del segundo caso, es posible que existan oportunidades de mejorar el tiempo que insume el proceso, pero, en la gran mayoría de los casos, no pasará de ser una pequeña molestia si no se consigue este objetivo.

Cuando estamos en el contexto de WebServer, la molestia puede ser tal que haga que nuestros visitantes abandonen el sitio (Para no regresar jamás).

Por otro lado, es de suponer que en un ambiente web la concurrencia es alta (Es decir, un script PHP que está ejecutando está compitiendo contra muchos otros similares a él por el uso de los recursos), con lo cual, el propio sistema suele tomarse algunos recaudos para evitar que muchos inocentes sufran por los desmanes de unos pocos alborotadores :).

Uno de los límites que se nos impone (desde el archivo php.ini) es el tiempo máximo de ejecución (Que normalmente está en los 30 segundos).

Pero eso es lo que el servidor soporta antes de determinar que nuestro script tarda demasiado… los usuarios reales tienen mucha menor tolerancia (Hay estudios que afirman que una demora de más de 4 segundos hace que el 75% de los visitantes pierdan la paciencia…).

Entonces… ¿cómo atacar este problema?

Como diría Zun Tzu, la mejor manera de salir vivo de una batalla es no entrar nunca (No sé si eso es exactamente lo que dijo, pero si no, seguro que pensaba algo parecido :)).

Llevado al mundo de la programación web, la primera pregunta que debe hacerse es: ¿es realmente necesario ejecutar este proceso consumidor de tiempo?. Aunque parezca una trivialidad, en muchas ocasiones la respuesta es un rotundo NO, y simplemente se hace por razones que pueden haber sido válidas tiempo atrás pero ya no lo son más.

La siguiente pregunta (Asumiendo que la respuesta a la primera haya sido SI) es: ¿es realmente necesario ejecutar este proceso ahora mismo?. Esta es una pregunta un poco más sutil, pero sumamente importante. Para responderla hay que pensar mucho sobre lo que significa «ahora mismo»: el momento en que se está ejecutando PHP en un WebServer es cuando se ha recibido una petición de un usuario y se está intentando generar una respuesta.

Aquí nos metemos un poco en temas de psicología más que de programación, pero vale la pena intentarlo: muchas veces un usuario preferirá una respuesta rápida y casi correcta (o que parezca correcta) antes que una respuesta perfecta pero retrasada.

Se puede pensar en esto como en un truco de magia (un acto de ilusionismo si se quiere), donde es más importante lo que se ve que lo que efectivamente sucede.

Un típico ejemplo de estos problemas los constituye el recálculo de contadores. Tomo a Facebook como ejemplo, si te fijás en los números que indican la cantidad de actualizaciones no leídas podrás notar que rara vez es correcto… sin embargo, ¿cuál es el riesgo de tener un número ligeramente diferente del real? ¿estarías dispuesto a esperar más para tener la tranquilidad de que el número es correcto?

En la mayoría de los casos, con que eventualmente los números cierren no habrá mayores problemas, lo cual da lugar a un esquema de solución muy utilizado: diferir la ejecución de procesos largos.

¿Cómo se logra esto? Una forma artesanal de hacerlo es guardar en algún medio de almacenamiento (por ejemplo una base de datos), toda la información necesaria para realizar el cálculo en cuestión, devolver al usuario algo que le de tranquilidad y, mediante algún mecanismo offline (un cronjob por ejemplo), terminar los trabajos que se dejaron a la mitad.

Otro modo de resolverlo (un poco más profesional) es utilizar algún sistema de procesamiento de trabajos en paralelo, por ejemplo Gearman.

¿Qué otras alternativas se te ocurren para resolver este problema?