samedi 29 mars 2014

Les bases NoSQL pour stocker du XML

Pendant de nombreuses années le XML tenait le haut du pavé dans le domaine de format de fichier: pour les données , les configurations etc. Le XML était partout:

Source: http://kensall.com/

Depuis, on revient à un usage plus raisonnable du XML. Et des formats comme le JSON, le YAML ont  maintenant trouvés leur place.

Comment stocker efficacement des fichiers XML ?.

La solution habituelle.

La solution basique consiste à extraire les informations pertinentes du XML pour les sérialiser dans une base de données. Le format XML se prête mal a des opérations de recherche.
Cette solution à ses limites surtout pour des enregistrements XML de taille variable. L'exemple qui vient à l'esprit est celui de la récente réforme des échanges bancaires: le SEPA.
D'un format fixe de 240 caractères , les nouvelles normes ont évoluées sur des articles XML de taille variable. Le volume est plus important en raison de l'utilisation du XML, du détails des opérations mais d'une taille non prédictible.

 Des solutions à base de NoSQL.


Le principe de ces solutions est de stocker les fichiers XML échangés dans  une base de donnée Nosql. Le choix de cette base se portera sur un dispositif orienté document comme MongoDB.
source:
http://blogs.the451group.com/information_management/2011/04/15/nosql-newsql-and-beyond/

Les informations seront stockées sous deux formes:
Sous la forme d'origine en XML et sous un format JSON avec une succession de  clé / valeur. Les opérations de recherche se feront sur la partie JSON.

Ci-dessous un exemple de programme en Ruby utilisant la librairie nokogiri pour parser le XML:

Le fichier XML est exploré récursivement  puis injecté dans une base NoSQL mongoDB par ce script:


Le fichier XML sera injecté par ailleurs.

Ainsi l'information sera disponible sous deux formes avec une des formes autorisant des recherches multicriteres. Le stockage dans un système sans schéma est particulièrement adapté à des informations hétérogènes.






lundi 3 février 2014

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.


dimanche 12 janvier 2014

Node.js : l'opendata de la mairie de Paris et architecture MEAN

Rencontre Node.js Paris du 8/01/14 (conférence 05).  (lien ici)

Dans les locaux prestigieux de la Marie de Paris devant un auditoire attentif:




 Les sujets abordés étaient les suivants:

L'offre d'API pour accéder aux données de la mairie de Paris.  Cette API (librairie interactive) permet de construire des applications exploitant des données diverses (café pas cher, velib etc) : c'est ce qu'on appelle de l'opendata. (lien ici ).


Toute cette api repose sur une nouvelle pile logicielle MEAN , on connaissait les applications 'LAMP' : Linux + Apache + Mysql (ou postgresql)  + PHP , voici les applications  'MEAN' : MongoDB (ou NoSQL) + Express + Angular.js + Node.js.



Puis nous avons eu des présentations sur : Grunt. Qui remplace les Makefile et autres usines à gaz MAVEN. 

Grunt fait une percée significative même dans le monde J2E.


Afin des exemples de gestion de file d'attente avec Kue.


La soirée s'est terminée devant un verre et des pizzas.
L'année 2014 commence bien.


samedi 4 janvier 2014

2 cadeaux pour la nouvelle année : merci google

Après des livres (lien ici ) ,  des jeux pour bien commencer la nouvelle année. Des jeux en ligne en javascript.


Le casse-brique

Le premier est un hommage des gars de google au célèbre casse-brique d'ATARI

Le lien est ici ou bien par une recherche google image avec les mots “Atari Breakout”.


Papaoutai.

Un autre jeu basé sur google map: GeoGuessr A partir d'un parachutage dans google street essayer de deviner le lieu.

Quelques astuces: Tourner dans les environs pour repérer les panneaux, le sens de circulation des voitures , le nom des boutiques.  Le nombre de point est fonction de précision de votre réponse.



 Après un tour en ville :

Je me suis perdu en Alaska.

lundi 23 décembre 2013

Livres informatiques gratuits pour noel

Sur github , victor felder a eu la bonne idée de référencer  les livres informatiques gratuits.
Le lien est ici. La partie française est là.

J'ai cherché aussi des livres gratuits sur spring-batch:



Et sur jenkins (lien ressource en francais ici)

dimanche 22 décembre 2013

Immortel COBOL : un framework MVC en COBOL

Avec le projet COBOL on Wheelchair donnez une seconde jeunesse à vos développements COBOL.


Ce projet est ici   il permet d’écrire des applications WEB en COBOL selon le modèle MVC .

Le prérequis : un serveur HTTP, un compilateur COBOL (ex: openCobol sur Linux)  ET des développeurs COBOL.
  Les parties Controleur et dispatching semblent marcher  mais la partie modèle (accès aux données) n'est pas abordée.
Il n'y pas de doute, les développeurs COBOL sont de la tribu des immortels.




mardi 17 décembre 2013

Pourquoi Paypal migre ses applications de Java/J2E vers Node.js

Paypal a fait une annonce qui fait le tour du web: cet acteur majeur dans le moyen de paiement a annoncé l'abandon de Java/J2E en faveur de Node.js pour tous ses services.
Lire l'article ici.  ou ici en francais.
Cette décision est motivée par:

  • La durée raccourcie du cycle de mise en production
  • La durée raccourcie d'apprentissage de la filière Javascript
  • Et surtout pour des raisons de coût et  de performance. 
Site Payal:(lien ici)

Sur la performance:
  • Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.
  • 35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.
Sur les couts:
  • Built almost twice as fast with fewer people
  • Written in 33% fewer lines of code
  • Constructed with 40% fewer file
Les gains  d'apprentissage constaté dans la nouvelle filière est  de 1 pour 10  (1 jour pour javascript vs 10 jours pour J2E) . La pile J2E utilisée était le  framework Spring.

Paypal a mis en place une pile logicielle à base du framework Express. Et a reversé des librairies javascript servant à prendre en charge la sécurité dont

Lusca
Out-of-the-box application security. Lusca is middleware that can be deployed over Express, and configured to plug common attack vectors. When used, it will:
• Enable Cross Site Request Forgery (CSRF) headers.
• Enable Content Security Policy (CSP) headers.
• Enable X-FRAME-OPTIONS headers to help prevent Clickjacking.
• Enable Platform for Privacy Preferences Project (P3P) headers.
Lusca (lien ici) implemente la couche sécurité pour Express.

Donc: moins de ligne, moins de personnel , plus rapide et plus simple.