#node.js + #jQuery : mettre un tigre dans votre #node.js

Il arrive souvent aux admin de faire des programmes qui récupèrent des pages HTML pour différentes bonnes raisons:

• Vérifier des liens 
• Extraire des informations d'une page

 Ces traitements de parsing sont toujours un peu délicats et très dépendants de la page à traiter.
 Ces opérations se font à coup d'expression régulière avec des contorsions pour traiter les balises ouvrantes et fermantes.
 Avec jsdom il est maintenant possible d'utiliser la puissance de jquery coté serveur.
La puissante de la meilleure librairie javascript cliente sur un serveur node.js
Ci dessous quelques exemples: jQuery peut etre lu à partir d'un fichier local, ou téléchargé. Pour le premier exemple la page html à traiter est lue en local , dans l'exemple suivant la page est récupérée à distance.

Tous les sélecteurs jQuery sont utilisables.

JSDOM vous permettra aussi de créer des nouveaux documents, enfin   il  peut servir comme modificateur de code HTML au sein d'un reverse_proxy.


Les exemples complets sont sur lemon-labs.

#Hadoop, les limites des #nosql

Le système complet de la famille de stockage NOSQL , HADOOP vient de sortir en version 1.0
Le phénomène NOSQL commence à diffuser au sein des directions informatiques grandes ou petites.
Le sujet des bases nosql soulève deux questions:
Quels sont les cas d'utilisation à retenir ?
 Sur le site http://www.saama.com  une infographie  propose une réponse à cette question.

Le nombre de cas d'utilisation est reduit et les risques d'erreur important.
Les applications métier de gestion sont à écarter, surtout si elles reposent sur un bon vieux framework MVC J2E.
A mon sens l'utilisation d'une base NoSQL se justifie pour des usages :

• très simples. 

Exemple: l'application ne sert qu'a afficher ou a manipuler quelques table sans valeur ajoutée. Les tables seront regoupées dans une seule entité d'une base NOSQL avec de la denormalisation et de la redondance assumée.

• Des architectures d'infrastructure  avec des fortes contraintes de volume  ou de disponibilité : Un serveur de session, un gestionnaire de message par l'exemple  
• Des applications qui mettent en oeuvre des opérations d'indexation ou de comptage. C'est ici qu'intervient le map/reduce mis en avant  par google. 

En conclusion: Le Nosql est en passe de devenir le nouveau truc à vendre par les SSII. Il y très peu de projets candidats.  

Vous avez envie de vous lancer dans l'aventure. 

La tentation est forte de commencer par hadoop: Ce projet a 6 ans d'age, labélisé par La fondation Apache.
 Hadoop se présente  comme un assemblage de plusieurs sous-projet avec à la base  un système de fichier HDFS et HBASE pour le stockage. Avec hadoop les données et les fichiers sont distribués sur plusieurs serveurs. Les opérations de map-reduce se passent sur chaque fragment eléméntaire de données.

Aussi, je vous conseille de commencer avec des produits NOSQL plus modestes comme Riak ou mongodb.
Leur spectre d'utilisation est plus grand que celui d'hadoop.
Avec les produits NOSQL il faudra souvent passer par du javascript (meme pour hadoop) qui s'impose comme le langage 'utilitaire' de ces nouvelles bases.

Les bases NOSQL vont aussi se retrouver au niveau du client,  cette  adoption est favorisée par l'adoption du HTML5 et de la décentralisation des traitements. Votre poste de travail mobile va extraire les informations geo-localisées depuis une base de données centrale. Puis votre terminal travaille sur les données locales pour une re-synchronisation future.

Mais attention.

Pouvoir stocker plus de données c'est bien, mais pour en faire quoi ? Une entreprise ne sait se servir que de moins de 5% de ses données. La donnée doit etre structurée, indexée et tracée  et non pas déversée en vrac dans un entrepot ou une base de données sinon elle sera perdue.
En 2020 , l'écart entre le volume d'information et la capacité de stockage va se creuser : en clair il faudra compresser la donnée et ne sélectionner que l'information pertinente.
Aussi de la même facon qu'il y a des DSI , il y aura de Data manager assurant la gouvernance des données au sein des SI. Après l'urbanisation des SI , c'est le tour des données.

Qui a peur de #node.js , #javascript ?

Le projet node.js est un recent et provoque pas mal de bruit sur le Net.
Le sommet de la polémique a été atteint par cet article: node.js est il un cancer  ?.
La discussion a continué sur reddit.com  avec des échanges vifs. Pourquoi un tel déchaînement de passion.

