Proyecto Liqueed (2)

Anterior Post

Como todo proyecto Node.js, el proyecto Liqueed, en

https://github.com/liquid-co-ops/liqueed

El contenido actual es:

{
  "name": "liqueed",
  "version": "0.0.2alpha",
  "private": true,
  "scripts": {
    "start": "node ./bin/www",
    "test": "simpleunit ./test ./testserver"
  },
  "dependencies": {
    "express": "~4.2.0",
    "static-favicon": "~1.0.0",
    "morgan": "~1.0.0",
    "cookie-parser": "~1.0.1",
    "body-parser": "~1.0.0",
    "debug": "~0.7.4",
    "ejs": "~0.8.5",
    "express-ejs-layouts": "^1.1.0",
    "ostore": "0.0.4",
    "simplelists": "0.0.4",
    "simpleasync": "0.0.5",
    "mongodb": "~1.4.19",
    "bcrypt-nodejs": "0.0.3",
    "express-session": "~1.9.3"
  },
  "devDependencies": {
    "simpleunit": "0.0.5",
    "simplejquery": "0.0.1",
    "zombie": "2.5.1"
  }
}

Es una aplicación privada, es decir, no se puede publicar en el repositorio público de npm.

Es una típica aplicación express, con código inicial generado con express-generator. El archivo bin\www tiene el código de lanzamiento de la aplicación. Tiene módulos express, como morgan, cookie-parser, body-parser, express-session, pero también algunos más que se usan en la implementación de la lógica interna del sistema:

- ostore: repositorio de simples objetos JavaScript en memoria, usado en varios tests y en la versión inicial, como persistencia en memoria, sin necesidad de usar una base de datos desde el principio.

- mongodb: el sistema final usa MongoDB como base NoSQL

- simplelists: un simple utilitario con funciones sobre listas (arreglos)

- simpleasync: una librería para encadenar llamadas asincrónicas sin morir en el intento.

- bcript-nodejs: módulo de encriptación escrito en JavaScript

Para los tests (armados siguiendo el flujo de trabajo de TDD, Test-Driven Development), uso:

- simpleunit: librería de test, basada en usar assert internamente, exportando los métodos a testear en cada archivo de test.

Para los tests de las páginas de la Single Page Application de public\index.html se usa:

- zombie: visita una página como si fuera un browser

Próximos temas en próximos posts: cómo está estructurada la lógica del servidor, los tests que se escribieron, exponer API, páginas MVC, persistencia, cliente SPA (Single Page Application).

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in JavaScript, Liqueed, NodeJs, Proyectos Open Source | Comments Off

Programando para Internet of Things

Como saben, siempre practico programar todos los días, especialmente aplicando TDD (Test-Driven Development). Y si bien hay proyectos no públicos, la mayor parte de esa práctica la pueden ver en mi cuenta pública de GitHub. Y como escribí en el post de ayer, Node.js es una tecnología muy interesante, por su poder y simplicidad, para implementar muchas ideas que en otras tecnologías (Java, .NET, Scala, Ruby, Python, Clojure, Smalltalk) no me parece que sea tan fácil (aclaro lo de siempre: el precio a pagar por programar en el paraíso de Node.js son los “callbacks”).

Hay muchas ideas e implementaciones interesantes (en aplicaciones, proyectos, “startups”) dando vueltas. Pero un tema interesante que ya está entre nosotros, pero que va ir creciendo todavía más, es el tema Internet of Things. ¿Habrá lugar para que “startups” puedan luchar e imponerse en este campo? ¿será deglutido por Google, Apple, Microsoft? Veremos. Pero independientemente de eso, es época para programar e implementar ideas, en código abierto. Si se puede montar una “startup” encima de eso, mejor (pienso que para una “startup” lo principal es la EJECUCION: ideas hay a millones, e implementaciones hay a miles).

Mientras, algunas ideas (con alguna implementación incipiente en mis proyectos públicos de GitHub, ya vieron algunas ideas e implementaciones en mis charlas) (por supuesto, hay YA implementaciones, y también “startups”, pero siempre es interesante explorar por uno mismo un campo):

