Bosque Viejo » programación

Juggernaut: invirtiendo el paradigma cliente/servidor

bombadil — Tue, 08 May 2012 14:40:56 +0000

Juggernaut, además de ser un personaje del universo Marvel, es un servidor escrito en Node.JS, que permite su integración con Ruby on Rails para realizar el intercambio de mensajes en dirección del servidor hacia el navegador.

Este esquema permite al servidor poder enviar mensajes al navegador en cualquier momento, de modo que se mantiene una actualización mucho más precisa que con refrescos esporádicos del navegador web hacia el servidor.

¿Cómo funciona?

Juggernaut, para conseguir esto se basa en el uso de un código en Flash que le permite abrir un socket y mantener la comunicación con el servidor de forma constante. En la parte del cliente, por lo tanto, está el navegador que realiza las peticiones al código de Rails como siempre y, además, el código Flash que abre la comunicación con el servidor de Juggernaut, que le va enviando código en JavaScript que ejecuta para realizar acciones concretas.

En la parte del servidor tenemos también dos elementos bien diferenciados, por un lado tenemos al servidor de Juggernaut ejecutándose en el puerto 5001 (por defecto) y el servidor de Rails ejecutándose en otro puerto (por defecto en desarrollo suele ser el 3000). La comunicación con el servidor de Rails es como siempre en protocolo HTTP, mientras que el intercambio de información a través del interfaz de Juggernaut se sucede en formato JSON, enviando información específica a ejecutar en el navegador.

Instalación

La verdad es que la instalación no queda nada clara, por lo que voy a explicar el cómo se instala el sistema para tenerlo funcionando en poco tiempo. En principio, necesitamos ejecutar lo siguiente:

gem install json
gem install eventmachine
gem install juggernaut
gem install maccman-juggernaut -s http://gems.github.com

Tenemos que crear un proyecto Rails. En principio, tendrá que ser una versión anterior a la 3.2, ya que en esa versión se ha eliminado el uso de plugins en favor de las gemas, por lo que, creamos nuestro proyecto Rails y ejecutamos:

ruby script/plugin install git://github.com/maccman/juggernaut_plugin.git

Ahora toca lanzar la parte servidora de Juggernaut, para eso, vamos a generar un fichero de configuración, el sistema nos puede generar uno automáticamente de la siguiente forma:

juggernaut -g juggernaut.yml

Con esto ya tenemos instalado todo el sistema de Juggernaut, y lo básico para poder integrarlo dentro de nuestro proyecto Rails.

Implementando Juggernaut en Rails

Introducir Juggernaut en Rails es tan sencillo como crear un nuevo controlador, por ejemplo uno llamado Chat, y escribir el siguiente código en el fichero chat_controller.rb:

class ChatController < ApplicationController
  def index
  end
 
  def send_data
    render :juggernaut do |page|
        page.insert_html :top, 'chat_data', "#{params['id']}: #{h params['chat_input']}
"
    end
    render :nothing => true
  end
 
end

En este código tenemos dos entradas, una es el index que lo emplearemos para entrar en la página inicial, y otra es la parte de envío de datos, a la que llamaremos mediante AJAX. El formulario lo montamos de la siguiente forma en el fichero index.html.erb:



    </b>Chat<b>
    <%= javascript_include_tag :defaults, :juggernaut %>
    <%= juggernaut(:client_id => params[:id]) %>


    <%= form_remote_tag(
          :url => { :action => :send_data },
          :complete => "$('chat_input').value = ''" ) %>
    <%= text_field_tag( 'chat_input', '', { :size => 20, :id => 'chat_input'} ) %>
    <%= hidden_field_tag( 'id', params[:id] ) %>
    <%= submit_tag "Add" %>
    
     id="chat_data" style="list-style:none">

Lanzando la aplicación

Lanzamos Rails (ya sea con mongrel, thin o cualquier otro servidor) y Juggernaut. El lanzamiento de Juggernaut lo podemos hacer de la siguiente forma:

juggernaut -c juggernaut.yml

Ahora vamos al navegador, abrimos dos navegadores:

http://localhost:3000/chat/index/yo

http://localhost:3000/chat/index/tu

Si vamos escribiendo en una ventana, veremos como van apareciendo los textos en ambas, algo como esto:

Con lo que comprobamos que el sistema funciona correctamente.

Algunas pegas

Como hemos visto desde el principio, la comunicación del navegador se realiza a través de un puerto que no es el 80, típico del protocolo HTTP, y que tampoco es protocolo HTTP lo que transita por ese puerto, por lo que, en instalaciones con acceso a Internet restringido, es posible que este sistema no funcione correctamente.

Además, se suma el problema de que el puerto 5001 debe de mantenerse abierto hacia Internet, si no configuramos con suficiente seguridad, a través del fichero juggernaut.yml el sistema, podemos encontrarnos un verdadero agujero de seguridad… ya depende de para qué usemos Juggernaut, pero teniendo en cuenta de que ejecuta código JavaScript en el cliente, podría ser algo nocivo.

Conclusiones

Esta aproximación al sistema de Juggernaut ha sido bastante interesante para descubrir una forma de realizar este tipo de comunicaciones entre cliente y servidor de forma inversa, es decir, que el servidor pueda enviar información al cliente sin que el cliente la solicite. No obstante, los navegadores actuales implementan un sistema denominado websocket que tenderá a sustituir estos mecanismos artesanos de una forma más estándar y frameworks como ChicagoBoss ya lo implementan de forma nativa. El futuro nos mostrará los caminos que se van tomando, de momento, Juggernaut es una muy buena solución para todos los navegadores web actuales.

Estructura Lider/Trabajador en Erlang

bombadil — Mon, 07 May 2012 11:22:51 +0000

Erlang es muy bueno para programación distribuida, y paralela, y concurrente, así mismo se hace muy simple la creación de servidores, tal y como he mostrado en entradas anteriores (servidor UDP y servidor TCP), pero nos queda una tipo de comportamiento que es algo complejo llevar a la práctica. Me refiero al paradigma de Maestro-Esclavo.

La teoría

El paradigma Maestro-Esclavo se basa en que, para acceder a un recurso que está disponible solo desde un punto o solo para un servicio, ya sea por que su acceso es crítico en concurrencia o porque solo se pueda acceder desde un único punto cada vez, se hace necesaria una estructura en la que un único punto sea el responsable de ese acceso, quedando todos los demás supeditados a este.

Esto genera igualmente un problema de cuello de botella, pero la misión no es distribuir, en este caso, para ganar más potencia de procesamiento, sino conseguir: una mayor alta disponibilidad para un recurso accesible solo desde un punto cada vez.

En la terminología de Erlang, la nomenclatura empleada es líder (leader) para referirse al maestro elegido cada vez, y trabajador (worker) para referirse a los esclavos. Esto es así por dos sutiles diferencias que existen entre el modelo clásico de maestro-esclavo frente a este de lider-trabajador:

El maestro es siempre uno y se carga con las tareas de replicación y de escritura, el líder, sin embargo, se carga con todas las tareas y no replica nada entre sus trabajadores.

El esclavo se encarga de las tareas más frecuentes, en su caso, las lecturas, sin pedir nada al maestro. Si le llega una escritura puede remitirla a su maestro o ignorarla, depende de la implementación. El trabajador, sin embargo, delega todos los trabajos al líder.