Pour rappel : qu'est ce que node.js.

Node.js est l'habillage du moteur d'exécution du javascript utilisé par Chrome. Ce moteur s'appelle V8. Il est en C et en javascript. Chrome s'en sert pour exécuter le javascript coté client. Ryan Dahl et ses amis lui ont  ajouté quelques librairies afin d'obtenir un produit autonome node.js. C'est une machine virtuelle comme la JVM sur laquelle vient s’exécuter du javascript. Un des créateurs du V8 était aussi concepteur de la JVM.
Les principes de node.js sont simples :

• La  gestion dans  boucle sans fin des évènements
• Une facilité de mise en oeuvre  de  programmation asynchrone
• Un seul processus , pas de multi-thread 

Est il dangereux d'installer node.js sur un serveur. 
La réponse est NON.

Le coeur de node.js , le moteur V8 est déjà présent coté client. Les failles de sécurités sont rapidement corrigées.
Par comparaison il est plus risqué d'installer sur un serveur les services suivants :
- Un serveur apache
- Un serveur Tomcat (les failles des JVM sont les plus dangereuses)
- Un webmin , un serveur telnet ou FTP

Alors pour pourquoi tant de réticence ? 

En premier lieu, le langage javascript. Tous les admin UNIX (moi le premier) ont au cours de leur carrière utilisé ou côtoyé du javascript pourri, récupéré par copier/coller sur un site de bidouilleur.
Les vrais développeurs javascript sont rares. Ce langage est souvent utilisé comme quelque chose de deuxième zone. Ce phénomène s'inverse et le javascript est maintenant à l'honneur.

L’hégémonie de la partie client.  
Le MVC serveur était jusqu’à présent le composant principal d'une application. Il était rentable d'investir dans l'ingénierie de ces composants. Hélas, les smartphones , les tablettes, le cout du SI  et tout simplement le bon sens sont venues perturber ce bel équilibre. Le MVC passe de l'autre coté.
L'effort du  développement porte sur le coté client. C'est tout simplement  cette partie qui offre le plus de rentabilité (ROI).  Non seulement le javascript est le seul langage universel coté navigateur (client) mais en plus maintenant il cherche à envahir les serveurs. On pourrait avoir un seul langage de bout en bout (serveur _ client).

La puissance que procure node.js

Il est possible en dix lignes de javascript d’écrire un programme qui embarque les couches réseaux d'un serveur web, la gestion de la délivrance du contenu et la configuration du serveur. Node.js reproduit même le système des 'pipes' des commandes unix : on va lire un fichier et brancher sa sortie sur le flux de réponse du client. Tout ceci est possible parce node.js transgresse un 'dogme'  UNIX : l'organisation en couche. Ryan Dahl veut faire de l'informatique simple et bon marché. Idem pour  la programmation objet qui  a été détournée de son objectif. Faire de l'objet revient à faire des couches. Et comme dans la vie courante , chacun essaye de refiler sa m.... à une autre couche. Voila pourquoi des choses comme node.js , jquery ,javascript , coffeescript et Rails font peur: ils sont simples, puissants  et ne coûtent pas cher. Les apparatchiks sont inquiets.. pour leur mur de berlin

 

comparaison frameworks #javascript : infographie

Sur ce site une infographie qui compare la popularité des différents framework javascript. Résultat : jQuery vainqueur par KO.


Javascript Frameworks and jQuery Infographic is brought to you by WebAppers.com

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.

5 tendances pour 2012 #nodejs #html5 #javascript

La fin d'année arrive avec son lot de prédiction, de tendance pour l'année 2012.
Je vais faire ici ma liste des 5 tendances qui vont  dominer ou non l'année qui arrive.
Par honnêteté je réaliserai l'an prochain à la même époque un bilan.

Tendance 1: De plus en plus de chose font se faire en javascript coté client. HTML5 annonce une mutation sur la manière de faire des applications. jQuery, Backbone , batman  seront les valeurs montantes. Les raisons de ce phénomène ?:
a) La fragmentation des postes clients (pc, tablettes, smartphone)
b) les couts de traitement coté serveur vous sont facturés cash (cloud computing, serveur , salle machine)

Tendance 2: amaigrissement des frameworks : c'est le corollaire du point 1. Les serveurs ne sont que des distributeurs  de données , en JSON si possible,  avec une simplification à l’extrême. Une application métier  sera l’agrégation de mini-services hétérogènes.

