nodebots: Piloter un arduino par le web.

Dans un précédent post, j'avais présenté l'utilisation la librairie  johnny-five qui permet de piloter des robots dont l'arduino en javascript.

Au lieu d'utiliser le langage natif d'arduino, on installe un programme 'firmata' qui permet de dialoguer avec un programme en javascript tournant sur un PC.

Johnny-five propose deux modes d'utilisation:
En interractif: REPL :Read - Eval - Print - Loop. C'est l'équivalent d'un interpréteur de commande.
(voir exemple dans mon post cité plus haut).
Soit en mode autonome: Le programme se déroule sur le PC et envoie ses instructions sur l'arduino.

Maintenant comment piloter son arduino depuis Internet, son smartphone , un site WEB .. ?
Le montage était destiné à piloter un laser pour distraire un chat (et moi par la même occasion)

 

Nous devons introduire un dialogue supplémentaire entre  le PC et le robot. Ce dialogue utilisera  le protocole MQTT: Le protocole des 'choses'  reliées à Internet.( MQ Telemetry Transport)
MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol.

Une série de slide ici sur MQTT.


Ce protocole est très léger et il connu par la plupart des objets connectés. Et son domaine d'utilisation s'est élargie au transport de message pour les Tchats.
  Pour mémoire, Facebook utilise MQTT pour sa messagerie instantanée (ici un lien sur l'histoire de MQTT)


Pour le mettre en place , il faut disposer d'un serveur MQTT et des clients.

Pour le serveur, mon choix s'est porté sur MOSCA. C'est un serveur MQTT en javascript propulsé par le réacteur Node.js

Lien ici.
Mosca vous permet de construire votre propre serveur MQTT.

Mon code pour le serveur est le suivant:

Le serveur utilise un bakend pour stocker les messages dans mon exemple j'utilise une base NoSQL MongoDB.


Le serveur se teste facilement avec un outil en ligne de commande: mosquitto
(MQTT est protocole de type : PubSub : publier , souscrire)
mosquitto_sub -t 'hello/you'

mosquitto_pub -m "c est moi" -t 'hello/you'

Le schéma général est le suivant:

réalisé avec http://shaky.github.bushong.net/

La partie web est en mode REST


Trois  motifs  sont utilisés pour décoder es URL , un pour l'axe des X , un pour l'axe des Y, le dernier pour allumer ou éteindre le laser.


La parie contrôle d'arduino est de la forme:

Le lasercat peut maintenant etre commandé depuis le site web sous Express , par un smartphone, en ligne de commande par curl.

Bonne fête les chats.

La scalabilité dans un fauteuil avec phusion passenger

Lors de la  mise en place d'architecture à base de Node.js, les mêmes questions reviennent:
Comment superviser des applications sous node.js ?
La réponse habituelle est FOREVER : forever permet de lancer un programme sous node.js et de le relancer si besoin.
Sur une machine multi-processeur, il est fréquent lancer plusieurs instances de l'applications sous node.js.
Node.js étant monoprocesseur (monothreading) il restera cantonné sur un CPU.

Je lance donc plusieurs instances de node.js (1 par CPU) par la commande forever.
Dans le cas où on dispose de plusieurs serveur (physique ou VM ) , il est d'usage de placer un serveur web NGINX en frontal qui fera office de reverse proxy.

On obtient les architectures suivantes:

(voir article sur ce lien)

Se pose alors le problème de supervision générale du système.
Pour ma part, je lance un 'agent' sur chaque serveur qui renseigne en temps reel sur les instances Node.js qui tournent sur un serveur.

Ce programme en coffeescript lance la commande forever avec l'option list  (lignes 22 à 28) et 'compte' le nombre de ligne retournée (lignes 9 à 19) .
Ce dispositif accessible par une API REST (lignes 30 à 35 )permet de construire des interfaces graphiques de supervision:

Avec le résultat suivant :

Tout ceci est à faire manuellement.

Est ce que je suis le seul à avoir ces problèmes ?: NON répond Hongli LAI à la conférence Dot.js de Paris: (video sur ce lien )

Il reprend les différentes étapes de construction d'un projet Node.js

forever forever...

Puis faire démarrer le tout

Mettre en serveur Nginx en reverse proxy

Mettre plusieurs instances en cluster

Et monitorer l'ensemble

Ces dispositifs sont utilisés chez quelques PME : Apple, Pixar, New York Times, AirBnB, Juniper etc.. et  over 350.000 websites.

Ce montage en couche peut être remplacé par 1 seul composant : phusion passenger

phusion passenger fournit les informations suivantes: 

Lancement des Node.js : phusion passenger se charge de lancer le nombre d'instance qu'il faut et d'équilibrer leur charge. 

Reverse proxy

Supervision: à la place d'une supervision à programmer , la ligne de commande phusion passenger retourne les informations suivantes.

$ passenger-status
Version : 4.0.37
Date    : 2013-11-14 21:55:30 +0100
Instance: 25002
----------- General information -----------
Max pool size : 6
Processes     : 1
Requests in top-level queue : 0

----------- Application groups -----------
/Users/phusion/nodetestapp#default:
  App root: /Users/phusion/nodetestapp
  Requests in queue: 0
  * PID: 25012   Sessions: 0       Processed: 2       Uptime: 9s
    CPU: 0%      Memory  : 14M     Last used: 3s ago

Phusion passenger fonctionne soit tout seul ,  integré avec nginx ou encore avec apache.

Avec Node.js les architectures sont encore plus simples , plus performantes  plus robustes et moins chères.

Une astuce à connaitre pour utiliser le module d'upload formidable dans Express

Dans un post précédent, je présentai le module de téléchargement 'formidable' pour Node.js.
J'ai essayé d'utiliser ce module dans le framework Express.  Après quelques essais infructueux et des recherches sur le site stackoverflow, j'ai compris les raisons du dysfonctionnement: la juxtaposition de deux couches de traitement du formulaire d'upload.

La couche web d'express se présente comme ceci:

La ligne : express.bodyParser()  prend en charge la gestion des données du formulaire.

Aussi la syntaxe    form = new formidable.IncomingForm()  est redondante avec bodyParser.

Deux solutions  possibles:
Commenter la ligne express.bodyParser()  et utiliser new formidable.IncomingForm()   pour traiter le formulaire ou inversement , ne pas utiliser new formidable.IncomingForm() et traiter le formulaire avec les primitives d'Express.

Pour ma part je préfère utiliser les méthodes de Formidable car elles sont plus adaptées à la gestion d'un upload.

Refactorisation en coffeescript d'une application Express

Je teste  des exemples en javascript que je reprends le plus souvent en Coffeescript.
L'erreur fréquente est de tenter de reprendre tel quel le code javascript. Aussi j'ai réalisé une vidéo explicative sur les modalités de re-factorisation d'un code javascript en coffeescript.
Je suis parti d'une application javascript générée pour le framework  Express.

Pour des raisons de taille j'ai fractionné le vidéo en deux parties. Elles disponibles  sur youtube respectivement ici pour la partie I et ici pour la partie II. 

Les slides de la présentation et les videos intégrées sont disponibles également sur le site slideshare.

  

Il est possible de travailler directement en coffeescript sur des applications d'Express avec les produits : Zappa et Express-Coffee

Le résultat de la re-factorisation est le suivant:

Dans le vidéos, j'utilise l'IDE sublime Text qui affiche directement la traduction en javascript du code coffeescript.

• J'élimine les ';' et les mots clés 'var'.
• Les fonctions  sont appelées sans les parenthèses autour des paramètres  sauf pour les appels de fonction sans paramètre.
• Les fonctions anonymes sont sorties des blocs pour devenir des fonctions nommées.
• Les appels de fonction chaînés par un '.' sont individualisés.

Des uploads formidables avec le module formidable pour node.js

Le transfert de fichier entre un client et un serveur reposait habituellement sur des protocoles de transferts dédiés: exemple FTP , SFTP (via ssh) ou TFTP (trivial FTP) . Mais l'usage du navigateur comme client léger universel a modifié les usages.
Il est fréquent maintenant de recourir au protocole HTML et HTTP pour 'uploader' ou' downloader'  des fichiers (video , photo etc.)

source : site du zero

Nous allons nous intéresser à l'utilisation du module Formidable pour node.js dans le cadre de l'upload (sens client vers serveur)

L'usage d'un serveur node.js est particulièrement adapté à ce type de service. Les connexions sont longues (le temps de transfert), par morceaux (trunk) et avec des temps de latences importants en raison des débits des réseaux.
Aussi le cas d'usage de l'upload est en plein dans le cœur de cible de node.js

Le module formidable

Son installation se fait par le gestionnaire de paquetage npm.
La commande d'installation est la suivante:
npm install formidable@latest
Avec comme résultat:

npm http GET https://registry.npmjs.org/formidable
npm http 200 https://registry.npmjs.org/formidable
formidable@1.0.11 node_modules/formidable

Le module est livré avec des exemples pour commencer des essais.

Le dialogue client/serveur est fait par le biais d'un formulaire html qui doit avoir les propriétés suivantes:

enctype="multipart/form-data" method="post

Et contenir une balise INPUT de type "file" name="upload" multiple="multiple"

(le code HTML est dans le répertoire 'example'  du module)

La requête envoyée au serveur va contenir des tronçons délimités par des 'boundary'. 
Un tronçon va contenir les données du fichier à télécharger  (l'image, le son ) , un autre contiendra les autres paramètres du formulaire.

Cette dualité se retrouve au niveau des évènements  gérés  par le module (on 'file' , on 'field')

form.parse(req, function(err, fields, files)

Un exemple complet  ici en coffeescript:

Il est souhaitable d'indiquer un répertoire  (uploadDir) de réception qui sera par défaut /tmp.
Le fichier sera nommé à l'aide d'une chaîne aléatoire. Le nom d'origine du fichier (celui du poste client) est indiqué qu'a titre indicatif.
Ce module est utilisé en production par des sites de téléchargement professionnels. Il est donc hautement recommandé de l'utiliser à la place de solution interne.

Nous verrons dans un autre post comment utiliser le module 'formidable' avec le framework 'express'

Utilisation de la librairie async.js pour Node.js

Dans un environnement synchrone classique, les fonctions s’enchaînent les une a la suite des autres de manière linéaire.

Avec Node.js doté d'un système d'entrée-sortie  non bloquant et asynchrone, les choses ne se déroulent pas toujours dans l'ordre souhaité.

Soit par exemple 3 fichiers: un petit , un moyen et un gros fichier.

Le programme ci-dessous en coffeescript va lire les 3 fichiers:

Le résultat d'exécution sera:

>coffee async1.coffee 
traitement termine
 Je termine de lire le petit fichier
 Je termine de lire le moyen fichier
 Je termine de lire le gros fichier

Deux remarques:

Le display de la dernière ligne s'affiche en premier . 

Les fonctions se terminent dans un ordre différent de leur appel: celle relative au fichier le plus petit , appelée en dernier se termine la première.

Tout cela est normal dans une logique asynchrone: Toutes ces appels de fonctions sont réalisés dans le même cycle d'exécution du moteur Node.js. Node.js n'attend pas la fin de l’exécution de la fonction pour passer à la suivante.

Pour enchaîner l’exécution des fonctions dans un ordre précis il faudrait re-ecrire le programme comme ceci:

Avec cette fois le résultat suivant:

> coffee async2.coffee
traitement termine
 Je termine de lire le gros fichier
 Je termine de lire le moyen fichier
 Je termine de lire le petit fichier

Chaque fonction appelle la fonction suivant dans sa dernière instruction. On se retrouve alors à devoir gérer des callbacks imbriqués dans des fonctions. Le programme perd en lisibilité.

Il existe une librairie très populaire dans la sphère de Node.js : async.js. qui prend en charge ce type de problème.
Ce module disponible par la commande  npm install async. permet de gérer plus facilement l'ordre d’exécution des fonctions.

Dans cet exemple, on utilise deux formes d'appel : le mode en série et parallèle.
Dans le  mode en série (serial),  async.js va attendre la fin de chaque fonction pour lancer la suivante.

remarque1 : async.js appelle vos fonctions en ajoutant une fonction de retour en paramètre  ce parametre ne sert qu'a un usage interne à async.js
(midf = (callback)-> fs.readFile 'middle_file', (err,data) => ...)

remarque2: la méthode toString appliquée à une fonction permet de lister le source de la fonction
 (console.log callback.toString() ...)
   

Think asynchrone ...

Express pour Node.je et Sinatra

Express est un framework MVC pour Node.js.  C'est donc du javascript (ou du coffeescript).



Express revendique clairement sa filiation avec Sinatra pour Ruby.

Et c'est vrai que l'analogie est frappante :

Coté Sinatra :

Au delà de cette simple comparaison, Sinatra et Express appartiennent bien à la même famille des DSL dans le domaine d'application de la couche WEB.

1) Le domaine d'application de Sinatra.

Sinatra permet offre un langage de manipulation de la couche web middleware.  Ruby possède une couche middleware très puissante appelée Rack.

Rack permet de faire le lien entre une requête HTTP  entrante (url, méthode et parametre) et des objets Ruby. Il est possible d'agencer à sa guise la pile de traitement d'une requete WEB.

Sinatra offre un langage permettant de travailler directement avec ces couches.

2) Le domaine d'application d'Express

Express tout comme Sinatra permet de manipuler facilement le middleware pour Node.js appelé 'connect.js'.

Express ne fournit pas directement un DSL comme dans Sinatra. Il permet en revanche de réaliser très facilement pour Node.js des applications WEB en mode MVC.

3) Les deux modes d'utilisation de Sinatra.

