Je termine ma présentation d'AngularJS par une application minimaliste.
Au passage je fais une petite démonstration de l'IDE Brackets.
Pour bien commencer : 2 livres gratuits consacrés à AngularJS
Les slides de support de la video sont :
La video est sur youtube: lien ici
Python, Ruby, javascript, node.js, cloud ,NoSQL bref que des bonnes choses
Contacter le robot germanlinux: german.eric AT gmail.com
samedi 14 juin 2014
lundi 9 juin 2014
Une introduction à angularJS et aux Single Page Application
J'étais parti pour faire une video sur AngularJS mais j'ai éprouvé la nécessité de remettre cette technologie dans un cadre plus général de développement des applications.
J'expose le système courant du templating coté serveur et coté client.
Avec ici la synthèse:
Mais le plus important est de replacer le phénomene des SPA: Single Page Application dans le contexte. REST , MVVM (angularJS ) , SPA et NoSQL sont autant des pièces d'un même puzzle.
Pourquoi des applications de ce type:
Au premier abord toutes ces notions semblent très compliquées, mais en commençant doucement par des exemples simples, tout devient possible.
En conclusion: ce n'est pas un simple mouvement de mode. Ces évolutions touchent la manière de faire des applications, de conduire des projets.
Le support des slides de la video est ici:lien
Sur youtube : la video est diffusée a cette adresse.
J'expose le système courant du templating coté serveur et coté client.
![]() |
| Templates coté client |
Avec ici la synthèse:
Mais le plus important est de replacer le phénomene des SPA: Single Page Application dans le contexte. REST , MVVM (angularJS ) , SPA et NoSQL sont autant des pièces d'un même puzzle.
Pourquoi des applications de ce type:
- Pour des raisons Economiques: les coûts sont partagés , elles sont scalables, elles sont simples.
- Pour la simplicité des solutions misent en oeuvre.
Au premier abord toutes ces notions semblent très compliquées, mais en commençant doucement par des exemples simples, tout devient possible.
En conclusion: ce n'est pas un simple mouvement de mode. Ces évolutions touchent la manière de faire des applications, de conduire des projets.
Le support des slides de la video est ici:lien
Sur youtube : la video est diffusée a cette adresse.
jeudi 1 mai 2014
Pour bien commencer avec les Architectures REST ou RESTFUL
La vague REST va déferler sur nous. Hélas, la encore des marchands de rêve vont chercher à vous vendre du REST au kilo.
Ce qu'il faut bien comprendre: Les architectures REST devront être une CONSÉQUENCE de l'évolution de vos applications et non pas une CAUSE d'évolution de celles-ci.
En clair: commencer par mette du REST sans avoir ce qui va avec, mettra en difficulté votre système informatique, vos équipes etc.
«Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.»
Un chapitre ici traduit en français. (Le 5eme : un des plus important)
Couverture ( observez qui à donné son avis sur le livre)
(selfie truqué : pourquoi ? : à vous de trouver l'erreur)
1) Utilisation des verbes (Méthodes) du HTTP.
GET : lire une ressource
DELETE : supprimer une ressource
POST et PUT: pour creer ou modifier une ressource
(ou inversement : l'idée est d avoir un verbe pour créer différent de celui utiliser pour modifier)
2) Chaque ressource a son URL. On interagit avec les ressources en combinant les url avec les methodes HTTP.
4) Le serveur applicatif ne sert qu'a délivrer de la donnée (le plus souvent au format JSON et non plus XML)
Voila le rapidement présenté le REST.
Aussi mettre en place du REST sans avoir un idée de la stratégie à mettre en place coté client (Angular, Backbone , Ember ?...) c'est prendre le sujet à l'envers.
Le critère de la session gérée coté client est important, sinon le simple test suivant est suffisant :
Est ce que votre application fonctionne avec le simple client HTTP en ligne de commande CURL ?
Ex : curl -X DELETE http://localhost:4567/pgm/5352d84751514034cc000048
(la partie serveur qui répond à la requete)
Ce qu'il faut bien comprendre: Les architectures REST devront être une CONSÉQUENCE de l'évolution de vos applications et non pas une CAUSE d'évolution de celles-ci.
En clair: commencer par mette du REST sans avoir ce qui va avec, mettra en difficulté votre système informatique, vos équipes etc.
Pour commencer le REST (ou RESTFUl ) c'est quoi ?
- C'est une une thèse de Roy T. Fielding. En 2000.
«Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.»
Un chapitre ici traduit en français. (Le 5eme : un des plus important)
- C'est un livre de chevet (publié en 2007) :lien ici
(selfie truqué : pourquoi ? : à vous de trouver l'erreur)
- C'est une série de principe :
1) Utilisation des verbes (Méthodes) du HTTP.
GET : lire une ressource
DELETE : supprimer une ressource
POST et PUT: pour creer ou modifier une ressource
(ou inversement : l'idée est d avoir un verbe pour créer différent de celui utiliser pour modifier)
![]() |
| source stackoverflow: http://stackoverflow.com/questions/630453/put-vs-post-in-rest |
- GET http://www.example.com/customers/12345
- GET http://www.example.com/customers/12345/orders
- GET http://www.example.com/buckets/sample
- PUT http://www.example.com/customers/12345
- PUT http://www.example.com/customers/12345/orders/98765
4) Le serveur applicatif ne sert qu'a délivrer de la donnée (le plus souvent au format JSON et non plus XML)
Voila le rapidement présenté le REST.
Pourquoi le REST a-t-il le vent en poupe ?
- Il permet de répartir les coûts d'infrastructure entre le fournisseur de ressource (service) et l'utilisateur (poste client). Il est donc pleinement compatible avec le modèle économique des clouds. Les traitements coûteux en CPU (assemblages des pages WEB, manipulation des donnée) sont réalisés sur la machine du client.
- Les infrastructures et les applications sont plus simples: pas besoin d'avoir des serveurs de session, des bus d'entreprise etc.
- La scalabilité est linéaire: sans partage de session à prévoir, avec des serveurs à gestion d 'événement (Node.js , nginx) , l'ajout d'un serveur augmente surement le nombre de connexion possible.
- Il met fin au débat entre les langages et les framework : PHP ,Java, Spring, Express, Rails :La partie serveur ne sert qu'a délivrer de la donnée JSON. Le seul langage à maîtriser vraiment est le Javascript (le seul langage universel pour le navigateurs). Aussi, si vous n'avez pas les ressources de développement aguerries au Javascript l'adoption du REST sera difficile.
Aussi mettre en place du REST sans avoir un idée de la stratégie à mettre en place coté client (Angular, Backbone , Ember ?...) c'est prendre le sujet à l'envers.
Comment reconnaître le vrai du faux REST.
Le critère de la session gérée coté client est important, sinon le simple test suivant est suffisant :
Est ce que votre application fonctionne avec le simple client HTTP en ligne de commande CURL ?
Ex : curl -X DELETE http://localhost:4567/pgm/5352d84751514034cc000048
## Restful uri
##
delete '/pgm/:id' do
@id_pgm = params[:id]
@pgm = @db['pgm'].remove('_id' => BSON::ObjectId(@id_pgm) )
response.write ("{ok}")
end
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:
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 ?.
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.
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.
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.
![]() |
| Source : https://delta-xi.net/gfx/xml-landscape.gif |
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
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 fonctionne soit tout seul , integré avec nginx ou encore avec apache.
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 lien est ici ou bien par une recherche google image avec les mots “Atari Breakout”.
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.
Le casse-brique
Le premier est un hommage des gars de google au célèbre casse-brique d'ATARILe 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.
Inscription à :
Articles (Atom)

