Tendance 3: Les entreprises vont continuer à investir dans les réseaux sociaux (Facebook pour ne pas le citer). Après les pages de groupe ou de fan, l'étape suivante est la création par les entreprises d'applications intégrées à Facebook. La force de Facebook n'est pas son contenu mais son architecture. C'est  une architecture ouverte qui permet à chacun de développer des applications qui viennent s'intégrer à Facebook (exemple ici avec Rails) .

Tendance 4: Virage de Twitter, l'usage que je préfère est le partage de lien. Il permet de savoir que telle ou telle personne   est en cours de lecture d'un document. Delicious remplissait ce role mais depuis peu , il se tourne vers la curation de contenu, dommage. L'autre usage de twitter est la recherche d'information en continu. 2012 sera une année charnière pour twitter qui doit dégager une logique économique ou etre mangé par un gros (Facebook , microsoft ou google)

Tendance 5: Les bases de données NoSQL. Les volumes de données explosent et les entreprises ne savent plus les analyser (moins de 10 % de données sont exploitées) . Les bases NOSQL ne vont pas résoudre ce problème mais ne font que le repousser.


Les conséquences de tout ca:

Croissance de javascript et HTML5 dans les systèmes d'information. Javascript va prendre pied sur le coté serveur avec la révolution de node.js. Node.js permet à un développeur moyen de programmer des services asynchrones repoussant très loin les limites: en temps de crise , l’intelligence remplace l'argent. Dans le monde JEE scalabilité est synonyme d'achat de serveur, c'est la fin d'une époque.

Seuls les framework qui  anticiperont ce mouvement vont tirer leur épingle du jeu: parmi ceux ci :Rails.

Posez vous cette question: c'est le framework qui est à votre service ou vous qui êtes à son service.

Le blues des frameworks MVC #node.js

Le concept du framework MVC  (modele vue controleur)  date du début des années 80 , bien avant le temps d'Internet ou de Java/JEE.

mvc 2

Jusqu’à maintenant les choses étaient simples. Un bon gros serveur MVC générant des vues pour le client.
La carrière de l'informaticien était toute tracée: Le MVC serveur tu maitriseras. Hélas des elements sont venus parasiter ce bel édifice.

• La montée en puissance du javascript.

Boosté par les gars de google ou de microsoft , le moteur d'exécution javascript est celui qui a gagné le plus en performance.

• Le javascript est le seul langage supporté par tous les navigateurs.

• La segmentation du poste client

Le PC est maintenant en concurrence directe avec les smatphones ou les tablettes. Le concepteur se retrouve devant une fragmentation du matériel et il doit gérer tous les cas de figure (clavier / ecran tactile)
ET cela même au niveau des applications métiers

 Il n'est donc  plus réaliste d'avoir tout le traitement de la vue préparé au niveau du serveur. Le framework se trouve réduit à un distributeur de données en ... JSON.  

• Plusieurs frameworks et non plus un seul framework

Certains traitements sont déportés sur le client mais sans pouvoir êtres terminés.
Prenons l'exemple d'un export CSV pris en charge par du javascript sur le poste client:
A)  Le client recoit de la donnée en JSON
B)  Le client retravaille les données et fabrique un export CSV
C) Le client NE POURRA pas enregistrer son travail sur son poste local (pour des raisons de sécurité, le navigateur refuse de dialoguer avec le système de fichier local) .

La solution est d'envoyer le fichier CSV vers un serveur qui se chargera de retourner le fichier reçu avec la bonne entete. Ce serveur joue le rôle d'un miroir qui se contente de renvoyer ce qu'il reçoit du client. Pour cela une dizaine de lignes suffit, nul besoin d'un framework embarquant plusieurs milliers de ligne de code.

Ainsi l'architecture applicative ne sera pas composée d'un gros serveur MVC mais de plusieurs composants hétérogènes de taille réduite.

On ne peut plus parler de modèle MVC. Sur ce site http://blog.nodejitsu.com/scaling-isomorphic-javascript-code  Charlie Robbins  liste les differents modèles induits par l'utilisation de framework client (backbone.js , batman.js etc ) et introduit la notion de RVP : Resource-View-Presenter

C'est pour ça que les frameworks  'classiques' vont devoir s'adapter ou disparaître. A ce jour seul Rails avec les versions > 3.0 a pris le parti de se mettre en retrait sa partie serveur pour mettre en avant la partie cliente.