Sinatra fonctionne sous deux modes:

Le mode 'classique' 

L'application tient dans un fichier et elle est écrite avec le DSL.

Le mode modulaire.

L'application peut être répartie dans plusieurs fichiers.  Il est possible d'avoir plusieurs applications pour un seul interpréteur Ruby actif. En revanche on ne pourra pas faire appel directement au DSL, il faudra passer par des méthodes.

Aucun mode n'est meilleur que l'autre. C'est vraiment deux usages différents. Dans les deux cas, le développeur pourra intervenir sur l'agencement de la couche middleware.
Dans les deux modes, il est possible et recommandé d'isoler les vues dans des sous-répertoires.

4) Les deux mode d'utilisation d'Express

Express lui aussi propose deux usages.

Le mode simple

Comme pour Sinatra, l'application tient dans un fichier et liste les actions à mener pour chaque url.



Ici un exemple en coffeescript.

Le mode MVC

Un appel à la commande express 'mon_appli' génère une arborescente qui ressemble  à celle  d'une grosse application Sinatra.

Par défaut Expres utilise le système de template 'jade' mais il est possible de choisir son moteur des template. Pour ma part , j'utilise 'ejs' qui se rapproche beaucoup de 'erb' pour ruby.

Dans les deux modes, le développeur garde la possibilité de modifier la couche middleware.



