Con este título nos encontramos un libro bastante curioso sobre esta tecnología, y digo tecnología, porque no solo cubre el lenguaje de programación funcional Erlang, sino también el framework de desarrollo OTP. El libro se estructura de forma que la introducción al lenguaje es efímera pero clara, y nos plantean, casi desde el principio, la creación de un proyecto de caché, al que van agregando los elementos de OTP, hasta culminar en un proyecto completo, funcional, y que contiene, desde la práctica, todos y cada uno de los elementos que podemos encontrar en el framework OTP.

Da un recorrido por las herramientas de Erlang, de monitorización, de depuración y los profilers, así como Mnesia (la base de datos que trae consigo Erlang) y los mecanismos para crear, publicar y actualizar en caliente aplicaciones en Erlang.

Sus autores, entusiastas de Erlang, trabajan en el proyecto Erlware, además de mantener el libro. Estos son Martin Logan, Eric Merritt y Richard Carlsson. El prólogo está escrito por Ulf Wiger, CTO de Erlang Solutions.

Comentar, simplemente, que el libro me ha gustado mucho por su carácter directo. Muestra un proyecto en proceso de creación con código completo y explicando, no solo la historia de cada uno de los elementos y el porqué funcionan y se comportan como se comportan, sino también mostrando la utilidad práctica y para el proyecto de cada elemento, siendo como ejemplo de uso de los elementos de que dispone Erlang/OTP.

Su redacción es amena y para nada pesada y, aún siendo una temática muy densa, se desarrolla con ejemplos, código y gráficos a lo largo de unas 370 páginas, aproximadamente, quedando explicado todo de forma muy concisa y clara. El autor se centra sobretodo en OTP y el desarrollo de soluciones reales más que en la sintaxis y propiedades del lenguaje, con lo que consigue que el texto sea más pragmático y menos académico que el propio libro de Joe Armstrong.

Recomiendo su lectura para todo aquél que desee aprender Erlang/OTP con una curva de aprendizaje más suavizada.

¿Qué es un CMS exactamente?

Un CMS es un sistema de administración de contenido (Content Management System), básicamente. Zotonic se centra en esto mismo, administrar el contenido de la web que está sirviendo. A diferencia de otros CMS realizados en otros lenguajes, Zotonic tiene la ventaja de ejecutarse en una máquina que permite la ejecución de software fuera de la petición.

Por ejemplo, en otros lenguajes como Ruby, Python, Perl o PHP, cuando una petición HTTP llega al sistema establece el contexto de ejecución (sesión, cookies, datos de la solicitud, etc.) y tras su respuesta, el contexto es liberado (o volcado a la memoria secundaria), con lo que, es imposible mantener una ejecución paralela que dispare el sistema.

Es más, hay herramientas como delayed::job (en Ruby) o DJJob (en PHP), precisamente para paliar un poco esto.

Sin embargo, Zotonic, tiene como ventaja el hecho de que puede disparar la ejecución de un proceso no dependiente de la solicitud que almacene su resultado en una cola de mensajes que sea descargada por el sistema AJAX de la vista para mostrarlos en el momento que sea necesario. Esto le da a Zotonic una sensación de rapidez y paralelismo que pocos entornos web tienen hoy en día.

¿Qué ofrece Zotonic?

En principio, Zotonic se puede instalar en una máquina o en varias (en clúster) manteniendo una única interfaz de administración y pudiendo balancear entre todas el acceso, de forma fácil y transparente. Además, cada clúster puede administrar varios dominios:

Su interfaz es muy parecida a WordPress, y permite igualmente escribir páginas y entradas de modo que se puedan emplear como páginas del propio sitio web. Su editor se ve así:

Como base de datos emplea PostgreSQL, y la forma de programar las plantillas es mediante el estándar de Django Template Library (DTL), lo cual facilita la creación de las vistas enormemente. Se puede revisar la documentación que, aunque el tema de las plantillas las trata poco (realmente es porque su simpleza no requiere de mayor información) es una sección de la web bastante extensa conteniendo temas como: SSL, Modelo de Datos, información sobre Erlang, PostgreSQL, conexión Ajax con Zotonic, mensajes Growl, etc.

Una lista bastante extensa y detallada de las características puede verse aquí (en inglés).

Instalando Zotonic

Se puede descargar en cualquier ruta de nuestro equipo, realmente, con el comando:

git clone git://github.com/zotonic/zotonic.git

Esto nos deja un entorno limpio con el que podemos hacer nuestra primera instalación. Por ejemplo, si ponemos en nuestro fichero /etc/hosts al lado de localhost la palabra miblog, podremos escribir lo siguiente:

make
bin/zotonic -s blog miblog
./start.sh

Ahora, solo tendremos que ir a un navegador, si ponemos la URL http://localhost:8000, veremos la interfaz de los dominios que tenemos en ejecución. Solo dispondremos, en estos momentos de miblog, por lo que, como lo hemos puesto en nuestro fichero de hosts, podemos seguir ese enlace y ver la web de nuestro sitio.

Si accedemos por la URL http://miblog:8000/admin/, nos preguntará por el login de acceso y contraseña. Este será, en principio (deberemos de cambiarlo): admin / admin; tras esto, se nos presentan todas las opciones disponibles de Zotonic… ¡y en castellano!

Todo queda bastante claro y muy fácil de manejar, a excepción de las plantillas, las cuales solo se pueden modificar a través de la edición de los ficheros en el directorio donde se haya creado el dominio. En este caso, como hemos creado el dominio miblog, la ruta será: priv/sites/miblog/templates.

Conclusiones