- Recolectar información de dispositivos, conectados a la red. Tener un repositorio de datos, enviados desde un SDK cliente para cada dispositivo. Luego, explotar esos datos.

- Aplicar Inteligencia Artificial (bueno, es un término amplio, lo admito, pero el mejor que tenemos por ahora) a todos esos datos, descubriendo patrones, aplicando “machine learning”, “deep learning”. Hábrán visto algunas implementaciones en JavaScript en mis proyectos

- Tomar decisiones, usando sistemas expertos u otros, y ejecutar comandos, acciones. De nuevo, habrán visto implementaciones mías en JavaScript/Node.js. Tener algo como IFTTT abierto, listo para usar, alimentado por eventos y datos colectados de Internet of Things.

- Aplicar para todo esto, computación distribuida, no solamente escalabilidad horizontal transparente en la nube. Hay mil estrategias para implementar, y Node.js es un vehículo interesante para experimentar. Luego, se puede pasar a un lenguaje y tecnología compilado, si hace falta ganar en rendimiento de serialización, por ejemplo.

Disculpen la auto-referencia a proyectos míos, pero quería pasar en limpio el panorama por el cual estoy haciendo esos proyectos.

Y además, me diviegto como logco! :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in Aplicaciones Distribuidas, Inteligencia Artificial, Internet of Things, JavaScript, NodeJs, Proyectos Open Source | Comments Off

Jornada Programando en Node.Js desde Cero, en Buenos Aires

Gracias a la gente del MUG (Microsoft User Group de Argentina), voy a dictar todo un día la jornada presencial:

http://www.mug-it.org.ar/Event.aspx?Event=218

Jueves 12 de Marzo, desde las 9:30hs hasta las 18:00hs, con intervalos.

La idea es que si vienen con una notebook y son programadores (.NET, o de otra tecnología), podamos ver juntos cómo es Node, programar algún código simple, aprender a usar y bajarse módulos. Entre el final de la mañana y el comienzo de la tarde, veremos programación web, usando algún ejemplo con Express. Después aparecerá un ejemplo con acceso a MongoDB, y hacia el final, visitaremos Socket.IO.

El temario es entonces:

1. Introducción a Node.js
1.1. Programación Javascript desde Node sobre el motor V8
1.2. Entrada/Salida asincrónica
1.3. Módulos
1.4. Manejador de paquetes npm
1.5. Elementos de Test-Driven Development
2. Programación Web con Node.js
2.1. Módulo HTTP
2.2. Manejo asincrónico
2.3. Acceso a MongoDB
3. Programación Web con Express
3.1. Concepto de Middleware
3.2. Lenguaje de Templates
3.3. Ejemplos con Páginas y Acceso a Datos
3.4. Programando con JSON
3.5. Elementos de Socket.IO

Veo a Node como la tecnología y ecosistema que mejor combina simplicidad con potencia. Es un aire fresco en la programación, ya sea web o de servicios expuestos por API, o distribuidos. Y realmente, el ecosistema de paquetes que tiene es el mejorcito con el que me he encontrado hasta ahora. El gran precio a pagar: usar y entender los “callback” en JavaScript, es el derecho de piso a pagar. He visto aplicaciones de startups y otras aplicaciones totalmente desarrolladas en Node.js, con buena escalabilidad y nivel de servicio. Hasta podrían usar .NET desde Node.js, aunque no es muy usado.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in Buenos Aires, JavaScript, NodeJs | Comments Off

Enviando Mensaje a Slack con JavaScript/Node.js

Hace ya como un año o algo más, entró en mi radar Slack:

https://slack.com/

Leo ahí “Slack is a platform for team communication; everything in one place, instantly searcheable, available wherever you go”.

En general, soy algo excéptico a las herramientas en línea de este tipo, prefiero una combinación más simple. Para lo que dice arriba, me basta gmail y listas de correo por proyecto o equipo. Pero pueden leer la interesante historia del fundador de Slack y las ideas que hay detrás del emprendimiento en:

http://www.wired.com/2014/08/the-most-fascinating-profile-youll-ever-read-about-a-guy-and-his-boring-startup/

Mis enlaces sobre Slack en:

https://delicious.com/ajlopez/slack

Por ejemplo, pueden leer este artículo con tips sobre como usarlo:

https://medium.com/@slackhq/11-useful-tips-for-getting-the-most-of-slack-5dfb3d1af77

Ayer a la tarde me puse a explorar cómo enviar un mensaje, usando la API expuesta por Slack, desde Node.js (que me parece la tecnología más simple para este tipo de experimentos). Más info general de la API en:

https://api.slack.com/

Busqué en Google algún módulo de Node.js y encontré como primer resultado:

https://github.com/xoxco/node-slack

Lo instalé con NPM en un directorio de trabajo, y probé algo como:

var domain = process.env.SLACK_DOMAIN;
var token = process.env.SLACK_TOKEN;

var Slack = require('node-slack');
var slack = new Slack(domain, token);

var channel = process.argv[2];
var message = process.argv[3];

console.log('Sending message', message, 'to channel', channel);

slack.send({
    text: message,
    channel: '#' + channel,
    username: username
});

Se debe poner valores en las variables de ambiente SLACK_DOMAIN y SLACK_TOKEN. Cuando uno ingresa a un grupo de Slack, corresponde a un dominio. Por ejemplo, uno es https://squeakros.slack.com donde está la gente de Smalltalk Squeak Rosario. Otro es https://nodejsar.slack.com, la gente de Node.js Argentina. El token es por usuario y aplicación y lo podemos pedir en:

https://api.slack.com/web

Bien, el programa ejecutó sin problema con

node run.js general “Hello, world”