Cuando un maestro muere, los esclavos quedan atendiendo lecturas, pero el sistema de escritura queda sin servicio, a menos que haya algún mecanismo que permita, por alta disponibilidad, levantar a otro maestro, pero no es la base del paradigma. Cuando un líder muere, en cambio, de entre los trabajadores se elige a un nuevo líder, que se encarga de las peticiones. El esquema está pensado en sí para tener una alta disponibilidad.

Aunque es un comportamiento bastante básico, aún no se ha introducido en la base de Erlang, ya que sus algoritmos de elección han sufrido cambios, incluso hasta hace pocos meses. Supongo que incluso aún habrá algún que otro cambio más, por lo que conviene mantenerse al día. El repositorio oficial (de momento) es este de github, gen_leader_revival de abecciu.

Los autores de la base son Andrew Thompson, Dave Fayram, Hans Svensson y Ulf Wiger.

La implementación

El código podemos descargarlo del repositorio indicado anteriormente, solo necesitaremos el código de gen_leader.erl y el código de skeleton.erl.

La plantilla nos da lo básico para que el gen_leader funcione. Si compilamos ambas y lanzamos desde una consola el skeleton, podemos ver que funciona correctamente. Es más, vamos a modificarlo muy poquito agregando solo impresiones por pantalla para saber en qué momento se ejecuta cada uno:

elected(State, Election, undefined) -> Synch = [], io:format("no one elected? ~p~n", [Election]), {ok, Synch, State}; elected(State, Election, Node) -> io:format("elected node [~p]: ~p~n", [Node, Election]), {reply, [], State}. surrendered(State, Synch, Election) -> io:format("surrendered (~p): ~p~n", [Synch, Election]), {ok, State}. handle_leader_call(Request, _From, State, Election) -> io:format("leader_call (~p): ~p~n", [gen_leader:leader_node(Election), Request]), {reply, ok, State}. from_leader(Synch, State, Election) -> io:format("from_leader (~p): ~p~n", [gen_leader:leader_node(Election), Synch]), {ok, State}. handle_DOWN(Node, State, Election) -> io:format("DOWN (~p): ~p~n", [Node, gen_leader:leader_node(Election)]), {ok, State}.

El código modificado es llamado como callback cuando se suceden las siguientes situaciones:

elected (con nodo undefined), es llamada cuando el nodo es elegido para ser líder, si la variable de Nodo no es undefined, entonces es llamado cuando un nuevo trabajador se ha unido al líder.

surrendered, llamada en trabajadores cuando un líder ha sido elegido, o cuando un nuevo nodo entra en el clúster, y se decide de nuevo quién es el líder, siendo llamado elected en el líder elegido y surrendered en el nuevo trabajador.

handle_leader_call, esta llamada la realiza quien necesita algo del cluster, o cualquiera de los trabajadores al líder, pero en esencia, solo se proces en el líder.

from_leader, mensajes que se emiten desde el líder hacia los trabajadores. Si la devolución de handle_leader_call es {reply, Reply, Broadcast, State}, se envía el mensaje de Broadcast a todos los trabajadores, con lo que pueden hacer alguna sincronización con su estado interno o realizar la acción que se requiera.

handle_DOWN, mensaje de caída recibida por el líder de los nodos que han caído. Cuando cae el líder, un nuevo líder es elegido y se le envía la señal de caída del nodo del antiguo líder.

Teniendo estas características en cuenta, podemos ejecutar el código y ver cómo se comporta:

En lider1@bosqueviejo:

(lider1@bosqueviejo)1> {ok, Pid} = datos:start_link(['lider1@bosqueviejo', 'lider2@bosqueviejo']). no one elected? {election,<0.55.0>,none,datos,lider1@bosqueviejo, [lider1@bosqueviejo,lider2@bosqueviejo], [], [lider2@bosqueviejo], [],[],none,norm, {1,6,0}, [],[],5000, {interval,#Ref<0.0.0.49>}, lider2@bosqueviejo,6,1,sender} {ok,<0.55.0>}

Ahora levantamos en lider2@bosqueviejo:

(lider2@bosqueviejo)1> {ok, Pid} = datos:start_link(['lider1@bosqueviejo', 'lider2@bosqueviejo']). {ok,<0.55.0>} surrendered ([]): {election,<6327.55.0>,none,datos,lider1@bosqueviejo, [lider1@bosqueviejo,lider2@bosqueviejo], [],[], [{lider1@bosqueviejo,lider1@bosqueviejo}, {#Ref<0.0.0.59>,lider1@bosqueviejo}, {#Ref<0.0.0.57>,lider1@bosqueviejo}], [],none,norm, {1,6,0}, [],[],5000,undefined,undefined,5,1,sender}

En lider1@bosqueviejo se sucede el siguiente mensaje al levantar al lider2@bosqueviejo:

elected node [lider2@bosqueviejo]: {election,<0.55.0>,none,datos, lider1@bosqueviejo, [lider1@bosqueviejo,lider2@bosqueviejo], [],[], [{#Ref<0.0.0.74>,lider2@bosqueviejo}], [],none,norm, {1,6,0}, [],[],5000, {interval,#Ref<0.0.0.49>}, lider2@bosqueviejo,6,1,sender}

Ahora en lider1@bosqueviejo enviamos un mensaje:

(lider1@bosqueviejo)2> gen_leader:leader_call(Pid, "hola"). leader_call (lider1@bosqueviejo): "hola" ok

Y lo que pasaba al mismo tiempo en lider2@bosqueviejo:

from_leader (lider1@bosqueviejo): [118,117,101,115,116,114,111,32,108,105,100, 101,114,32,100,105,99,101,58,32,"hola", "\n"]

En caso de que salgamos de la consola del lider1@bosqueviejo vemos lo siguiente en lider2@bosqueviejo:

no one elected? {election,<0.55.0>,<6327.55.0>,datos,lider2@bosqueviejo, [lider1@bosqueviejo,lider2@bosqueviejo], [], [lider1@bosqueviejo], [{#Ref<0.0.0.59>,lider1@bosqueviejo}, {#Ref<0.0.0.57>,lider1@bosqueviejo}], [],none,norm, {2,5,1}, [],[],5000, {interval,#Ref<0.0.0.75>}, lider2@bosqueviejo,5,2,sender} DOWN (lider1@bosqueviejo): lider2@bosqueviejo

Es decir, se elige a un nuevo líder y se envía el mensaje de caída del líder.

Conclusiones

Este esquema es bastante útil ya que simplifica el problema de tener varios servidores, por ejemplo, y recursos que solo pueden estar disponibles en un solo servidor cada vez. Por ejemplo, el acceso a un recurso propietario que solo nos da una licencia de uso, el acceso con control de concurrencia a un recurso.

Su interfaz de broadcast, permite que el sistema pueda recibir peticiones de lectura y escritura, haciendo que su broadcast deje la información en cada worker para, en caso de que cayese el líder, puedan seguir funcionando sin problema alguno.

Realmente, otro elemento más para facilitar la creación de sistemas servidores de alta disponibilidad en Erlang.

Go: El lenguaje de Google

bombadil — Tue, 10 Apr 2012 17:32:54 +0000

Hace un par de años que escuché que Google trabajaba en un lenguaje, y hace poco que ya había visto la luz una versión estable, la primera.

Hay personas que me han comentado que Go era parecido a Erlang, que Go hacía concurrencia de forma muy simple, y que Go es un lenguaje muy a tener en cuenta y presente, sobretodo en terreno de concurrencia y escalabilidad. Hoy le he dedicado un par de horas a revisar la documentación y a programar un poco y ver cómo se programa en Go, las potencias que tiene el lenguaje según sus creadores (y lo que han podido introducir a lo largo del tutorial y el manual).

En 2007, un diseño inicial de Go fue comenzado por Robert Griesemer, junto a Rob Pike (creador del lenguaje Limbo) y Ken Thompson (uno de los creadores del lenguaje C y Unix), todos ellos bajo el seno de Google, donde los tres trabajan actualmente, por lo que, de momento, por su historia, promete.

Revisión del lenguaje

En principio, Go es un lenguaje tipado y fuertemente tipado. Tiene auto-detección de tipos para no tener que escribir mucho y han organizado su declaración de modo que resulta un poco extraño para quien haya programado en C y Java, por ejemplo. Mientras que un código en estos lenguajes declara el tipo y modificadores para después indicar el nombre de la variable, Go lo hace al revés. Se indica primero el nombre de las variables y después el tipo. Además, el tipo puede tomarse de forma intrínseca si se hace una inicialización con un valor. Por ejemplo:

var x int // declaración simple var y, z int // declaración múltiple, ambas serán int var a := 1 // declaración intrínseca a int var a, b := 1, 2 // declaración intrínseca de a y b a int

En este aspecto, recuerda bastante a Python, pudiendo hacer asignación múltiple en una misma línea. La palabra var es necesaria en la declaración de las variables de modo global, y solo opcional dentro de las funciones. Un dato de tipo intrínseco dentro de las funciones, a menos que se emplee var, debe de indicarse con el operador :=

La declaración de funciones se realiza con la palabra clave func, pudiendo aceptar parámetros tipados de la misma forma que la declaración de variables. El retorno, al igual que la asignación, se realiza de modo que se puedan retornar varios valores, igualmente, otro parecido más a Python en este sentido:

func add( x, y int ) int { return x + y }

En parecido con C, para que el código sea ejecutado, debe de existir una función main.

Como estructuras de control, tenemos if, for y switch. El bucle while se puede simular a través del uso simplificado de for, que permite eliminar la parte de inicialización y actualización para realizar son la condición de bucle. Igualmente, si no se indican ninguna de las tres, se realiza un bucle infinito.

for i := 1; i<10; i++ { // bucle for normal } for i < 10 { // simulación de while } for { // bucle infinito }

Las estructuras if permiten el uso de la parte de inicialización, como si se tratase de un bucle for, y las estructuras switch permiten declarar comparadores, no solo valores estáticos como en Java, C, PHP y otros, además de también el bloque de inicialización como if:

if i == 10 { // if normal } if i=10; i==10 { // if con inicialización } switch i=10; i { case 1: // si es 1 case 2: // si es 2 case 10: // aqui entra default: // por defecto } switch { case i == 1: // si es 1 case i == 2: // si es 2 case i > 3: // aqui entra default: // por defecto }

La organización de las estructuras de datos se puede hacer mediante struct, al igual que en C, e incluso se pueden definir funciones que trabajen como si uno de sus parámetros intrínsecos fuese un struct. Con esto se puede simular el uso de los métodos, pero queda muy lejos de lo que respecta a la programación orientada a objetos.

Se pueden ver más ejemplos en tutorial de Go (en inglés).

Potencias del lenguaje

Revisándolo a fondo, veo que la tendencia de los lenguajes de tipado estático comienza a estar de moda, tienen sus ventajas ya que permiten cazar fallos en tiempo de compilación (cuando no hay inferencia de tipos, claro). En este caso esa cualidad es bastante evidente, así como que el código pueda compilarse de forma nativa como hace también Opa.

La concurrencia que emplea Go se parece bastante a Erlang en base en que es por paso de mensajes. La única diferencia radica en que el buzón para el paso de mensajes se debe de crear. Go nomina sus buzones como canales de comunicación. Un símil muy aproximado a los sockets Unix, ya que se establecen como recursos independientes y se pueden emplear en cualquier proceso y en cualquier momento.

Conclusiones

El lenguaje Go es un lenguaje que ha nacido con un propósito claro, según sus objetivos entre los que se encuentran: seguridad (de tipos y de memoria), buen soporte de concurrencia y comunicación, eficiencia en la recolección de basura (sin latencias) y alta velocidad de compilación.

Viniendo de dos de los trabajadores de los laboratorios Bell que contribuyeron a lenguajes como Limbo, C, BPEL, etc. y estando en el seno de Google, el futuro de este lenguaje se ve muy prometedor.

Este lenguaje permite la programación orientada a la concurrencia o modelo actor, con lo que, la orientación a objetos, realmente, no es una característica que se eche en falta, ni mucho menos, siempre teniendo presente que el paradigma de programación al que se orienta no son los objetos, en su núcleo central, sino los procesos (o hilos).

Cabe destacar que el uso de la memoria compartida es un hecho ya que el comando go lo que hace es lanzar, como dice el tutorial goroutines, que a nivel interno son hilos, por lo que comparte el mismo heap de memoria y puede llegar a ser un problema en el uso de la concurrencia y el modelo actor propiamente dicho.

Por otro lado, carece de estructuras que faciliten el uso de monitores de hilos a modo de que cuando uno muera se notifique este hecho a otro y poder construir estructuras como las de los supervisores.

Veremos como va progresando a lo largo de las siguientes liberaciones, de momento son buenos pasos los que ha dado el pequeño, y con la promesa de Google de mantener la sintaxis y compatibilidad en sus futuras versiones, es una seguridad de cara a programar y no tener que refactorizar al cambiar a una nueva versión.

Erlang: Servidores Concurrentes TCP

bombadil — Mon, 09 Apr 2012 10:43:10 +0000

Para la programación de elementos que requieran concurrencia, Erlang, es una de las mejores elecciones que se puede tomar. El hecho de construir servidores UDP con los mecanismos que nos ofrece OTP es algo trivial, muy simple de conseguir, tal y como se puede ver en este otro artículo, pero la cosa se complica, cuando lo que queremos obtener es una conexión, o un conjunto de conexiones concurrentes para TCP.

Para comenzar, vamos a poner de nuevo de manifiesto la plantilla del gen_server, si se quieren tener más referencias sobre el gen_server se puede consultar este otro artículo, o de forma más extensa en este artículo del Blog Aprendiendo Erlang.

Por lo tanto, la estructura de un código con gen_server es la siguiente:

-module(server). -author('bombadil@bosqueviejo.net'). -behaviour(gen_server). -define(SERVER, ?MODULE). -export([start_link/0]). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -record(state, {}). start_link() -> gen_server:start_link({local, ?SERVER}, ?MODULE, [], []). init([]) -> {ok, #state{}}. handle_call(_Request, _From, State) -> Reply = ok, {reply, Reply, State}. handle_cast(_Msg, State) -> {noreply, State}. handle_info(_Info, State) -> {noreply, State}. terminate(_Reason, _State) -> ok. code_change(_OldVsn, State, _Extra) -> {ok, State}.

Agregando conexiones TCP

TCP, a diferencia de UDP, necesita formalizar que está escuchando en un nodo, y aceptar cada petición entrante para mantener una comunicación bilateral. En este caso, el init se complica. Debemos de establecer la escucha del puerto y esto requiere de que pasemos algunos parámetro y opciones:

-record(state, {lsocket, socket}). init([]) -> Opts = [binary, {packet, 0}, {active, true}], case gen_tcp:listen(5000, Opts) of {ok, LSocket} -> {ok, #state{lsocket = LSocket}, 0}; {error, Reason} -> {stop, Reason} end.

Para esto, tendremos que agregar el parámetro lsocket y socket al registro de estado.

La función init se encarga de establecer la escucha en el puerto 5000, de forma activa. Para más opciones se puede revisar tanto la documentación de gen_tcp, como las opciones específicas disponibles en el paquete inet a través de setops.

Como se puede ver, en caso de que la escucha se establezca de forma apropiada, hay un timeout configurado a cero, por lo que, se llamará al callback de handle_info, con el parámetro timeout. En ese punto, es donde tenemos que agregar la parte del servidor TCP en la que se espera por una conexión entrante para poder atenderla. La función, por tanto, sería:

handle_info(timeout, State=#state{lsocket=LSocket}) -> {ok, Socket} = gen_tcp:accept(LSocket), {noreply, State#state{socket=Socket}}; handle_info(Info, State=#state{socket=Socket}) -> io:format("~p~n", [Info]), gen_tcp:send(Socket, io_lib:format("~p~n", [{date(),time()}])), gen_tcp:close(Socket), {noreply, State, 0}.

El programa es algo simple, ya que acepta la conexión, espera una transmisión y responde enviando la fecha y hora y cierra la conexión. Podemos probarlo de la siguiente forma:

$ nc localhost 5000 hola {{2012,4,4},{20,5,49}}

Y ahora… la concurrencia

Como puedes observar, mientras tienes abierta la primera conexión, la segunda no se establece porque el sistema está ocupado con la primera petición. Esto conlleva un cuello de botella, ya que la concurrencia es nula.

Para conseguir ampliar la concurrencia, desde el primer servidor, el proceso que tiene en escucha el puerto, debe de lanzar un proceso, un nuevo servidor para atender cada petición de forma independiente.

Para esto necesitamos crear otro nuevo gen_server, pero con unas características diferentes, ya que no se mantendrá a la espera de conexiones entrantes, sino que será para manejar una conexión activa.

El módulo gen_tcp nos ayuda en esta tarea, ya que cada mensaje entrante lo recibimos a través de handle_info en el proceso padre, como habíamos visto antes, y esto debemos de redireccionarlo hacia el proceso hijo que creemos. En principio, copiando la estructura de gen_server de nuevo y llamándola request, agregamos un par de cambios como el siguiente:

start_link(Socket) -> {ok, Pid} = gen_server:start_link(?MODULE, [Socket], []), gen_tcp:controlling_process(Socket,Pid), inet:setopts(Socket, [{active, once}]), {ok, Pid}.

Esta forma de lanzar el gen_server, hace que el proceso no tenga un nombre asociado, por lo que se pueden lanzar tantos como queramos o necesitemos. Para el gen_tcp, indicamos que el proceso que atenderá las peticiones de ese socket será el que se acaba de crear, y se le indica que puede enviar una petición.

La función de inicialización tendrá esta forma:

-record(state, {socket}). init([Socket]) -> {ok, #state{socket=Socket}}.

En el módulo server podemos eliminar la parte de gestión de la petición (la parte de handle_info que se refiere estrictamente a la gestión de la petición) y dejar solo la parte de la aceptación de la petición de esta forma:

handle_info(timeout, State=#state{lsocket=LSocket}) -> {ok, Socket} = gen_tcp:accept(LSocket), request:start_link(Socket), {noreply, State, 0}.

En el nuevo módulo request, agregamos la parte de código que se encarga de realizar la contestación:

handle_info(Info, State=#state{socket=Socket}) -> io:format("~p~n", [Info]), gen_tcp:send(Socket, io_lib:format("~p~n", [{date(),time()}])), gen_tcp:close(Socket), {stop, normal, State}.

En este caso, cuando gen_tcp envía un mensaje desde el cliente al servidor, este mensaje disparará la ejecución de esta función, imprimirá por pantalla el mensaje recibido, contestará de forma fija con la fecha y hora actual, cerrará la conexión con el cliente y detendrá la ejecución del proceso.

Algunas pruebas

Si ejecutamos en una máquina virtual de Erlang el servidor, y abrimos dos consolas o tres o más con el siguiente comando:

$ nc localhost 5000

Veremos que todas y cada una de las consolas obtienen conexión y quedan en el proceso hijo a la espera de un mensaje que envíes. Puedes poner el texto que quieras y presionar el retorno de carro. Volviendo a la consola de Erlang, se verá el mensaje escrito en cada una de las consolas.

Si modificamos el código para que acepte paquetes de tipo http y procesamos una respuesta válida, podemos probar la carga a través de programas como wrk o ab. En mis pruebas, he conseguido:

$ ab -n 10000 -c 50 http://127.0.0.1:5000/ [...] Concurrency Level: 50 Time taken for tests: 0.885 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 760000 bytes HTML transferred: 110000 bytes Requests per second: 11303.38 [#/sec] (mean) Time per request: 4.423 [ms] (mean) Time per request: 0.088 [ms] (mean, across all concurrent requests) Transfer rate: 838.92 [Kbytes/sec] received

Una tasa de unas 11 mil peticiones por segundo. Nada mal.

Erlang: Servidores UDP

bombadil — Wed, 21 Mar 2012 10:03:23 +0000

Una de las grandes potencias de Erlang es su capacidad para construir servidores. A través de OTP, esta tarea se convierte en algo tan sencillo, que asombra ver con qué pocas líneas de código se crea un servidor.

En este caso vamos a montar un servidor UDP. Esto lo revisé en su día porque estuve realizando un pequeño servidor para el protocolo syslog, de lo que resultó este servidor, que permite pasar a través de un manejador de eventos (gen_event) los mensajes de syslog recibidos a través del puerto 514 en formato UDP.

En principio, comentaré un poco la estructura del comportamiento (behaviour) de Erlang/OTP que emplearemos: gen_server.

Empleando los gen_server

El gen_server es el comportamiento más básico que se encuentra disponible en OTP, ya que sobre él se construyen otros como gen_fsm. Este comportamiento específico se fundamenta en la recepción de mensajes y su manejo a través de unos callbacks, de modo que tenemos tres tipos de mensajes que podemos procesar:

call: referidos a llamadas en las que se envía una petición y se espera por una respuesta del servidor. Siendo realizadas desde otros procesos de Erlang.

cast: estas son llamadas que se envían y no se espera por una respuesta. También son realizadas desde otros procesos de Erlang.

info: este podría considerarse un comodín, ya que en esta categoría entran todos los mensajes que no entran en las anteriores. Normalmente, aquí es donde recibiremos la información UDP y TCP de los servidores que creemos de cara a la red.

La estructura de un código con gen_server es la siguiente:

-module(server). -author('bombadil@bosqueviejo.net'). -behaviour(gen_server). -define(SERVER, ?MODULE). -export([start_link/0]). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -record(state, {}). start_link() -> gen_server:start_link({local, ?SERVER}, ?MODULE, [], []). init([]) -> {ok, #state{}}. handle_call(_Request, _From, State) -> Reply = ok, {reply, Reply, State}. handle_cast(_Msg, State) -> {noreply, State}. handle_info(_Info, State) -> {noreply, State}. terminate(_Reason, _State) -> ok. code_change(_OldVsn, State, _Extra) -> {ok, State}.

Si guardamos esta estructura como server.erl (que es el nombre del módulo, tal y como se indica en la primera línea), el sistema compilará y lo podremos incluso lanzar con el comando:

server:start_link().

Convirtiendo nuestro gen_server en servidor UDP

Para convertir nuestro gen_server en un servidor UDP solo necesitamos abrir en escucha el puerto que queramos en modo UDP a través de gen_udp y el resto lo hará la estructura gen_server. Sería tan simple como modificar la función init para que albergase el siguiente código:

init([]) -> Port = 5000, {ok, Socket} = gen_udp:open(Port), error_logger:info_msg("Listen in port ~p~n", [Port]), {ok, #state{socket=Socket}}.

Y también la estructura del registro de estado, para albergar la información que necesitamos almacenar en el proceso, que será el recurso del puerto abierto:

-record(state, {socket}).

Es bueno que, además, agregemos en el terminate la cláusula que nos permita cerrar el servidor UDP, esto lo podemos agregar modificando la función termiante de la siguiente forma:

terminate(_Reason, State) -> gen_udp:close(State#state.socket), ok.

Por último, vamos a hacer que cada mensaje que nos llegue desde el servidor UDP se presente a modo de log en la consola. Esto lo haremos modificando la función handle_info, que como habíamos visto antes, es la que recibe los mensajes UDP:

handle_info(Info, State) -> error_logger:info_msg("Received via INFO: ~p~n", [Info]), {noreply, State}.

Probando el servidor

Para probarlo, solo tenemos que ejecutar en una consola:

$ erl Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> server:start_link(). =INFO REPORT==== 21-Mar-2012::10:52:44 === Listen in port 5000 {ok,<0.34.0>}

Abrimos otra consola, y ejecutamos el siguiente comando para generar un paquete UDP:

$ nc -u localhost 5000 hola

NOTA: tras escribir hola hay que presionar el retorno de carro (enter o intro) para que el paquete sea enviado.

Esto generará en la consola de Erlang el siguiente mensaje:

=INFO REPORT==== 21-Mar-2012::10:54:01 === Received via INFO: {udp,#Port<0.506>,{127,0,0,1},36772,"hola\n"}

Empleando el match en la función handle_info e incluso con expresiones regulares o lo que queramos, podremos tratar de forma más adecuada el mensaje.

Un ejemplo de aplicación de este servidor, como comenté al principio, se puede ver en este proyecto que comencé hace tiempo, un servidor de syslog, que se basa en la recepción de mensajes por el puerto UDP 514, y el envío, a través de gen_event de los mensajes recibidos.

Conclusiones

Con este ejemplo, Erlang demuestra que es muy fácil construir servidores de red, con muy pocas líneas de código. En este ejemplo, el hecho de ser un servidor UDP permite eliminar el payload de la escucha, aceptación y mantenimiento de conexión con el destinatario, simplemente se acepta el mensaje, se lee y procesa, muy simple y con un buen rendimiento del sistema.

¿Qué es el código Ravioli?

bombadil — Mon, 05 Mar 2012 18:16:17 +0000

Leyendo un documento sobre Erlang, en el que introduce el concepto de módulos parametrizados, encuentro un aviso que dice (traducido): cuidado con el código Ravioli. Por lo que llego a preguntarme… ¿qué es el código Ravioli?

Hasta ahora, yo conocía el código Spaguetti, que se basaba en la programación con saltos entre las líneas del código, vamos, el uso de la sentencia goto, que quedó obsoleta con la programación estructurada. Pero al adentrarnos en la programación estructurada, surge otro anti-patrón a tener en cuenta, que es el código Ravioli.

El código Ravioli se basa en que el código se refactoriza en demasiados trozos pequeños del mismo que llegan a ser difíciles o imposibles de seguir. Este caso se da también en la programación orientada a objetos, donde el origen del código ya no está disperso entre funciones o procedimientos, sino también entre clases y paquetes, haciendo que el código sea difícilmente trazable.

Los consejos que podemos seguir para no caer en este tipo de programación son:

No ir más allá de 7 +/- 2 trozos de código. Si el código que estamos trazando (propio nuestro) tiene que ahondar en más de 7 (o 9 métodos/funciones/…) entonces quizás comience a caer en la definición de Ravioli.

Programación por parejas: si uno de los dos se comienza a perder, es mala señal.

Refactorización Sin Piedad: refactorizar intentando hacer común lo específico de modo que si hay dos funciones que hagan cosas similares, se unifiquen, y si hay dos objetos también similares, igual.

…y sobre todo, mucho sentido común. Intenta escribir cosas lógicas, que llegando a un momento dado, olvidando que lo has escrito tú, al verlo, consideres que esa es la ubicación lógica donde lo encontraría cualquier persona que viese de nuevas el código.

Con todo eso, el código Ravioli no será más un problema para tus códigos

V8: Extendiendo PHP

bombadil — Tue, 28 Feb 2012 17:39:16 +0000

Hace prácticamente un año escribí un artículo denominado Spidermonkey: extendiendo PHP, donde comentaba como emplear Spidermonkey para poder emplearlo como lenguaje de extensión a un núcleo sencillo hecho en PHP.

Incluso lo emplee como elemento principal en el desarrollo de PHAS-JS, realizando un servidor de aplicaciones en PHP, con la potencia que brindan muchas de sus librerías, pero escribiendo código de forma segura en JavaScript (o ECMAScript).

Hoy voy a tratar otra máquina que permite ejecutar código JavaScript dentro de PHP, de la misma forma que cuando vimos Spidermonkey, pero variando la forma en la que interactúa con PHP. En esta ocasión tenemos entre nosotros la máquina: el V8 de Google. Va a estar un poco inspirado en lo que he ido comentando con Sergio, que he visto que ha escrito también al respecto en su blog: PHP y JavaScript se entienden.

Instalando

Lo primero, es que si tenemos como paquete el libv8-dev, todo será más fácil ya que se resume en estos sencillos pasos (esto es válido para Debian y Ubuntu):

apt-get install libv8-dev pecl install v8js

Esta es una de las implementaciones de V8 que hay para PHP, también está disponible V8 (a secas) que es un módulo que intenta imitar la implementación de Spidermonkey, con lo que, si tienes un código que emplee el sistema de spidermonkey, pasar a v8 debe de ser cambiar muy poquitas cosas. No obstante este código está marcado como experimental y hay cosas que no funcionan del todo. La instanación sería:

apt-get install libv8-dev git clone https://github.com/metagoto/v8.git cd v8 && phpize && ./configure && make && make install

La configuración es compatible si instalamos los dos, ya que es:

extension=v8js.so extension=v8.so

Actualización: escribí un email a metagoto sobre el mantenimiento y mejora del módulo v8 para PHP. La respuesta fue que esa implementación la realizó para poder jugar y ver cómo se comportaba el sistema v8, y que no le pudo dedicar mucho tiempo, es más, abandonó el desarrollo y no tiene pensado retomarlo. Sobre el problema que observé del paso de objetos y que no pasaba sus métodos, parece que el problema no es trivial, por lo que, desecho la idea de tomarlo como una solución práctica y la dejo únicamente para pruebas y ensayos.

Probando…

En principio, podemos repetir la misma prueba que hicimos en el artículo de spidermonkey, a modo de poder enseñarlo de ambas formas. El código, por tanto sería así:

// crea la máquina para JavaScript $js = new V8Js(); // define valores para el entorno JS $js->a = 10; $js->b = 2; // define el código a ejecutar $script = <<; // evalua el script y muestra el resultado echo "La suma de $a y $b es: " . $js->executeScript($script);

La pega que tiene este, en comparación con spidermonkey, es que las funciones solo se pueden pasar si son anónimas (como variables) y que la ejecución restringe o separa lo que se pasa desde PHP en un objeto específico, por lo que queda un poco engorroso (desde mi punto de vista).

Con el tema de los objetos pasa igual, se pueden pasar objetos, pero no clases, con lo que no se pueden realizar instancias nuevas, a menos que se emplee una función anónima que haga las veces de factory o singleton.

El código de v8, que intenta emular a spidermonkey facilita esto agregando registro de funciones, clases y variables en la parte global. No obstante, este código no es completamente funcional, ya que, en las pruebas realizadas, por ejemplo, no se tiene acceso a los métodos de las clases registradas cuando se crea un nuevo objeto dentro de V8.

Conclusiones

La máquina V8 ha demostrado ser un gran intérprete de JavaScript, ya que es la que emplea Google en el navegador Chorme, no obstante, su integración con PHP falta que madure un poco y se ajuste en usabilidad a algo similar a lo que se puede conseguir con Spidermonkey.

Montículos

bombadil — Sun, 12 Feb 2012 13:56:48 +0000

Pues sí, otra vez de exámenes, otra vez estudiando, y llego a un apartado, en el que lo que decía el libro me sorprende y, al implementarlo, me confirmo. La teoría o lo que viene en los libros no es 100% fiable, en caso de teorías matemáticas, físicas, … o de computación, hay que comprobar lo que nos indican los libros, porque podemos encontrarnos con una errata.

Teniendo en cuenta que lo que indica el libro es un pseudocódigo, es peor aún, puesto que quien lo escribe está seguro de hacerlo bien, y no dudo que incluso lo haya comprobado, pero claro, nos encontramos con que, como no es un lenguaje concreto, pueda ser una interpretación de una implementación, para la cual, se ha podido perder algo de sustancia por el camino, o cometer un error tipográfico.

Pero al grano. Montículos.

¿Qué es un montículo?

Un montículo es un árbol binario balanceado que cumple con la premisa de que: ningún padre tiene un hijo mayor (montículo de máximos) o menor (montículo de mínimos) a él. Una definición corta y concreta, ¿no?

Esta estructura de datos fue propuesta por Robert W. Floyd (premio Turing en 1978) para resolver el problema de la ordenación de elementos dentro de un vector, el famoso heapsort (u ordenación por montículo).

En la asignatura de Programación y Estructuras de Datos Avanzadas (en la carrera de Grado en Ingenería Informática de la UNED), se propone al inicio de la asignatura, como conocimiento de las estructuras de datos, el montículo.

El montículo, aunque conceptualmente se dibuja en forma de árbol, está implementado sobre un vector. Ya que es balanceado y binario, un nodo solo puede contener dos hijos. La formula para acceder a cada hijo, dado el índice del padre (i), sería:

hijo_izquierdo = 2i hijo_derecho = 2i+1

El acceso al padre se realizaría con una división entera: i / 2.

¿Para qué sirve un montículo?

El montículo se emplea en lenguajes de alto y medio nivel, muchas veces sin darnos cuenta. En Java, por ejemplo, se implementa a través de la clase PriorityQueue, la cual permite, a través de un comparador, implementar la ordenación interna del montículo. En otros lenguajes puede aparecer igualmente como cola de prioridad (PriorityQueue) o como montículo (Heap).

El montículo en sí permite:

Ordenar elementos de un vector de forma fácil y óptima, pudiendo implementar un comparador a medida.

Búsquedas el máximos, mínimos, o cualquier otro factor a tener en cuenta en la selección de búsqueda de elementos.

En problemas específicos de grafos como el recubrimiento mínimo de Prim o el camino más corto de Dijkstra.

Implementación del algoritmo

Me ha costado un poco decidir el lenguaje en el que implementarlo, finalmente, he optado por Ruby, ya que su código queda bastante pseudocodificado, pero igualmente habría quedado igual de bien en Python. El código sería:

class MonticuloMaximos end

Vale, esto es lo básico, la definición de la clase. Ahora vamos a ir creando los métodos:

inicializador (o constructor): inicializa el vector interno, de modo que en el momento de crear el montículo, este estará vacío:
def initialize() @vector = [] end

vacio?: esta es una de las cosas que más me gusta de Ruby, que puedes poner en un método el símbolo de interrogación, con lo que queda bastante pseudocodificado lo que hace el método en sí. Pregunta si el montículo está vacío, y la respuesta será lógica: sí o no (veradero o falso):
def vacio?() (@vector.length == 0) end

flotar: aquí ya comenzamos con las acciones básicas de un montículo. La acción de flotar, se emplea cuando se agrega un elemento nuevo a la estructura. Lo más simple, dado que el montículo se implementa en un vector, es agregar al final del vector el elemento y flotarlo, hasta que su peso nos diga que está en el lugar indóneo, esto hace que el coste del algoritmo sea lineal, y por lo cual, óptimo:
def flotar(i) padre = i / 2 while (i>1 and @vector[padre-1]<@vector[i-1]) @vector[i-1], @vector[padre-1] = @vector[padre-1], @vector[i-1] i = i / 2 padre = i / 2 end end

hundir: sería la contrapartida a flotar. En este caso, lo que se hace es que, si eliminamos la cima del montículo, la acción rápida, sería mover el último elemento del vector al principio, cambiar el dimensionamiento del vector y realizar este algoritmo para llevar (o hundir) al elemento a su posición correcta. Igualmente, el algoritmo es lineal:
def hundir(i) begin hi = 2 * i hd = 2 * i + 1 p = i if (hd <= @vector.length and @vector[hd-1] > @vector[i-1]) i = hd end if (hi <= @vector.length and @vector[hi-1] > @vector[i-1]) i = hi end if (p != i) @vector[p-1], @vector[i-1] = @vector[i-1], @vector[p-1] end end until p == i end

insertar: en este método, insertamos (como bien dijimos en flotar) un elemento en la estructura, por lo que, hacemos eso mismo, agregamos el elemento y lo flotamos:
def insertar( e ) @vector.push(e) flotar(@vector.length) end

primero: nos da el primer elemento del montículo (la cima), pero sin eliminarlo de la estructura. Por lo que el algoritmo es:
def primero() @vector[0] end

cima: igual que el anterior, pero eliminando el elemento de la cima. Para ello, como se comentó en hundir, se toma el último elemento, se inserta en la cima (que queda vacía) y se hunde hacia su posición correcta. El algoritmo sería:
def cima() e = @vector[0] if @vector.length > 1 @vector[0] = @vector.pop hundir(1) else @vector = [] end e end

Como ayuda o soporte vamos a crear dos métodos más, uno genérico a Ruby (y presente en otros lenguajes como Java, PHP y Python, pero con distinto nombre) que permite tener una representación en formato texto (o cadena, o string) del montículo: to_s; y otro método que nos dará los elementos del montículo en un vector ordenado (eliminándolos del montículo, claro): ordenado; la implementación de ambos:
def to_s() "[ " + @vector.join(", ") + " ]" end def ordenado() a = [] a.push cima while not vacio? a end

Una vez visto todo el código, podemos hacer una prueba como la siguiente, en la que insertaremos unos datos aleatorios y obtendremos el resultado de su almacenamiento en forma de montículo, y el resultado en un vector ordenado:

a = [ 6, 4, 3, 1, 5, 2, 4 ] m = MonticuloMaximos.new a.each do |e| m.insertar(e) end puts m puts "[ " + m.ordenado.join(", ") + " ]"

El resultado es el siguiente:

[ 6, 5, 4, 1, 4, 2, 3 ] [ 6, 5, 4, 4, 3, 2, 1 ]

NOTA: Como se podrá ver en la implementación, este código estaba preparado para vectores que enumerasen sus elementos en base a 1..N, y sin embargo, todos los lenguajes (a excepción de Pascal, Modula-2, y otros similares) numeran los vectores de 0..N-1, por lo que en cada acceso al atributo @vector se ha tenido que decrementar en 1 el número, para pasar de la notación 1..N a 0..N-1.

Conclusiones

El montículo es un gran elemento que se sigue empleando por su simpleza y óptima respuesta, ya que en lugar de emplear estructura de árbol, grafos o listas, emplea un simple vector, por lo que cada acción a realizar sobre él resulta con un coste bastante reducido. Así mismo, como había dicho al principio, esté presente en todos los lenguajes, ya sea con el nombre de heap, o PriorityQueue, con la capacidad de poder implementar su comparador (para máximos, mínimos o a medida), por lo que no hay excusa para no emplearlo cuando la situación lo requiera.

Las gemas de Ruby

bombadil — Mon, 02 Jan 2012 17:03:31 +0000

Tengo a Ruby un poco abandonado, por lo que me he decidido a escribir un poco acerca de él, al igual que hice con Python, para detallar un poco cómo son los paquetes de código (o librerías) de Ruby: las gemas.

Las gemas de Ruby son paquetes de librerías para Ruby que se instalan en el sistema y quedan listas para ser usadas, con un simple require o con mecanismos que aporta el propio sistema de gemas para Ruby.

El gestor de gemas: rubygems

En distribuciones de GNU/Linux, e instalaciones automáticas para Windows, se nos habilita un comando, generalmente, que nos permite agregar librerías y código de un repositorio muy extenso de código listo para usar. Esto es conocido como el gestor de gemas, rubygems, o simplemente gem.

El gestor de gemas es un comando que nos permite listar las gemas instaladas, buscar gemas remotas o localmente (de las instaladas), instalar, actualizar y eliminar gemas. Se puede saber si está instalado simplemente ejecutando:

gem --version

La última versión a día de hoy es la 1.8.12, actualizar el sistema de gemas es tan simple como ejecutar:

gem update --system

Instalar una gema

Por ejemplo, si queremos usar el código siguiente:

require "rubygems"; require "json"; puts [ "hola a todos", 12, "C/Sin nombre, 25" ].to_json

Tendremos que instalar previamente la gema json. Para instalarla, solo tenemos que ejecutar el siguiente comando:

$ sudo gem install json [sudo] password for marubio: Building native extensions. This could take a while... Successfully installed json-1.6.4 1 gem installed Installing ri documentation for json-1.6.4... Installing RDoc documentation for json-1.6.4...

Como se puede apreciar, se instala la gema y se genera la documentación para ri y rdoc. La generación de la documentación es bastante lenta y si tenemos que instalar muchas gemas, puede ser algo tedioso. Se puede eliminar esta tarea agregando al comando de instalación: --no-ri --no-rdoc

Ahora, cuando listemos los paquetes instalados podremos ver:

$ sudo gem list *** LOCAL GEMS *** json (1.6.4)

Nos indica la versión, ya que podríamos tener varias versiones instaladas y conviviendo, y desde el código emplear la que requiramos específicamente. Si queremos instalar una versión específica de un paquete, podemos hacerlo agregando la opción, por ejemplo: --v=1.6.1

Buscando una gema

Si queremos buscar una gema específica del directorio de gemas, podemos hacerlo a través de la propia página web: RubyGems; o a través del comando:

$ gem search -r jsonn *** REMOTE GEMS *** active_record_serialize_json (0.1.2) activejson (0.1.2) activeresource_json_patch (0.0.1) assert_json (0.1.1) capcode-render-json (0.2.0) capybara-json (0.1.1) colorful_json (0.9.1) csv2json (0.2.0) cucumber-json (0.0.2) dm-json-search (0.0.3) [...]

La base de datos de gemas tiene la friolera de más de 32 mil gemas, por lo que, no es de extrañar que ante algo trivial (como JSON) puedan aparecer cientos de gemas. A la hora de buscar deberemos de ser más precisos con los términos a elegir.

Conclusiones

Ha sido una introducción muy ligera a este entorno de gestión de paquetes de Ruby, lo sé, pero al menos complementa un poco la entrada de hace algunos meses sobre Bundler y da un poco de información sobre los comandos más usuales a la hora de instalar una librería en Ruby, ya sea para código scripting o para Rails.

Catalyst: framework web para Perl

bombadil — Tue, 29 Nov 2011 18:20:22 +0000

Justo cuando colgaba la encuesta sobre: Si tuvieses que hacer un sitio web dinámico, ¿en qué tecnología lo harías?; busqué un framework en los lenguajes más populares de desarrollo web y, topé con Catalyst, un framework en Perl para el desarrollo de aplicaciones web.

Después de un recorrido por Symfony (PHP), Rails (Ruby) y Django (Python), he decidido echarle un vistazo a Catalyst (Perl) para ver qué novedades integra y en qué mejora, tanto a nivel de rendimiento, como a nivel de desarrollo, la generación de sitios web dinámicos.

Perspectiva MVC

Cada entorno integra MVC de una forma diferente, incluso lo que se entiende por MVC, desde los primeros libros a finales de los 70 y principios de los 80, es un esquema en el que la Vista puede interactuar con el modelo, al igual que el controlador con la vista y con el modelo.

En Rails, se presenta el fat model, donde la codificación referente a base de datos se realiza en estos, y el flujo de la aplicación recae en los controladores, que deciden qué tipo de vista o presentación de la información emplear, dando facilidades para la presentación en HTML, JSON, XML… e incluso vía email.

En cambio, Django, no dispone de controlador como tal, ya que lo nombran por defecto como views, siendo esta la entidad que controla el flujo y la presentación, ayudada de la plantillas usando DTL. En este caso, la parte de MVC queda más difusa y ellos mismos explican en su web, que se podría decir más bien que Django es MTV (Model-Template-View).

Catalyst, sin embargo, tiene más semejanza a Rails en este sentido. Tiene un parte para los controladores, una parte para los modelos y otra parte para las vistas. Así mismo, las vistas se desarrollan, al igual que Django y Rails, con un sistema de plantillas (templates).

Al crear un proyecto, tan solo ejecutando el siguiente comando, se genera la estructura de ficheros que podemos ver a continuación:

$ catalyst.pl miproject created "miproject" created "miproject/script" created "miproject/lib" created "miproject/root" created "miproject/root/static" created "miproject/root/static/images" [...] $ tree . ├── Changes ├── lib │ ├── miproject │ │ ├── Controller │ │ │ └── Root.pm │ │ ├── Model │ │ └── View │ └── miproject.pm ├── Makefile.PL ├── miproject.conf ├── miproject.psgi ├── README ├── root │ ├── favicon.ico │ └── static │ └── images │ ├── btn_120x50_built.png │ ├── btn_120x50_built_shadow.png │ ├── btn_120x50_powered.png │ ├── btn_120x50_powered_shadow.png │ ├── btn_88x31_built.png │ ├── btn_88x31_built_shadow.png │ ├── btn_88x31_powered.png │ ├── btn_88x31_powered_shadow.png │ └── catalyst_logo.png ├── script │ ├── miproject_cgi.pl │ ├── miproject_create.pl │ ├── miproject_fastcgi.pl │ ├── miproject_server.pl │ └── miproject_test.pl └── t ├── 01app.t ├── 02pod.t └── 03podcoverage.t 10 directories, 25 files

En el directorio lib/miproject es donde está el código principal.

Los controladores

A diferencia de otros entornos, las URLs o rutas para acceso a los métodos de Catalyst son implícitas a las subrutinas de cada paquete que está en el directorio (o paquete) de controladores. Por ejemplo, si editamos el fichero lib/miproject/Controller/Root.pm y agregamos el siguiente código:

sub libros :Global { my ($self, $c) = @_; $c->response->body ( "listado de libros!" ); }

Al ejecutar el servidor de pruebas: script/miproject_server.pl; podremos ver la siguiente tabla:

[debug] Loaded Private actions: .----------------------+--------------------------------------+--------------. | Private | Class | Method | +----------------------+--------------------------------------+--------------+ | /default | miproject::Controller::Root | default | | /end | miproject::Controller::Root | end | | /libros | miproject::Controller::Root | libros | | /index | miproject::Controller::Root | index | '----------------------+--------------------------------------+--------------'

Al cargar la página http://localhost:3000/libros podemos ver el resultado de la ejecución de la subrutina escrita.

La vista

Hemos realizado antes una salida directa desde el controlador, pero lo suyo es crear una vista. El sistema de plantillas de Perl se denomina TT. Es parecido al que se usa en JSP e incluso al que usa la DTL (Django Template Library), pero difiere bastante. Vamos a generar una vista primero:

$ script/miproject_create.pl view HTML TT

Con esto nuestro directorio de View se completa con la generación de un módulo de Perl HTML.pm. Ahora creamos una vista con la siguiente información en la ruta root con el nombre listado.tt:

Hola mundo!

[% libros %]

Para lo que habrá que cambiar la subrutina escrita anteriormente a la siguiente (también se puede cambiar el nombre y agregar como una completamente nueva):

sub libros :Global { my ($self, $c) = @_; $c->stash(template => "listado.tt"); $c->stash(libros => "no hay libros"); }

Los modelos

Tanto Django como Rails, e incluso Doctrine, tienen sistemas de migraciones o sincronización con base de datos. Catalyst no dispone de estos mecanismos. Puede generar sus modelos de una conexión de base de datos con tablas ya creadas, pero no al contrario.

No obstante, su ORM es bastante potente. Por ejemplo, pongamos que creamos una base de datos SQLite (supongamos que en /tmp/libros.db):

PRAGMA foreign_keys = ON; CREATE TABLE libros ( id INTEGER PRIMARY KEY, titulo TEXT ); CREATE TABLE autores ( id INTEGER PRIMARY KEY, nombre TEXT, apellidos TEXT ); CREATE TABLE libros_autores ( libro_id INTEGER REFERENCES libros(id) ON DELETE CASCADE ON UPDATE CASCADE, autor_id INTEGER REFERENCES autores(id) ON DELETE CASCADE ON UPDATE CASCADE, PRIMARY KEY (libro_id, autor_id) ); INSERT INTO libros VALUES (1, 'Diseño Ágil con TDD'); INSERT INTO libros VALUES (2, 'No me hagas pensar'); INSERT INTO libros VALUES (3, 'Hacking Etico'); INSERT INTO libros VALUES (4, 'Perl Best Practices'); INSERT INTO autores VALUES (1, 'Carlos', 'Ble'); INSERT INTO autores VALUES (2, 'Steve', 'Krug'); INSERT INTO autores VALUES (3, 'Carlos', 'Tori'); INSERT INTO autores VALUES (4, 'Damian', 'Conway'); INSERT INTO libros_autores VALUES (1, 1); INSERT INTO libros_autores VALUES (2, 2); INSERT INTO libros_autores VALUES (3, 3); INSERT INTO libros_autores VALUES (4, 4);

Generamos nuestros modelos con el siguiente comando:

$ script/miproject_create.pl model DB DBIC::Schema \ MiProject::Schema create=static \ dbi:SQLite:/tmp/libros.sqlite \ on_connect_do="PRAGMA foreign_keys = ON"

Con esto nos genera un fichero de esquema en el directorio Model, con lo que tendremos el acceso a la base de datos configurada. Si quisieramos probar, tan solo necesitaríamos ejecutar lo siguiente. Modificamos la subrutina de nuevo:

sub libros :Global { my ($self, $c) = @_; $c->stash(template => "listado.tt"); $c->stash(libros => [$c->model('DB::Libro')->all]); }

Y también el fichero de plantilla por lo siguiente:

Hola mundo!
[% FOREACH libro IN libros -%] [% tt_autores = []; tt_autores.push(autor.apellidos) FOREACH autor = libro.autores %]
[% libro.titulo %] - [% tt_autores.join(', ') | html %]
[% END -%]

Por último, agregamos las referencias necesarias en Libro.pm y Autore.pm (es lo malo del pluralize del inglés cuando se usan palabras castellanas):

__PACKAGE__->many_to_many(libros => 'libros_autores', 'libro');

Y esto para Autore.pm:

__PACKAGE__->many_to_many(autores => 'libros_autores', 'autor');

Con esto ya tendríamos un listado muy simple en funcionamiento. Puedes ver el tutorial completo (con un CRUD de ejemplo y más cosas aún) en la siguiente dirección (en inglés): Tutorial.

Conclusiones

El entorno proporciona las bases que proporcionan el resto de frameworks, su simpleza en las rutas y su formato de ORM hace que la programación de elementos sea bastante simple y rápida, no obstante, hay ciertos elementos con los que hay que tratar y revisarlos bien, leer bien la documentación y tratar de entenderlos, si no queremos toparnos con ningún problema a la hora de realizar cualquier entorno.

Personalmente, me ha gustado la experiencia y el entorno en sí, la programación con los módulos de Perl, lo documentado que queda todo si se siguen las líneas y el hecho de que no hace falta escribir mucho código para conseguir que el sistema funcione bien, hacen que sea un framework muy cómodo de utilizar.

Bosque Viejo » programación

Juggernaut: invirtiendo el paradigma cliente/servidor

¿Cómo funciona?

Instalación

Implementando Juggernaut en Rails

Lanzando la aplicación

Algunas pegas

Conclusiones

Estructura Lider/Trabajador en Erlang

La teoría

La implementación

Conclusiones

Go: El lenguaje de Google

Revisión del lenguaje

Potencias del lenguaje

Conclusiones

Erlang: Servidores Concurrentes TCP

Agregando conexiones TCP

Y ahora… la concurrencia

Algunas pruebas

Erlang: Servidores UDP

Empleando los gen_server

Convirtiendo nuestro gen_server en servidor UDP

Probando el servidor

Conclusiones

¿Qué es el código Ravioli?

V8: Extendiendo PHP

Instalando

Probando…

Conclusiones

Montículos

¿Qué es un montículo?

¿Para qué sirve un montículo?

Implementación del algoritmo

Conclusiones

Las gemas de Ruby

El gestor de gemas: rubygems

Instalar una gema

Buscando una gema

Conclusiones

Catalyst: framework web para Perl

Perspectiva MVC

Los controladores

La vista

Hola mundo!

Los modelos

Hola mundo!

Conclusiones