En conclusion: Sinatra est a réserver pour les petite applications, après il vaut mieux passer à Rails.

Express, lui prend en charge tout l'aspect serveur WEB (cache , session )  qui n'existe pas en l'état dans Nodes.js  Express sert souvent de base pour d'autres frameworks.
je prépare une série de vidéos sur le thème d'express, rendez vous sur twitter.





 

Publier une simple application pour Node.js sur le Cloud Heroku

Encore une nouvelle vidéo de "made by German".  Cette fois, elle a pour objet la publication d'une application Node.js sur le  cloud Heroku.

La video ou screencast est en ligne ici.




Le programme est très simple, il n'y a pas de dépendance.
Voici le source en coffee script :

Sans dépendance  le fichier package.json est très simple:


Le reste des manipulations sont celles vues sur les vidéos précédentes.



Le prochaine série de vidéo sera consacrée au projet Express qui est le pendant de Sinatra mais pour Node.js

Lire un fichier ligne à ligne en #javascript - #coffeescript

Lire un fichier texte ligne à ligne n'est forcement quelque chose de naturel avec javascript  (coffeescript):
Ci dessous un exemple complet:

La lecture se fait de manière asynchrone par l'ouverture d'un stream en lecture. L'avantage de se mode de fonctionnement est qu'il permet de traiter des gros fichiers, seul un tronçon de fichier transite en mémoire.

