inmensia

Facebook es la red social de más éxito hoy en día, y desde un punto de vista puramente técnico, sus datos son realmente espectaculares. Presume de tener del orden de unos 30.000 servidores capaces de servir unos 570 billones de páginas al mes. Hace una semana publicaron un artículo con algunos detalles del software que utilizan en sus máquinas.

Aunque empiezan diciendo que se consideran un sistema de tipo LAMP (Linux Apache MySQL PHP), enseguida aclaran que más bien es un "LAMP con heteroides". Utilizan versiones de Linux, MySQL y PHP que ellos mismos han optimizado. Además de mucho otro software, naturalmente, propio y ajeno, la mayoría de código abierto.

- HipHop para PHP es uno de los desarrollos propios de Facebook más conocidos, y se trata básicamente de un compilador cruzado que toma código escrito en PHP y genera código equivalente en C++ que puede ser compilado con g++ para una ejecución de forma nativa más óptima. Con este enfoque aseguran haber conseguido hasta una reducción de un 50% del consumo de CPU en sus servidores.

- Thrift es un desarrollo propio de Facebook que liberó y ahora forma parte de la fundación Apache. Sirve para poder realizar llamadas entre distintos lenguajes de programación, que en el caso de Facebook son unos cuantos: PHP, C++, Java, Erlang, ... La idea es que en un fichero de texto plano se definen las estructuras de datos y las funciones públicas, y la librería genera el código fuente correspondiente para el lenguaje de programación que se le indique. La librería garantiza que los datos serán serializados en el cliente y reconstruidos en el servidor donde quieran que se ejecuten estos de una forma totalmente transparente y eficiente. O sea, un RPC (posibilidad de realizar llamadas remotas) con su propio IDL (lenguaje de definición de interfaces). No obstante es un proyecto que ha decaido un poco, sobre todo por el auge de Avro que el mes pasado se convirtió en un proyecto "raíz" de Apache. De características similares, pero con un enfoque más atractivo, ya que no obliga a utilizar código fuente generado de forma automática por una herramienta.

- Cassandra es otro de los productos estrella de Facebook. Es un sistema de almacenamiento distribuido altamente escalable y con una gran tolerancia a fallos. Es uno de los baluartes actuales de las base de datos "NoSQL" para el almacenamiento de pares (clave, valor). Hace un tiempo escribí un post explicando el modelo de datos en el que se basa su funcionamiento. Es un software muy interesante y que ha entrado a formar parte también de la fundación Apache.

- Hadoop es un conjunto de proyectos de código abierto originales de la fundación Apache con los que se persigue que los desarrolladores tengamos las herramientas necesarias para poder generar programas distribuidos, escalables y con alta disponibilidad. Se compone de un núcleo de librerías comunes, varios frameworks, y una serie de software más específico implementado sobre los anteriores. Uno de los más populares es MapReduce que implementa las funciones Map y Reduce utilizadas para el procesamiento de grandes cantidades de información en entornos principalmente de cloud computing. La idea básica es que se parte de unos vectores con los datos a procesar a los que aplica la función Map para generar nuevos vectores en un dominio distinto, y luego se aplica la función Reduce para agrupar los vectores generados al dominio de salida deseado. Recomiendo leer el artículo de la Wikipedia para entenderlo mejor. Es muy interesante.

- Hive es un subproyecto dentro de Hadoop, aunque es un desarrollo original de Facebook que luego liberó. Es un datawarehouse cuyo objetivo es permitir acceder a través de consultas SQL a los enormes vectores de información utilizados normalmente con Hadoop con el propósito de realizar análisis estadísticos o de tipo data-mining.

- BigPipe es una de las "armas secretas" de Facebook. Es un servidor de páginas webs dinámicas que introduce el concepto de pagelets con el que descompone una página web en varias partes, de forma que cada una de ellas pueda generarse en paralelo. La idea es que cuando se solicita una página web esta se devuelva lo antes posible, pero con una estructura mínima que se compone de bloques vacíos (perfil, búsqueda, chat, ...). Estos bloques son las pagelets que se van generando en paralelo en el servidor, y que cuando están listas se envian al cliente y se renderizan con JavaScript. De esta forma se consigue que la generación de una única página web se haga en paralelo, en vez de forma secuencial como es lo más habitual, y que el fallo en un subsistema (perfil, búsqueda, chat, ...) no impida servir una página, aunque esté incompleta.