Zotonic se ha convertido en poco tiempo en un CMS con amplias características y muy usado en el mundo del web, aunque no tanto como otros que llevan más tiempo como por ejemplo Zope, Drupal o Joomla, pero poco a poco, gracias a sus características propias de alta disponibilidad, redundancia y escalabilidad, de seguro comenzará a ser cada vez más popular.

En su presentación en la Erlang Factory de Londres de 2011, Demonware preparó una presentación de Erlang and First-Person Shooters.

En resumen, ya que el documento es bastante gráfico e interesante de ver, Demonware es una empresa que se dedica a dar soporte de servidor a videojuegos multi-jugador de Activision y Blizzard. No solo la parte en sí del juego, sino también el chat y audio/vídeo que se puede activar en algunos juegos, así como sistemas anti-trampas, etc.

Los juegos que mantienen en sus servidores van desde Call of Duty (todas las entregas), pasando por Guitar Hero (y derivados), hasta otros como Blur y Marvel Ultimate Alliance 2.

Para hacernos una idea de su crecimiento y tecnologías:

Según la empresa, si el cambio no se hubiese realizado, la crisis podría haber sido un desastre, ya que el paso de mil a 20 mil usuarios se realizó con una sola salida al mercado, la de Call Of Duty 4: Modern Warfare.

Terminan la presentación, comentando algunas cosas que han aprendido con la práctica, que son bastante interesante, a la par que útiles. Nada, lo dicho, recomiendo su visualización.

Actualización 16/09/2011: se me olvidó comentar que SPOF significa, según sus siglas, Single Point Of Failure, algo así como el punto único de fallo. Se refiere a cuando un sistema, aún teniendo bastante redundancia, tiene un punto único, en la red, en el software o en alguna parte del sistema que, fallando, deja sin servicio a todo.

Como la mayoría de software realizado por empresas y que se adentran en el software libre, Riak tiene dos versiones, una Open Source (que es completa y funcional) y otra Enterprise (que agrega commodities -o facilidades- tales como una interfaz de administración).

La base de datos Riak está basada en el documento escrito por Amazon sobre el sistema de almacenamiento Dynamo, el cual se basa en un sistema de alta disponibilidad, con estructura de almacenamiento del par clave-valor y distribuido. Este documento ha sido seguido, además, por Cassandra (la base de datos de Facebook, liberada y acogida en el seno de la Fundación Apache, y que ha sido implementada desde entonces por Digg, Twitter, Reddit, Rackspace, etc.) y por Voldemort (la base de datos de LinkedIn).

Características principales

Riak, además de seguir las bases de Dynamo, ha agregado otras características propias a la lista, quedando (visto en su página web oficial) la siguiente lista de características a destacar:

• Escalabilidad: la escalabilidad con Riak es lineal, predecible y de coste efectivo. Agregar nuevas máquinas no significa tener una avalancha de de peticiones que ponga en peligro la efectividad del sistema. Se pueden ir agregando o eliminando máquinas sin mayor problema, y sin que suponga una carga excesiva para el sistema base.
• Tolerancia a fallos: el cluster soporta o admite fallos en nodos aislados, o incluso en partes del cluster, está preparado para no perder datos ante este tipo de fallos. El sistema ha sido diseñado con fallos de máquinas e interrupciones de servicio de red como norma, no como excepción.
• Alta disponibilidad: para alta disponibilidad el sistema debe de estar disponible, no solo para lecturas, sino también para escrituras. La arquitectura de share-nothing (nada compartido) hace que cada nodo en el cluster esté habilitado para realizar lecturas y escrituras, por lo que, la alta disponibilidad está garantizada.
• Replicación: dependiendo de las necesidades, Riak se puede configurar para replicar entre múltiples clusters iguales o diseñar uno o más clusters como solo-lectura o backup. Cada nodo en el cluster puede responder a las peticiones de lecutra/escritura, y el evento de replicación asegura que todos los clusters sean actualizados. Los algoritmos se ejecutan en cada nodo asegurando la consistencia de datos.

En base al teorema CAP del Dr. Eric Brewer, las tres propiedades deseadas de un sistema distribuido son: consistencia, disponibilidad y partición (tolerancia a fallos). El teorema establece que puedes solo puedes tener dos de las tres propiedades en cada momento. Riak se enfoca en Disponibilidad y Partición. Esta elección pone a Riak en el campo de la consistencia eventual. Sin embargo, la ventana para consistencia eventual es en términos de milisegundos, lo que es suficiente para la mayoría de aplicaciones.

¿Cómo funciona?

No me quiero extender mucho, ya que esta información está disponible (aunque en inglés) en la propia web de Riak, en Concepts, así que resumiré un poco.

El almacén de datos se realiza en base a el par clave-valor, es lo que podríamos llamar una base de datos hash. No obstante, la clave se compone de bucket y key, que son como en Erlang el módulo y la función, o en Java el paquete y la clase. El conjunto bucket/key es la unidad de organización única que puede emplearse.

El sistema admite también el uso de enlaces (links). Esto quiere decir que el contenido de un bucket/key, puede ser un contenido o un enlace a otro bucket/key que tenga su propio contenido. Algo así como el enlace simbólico en los sistemas de ficheros de Unix/Linux/BSD/…

Además, el contenido, puede ir estructurado en forma de metadatos, es decir, como las cabeceras de los mensajes HTTP, para disponer de arrays asociativos (hash) dentro del contenido.

Uso de diferentes backends. En la versión 0.12, Bitcask se estableció como backend para Riak, pero hay más, aquí ponemos un listado de los disponibles:

• Bitcask: simple pero potente almacenaje de pares clave-valor. Es de baja latencia y alto rendimiento.
• DETS / ETS: tablas incorporadas en Erlang para el almacenamiento de información.
• Erlang Balanced Trees (gb_trees): sistema de árbol balanceado. Rápido para leer, pero algo lento para escribir.
• Innostore: basado en el engine InnoDB de MySQL. Debido a restricciones de licencia, se proporciona por separado.

Cada cluster que se configura de Riak, consta de los siguientes elementos:

• Nodos: nodos físicos, o máquinas, de las que se compone el cluster.
• Nodos Virtuales: nodos virtuales (o vnodes) que corren en cada máquina. Cada máquina física puede contener uno o varios nodos virtuales.
• Particiones: cada cluster Riak tiene un entero de 160-bits dividido en particiones ecuánimes. Cada vnode reclamará una partición del anillo.

Cada nodo en el cluster es responsable del 1/(número total de nodos físicos) del anillo. Puedes determinar el número de vnodes en cada nodo calculando el (número de particiones)/(número de nodos). Por ejemplo, un anillo con 32 particiones, compuesto por cuatro nodos físicos, tendrá aproximadamente ocho vnodos por nodo. Esta configuración es representada por el siguiente diagrama:

Riak está diseñado para ser un sistema distribuido, cuantos más nodos haya en el sistema, más rápido funcionará.

No hay nodo maestro, todos los nodos en Riak son iguales. Cada nodo es completamente capaz de servir cualquier petición de cliente. Esto es posible debido a la forma en la que Riak usa la consistencia de hash para distribuir datos a través del cluster, que se realiza a través de un gossip protocol.

Sobre la replicación

Riak controla tantas réplicas como datos son mantenidos a través de una configuración llamada n-valor. Este valor tiene una configuración por defecto en cada nodo pero puede ser sobreescrito por cada bucket. Los objetos de Riak heredan el n-valor de su bucket padre. Todos los nodos en el mismo cluster deben de acordar y usar el mismo n-valor.

Por ejemplo, aquí hay una representación de que sucede cuando n-valor es 3 (esta es la configuración por defecto). Cuando almacenas el dato en el bucket con un n-valor de tres, el dato se replicará a tres particiones separadas del anillo.

Y cuando un nodo falla o se agrega otro nodo, ¿qué sucede?

Riak usa una técnica llamada hinted handoff, para compensar el cluster en el momento que un nodo falla. Los vecinos del nodo fallido tomarán relevo y realizarán el trabajo de ese nodo permitiendo al cluster trabajar de forma normal. Esto puede considerarse una forma de auto-curación.

Si se agrega un nodo nuevo, en cambio, se rebalancean los datos.

Algunas pegas… siempre las hay

Primero, los buckets que usan un conjunto de propiedades no estandar forzarán a Riak a enviar vía gossip más datos a través del cluster. Los datos adicionales pueden ralentizar el proceso. Segundo, algunos backends, como Innostore, almacenan cada bucket como una entidad separada. Esto puede causar que nos quedemos sin recursos tales como manejadores de ficheros. Estas restricciones de recursos pueden no impactar al rendimiento, pero representarán otro límite en el máximo número de buckets a gestionar.

Conclusiones

A nivel teórico, todo bien, parece. Habrá que realizar un banco de pruebas y ver qué tal va el sistema. De momento, me he quedado sin tiempo (del que había planificado) para escribir este artículo, por lo que, dejo las pruebas para la siguiente parte… que entraremos de lleno en la práctica.

Criticando su estilo

Es curioso que gente como Damien Katz (creador de CouchDB), o Toni Arcieri (creador de Reia) hayan sido de los primeros (o al menos los que he encontrado) que hayan arrojado una piedra en contra del lenguaje que eligieron para desarrollar elementos que han sido bastante respetados, apoyados y usados.

En este aspecto, otros como Yariv Sadan, han defendido y reconocido algunos de estos comentarios y, tras leer a unos y a otros, me queda la pregunta de, ¿realmente han entendido para qué sirve Erlang?, ¿qué hace y cuales son sus potencias?, ¿cómo sacarle el máximo provecho así como programar orientados a la concurrencia?

Crítica a la sintaxis

Lo primero que critican de Erlang es su sintaxis. Recuerdo la primera vez que vi el lenguaje C, después de haber programado en Basic, Pascal y Modula-2 que dije… ¡qué raro! y ya ni digamos de cuando unos años más tarde comencé a ver Perl…

La sintaxis C-like, como dicen muchos, es muy extendida, pero no es nada comprensible para una persona que comienza desde cero. Niklaus Wirth desarrollo por esto mismo lenguajes como Pascal, para que sirviesen de aprendizaje al modo pseudocódigo. Un código que nada más leerlo, se entienda.

Erlang, en cambio, sigue una metodología más como Prolog, está orientado al desarrollo de funciones matemáticas, por ello, la función tiene una conclusión (->) para su comienzo y termina con un punto final. Cada elemento dentro de la función o expresión matemática se separa por comas, y todo es funcional, es decir, todo elemento en Erlang hace algo y DEBE retornar algo, incluso las estructuras condicionales, por eso tiene la forma que tiene.

Tipos de datos: registros y cadenas de caracteres

Los registros, son a nivel de preprocesador: tuplas. Esto quiere decir que funciones del tipo record_info no existen realmente, por lo que no se pueden emplear variables para pasarle a esa macro y queda el espectro del uso de los registros algo limitado. No obstante, hay algunos trucos que se pueden emplear y existen para paliar esto, en caso de que se requiera/necesite.

Otro de los problemas, con los tipos de datos, son las cadenas de caracteres, las cuales son listas de enteros. Esto no debe de extrañarnos, ya que en todos los lenguajes son listas (o arrays, o vectores) de bytes. En lenguaje C, por ejemplo:

char c[] = "Esto es una cadena";
char d[] = { 'E', 's', 't', 'o', 32, 'e', 's', 32, ..., 0 };
 
printf("%s\n", strcmp(c, d)==0 ? "true" : "false");

Esto nos dará verdadero, ya que ambas son listas de bytes, al igual que en Erlang podemos ver algo parecido con las listas de enteros:

[100,111,103] == "dog".

Lo cual también retornará verdadero.

Rendimiento: Churras con Merinas

Realmente, al leer el artículo de Toni, cuando llego al punto que dice: Erlang sucks at managing memory; habla de una comparación entre Erlang y Azul Vega, un procesador de 54 cores optimizado para ejecutar la JVM.

Un programa con ese procesador y esa JVM, NO se ejecutaría de forma distribuida, realmente, ya que solo se distribuyen las tareas posibles e internas de la JVM entre los cores, en tanto y en cuanto se puedan distribuir estas tareas. No obstante, no está diseñado para conectarse con otros nodos, por lo que NO es escalable. Además, solo tiene cuatro canales para acceso a memoria, por lo que, 27 máquinas de Pentium IV con HyperThreading podrían hacer ese mismo trabajo con Erlang… y aún así aún podríamos poner más hierro a bajo coste para seguir escalando y mejorando el rendimiento del software desarrollado.

¿Es un lenguaje de propósito general?

Erlang fue creado para entornos en los que hubiese que desarrollar software con alto grado de concurrencia, esto lo hace ideal para entornos servidores de cualquier tipo, y actualmente, para los escritorios modernos, donde los programas se ejecutan de forma concurrente, claro.

¿Elrang puede desarrollar web? Sí, ejemplos como ChicagoBoss, o Erlyweb, o Nitrogen lo atestiguan. ¿Erlang puede desarrollar aplicaciones de escritorio? Sí, ejemplos como Wings3D dan crédito de ello. ¿Erlang sirve para desarrollar aplicaciones de servidor? ¡Claro!, para eso fue creado.

En mi opinión, si PHP tiene esa denominación y es un lenguaje de marcas, Erlang DEBE de tenerla

Asignación única… ¿por qué?

Para trazar mejor los códigos, claro, y porque bien pensado, un lenguaje funcional no requiere del uso de tantas variables, por ejemplo, tal y como decía Damien Katz en su artículo, tienes este código:

f(X) ->
  X1 = foo(X),
  X2 = bar(X1),
  baz(X2).

Este código, bien escrito, sería:

f(X) ->
  baz(bar(foo(X))).

¿Quieres agregar logs para que se vean en el cambio de funciones y no los quieres poner dentro de las propias funciones, sino entre las llamadas… pues puedes hacerlo con otras funciones:

log(Caller, X) -> io:format("~s: ~p~n", [Caller, X]), X.
f(X) ->
  log("BAZ: ", baz(log("BAR: ", bar(log("FOO: ", foo(X)))))).

Realmente no es complejo si se escribe y ordena el código de forma adecuada… en otros lenguajes, como por ejemplo C, se pueden escribir cosas como esta:

char *s = "Parsea la cadena";
int size;
for (int i=0, size; s[i]!='\0' && i<100; i++, size++)
  ;

Otros códigos en Perl dan incluso hasta más miedo… pero es como siempre se dice… depende del programador.

El desarrollo en sí

Lo que creo que no se entiende, es que el desarrollo en Erlang, como tal, no es ni escalable, ni redundante, ni aprovecha todos los núcleos y procesadores de las máquinas, así como el resto de núcleos que estén conectados. El hecho de que se pueda aprovechar la forma en la que Erlang fue diseñado, es desarrollar el software de forma concurrente. Con los patrones adecuados.

Por ejemplo, Erlang puede, en un solo nodo, ejecutar casi 2 millones de procesos concurrentes. Esto quiere decir que, cada tarea que haya que realizar, debería de correr en su propio proceso, y este proceso es el que se lanza en el núcleo, procesador y nodo que corresponda. Como cuando se desarrollaba en PVM o MPICH.

Emplear los patrones de OTP es esencial para sacar el máximo provecho de la arquitectura de Erlang, y el crear manejadores de eventos, máquinas de estos, memorias compartidas a través de servidores, etc. debe de realizarse, necesariamente a través de los mecanismos que aporta Erlang.

Si se emplease Erlang para hacer llamadas a Mnesia, desde cualquier parte del código con las llamadas dirty y generando un nuevo proceso por cada petición aislada, tendríamos un programa que puede tiene potenciales errores de concurrencia, y que no aprovecha los nodos que tenga configurados y conectados el sistema.

Conclusión

Me parece muy poco profesional escribir este tipo de artículos, tanto para Tony como para Damien, en los que ponen una serie de circunstancias poco contrastadas y debidas al bajo conocimiento del lenguaje y, precisamente ellos, que han desarrollado grandes herramientas en este lenguaje.

Java, igualmente, es un gran lenguaje, pero como el mismo Tony comenta, requiere de que la JVM cumpla la especificación RTSJ y, en las comparaciones, por ejemplo, hablan incluso de que habría que adquirir un hardware especial para poder desarrollar algo parecido a lo que Erlang hace en cualquier arquitectura, creo que son muy poco objetivos.

Las máquinas de estados finitos se pueden emplear para definir los elementos con los que debe de interactuar una aplicación, y que puede darse el caso de iniciar su existencia (por llamarlo de alguna forma) en un estado definido, y mediante una sucesión ordenada o específica de eventos, ir realizando las transiciones específicas, hasta su finalización.

