Cómo se hizo El Selector

La idea de El Selector nace a principios de diciembre. Por supuesto, sin nombre, no iba a ser menos que el propio soitu.es :). A partir de ese momento, una carrera, con Navidades por el medio, para lograr tenerlo a mediados de enero. Por supuesto, habríamos llegado si Obama no se nos hubiera metido por el medio :).

A continuación os contamos lo que El Selector representó para MET. O sea, para la parte técnica y de diseño de soitu.es. Para la Redacción también representó cambios pero, esos, que los escriban ellos, que ya están sueltos en esto de escribir :).

Decisiones iniciales

Tener nuevas ideas es estupendo —¡faltaría más!— pero, desde el punto de vista técnico, lo mejor es tener todo claro y bien definido. Así que, a pesar de todos los flecos, se decidieron varias cosas que definieron el producto allí hasta donde nosotros [MET] necesitábamos:

• Todos los desarrollos deben quedar, desde un primer momento, metidos en clases, librerías y directorios. Por tanto, nosotros necesitábamos un nombre. A partir de ese momento fue —y sigue siendo— "WASAP".
• Las recomendaciones tendrían título, subtítulo, un dónde, enlace y su tipo. Poco después se añadiría el idioma.
• Necesitábamos autenticar a los usuarios y habría de dos tipos: editores y supereditores. Los primeros somos todos aquellos que podemos recomendar noticias, los segundos tienen el 'poder' para modificar/borrar las recomendaciones del resto. Cómo autenticarlos aún no estaba claro, porque repartir certificados era impracticable para la dimensión de recomendadores que pretendíamos, que ahora mismo con más de 130.
• Ese número de recomendadores nos podría llevar a choques de procesamiento pues el número de secciones es mucho menor que el primero. Por tanto, debíamos implementar colas de procesamiento que los evitaran.
• 100 noticias públicas por sección y listas circulares de 200. Por tanto, más de 1700 noticias públicas y manejando 3400 en todo momento.

Repartiendo marrones

Para MET, WASAP se divide en dos grandes partes: cajas verdes (aquellas donde todos nosotros recomendamos. O sea, las secciones) y las cajas rojas y azules (las que gestiona Redacción).

Con eso en mente, el trabajo se dividió en cuatro grandes bloques:

• Diseño empezó con la apariencia. Por supuesto, éste no terminó hasta la semana después de salir pero lo primero fue definir aquello que entroncaría con la "recomendación pública": qué contendrían las cajas de portada y portadilla de cada sección (cajas verdes). A mediados de diciembre ya teníamos código HTML para dichas cajas, el resto del armazón ya tenía un esbozo y comenzamos con los cambios necesarios, en las primeras, para poder implementar los movimientos y/o personalización.
• Editores públicos: definido qué contendrían las cajas verdes, había que dotar a los usuarios de unos editores muy sencillos para que pudieran meter la información. Dos puntos fundamentales: públicos (atacables, masivos, repartidos por la granja pública, etc.) y sencillos (del estilo 1-2-3-¡publicado!). Escritos desde cero, luego hablamos de ellos.
• Editores internos: manejarían las cajas rojas (El papel también existe, El personaje, etc.) y la azul (Lo que + nos gusta). Estas cajas necesitan procesar fotos (elegirlas de agencias, recortarlas, etc.) y, por tanto, están enganchados con los editores completos de soitu.es.
• Procesadores: son los encargados de procesar las noticias que entran y de generar todos los elementos necesarios (html, rss, etc.). Son dos y gestionan las colas que antes mencionamos. Luego seguimos con ellos.

Rapidez