- Memcached es un proyecto externo de código abierto muy popular al que Facebook ha contribuido optimizando algunas partes. Es un sistema distribuido de cache de objetos con un alto rendimiento. La idea es evitar tener que hacer consultas pesadas almacenando resultados previos en memoria, de forma que pueden ser servidos directamente en vez de ejecutando cada vez las consultas. O sea, el funcionamiento normal de una cache pero aplicado a gran escala, sobre queries que atacan una base de datos, clientes que solicitan páginas webs, o cualquier otro tipo de pares (clave, valor). Pero no es mágico, no es un software que se pone entre cliente y servidor y lo hace todo. Hay que programar. En los clientes hay que llamar a la cache para ver si tiene el dato, y si no lo tiene hacer la consulta de la forma habitual, y entonces llamar a la cache para que almacene el dato durante el tiempo que se quiera que sea válido.

- Varnish es un acelerador de HTTP de código abierto. Se coloca entre los clientes y uno o más servidores web actuando como balanceador de carga. Pero es un software que ofrece mucha más funcionalidad que la de mero balanceador. Ofrece un servicio de cache para responder a las peticiones de forma inmediata sin tener que realizar realmente las llamadas a los servidores web, y permite ejecutar procesos a medida para prácticamente cualquier tipo de información o evento que se produce en una comunicación HTTP. Facebook lo utiliza sobre todo para servir las fotos e imágenes de los perfiles, ¡unos cuantos billones de ficheros cada día!

- Scribe es el sistema de log desarrollado por Facebook y liberado como código abierto. La idea es que los cliente envian a servidores dedicados, a través del anteriormente mencionado Thrift, las trazas en forma de pares (categoría, mensaje). Y los servidores organizan todos los mensajes recibidos en función de sus categorías escribiéndolos finalmente en ficheros alojados en algún tipo de filesystem distribuido, ¡unas cuantas decenas de billones de mensajes cada día!

WebGL es la forma de acceder a OpenGL desde JavaScript. A diferencia de lo que inicialmente pudiera pensarse, no es una especificación de muy alto nivel que busca encapsular todo el trabajo duro detrás de una librería con un API simplificado. Todo lo contrario, es de tan de bajo nivel como pueda serlo el propio OpenGL. El famoso "canvas" es sólo la puerta de entrada, la forma de instanciar un contexto de trabajo gráfico. A partir de ahí sigue siendo necesario crear buffers, hacer binds, operar matrices, compilar shaders, ... y toda la parafernalia habitual de los programas que trabajan con OpenGL.

Gracias a que navegadores como Chrome o Firefox están empezando a implementar esta tecnología, más el primero que el segundo, se están empezando a ver algunas demos tecnológicas muy interesantes. En estos días me ha llamado particularmente la atención un visor de ficheros MD5 que muestra un modelo de una criatura de DOOM 3 con sus texturas aplicadas, e incluso con una animación. Muy espectacular, sobre todo porque el modelo en si mismo lo es. La demo es de Brandon Jones, el mismo que hizo el visor de ficheros Collada, mostrando en ese caso un modelo generado con "Spore Creature Creator".

He estado mirando la documentación, y para hacerme una idea de como estaba montado el API he acabado escribiendo una pequeña hoja de referencia (pulsar en la imagen que acompaña este post para agrandarla). No obstante, las funciones de WebGL no bastan por si solas, por lo que he añadido también un listado de referencia del "OpenGL ES Shading Language" necesario para escribir los shaders. Y es que como ya dije previamente, utilizar WebGL es como usar OpenGL. Aplican las mismas técnicas, por lo que es necesario escribir vertex shaders y fragment shaders. Se puede incluso desarrollar un motor utilizando Deferred Shading, las bases con las que se trabaja son las mismas.

Hay algunas diferencias y restricciones entre WebGL y su hermano mayor OpenGL, pero son bastantes técnicas, están en la documentación oficial, y creo que pueden obviarse en un primer momento. Lo que más está preocupando en estos momentos es la "descarga de contenidos". Es decir, la descarga de los modelos, texturas, animaciones, shaders, y toda esa serie de ficheros que luego se quieren mostrar por pantalla. En una distribución normal se empaqueta y se obliga al cliente a descargar y instalar. En una distribución web la cosa cambia un poco, ya que obliga a esperar que el navegador descargue todos los ficheros, y además normalmente son muchos ficheros sueltos que pueden estar, o no, en la cache del navegador. Los métodos tradicionales a base de referencias (links) puede que no sean lo más apropiado para este tipo de aplicaciones. Lo curioso es que si al final se llega a otra solución, más parecida a la distribución de las aplicaciones tradicionales, ¿no estamos entrando en una contradicción?