Una máquina de estados finitos puede ser algo tan simple como un despertador (o sistema de cron), o una transacción bancaria, o una llamada telefónica, …

En este artículo voy a desarrollar un ejemplo para que se vea lo simple que es realizar este tipo de desarrollos en Erlang, usando OTP.

El generador de máquinas de estados

En el conjunto de funciones OTP de Erlang, hay uno específico que recibe el nombre de gen_fsm. Esta es la acortación de generator: finite state machine. Como su nombre indica es un generador. Los generadores, en Erlang/OTP son comportamientos, código base que se emplea, a modo de framework, para desarrollar un comportamiento específico.

Un módulo en Erlang es tan simple como definir la primera línea diciendo el nombre del módulo, especificar la exportación de funciones, y acto seguido definir las funciones. El módulo más pequeño podría constar, sin problemas, de tres líneas de código.

Los generadores son distintos, ya que necesitan de la línea específica que indica de qué comportamiento (behaviour) vamos a tomar el código base, y la definición de todos los callbacks para el código base.

En sí, el gen_fsm es el código base que se mantendrá en ejecución y, ante la llegada de un evento, realizará una llamada a una función específica. Por convención, los callbacks tienen una forma específica, tanto en nombre como en parámetros, y los retornos también están normalizados.

Para facilitar las cosas, nos basaremos en esta plantilla, pero suprimiremos los comentarios para que no ocupe mucho.

Ejemplo del ascensor

El ejemplo que voy a poner va a ser muy simple. Supongamos que tenemos un ascensor de tres plantas: bajo, primera y segunda. Este ascensor tiene solo dos botones etiquetados como: subir y bajar; para en todas las plantas cada vez. Por tanto, según en la planta que esté, los botones tienen funciones válidas, o no.

Si estamos dentro del ascensor en la primera planta, pulsemos el botón subir o bajar, el ascensor tendrá un estado al que saltar… pero si estamos en la planta bajo, por ejemplo, presionar el botón de bajar no tiene sentido.

Desarrollando la solución

El código, tomando la plantilla del gen_fsm sería bastante simple. Tenemos tres estados y dos eventos por estado. Esto nos hace tener un total de seis funciones a desarrollar:

-module(ascensor).
-behaviour(gen_fsm).
 
-compile([export_all]). % para simplificar, cambiar por -export().
 
-record(state, {}).
 
start_link() ->
    gen_fsm:start_link({local, ?MODULE}, ?MODULE, [], []).
 