La traduction en javascript donne:

Du code bien expliqué avec docco.coffee #javascript

Pour expliquer le contenu d'un programme, il n'y rien de mieux que les annotations en marge du listing.  Cette opération est maintenant automatique avec l'utilitaire docco.coffee. Il fonctionne  avec node.js, il utilise la librairie python 'pygments'.

Il fonctionne très simplement:  docco *js ou docco *coffee ,  va créer un répertoire 'docs' qui contiendra une page HTML.

Tout ca donne vraiment envie d'écrire de la doc.

serveur documentaire en #coffeescript pour node.js

Il arrive parfois d'avoir besoin d'un petit serveur de document en complément d'une application métier lourde.

ci dessous un exmple de programme en coffescript (qui sera traduit en javascript) pour un moteur node.js



Le programme commence par récuperer les parametres de lancement
Pour chaque requete le serveur vérifie la présence du fichier dans son cache mémoire (ligne 24-29) . Si le fichier n'est pas en cache, il va le lire, l'envoyer puis le mettre dans son cache mémoire. Le programme est tout simple et il présente une alternative interressante à un serveur Tomcat ou apache.
Il suffit de déployer  un sous-répertoire de document  dans le répertoire d'installation.

Le point fort de ce serveur est sa simplicité (une vingtaine de ligne)  et sa robustesse.  Par sa conception et son moteur d'exécution il est capable d'encaisser une charge supérieure à un tomcat ou a un apache dans les mêmes conditions.
C'est un serveur qui ne coute pas cher à deployer ou à maintenir. Il offre plus de sécurité qu'un serveur apache pour le même usage: pas besoin de mettre des options de droit sur l'affichage de répertoire