en Windows (o sea, el primer argumento luego de run.js, es el canal destino, sin el # (numeral), y el segundo argumento es el texto del mensaje). Pero no llegaba el mensaje. Tampoco daba error. Al fin, encontré el Pull Request:

https://github.com/xoxco/node-slack/pull/8

que parece que no fue integrado todavía al código original. Resulta que hace unos meses, cambió la API de Slack. El pull request sugerido usa otro forma de acceso, en vez de token usa una URL provista desde:

https://your-domain.slack.com/services/new/incoming-webhook

Usé la sugerencia que está en uno de los comentarios, pedir el node-slack directamente desde la dirección en GitHub del pull request, en el package.json que describe al proyecto y sus dependencias:

{
  "name": "slack-demo",
  "private": true,
  "version": "0.0.1",
  "dependencies": {
    "node-slack": "git://github.com/Dahlgren/node-slack.git#hook-url"
  }
}

Y el programa ahora usa esa URL, tomada desde una variable de ambiente:

var hookUrl = process.env.SLACK_WEBHOOK;
var username = process.env.SLACK_USER;

var Slack = require('node-slack');
//var slack = new Slack(domain, token);
var slack = new Slack(hookUrl);

var channel = process.argv[2];
var message = process.argv[3];

console.log('Sending message', message, 'to channel', channel);

slack.send({
    text: message,
    channel: '#' + channel,
    username: username
});

Todo funciona. Temas a investigar: ¿se podrá seguir usando dominio/token? ¿de qué manera? ¿hay otros módulos más actualizados? Por ahora, sigo experimento con este módulo.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in JavaScript, NodeJs, Slack | Comments Off

Resoluciones del Nuevo Mes: Febrero 2015

De nuevo, tiempo de revisar mis resoluciones del pasado mes, y escribir las nuevas.

- Continuar agregando caracteristicas distribuidas a AjErl, un intérprete tipo Erlang en C# [pendiente]
- Mejorar ClojSharp [completo] repo
- Mejorar ScalaSharp [completo] repo
- Mejorar emulador Chip8 [completo] repo
- Generación de Código con AjGenesis para Node [pendiente]
- Mejorar Lenguaje Basic Script en  C# [completo] repo
- Escribir JavaScript e Inteligencia Artificial [completo] post 1 post 2 post 3

Adicionalmente, estuve trabajando en:

- Comenzar ClojJS, compilador y ejecutor ClojureScript a JavaScript [completo] repo
- Comenzar DValues, valores de datos para Internet of Things [completo] repo
- Trabajar el en Proyecto Liqueed [completo] repo
- Mejorar AjScript, un intérprete tipo JavaScript en C# [completo] repo

Las resoluciones para este nuevo mes de febrero:

- Completar la primera versión de ClojJS
- Completar la primera versión de BScript
- Mejorar ClojSharp
- Mejorar ScalaSharp
- Completar primera versión de emulador Chip8
- Escribir más posts sobre JavaScript e Inteligencia Artificial

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in .NET, C#, Clojure, Java, JavaScript, NodeJs, Proyectos Open Source | Leave a comment

El valor de TDD (2)

Anterior Post

En el anterior post comentaba que una de las ventajas de TDD (Test-Driven Development) es que facilita cambiar nuestro código, ya sea para mejorarlo o para adaptarlo a nuevos casos de uso. Quería comentar hoy algunas experiencias (me temo que sobre proyectos no públicos, así que no tengo un repo para mostrar) donde descubrí ese valor de TDD.

Por ejemplo, en un proyecto ya terminado y entregado, el cliente pide despues de un tiempo un cambio: un nuevo caso de uso. El proyecto contenía un “parser” de expresiones de consulta, tipo SQL, sobre un modelo de dominio en memoria, y en en lenguaje consulta que se había implementado había filtros como

where Year = 2013

Donde se admiten otros operadores que el igual, pero donde la expresión de la derecha era siempre una constante. Para el nuevo caso de uso el cliente pedía extender este lenguaje de consulta (tanto el “parser” como la ejecución de la consulta, para tener expresiones como

where Year = @today – 10

donde @today es el año actual, donde la expresión de arriba es “dame los datos de hace diez años”. Bien, como tanto el “parser” como el ejecutor de comandos estuvieron hechos con TDD, estaba todo preparado para probarlos, y se escribieron los nuevos tests a pasar. Al principio no compilaba (en C#), y luego comenzó a compilar, pero dando las pruebas nuevas en rojo. Se agregó el código necesario para que pasen a verde, se corrieron todas las pruebas para ver si había algún “side effect”, efecto colateral, que rompiera algo, pero todo anduvo bien. Se entregó el resultado al cliente, lo probó, y hasta el día de hoy no ha reportado un solo “bug” sobre el tema. Lo está usando sin problema. ¿Cuánto se tardó en modificar el código? Pues:

UNA HORA

Tardé otra hora explicando lo que había hecho (en inglés, que no es un tema que domino mucho ;-).

Pero no es solamente el tiempo, sino que la forma de trabajo (TDD antes, TDD ahora), permitió:

- Apenas gastar tiempo mínimo en depuración
- No romper nada de lo anterior (porque TODO LO IMPORTANTE que anda de lo ANTERIOR, se implementó siguiendo el flujo de trabajo de TDD, no con simple “test-after”; entonces si los tests de ahora dan en verde, es ALTAMENTE PROBLABLE que el sistema en conjunto siga funcionando)
- Dejar todo preparado para que otro equipo pueda hacer lo mismo (adaptar el sistema a un nuevo caso de uso) más adelante.

Pongamos un ejemplo negativo. En un proyecto, había una lógica que, dado un usuario y un tema, devolvía una lista de documentos de ese tema y accesibles por el usuario (no era exactamente así, pero basta en este post esa descripción para el ejemplo). Obtener esa lista no era simple: había una gran cantidad de lógica, no siempre directa (un documento podría heredar de otro, y heredar entonces su accesibilidad o innaccesibilidad por un usuario; había distintas accesibilidades (para ver, para modificar, etc)…). Y además, en la implementación del anterior equipo de desarrollo, alguien había decidido algo como “si lo ponemos en un Stored Procedure va a andar más rápido” (sin hacer ninguna prueba que corrobere esa afirmación). Conclusión: todo estaba en un stored procedure de decenas de líneas.

Llegó el momento de, ante un caso de uso nuevo, hubo que refactorizar esa lógica: en el caso de uso nuevo, en algunas ocasiones, obtener esa lista llevaba un par de decenas de minutos (jeje… si, la “magia” de poner todo en el stored procedure ;-). Eso en sí no es problema: no siempre la primera implementación es “la mejor” (en parte, porque no hay “la mejor”, sino que quizás hay “la mejor para los actuales casos de uso, pero tal vez hay que cambiarla cuando aparezcan nuevos casos”), y la original implementación que ya estaba en producción había cumplido con su cometido, y el sistema estaba funcionando sin mayor problema. Pero al hacerlo sin TDD, una consecuencia es: FUE DIFICIL agregar un caso de uso, y reimplementar la lógica, porque no había forma de saber, por pruebas automáticas, qué casos eran cumplidos por la nueva implementación (un modelo en memoria fue la nueva implementación, mucho más rápido), y cuáles no. Conclusión: hubo que implementar pruebas con casos de uso más frecuentes, y como no estaba claro qué tenía que devolver en cada caso, la prueba comparaba el resultado DE LA NUEVA implementación, con el resultado que daba la VIEJA implementación. No es la mejor solución.

¿Lección aprendida? Hacer TDD, paga, nos da beneficios, en especial al cliente final, y a todo equipo que venga a mantener el sistema. Sin TDD: horas o días para reproducir y arreglar un bug, interminables sesiones de depuración, costo mayor para el cliente final, desgaste y poco avance diario. Con TDD: todos felices, y dedicando el tiempo a agregar valor y no a remar en un río de mermelada ;-)

Tengo más casos para comentar, pero espero que lo de arriba sirva para aportar agua para el molino de TDD.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in Desarrollo Agil, Programacion, Test-Driven Development | Comments Off

Proyecto Liqueed (1)

Siguiente Post

Hoy quería presentar en un post corto, al proyecto Liqueed, pueden ver el repo en:

https://github.com/liquid-co-ops/liqueed

desarrollado como aplicación web sobre una idea del bueno de @acyment, leer su post (en inglés):

http://blog.agilar.org/index.php/2014/04/30/leancoops-first-draft/

La idea básica de la aplicación es ayudar a los equipos que estén desarrollando algo a la manera que sugiere Cyment en el tema del reparto de acciones sobre el proyecto. Desde hace unos meses, la aplicación (el código, el backlog, las ideas, la implementación, el hosting y demás) se viene armando en un equipo que también quiere ser “líquido” (con entrada y salida de gente, pero aún estamos cortos con el tema de las votaciones propias, en casa de herrero :-)

En esta serie de posts que hoy inicio, quisiera comentar temas técnicos interesantes que plantea el proyecto. Por hoy, comento que:

– Es una aplicación Node.js, expuesta a la web usando Express. Con lo que el lenguaje de programación es JavaScript.

– Además de algunas páginas internas de administración con MVC, tiene una API expuesta, que intercambia JSON.

‘- Hay una aplicación Single Page que es la que tendría que usar el usuario final, para ver los proyectos, las votaciones, los repartos de acciones y para ingresar las nuevas votaciones

– La mayor parte del código fue escrito usando el flujo de trabajo de TDD (Test-Driven Development). Incluso, el primer código implementó el modelo en memoria, permitiendo avanzar más fácil sobre la implementación de casos de uso, sin tener que detenerse tanto en la persistencia (hasta el cliente SPA puede ejecutarse sin necesidad de tener un servidor andando)

– Hace ya unos meses, agregamos persistencia con MongoDB. Podríamos usar otra base, relacional quizás. No estamos aprovechando las facilidades de manejar documentos de MongoDB todavía. Solamente la elegimos por su ubicuidad en las plataformas de desarrollo y en los distintos servicios de hosting de Node.

– En algún momento agregamos Istambul para el cubrimiento de código.

– Cuando los tests de TDD por código puro comenzaron a ser largos, se agregó un DSL (Domain Specific Language) simple que permite escribir archivos de texto con los pasos a seguir en el test funcional

– Comenzamos a agregar tests de la SPA (Single Page Application) usando Zombie

Y habría mucho más para comentar, espero que con más detalle en los próximos posts.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in Desarrollo Agil, Desarrollo Web, JavaScript, Liqueed, MongoDB, NodeJs, Proyectos Open Source | Comments Off

JavaScript e Inteligencia Artificial (3)

Anterior Post

Un tema que presenté con un ejemplo (pero sin ejecutarlo) es la evaluación de la próxima jugada en un juego de tablero. No pude dejar de mencionar a una película que vi hace décadas y que me influyó bastante en la forma de ver la inteligencia artificial, Juegos de Guerra (“War Games” de 1983, ver Wikipedia ver IMDB):

En los juegos de tablero, es común evaluar una posición, y dada las posibles jugadas, evaluar las posiciones resultantes, eligiendo la mejor para nuestro bando. El problema es determinar cuál es “la mejor”. En general, no hay funciones de evaluación perfecta de una posición. Lo que se puede hacer, es explorar un árbol de jugadas, para tener una evaluación “más profunda” de la posición actual. Esto permite calcular un valor de la posición actual en base a la posible evolución de las próximas jugadas. Hay varias formas de explorar un árbol (los remito al libro mencionado en el anterior post, base de toda la charla)

Elegí como ejemplo, un juego de tablero con azar, donde las jugadas son azarozas (hay un tiro de dados), el conocido backgammon. Lo elegí con cierta nostalgia del trabajo de Hans Berliner, en los ochenta, que conocí gracias a un artículo del Scientific American:

 

Fue el primer programa que le ganó a un campeón mundial humano en un juego de tablero. Pueden leer los artículos de Hans Berliner en:

Backgammon Computer Program Beats World Champion
Computer Backgammon

Si leen la descripción del programa, tiene mucha heurística, mucho conocimiento experto del juego. Mi proyecto es más modesto y trata de que la evaluación de una posición “emerga” de explorar el árbol de jugadas, calculando al final una “métrica” sencilla de cuán lejos estamos del objetivo final (sacar todas las fichas del tablero antes que el adversario).

El proyecto en JavaScript en:

https://github.com/ajlopez/SimpleGammon

Escrito usando TDD (Test-Driven Development) desde Node.js consola. Pero el ejemplo es para browser:

https://github.com/ajlopez/SimpleGammon/tree/master/samples/html

Tiene una interfaz simple, a mejorar:

Ejecuta la evaluación de dos jugadas hacia adelante, en el cliente. Antes de “Play” pueden elegir quien mueve, y cuales son los dados iniciales. Pero vean que tarda sus buenos segundos, un tema a mejorar. Varias opciones a explorar, como procesamiento en paralelo (vimos en la conferencia que JavaScript tiene implementaciones para aprovechar procesadores), y también, derivar la evaluación al servidor, y que éste lo derive a varias máquinas “worker” (algo así hice para otro ejemplo, de algoritmos genéticos).

Otros proyectos en los que estoy trabajando para evaluar posiciones (pero todavía sin ejemplos, trabajo en progreso):

https://github.com/ajlopez/SimpleGo
https://github.com/ajlopez/SimpleChess

El juego del Go es atrapante, pero no trivial. Primero, quiero avanzar más con la implementación de backgammon, el primer candidato es evaluación distribuida.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in Charlas, Inteligencia Artificial, JavaScript, NodeJs, Proyectos Open Source | Comments Off

Resoluciones del Nuevo Mes: Enero 2015

Un nuevo año comienza. Pero para mí, sigue siendo el mes la unidad de “nuevas resoluciones”: me parece así que es más útil, flexible y alcanzable. Tiempo de revisar las resoluciones del mes pasado,  y plantear las nuevas:

- Agregar características distribuidas a AjErl, el intérprete tipo Erlang en C# [parcial] ver repo
- Mejorar ClojSharp [completo] ver repo
- Mejorar SimpleLisp [completo] ver repo
- Generación de Código con AjGenesis para Node [pendiente]
- Comenzar Basic Script Language en C# [completo] ver repo

Adicionalmente, estuve trabajando en:

- Mejorar ScalaSharp [completo] ver repo
- Primeras operaciones del emulador Chip8 en JavaScript [completo] ver repo
- Escribir ejemplos de Clojure (con Ring, Compojure) [completo] ver repo
- Trabajar en proyecto Liqueed [completo] ver repo
- Mejorar AjScript [completo] ver repo

Las resoluciones para el nuevo mes:

- Continuar con características distribuidas de AjErl, intérprete tipo Erlang en C#
- Mejorar ClojSharp
- Mejorar ScalaSharp
- Mejorar emulador Chip8 en JavaScript
- Generar código con AjGenesis para Node
- Mejorar Basic Script Language para C#
- Escribir posts de JavaScript e Inteligencia Artificial

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in .NET, AjErl, AjScript, C#, ClojSharp, JavaScript, NodeJs, Proyectos Open Source, Simpl, SimpleLisp | Leave a comment

Aktores Implementando Akka Actor Model en C# (2) Un simple Ejemplo

Anterior Post

Veamos hoy un simple ejemplo que crea dos actores y les envía mensaje. El código completo está en:

https://github.com/ajlopez/Aktores/tree/master/Samples/PingPong

Como siempre, todo es “trabajo en progreso”, y puede cambiar en el futuro. Estoy siguiendo el flujo de trabajo de TDD (Test-Driven Development), así que alguna llamada a la API puede ir cambiado, o cambiar algún concepto de base, a medida que me planteo casos de uso cada vez más interesantes (ya llegué a implementar caso de uso distribuido, por ejemplo).

En este ejemplo, tenemos un actor:

using Aktores.Core;

public class PingActor : Actor
{
    private int messagecount;

    public int MessageCount { get { return this.messagecount; } }

    public override void Receive(object message)
    {
        messagecount++;
        this.Sender.Tell("ping", this.Self);
    }
}

Vean que un actor desciende de una clase base Actor. El gran método a implementar es el Receive, que recibe un mensaje enviado por alguien en el sistema (otro actor, otro objeto) a nuestra instancia. Aktores se asegura que los mensajes nos lleguen y se procesen de a uno por vez. En el actor de arriba, una vez recibido un mensaje, incrementa un contador y le responde al enviador del mensaje original con otro mensaje (el enviador está referenciado en this.Self, DURANTE el proceso de un mensaje; luego puede cambiar al llegar otro mensaje).

Otro actor similar:

using Aktores.Core;

public class PongActor : Actor
{
    private int messagecount;

    public int MessageCount { get { return this.messagecount; } }

    public override void Receive(object message)
    {
        messagecount++;
        this.Sender.Tell("pong", this.Self);
    }
}

El programa principal, lo que hace, es crear un sistema de actores, crear dos actores, uno del tipo Ping y otro del tipo Pong, y luego le envía mensajes a procesar:

public static void Main(string[] args)
{
    ActorSystem system = new ActorSystem(2);
    var pingactor = new PingActor();
    var pongactor = new PongActor();
    
    var ping = system.ActorOf(pingactor);
    var pong = system.ActorOf(pongactor);

    for (int k = 0; k < 10; k++)
    {
        ping.Tell("pong", pong);
        pong.Tell("ping", ping);
    }

    // ....
}

Tiene código adicional para medir la cantidad de mensajes que se procesan en el tiempo. El parámetro 2 en el constructor de ActorSystem indica que necesita DOS threads de trabajo interno para procesar mensajes. Deberé revisar si esa información queda ahí o de otra manera. Dos threads son suficientes porque no tenemos más que dos instancias de actores, pero podríamos poner otro número si usamos más actores.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Posted in .NET, Actor Model, Aktores, C, C#, Proyectos Open Source | Comments Off