Una última nota, para probar las demos de los enlaces que he puesto es necesario tener un navegador que soporte WebGL. A día de hoy recomiendo Chrome. No obstante, la versión actual no tiene habilitado WebGL por defecto. Para activarlo hay que pasarle la cadena "--in-process-webgl --enable-webgl" como parámetro en la línea de comandos.

En estos últimos días ha terminado de liberarse el código fuente de una serie de juegos "indies" bastantes populares: Aquaria, Gish, Penumbra Overture y Lugaru. Todo esto dentro de una iniciativa (ya finalizada) llamada "The Humble Indie Bundle (pay what you want)" que permitía a los usuarios pagar el precio que quisieran por estos juegos, además de World of Goo, para el que no se va a liberar los fuentes. Una campaña que si bien puede parecer arriesgada, ha conseguido recaudar 1.273.613 dólares, de los cuales el 30,85% (392.953 dólares) han sido destinados a Electronic Frontier Foundation y Child's Play Charity.

Cada proyecto ha puesto los fuentes en un sitio distinto y con una licencia distinta. Aquaria lo ha colgado en un repositorio público con Mercurial y licencia GNU, Gish en un simple zip con licencia GPL, Penumbra Overture en un repositorio con git y licencia GNU, y Lugaru en otro repositorio también con Mercurial pero con licencia GPL2. Mucho que cotillear ahí dentro.

Lo bueno que tienen estos proyectos es que funcionan para las tres plataformas más extendidas actualmente: PC, Mac y Linux. Además de que son juegos de tipos completamente distintos. En 2D y 3D. Aunque naturalmente la idea no es que se compile el código y se haga el mismo juego con gráficos o sonidos distintos. Eso no tiene ningún sentido. Al menos no más allá de un homenaje al juego original. Lo que si puede servir es para que algunos programadores se fijen en como están resueltos algunos problemas que les impiden avanzar en sus proyectos. O tomar decisiones acerca de cuales librerías multiplataforma utilizar. Sobre todo cuanto se está empezando y no se tiene criterio para tomar este tipo de decisiones.

En cuanto al código en si mismo, me ha llamado la atención que Gish esté hecho en C, y no en C++ como el resto. Pero por lo demás no hay muchas sorpresas, ya que lógicamente usan SDL, OpenGL y OpenAL. Y sin ninguna capa de abstracción, o muy sencillas, en la mayoría de los casos, como era de esperar. Los ficheros de mayor peso son los que hacen la mayor parte del trabajo, y contienen en algunos casos métodos de bastantes cientos líneas de código, de miles en algunos casos. También hay código comentado, obsoleto, o con indicaciones del autor acerca de su propósito, normalmente para activar algunos procesos de depuración específicos. Para compilar contra una plataforma u otra se usan directivas #ifdef embebidas dentro de las clases en los puntos en los que fueron necesarios ponerlos. Penumbra tiene un motor separado, ya que es un proyecto más técnico que surgió a partir de unas demos tecnológicas, pero el resto son más programas "de una pieza" a los que se han ido añadido clases a medida que hacían falta.

Curiosamente, o no, el comentario de todos los programadores que han liberado su código es "ahí lo tenéis, pero no esperéis gran cosa". La mayoría se muestra orgullosa de que funcione y que fuera un éxito, pero a la hora de mostrar el código lo ven de otra forma. Que si es un lío. Que si es una mezcla de varios proyectos anteriores. Que si se hizo después de un par de copas. En fin ... Supongo que esto pone el desarrollo de este tipo de software al nivel de la "artesanía" que sigue siendo hoy en la mayoría de los casos. Crear diseños sólidos, módulos debilmente acoplados, interfaces claras, y todo ese tipo de características que propugna la ingeniería del software es algo deseable, pero también muy dificil y costoso. Un programador trabajando por su cuenta en un proyecto personal puede permitirse el lujo de empezar la casa por el tejado y luego ir uniendo el resto de las partes. No sé a qué vienen tantos reparos. La mayoría del código que se produce hoy en día, y se produce una barbaridad, tiene que ser por fuerza mediocre. Ya es hora de que nos permitan sentirnos orgullosos de nuestro trabajo.