Le programme est disponible sur https://github.com/germanlinux/Lemon-labs/tree/master/nodeJS
L'idée originale est de casimir Antunes. J'ai ajouté la gestion du cache inMemory et le controle de l'existence des fichiers.

LemonNode.js nouvel SSO en javascript

J'ai initialisé le projet lemon:node.js sur la forge github (lien ici ) .

Le dessin ci dessous illustre l'aspect novateur de cette solution :

Plus besoin d'infrastructure dédiée, chaque application est responsable du  SSO. Le SSO fait partie de l'application et n'est plus un composant tiers.
Tout ce ci est possible grace à plusieurs facteurs :


Le serveur de javascript  node.js : Il est léger, terriblement efficace. Il s'installe infdifferement sur des serveurs unices ou windows. Il facilite la programmation asynchrone non bloquante.


Le langage coffeescript: il permet de générer du javascript à partir d'un langage projet du python ou du ruby.
Lemon:node.js c'est une centaine de ligne de code à comparer au millier de ligne de code d'un lemonldap (ou lemnladap::ng)

Tout est parti de cet article :
A HTTP Proxy Server in 20 Lines of node.js Code . Dans ce,  post  Peteris Krumin explique comment réaliser un proxy web en 20 lignes de javascript. En ajoutant quelques lignes de plus cela est devenu un reverse-proxy.

Je vais tacher maintenant de completer le projet avec de la documentation.

Comment utiliser lemon:node.js :

Les prérequis sont :
L'installation de node.js
L'installation de npm : le gestionnaire de module pour node
Le module api_request

Coffeescript  n'est utilise que pour modifier le source. Le projet contient les sources coffee et le javascript généré.

Conférence sur coffeescript