Una de nuestras mayores obsesiones —tenemos un montón— es que todo aquello que funcione de cara al público debe ir rápido, muy rápido, y, sobre todo, nunca debe ser un problema tener éxito. O sea, debe funcionar con unos pocos cientos de usuarios o con cientos de miles. 'La muerte de éxito' es muy chunga, suele tener muy mala solución y es difícil de explicar :(.

En el caso de WASAP esto nos lleva a:

• Todo el procesamiento de recomendaciones se hace de modo asíncrono mediante procesos en Perl que gestionan colas.
• Las bases de datos (usuarios autorizados, sacos de noticias, etc.) no son tales sino ficheros BerkeleyDB. Por supuesto, hay BB.DD. tradicionales (nosotros usamos PostgreSQL) pero los usuarios no llegáis a ellas.
• Las secciones se traducen en listas circulares almacenadas en ficheros Berkeley. Por tanto, recorrerlos y extraer información es extremadamente rápido, por muy grandes que estos sean.

Autenticación

Como ya se explicó, manejar certificados SSL de cliente, para poder acceder a los editores de WASAP, era inabarcable [logísticamente] para tantos usuarios pero sí necesitábamos tenerlos autenticados frente al editor.

Una de las modificaciones hechas en el NGINX nos permite abstraer completamente el proceso de autenticación. Por tanto, que el backend sepa quien es el usuario ya no era un problema, sólo habría que añadir un estado más que permitiera saber si era "editor" o "supereditor".

Por tanto:

• Se crea una nueva clase para que los programas puedan saber, dado un usuario autenticado por el NGINX, si está autorizado a editar noticias o no.
• La propia Redacción pasa a gestionar los privilegios de los usuarios con un sencillo editor.
• Los datos, ya existentes, del perfil del usuario con la URL, trabajo y demás pasan a ser usados para poder crear las cajas con los recomendadores. El diseño de esto último y la posibilidad de ordenarlos "manualmente" pero partiendo de los perfiles de los usuarios, fue lo que, sinceramente, más tiempo nos llevó.

Todos esos datos se meten en un BerkeleyDB para que sean consultados al vuelo. La siguiente optimización sería ponerlos en una MemCache pero esto no es, ni mucho menos, necesario aún.

Editores públicos

Nuestro editor, aquel con el que se hace soitu.es, es un pequeño gran monstruito lleno de cientos de funcionalidades que, a fin de cuentas, provocan una complejidad no deseable detrás del pequeño editor público que WASAP necesitaba.

Por tanto, se tomaron dos decisiones:

• Desarrollar una versión específica de librerías para el editor de WASAP que se pudiese alimentar de ficheros Berkeley y que escribiese XMLs. Poquito más es necesario.
• Crear un mini-runtime de las plantillas Smarty para que no fuese necesario cargar ni esa librería.

El resto, sencillo, como se verá luego escribir XMLs y leer entradas desde los Berkeleys.

Editores internos

Las cajas rojas y la azul tienen una apariencia más compleja que las verdes (por ejemplo: fotos y tipos de título) y, además, pueden llevar una noticia explicativa por detrás (por ejemplo: en el caso de la caja azul, puede llevar una noticia que explique por qué [no] nos gusta).

Ya sólo el hecho de necesitar fotos, hizo que optáramos por usar los editores completos (aquellos que gestionan el resto de soitu.es) para generar dichas cajas. Reimplementar todas las opciones que los redactores tienen para gestionar fotos (importarlas desde teletipos, sugerencias automatizadas según temas, recorte, centrado, etc.) no tenía sentido.

Por tanto, a los editores se les añadió alguna pequeña funcionalidad que necesitábamos (fundamentalmente una escritura condicional de los bloques elegible por el usuario) y lo teníamos todo.

Procesadores de colas

Lo mejor siempre es un ejemplo práctico... Recomendar una noticia en WASAP implica:

• Un usuario (autenticado por el NGINX y autorizado a recomendar por el editor) elige una sección y rellena los campos en el editor público.
• Eso genera una entrada, de tipo ADD, en cola#1 con un XML que contiene lo tecleado por el usuario.
• El trabajo del editor terminará aquí y al usuario se le presenta otra vez el formulario para meter más noticias.
• En horquillas de menos de 10 segundos, el procesador de colas procesador#1 lee todas las entradas de cola#1 y las va añadiendo al Berkeley de sección que le corresponde. Cada vez que 'toca' una nueva sección crea un entrada en cola#2, indicando que es necesario regenerar esa sección pues han cambiado datos.
• Cuando procesadior#1 termina, procesador#2 arranca y sabe si su compañero le ha dejado algo de trabajo o no. Si es que sí, genera las secciones correspondientes (cajas para portada, widgets, rss, etc.).
• Además de ADD, existen otros dos comandos DEL y EDIT.

¿Total de tiempo? Despreciable. Si no fuera por la comprobación de si la URL es 'descargable' o no, podríamos procesar cientos de noticias en poco más de 1 segundo.

Juntando piezas

Bien. Lo teníamos todo. Lo único que nos quedaba era juntar las partes:

• La recomendación de noticias (editores externos y procesadores) pasaron a producción a finales del año pasado. Por supuesto, se limaron cosas hasta su lanzamiento pero, si vais a la Hemeroteca, veréis que la primera recomendación es de las 17:26 del 29/12/2008.
• Los cambios en los editores internos implicaban modificaciones en las librerías comunes por lo que esperamos a estar todos de vuelta de Navidad para llevarlos a producción. Tampoco había mucha prisa porque son cajas pegadas, más o menos, a la actualidad. Una semana antes de la fecha de lanzamiento, quedaron listas.
• Todas las funciones de personalización de la portada, incluido el editor visual que permite a la Redacción colocar los bloques por defecto y que todo funcionara correctamente en el IExplorer :), quedaron listas dos semanas antes del lanzamiento. El grueso del trabajo estaba cerrado.
• En diseño, lo dicho, una semana después del lanzamiento aún se estaban cerrando detalles. Normalmente ajustes finos, pero de gran laboriosidad. Mención especial a los gráficos Flash explicativos, ya que se tardó casi una semana en hacerlos.

¡Voilà! Todo estaba listo para lanzar El Selector, codename WASAP. Ahora es todo vuestro :).

P.S.: Sí, sí, ya sé. Me faltó explicar qué pasó con Obama y su relación con El Selector. Pues bien, la fecha de lanzamiento de WASAP estaba fijada en la semana anterior a la que se hizo. ¿Razón? La investidura de Obama y una Redacción loca con todo lo que había que preparar para ello. Todo sea por el chico nuevo :).