En la web de la reciente Google I/O 2010 ya puede accederse a los vídeos individuales de cada una de las sesiones técnicas que se desarrollaron durante el evento.

Más concretamente, en la siguiente dirección:
http://code.google.com/intl/es-ES/events/io/2010/sessions.html

Los vídeos cubren las sesiones integras, de una hora de duración cada una, con un formato de 45 minutos de exposición y 15 de preguntas. Y teniendo en cuenta que hubo casi 100 de estas sesiones, pues la cantidad de información disponible es realmente grande.

Evidentemente las presentaciones son para promocionar productos y tecnologías de Google. Como Android por ejemplo, incluyendo un vídeo titulado "Writing real-time games for Android redux" que presenta un caso real de un juego desarrollado para esta plataforma. Desde aspectos puramente técnicos, hasta otros de tipo promocional y económico. O sea, como hacer un juego para que funcione en la mayoria de las plataformas existentes, que además vaya rápido (30 FPS), y que se venda bien. Eso sí, lo que no menciona por ningún lado es lo desesperadamente lento que va el emulador del SDK sobre un PC "normalito".

Sobre HTML5 hay unos cuantos vídeos, aunque la mayoria utilizados como excusa para promocionar Chrome, el navegador de Google. En "Developing With HTML5" pueden verse las palabras claves a seguir: el popular canvas (para acceder al área de dibujado), WebGL (la versión web de OpenGL), las etiquetas audio y video (de uso obvio), localStorage (para almacenar datos de forma local), Web SQL DB (para ejecutar queries SQL desde JavaScript), Worker Threads (para ejecutar hilos desde JavaScript), y unas cuantas cosas más, como mejoras en CSS (animaciones y drag and drop de forma nativa) o un sistema de notificaciones para alertar a los usuarios de un determinado evento.

En "GWT + HTML5 can do what?!" se explican detalles del "port" de Quake a HTML5 usando GWT. Muy técnica, y con un ritmo un poco lento, pero que diablos, ¡el Quake en un navegador!

El resto de vídeos están englobados dentro de servicios, productos y tecnologías como Google App Engine, Google Maps API (o cualquiera de las decenas de API de Google), Buzz o Wave, y más, mucho más.

Smokescreen es otro proyecto que trata de reproducir Flash en el navegador a través de un programa escrito completamente en JavaScript utilizando HTML5. En la web del proyecto se pueden ver algunas demos, e incluso un video con las demos ejecutándose sobre un iPad. Muy similar al proyecto Gordon, en bastantes aspectos.

Por el momento no resulta muy espectacular, ya que las películas Flash que requieren más proceso se ejecutan de una forma bastante lenta. Va requerir un poco más de optimización. Para lo que sirven en realidad este tipo de proyectos es para darse cuenta de que muchas cosas que se hacen "por inercia" con Flash se pueden hacer también con otras tecnologías. El principal problema es que no existen herramientas tan sencillas y productivas como Flash para hacerlas. Hay es donde se tienen que poner las pilas los desarrolladores. Y evidentemente falta que Internet Explorer empiece a soportar todas estas tecnologías. Microsoft debería tomar nota para la versión 9 de su navegador, que ya le toca. Silverlight y HTML5 pueden coexistir.

Según la web del proyecto, el código fuente de Smokescreen se liberará dentro de un tiempo. No obstante, a dia de hoy se puede analizar el JavaScript que se ejecuta en la página de las demos: http://smokescreen.us/demos/js/smokescreen.0.1.3-min.js

Leyendo entre líneas, se puede ver que han implementado un parser de ficheros SWF, de igual forma que se observa algunos nombres de clases del core del runtime de Flash para el player. Lo que no parece tener soporte el reproductor es para ActionScript, al menos en su versión 3, aunque teniendo sólo el código "minificado" es bastante complicado de saber a ciencia cierta.

En cualquier caso, si bien estos "experimentos" resultan interesantes, la guerra entre Flash y HTML5 se ha enfriado un poco con la liberación de la versión Flash 10.1 (beta) que ya se puede ejecutar en móviles con Android 2.2 (Froyo). Google lo tiene claro: dar soporte para Flash, y otros ingenios como Unity por ejemplo. Si los usuarios no quieren utilizarlo que no lo hagan, es algo opcional.

En la pasada Google I/O 2010 se pudieron ver bastantes cosas relativas a este tema, incluida una presentación de una aplicación de Adobe, aún en pañales, para generar animaciones directamente en HTML5 de forma similar a como se hace actualmente en Flash.