Dans cette vidéo,  David Kinney de Redpoint Technologies présente les avantages de coffeescript.
J'ai réalisé le montage suivant à partir de sa présentation :
Dave met en parallèle la grosse bible : guide définitif de javascript et le petit fascicule sur les bons morceaux de javascript. C'est vrai qe javascript PLUS que tous les autres langages est une arme dangereuse à ne pas mettre en toutes les mains.

La preuve cette petite expérience:
Sur une console lancer  le calcul : '10' + '4'  puis '10' -'4'
Le résultat est là:


node
console.log('10' + '4')
104
console.log('10' - '4')
6


Surprenant !

Aussi coffeescript permet d'éviter la plupart des pièges de javascript tout en générant du javascript propre.

En plus il fournit des opérateurs qui simplifie la vie comme par exemple le '?'

Sa présentation se termine par l'intégration dans  rails 3.1 de coffeescript

La video :

CoffeeScript: A New Brew by David Kinney, Redpoint Technologies from ChicagoRuby on Vimeo.

Les evenements #Node.js et #cofffeescript

J'ai evoqué dans un  précedent post, l'importance des fonctions de retour  (callback) dans l'architecture d'une application asynchrone. Gérer une suite d'action asynchrone par un chainage de callback se révèle vite très difficile. Aussi , il existe un deuxième composant venant en complément des callback : les évènements.
Node.js fournit une librairie pour gérer les évènements : require ('event'). Les évènements sont le véritable centre nerveux d'une application asynchrone dans Node.js. Ils  émettrent  des signaux qui  associés à des callback, orientent et cadencent  le déroulement du programme.
Exemple:
Les opérations pour  interroger une  page WEB les suivantes:
1) Se connecter au serveur
2) Lancer la requête
3) Traiter les entêtes
4) Traiter le corps de la page
4) Se déconnecter

Pour ne pas bloquer le système entre chaque étape notamment celle qui attend la réponse du serveur, il est judicieux de programmer l'émission de signaux à des moments clés du cycle. Exemple 'j'ai reçu les entetes'  , 'j'ai  reçu les données de la page' et 'le serveur m'indique que c'est terminé'.  pour chacun de ces signaux, il sera nécessaire de les 'ecouter' et de réagir  en  lançant les actions associées (callback) .
Ce système est composé de deux parties: l'emetteur de signaux (evenement) et le recepteur (listener) qui attend les évenements et lance les actions (callback ) prévues.


Les API de base de node.js sont livrées avec une gestion d’évènement, en charge pour le developpeur de réaliser la partie qui va traiter ces évènements.
(Exemple API HTTP: documentation ici )

  Avec  ici un exemple de récepteur sur l’évènement 'data':

  res.on('data', function (chunk) {
    console.log('BODY: ' + chunk);
  });

Comment mettre en place son propre système d’évènement.

La partie réception et traitement est la plus facile en voici un exemple:


Deux récepteurs sont mis à l'écoute.

La partie émission des signaux.

Node.js fournit la libraire 'event' et voici un exemple en coffeescript qui fonctionne avec le programme précédent:


Il ne faut pas grand chose ! C'est la magie de coffeescript et la puissance de node.js.
Pourquoi la magie de coffesscript ?
Parce en javascript écrit à la main, dans les règles de l'art,  cela donne:


La premiere fonction sert à construire proprement des objets, sans effet de bord sur d'autres modules.
(copiée sur api_request )

Il est intéressant de voir que tous ces problèmes de constructeur sont pris en charge par coffescript comme le montre le javascript issu du programme coffee. 

Aussi, coffescript n'est pas un simple générateur de code. Il met en place les bonnes pratiques et vous économise des lignes de code.

Temporisation en coffeescript et javascript

Pour un néophyte ,il est surprenant de ne pas trouver un équivalant à wait ou sleep dans les instructions du javascript. ci dessus des exemples de timers en coffeescript:
Le bloc à base de while est à éviter. Il monopolisera les ressources durant son exécution.