init([]) ->
    {ok, planta_baja, #state{}}.
 
planta_baja(bajar, State) ->
    io:format("Beeep!, opcion incorrecta~n", []),
    {next_state, planta_baja, State};
planta_baja(subir, State) ->
    io:format("Subiendo a la planta primera~n", []),
    {next_state, planta_primera, State}.
 
planta_primera(bajar, State) ->
    io:format("Bajando a la planta baja~n", []),
    {next_state, planta_baja, State};
planta_primera(subir, State) ->
    io:format("Subiendo a la planta segunda~n", []),
    {next_state, planta_segunda, State}.
 
planta_segunda(bajar, State) ->
    io:format("Bajando a la planta primera~n", []),
    {next_state, planta_primera, State};
planta_segunda(subir, State) ->
    io:format("Beeep!, opcion incorrecta~n", []),
    {next_state, planta_segunda, State}.
 
% agregamos funciones para facilitar las llamadas
% estas son opcionales:
 
boton_subir() ->
    gen_fsm:send_event(?MODULE, subir).
 
boton_bajar() ->
    gen_fsm:send_event(?MODULE, bajar).

Si se mira la imagen, y la conversión al código, se verá que hay una relación directa entre el esquema que se dibuja y cómo se programa el módulo en sí. Esto hace que sea muy fácil desarrollar un sistema de estados relativo a temas de los que ya comentábamos antes algunos: transferencia bancaria, pago por internet, subasta con varios participantes, una llamada telefónica, un concurso, un videojuego, etc.

Cómo funciona

Las funciones de start_link, y las que se definen abajo, no son realmente del sistema en sí, sino que son facilitadores del trabajo de lanzar la máquina de estados e interactuar con ella.

La máquina de estados, nada más lanzarse, lo primero que hace es ejecutar init. La ejecución de esta función deja un estado marcado como el que está en ejecución, y permite pasar los datos que se mantienen entre llamadas o generación de eventos al FSM.

Una vez está en ejecución, el código base es el que se encarga de llamar a la función con el estado actual en el que se encuentra, cuando se recibe el estado que debe de casar con el que se indica como parámetro.

Ejecutando el código

Una vez escrito el código, podemos entrar en la máquina virtual de Erlang y ejecutarlo sin problemas:

$ erl
[...]
1> c(ascensor). % compila el código.
{ok,ascensor}
2> ascensor:start_link(). % lanzamos la máquina de estados.
{ok,<0.38.0>}
3> ascensor:boton_bajar().
Beeep!, opcion incorrecta
ok
4> ascensor:boton_subir().
Subiendo a la planta primera
ok

La máquina de estados va realizando las llamadas a las funciones, según el estado en el que se encuentre y el evento que se pase.

Agregamos tiempo

Una de las cosas buenas que tiene FSM, es que, no solo afectan los eventos provocados por una llamada, sino también por tiempo, por lo que, en el caso de ejemplo, podemos agregar que, no se mantenga en una misma planta más de 5 segundos, yendo de arriba hacia abajo cada vez, a menos que se indique lo contrario.

Aquí también necesitaremos la memoria para saber, en caso de que vengamos de arriba, que siga hacia abajo, cuando llegue a la planta primera, y viceversa.

Agregar memoria es tan simple como modificar el registro del estado para decirle la dirección que se lleva:

-record(state, {direccion}).
 
init([]) ->
    {ok, planta_baja, #state{direccion=subir}, 5000}.

El tiempo se mide en milisegundos, con lo que, este código hará que, el ascensor se inicie y, si no llega ningún evento en 5 segundos, el ascensor subirá solo. En este caso se agrega un nuevo evento:

Las nuevas funciones:

planta_baja(bajar, _State) ->
    io:format("Beeep!, opcion incorrecta~n", []),
    {next_state, planta_baja, #state{direccion=subir}, 5000};
planta_baja(subir, _State) ->
    io:format("Subiendo a la planta primera~n", []),
    {next_state, planta_primera, #state{direccion=subir}, 5000};
planta_baja(timeout, _State) ->
    io:format("Subiendo automatico a la planta primera~n", []),
    {next_state, planta_primera, #state{direccion=subir}, 5000}.
 
planta_primera(bajar, State) ->
    io:format("Bajando a la planta baja~n", []),
    {next_state, planta_baja, State, 5000};
planta_primera(subir, State) ->
    io:format("Subiendo a la planta segunda~n", []),
    {next_state, planta_segunda, State, 5000};
planta_primera(timeout, State) ->
    NextState = case State#state.direccion of
        subir -> 
            io:format("Subiendo a planta segunda~n", []),
            planta_segunda;
        bajar ->
            io:format("Bajando a planta baja~n", []),
            planta_baja
    end,
    {next_state, NextState, State, 5000}.
 
planta_segunda(bajar, State) ->
    io:format("Bajando a la planta primera~n", []),
    {next_state, planta_primera, State, 5000};
planta_segunda(subir, State) ->
    io:format("Beeep!, opcion incorrecta~n", []),
    {next_state, planta_segunda, State, 5000};
planta_segunda(timeout, _State) ->
    io:format("Bajando automatico a la planta primera~n", []),
    {next_state, planta_primera, #state{direccion=bajar}, 5000}.

Con esto, ya tenemos nuestros tres estados, con los tres eventos posibles, es decir, la programación de las nueve funciones posibles que se pueden dar en ejecución.

En caso de tener muchos más estados, se podría usar el formato handle_event, de modo que el nombre de estado viajaría en modo de parámetro y se podría gestionar mediante código. Los eventos ya lo hacen así, por lo que en este sentido, se pueden unificar u optimizar en caso de ser mucho más numerosos.

Conclusión

Los sistemas FSM para Erlang, nos dan una gran potencia al poder realizar, de forma fácil, un elemento que, en caso de ser consultado o que se generen los eventos desde varios puntos concurrentes, su interfaz hace que su comportamiento sea el esperado en cada momento.

Estas búsquedas, igualmente, dieron con una serie de lenguajes nuevos, que han sido desarrollados usando estos analizadores, sobre Erlang, por lo que aprovechan sus ventajas, y salvan algunos de los inconvenientes que tienen algunas personas al ver Erlang por primera vez, con respecto a la sintaxis del lenguaje y la asignación única de variables.

Reia

Con el primer lenguaje que me topé fue Reia, del cual hablé ya en otra ocasión. Este lenguaje fue desarrollado por una persona a la que le gusta mucho la sintaxis particular de Python y Ruby, pero también es muy aficionado a Erlang. Las primeras versiones de Reia tenían un formato muy parecido a Python con tintes de Ruby, y fue modificándose poco a poco, haciendo que cada vez más, se pareciese a Ruby.

La última noticia que he tenido sobre Reia, es que su desarrollador ha decidido abandonar su desarrollo, debido a que encontró otro lenguaje muy parecido, hecho de la misma forma, y que considera que se desarrolló de una forma mucho más elegante. Este lenguaje es Elixir. Por lo que, junto con el autor del lenguaje, Jose Valim, Tony (creador de Reia), se sumará a la lista de desarrolladores de Elixir.

Un ejemplo del lenguaje (aunque se puede ver en el artículo anterior):

# Hello, world!
"Hello, world!".puts()

LFE

Un lenguaje que también me ha llamado la atención, aunque al igual que Erlang, su sintaxis es algo rara para programadores del tipo Java, PHP, Ruby, Python y similares, es LFE (Lisp Flavoured Erlang, algo como Erlang con sabor a Lisp). Este lenguaje, desarrollado por Robert Virding, es una sintaxis de Lisp sobre Erlang.

Se encarga de traducir la sintaxis exacta de lo que se escribe a código Erlang. Un ejemplo de lo que se escribiría en LFE:

(defmodule myhello
  (export (start 0)))
 
(defun start ()
  (: io format '"Hello World!~n"))

Se traduciría así en código Erlang:

-module(myhello).
-export([start/0]).
 
start() ->
  io:format("Hello Wordl!~n", []).

El sistema no tiene una forma fácil de compilar, pero el sistema está bien desarrollado y para los amantes de la sintaxis Lisp o Scheme es una gran oportunidad de poder desarrollar en ese entorno.

La ventaja de LFE, es que mantiene completamente la ideología en sí de Erlang y solo cambia la sintaxis, por lo que la metodología de OTP es completamente válida y se puede emplear al 100% como si de Erlang en sí se tratara.

Elixir

Lo descubrí a través de Reia. Este lenguaje, al igual que Reia, se basa en Ruby, sin tintes de Python. Ofrece una orientación a objetos más fuerte que Ruby y que Reia, ya que ni tan siquiera admite funciones de tipo built-in como puts, todos los métodos deben de pertenecer a un objeto.

La motivación e influencias en la creación de Elixir fueron, precisamente, Reia y LFE, según afirma el propio Jose Vallim en su respuesta a la noticia de Tony de parar el desarrollo de Reia.

Este lenguaje, permite además, hacer scripting, por lo que da una mayor versatilidad. El lenguaje es muy parecido (tiene algunas variaciones) que Ruby y tiene acceso a módulos Erlang de forma sencilla.

Un ejemplo del código:

module Hello
  def world
    IO.puts "Hello World"
  end
end

Elixir respeta un poco, o intenta llevar a su sintaxis, el paradigma de OTP de una forma más o menos asequible. En el ejemplo gen_server_bookshelf, se muestra cómo crear un gen_server y las diferencias que agrega al paradigma de OTP, debido a la propia ideología del lenguaje. El uso del pattern matching en los argumentos de las llamadas hace que se vea muy parecido a Erlang por lo que es un buen ejemplo de cambio de sintaxis manteniendo la potencia de Erlang por debajo.

Efene

Desarrollado por Marion Guerra y basado en la sintaxis de JavaScript y Python, Efene es otro de los lenguajes que se ejecuta sobre la máquina virtual de Erlang.

Un ejemplo de este lenguaje:

# classic hello world
 
hello = fn (Who) {
    io.format("hello ~s!~n", [Who])
}
 
@public
run = fn () {
    hello("world")
}

La sintaxis del lenguaje, para los que prefieran el formato de tipo JavaScript, será más cómoda, y el uso de los módulos se abstrae, permitiendo usar los que ya trae consigo Erlang (ejemplo el io.format, que es una traducción para el io:format de Erlang).

El defecto viene quizás en el hecho de que efene no tiene soporte de procesos, por lo que el lanzamiento de los mismos, junto con la posibilidad de usar el paradigma de OTP encubierto en el propio lenguaje, se anula completamente.

Conclusiones

Muchos de los lenguajes tienen la potencia de aportar una nueva sintaxis, que era el gran problema que le veían muchos programadores a Erlang, sobre una potente infraestructura. No obstante, el paradigma de programación que introduce Erlang a través de OTP queda un poco tapado o incluso anulado en algunos de estos lenguajes, afortunadamente, de los vistos, solo efene.

En sí, quien programa en Erlang, y termina usando y viendo el paradigma del lenguaje en sí, la programación funcional, OTP y su sintaxis, es normal que no quiera abstraerse a otro tipo de sintaxis. No obstante, admito que a veces, tener otra sintaxis más amigable se agradece, no solo por ver mejor el lenguaje, sino también para introducir a más gente en él.

Los datos y su acceso

En un principio, me resultó curioso, el sistema de ChicagoBoss había resuelto de una forma muy elegante un problema que llevaba tiempo intentando resolver en Erlang… la definición rápida de los modelos. Para un proyecto de ChicagoBoss, un modelo puede definirse tal que así:

-module(person, [Id, Firstname, Lastname]).

Algo bastante impresionante. Agregado con la posibilidad de conectar con base de datos tan variadas como: MySQL, PostgreSQL, MongoDB, Tokyo Tyrant o Mnesia.

Un “vista”zo

Otro factor bastante curioso, la forma en la que escribir código mezclado con el código HTML en modo de tags, tal y como hacen lenguajes como Ruby (con el erb de rails), JSP, PHP, ASP… me parecía muy curioso y potente al mismo tiempo. La solución acogida por ChicagoBoss ha sido la misma que se empleó en Django (en Python):

{% for person in people %}
 - {{ person.full_name }}
{% endfor %}

El código que hace esta magia es el ErlyDTL.

Por último… los controladores

Los controladores son tan simples de generar como lo son los de Rails. Para quien no haya manejado ninguno de estos sistemas, puede que un ejemplo le resulte aclarador:

-module(book_controller, [Req]).
-compile(export_all).
 
edit('GET', []) ->
   ok;
edit('POST', []) ->
   {redirect, "/somewhere"}.

Como se puede ver, si el controlador atiende a la ruta /book/edit, si lo hace mediante método GET, se ejecutará el primer método retornando simplemente ok. Si se tratase de un formulario con método POST, entraría por el segundo método y se redireccionaría la página a la ruta /somewhere.

La capacidad de gestión de los datos entre los modelos y el paso de estos a través del controlador hacia la vista, es igual de potente que en rails, django y frameworks similares. El controlador se hace bastante simple y puede contener código más volcado al flujo de las llamadas y la lógica propia del sitio web que se desee desarrollar.

Las rutas y la administración… bonus track!

Como agregados, aunque otros frameworks similares tienen también algunas de estas facilidades, como son los ficheros de rutas, nos encontramos por otro lado con la interfaz de administración. La cual nos brinda información del entorno, la posibilidad de escribir ficheros de idioma (para traducir la web) y visualizar las rutas.

Conclusiones

Hace tiempo comentaba la potencia que se comenzaba a ver en el desarrollo de proyectos erlang para la web, ahora, cada vez es más una realidad, gracias a trabajos de tanta calidad como Nitrogen, Erlyweb o este, ChicagoBoss.

Aún no llevo el suficiente tiempo jugando con la herramienta en sí, pero me ha resultado bastante cómoda la generación del entorno (aunque algo buggy… se nota que hay que pulir aún por ahí un poco) y la documentación aún es algo escasa… no obstante, se perfila como un entorno a tener en cuenta por su versatilidad y porque ofrece cosas que en otros entornos son bastante más complejas de conseguir: escalabilidad y redundancia.

Hola 1
Hola 4
Hola 9
Hola 16
...

He realizado las pruebas en los lenguajes: C, Perl, Ruby, Python, PHP, Lua, Shell script, Erlang script y Java.

C

En lenguaje C se ha realizado el siguiente código:

#include <stdio.h>
 
main() {
        int i;
 
        for (i=0; i<100000; i++) {
                printf("Hola %d\n", i*i);
        }
}

Perl

En el lenguaje Perl, se ha implementado el código siguiente:

#!/usr/bin/perl
 
for ($i=0; $i<100000; $i++) {
        print "Hola " . ($i*$i) . "\n";
}

Ruby

En Ruby, el código escrito ha sido:

#!/usr/bin/ruby
 
(1..100000).each do |i|
        puts "hola " + (i*i).to_s
end

Python

En Python, el código ha sido:

#!/usr/bin/python
 
for i in range(1,1000000):
        print "Hola " + str(i*i)

PHP

En PHP el código escrito ha sido:

#!/usr/bin/php -q
<?php
 
for ($i=0; $i<100000; $i++) {
        print "Hola " . ($i*$i) . "\n";
}

Lua

El código de Lua escrito ha sido:

#!/usr/bin/lua
 
for i=1,100000 do
        print("Hola " .. (i*i))
end

Shell script

En shell script (en bash) se ha implementado lo siguiente:

#!/bin/bash
 
for i in $(seq 1 100000); do
        let RESULT=$i*$i
        echo "Hola $RESULT"
done

Erlang (Script)

Erlang también puede emplearse como lenguaje de scripting usando el intérprete escript. El código escrito para este intérprete ha sido:

#!/usr/bin/escript
 
main(_Args) ->
        loop(100000).
 
loop(0) -> 0;
loop(I) ->
        io:format("Hola ~p~n", [I*I]),
        loop(I-1).

Java

El código que se ha usado para la prueba de Java ha sido:

public class loop {
        public static void main( final String[] args ) {
                for (int i=0; i<100000; i++) {
                        System.out.println("Hola " + (i*i));
                }
        }
}

Resultado de las pruebas

Tras ejecutar 5 veces cada script, controlando el tiempo que toma cada uno hemos obtenido, según el equipo en el que se ha ejecutado. El equipo 1 es un Intel vPro con Debian GNU/Linux Lenny:

En el equipo 2, un Apple iBook G4 (PowerPC):

Ordenados por velocidad, se ve que el lenguaje C, como cabía esperar, es el más rápido, seguido de Perl, como el lenguaje de scripting más rápido.

Lo único que ha sido una piedra en el camino, es la curva de aprendizaje y la cantidad de código a modo de plantilla que hace falta para poder programar de forma rápida.

Por todo esto, decidí hacer un sistema de scripts (para Mac OS X y GNU/Linux, en principio, aunque en sistemas Solaris, HPUX, AIX, BSD, y demás sabores de Unix pueda funcionar sin cambios, e incluso en Windows a través de Cygwin), que faciliten la creación de proyectos y módulos de tipo OTP dentro del proyecto que se quiera desarrollar.

Trabajando con Erlang/OTP

En principio, cuando se realiza un proyecto de tipo Erlang/OTP, es normal tener un entorno que pueda compilar y ejecutar el código de forma adecuada. Una vez se quiere pasar eso a producción, tal y como funcionan estos elementos que son de tipo servidor, se debe de realizar la ejecución de forma que cargue la aplicación y la lance junto con todas sus dependencias.

En este aspecto, los procedimientos para realizar estas tareas son algo tediosos y muy repetitivos, ya que por cada aplicación hay que generar un fichero de tipo app que describa y configure el entorno en el que se va a ejecutar la aplicación, un fichero de tipo rel que especifique las dependencias y el código en sí que se debe de poner en producción, además del código en sí, un módulo que debe obtener el comportamiento específico de la aplicación (behaviour application).

Una vez realizado todo esto, tenemos la base para la instalación. Pero el sistema debe de poder construirse, por lo que hace falta algo como make (erlang tiene un sistema make integrado que puede usarse fácilmente), que permita compilar y limpiar el entorno de trabajo, así como instalar el resultado.

La creación de este entorno, ya sabiendo lo que había que ir poniendo y tratando de no olvidar nada, me llevaba mucho tiempo, por lo que me decanté por construir un sistema genérico que pudiese realizar estas tareas de forma automática.

ErlDev

El sistema ErlDev consiste en una serie de scripts que se encargan de realizar las tareas básicas, pero más costosas y propensas a error, que se originan al principio del proyecto.

Este sistema fue desarrollado con la principal idea en mente de: ser sencillo, fácil y flexible. Poco a poco a ido evolucionando la idea hasta llegar a lo que, en su versión 1.0, ha llegado a ser: un sistema completo y robusto para desarrollar aplicaciones Erlang/OTP.

Las herramientas de que dispone el sistema son:

• elrmk: es la herramienta que nos creará el proyecto base. Se encarga de crear el esqueleto al que después se puede ir agregando el código, directamente, de la aplicación y los módulos que se requiera/necesiten.
• erlmod: dentro de un proyecto, se encarga de crear un módulo de tipo: gen_server, gen_fsm, gen_event, supervisor o application. Estos son los comportamientos básicos de OTP. Poco a poco se irán incluyendo más plantillas.
• erlget: como la reutilización de código es una realidad innegable, hemos acumulado en un repositorio mucho software libre útil para Erlang, dando la posibilidad de instalar dentro del propio proyecto cualquiera de los paquetes y utilizarlo directamente.

¿Más cosas?

Creo que ya lo mejor es que, si ya sabes algo de Erlang y OTP, te lances a comenzar a usar el sistema. Lee un poco la documentación y si tienes alguna sugerencia o mejora… ¡me encantaría oirla!