L'instruction qui permet de simuler ce comportement est la fonction setTimeout. Sa premiere utilisation est délicate. En effet on est souvent tenté de lui passer en paramètre un appel à une fonction mais c'est une expression qui est attendue.
Dans l'exemple en coffeescript le symbole '->'  permet de définir des fonctions anonymes. '=>' est une variante à cette utilisation.

Client HTTP asynchrone avec node et coffescript

Un des points forts de Node est de pouvoir programmer facilement des fonctions asynchrones.  Ci dessous un exemple de programmation d'un client HTTP. Cette fonction va interroger une base NoSQL en faisant varier la clé de 0 à 4.  Le programme est en coffeescript,  il utilise la librairie api_request. disponible ici sur github. 

L’exécution de programme montre bien l'aspect asynchrone des requêtes : La boucle 'for' est exécutée sans interruption (les lignes : début de fonction) , puis Node commence à envoyer les requêtes au serveur Nosql dans un ordre qui n'est pas celui de la boucle.  Il commence par la 'clé 4' . Avec une boucle plus grande (ex : 100) on retrouve cette 'clé 4' en première requête. Cette valeur peut changer sur une autre machine.  Pendant la boucle for , le gestionnaire d’évènement se contente de stocker les demandes, puis en   fonction de son cycle interne , profite des interruptions pour réaliser les requêtes. Avec une boucle de 100 requêtes, les 10 premières sont en vrac puis le système se régule. Dans un système asynchrone, la fonction appelée retourne un callback  (fonction de retour) et se termine. Ce callback sera appelé lors de la réalisation  de l’évènement associé.
 
Il existe des moyens pour enchaîner des actions synchrones  dans un univers asynchrone (ce n'est pas une aberration) . Le callback doit prévoir cet  enchainement d'action.

exemple :



La fonction de callback fait un appel récursif tout en incrémentant  la clé. A la réception de réponse du serveur, un évènement sera déclenché. La fonction callback associée à la réalisation de l'évènement sera appelé et cette fonction fournira l’enchaînement suivant. On utilise dans cet exemple des techniques de programmation fonctionnelle, ce n'est pas un hasard. Les fonctions callback se déclenchent dans un temps incertain et surtout avec des variables globales dans un état lui aussi incertain. La programmation fonctionnelle donne des modes de résolution pour ce type de problème avec des  variables partagée.

Une tasse de coffeescript

Coffeescript est un nouveau langage de programmation qui génère du javascript. Le site officiel est ici.

 Ce langage est remarquable, il fait parti des DSL (domain specific language). Son auteur Jeremy Ashkenas a démarré en utilisant un livre très connu des hackers : Comment ecrire son propre langage de programmation.

La première version de coffeescript était en Ruby, un langage très adapté pour les DSL. Les versions suivantes  de coffescript sont en  coffeesript...
Coffeescript utilise la bombe du moment 'node.js' comme interpréteur.

Le programme javascript généré peut s’exécuter dans un navigateur ou sur une instance de node. La syntaxe de coffeescript est un mélange de Ruby et de Python dont il reprend les principes d'indentation.
Un script coffeescript par convention prendra l’extension '.coffee'
La génération du javascript se fait par la commande coffee -c monscript.coffee. On obtiendra ainsi  un  programme monscript.js. Ce programme répond à tous les critères de qualité des outils comme jslint.
Sans l'option '-c' le script est  traduit et exécuté directement  par node.js

Le framework Ruby on Rails dans sa dernière version intègre ce générateur de code.
Il suffit de placer un script avec l'extension coffee dans le répertoire javascript pour qu'il soit compilé et rendu disponible à l'application.

Ici j'utilise jquery via coffeescript :

$ ->

   alert "mon premier script avec coffeescript" 

Après un temps d'adaptation de quelques jours, j'ai du mal maintenant à écrire directement du javascript. D'autant qu'il se charge du sale boulot: déclaration des variables locales, closures etc.
La simple ligne : puts = console.log permet d'utiliser la notation classique puts "mon message" comme en Ruby.
J'ai profité du site www.scoop.it pour rassembler des liens sur le sujet : lien de curation ici.