« Le site web, le blog et les projets de Stéphane Klein »
stephane-klein.info est le site web d'un développeur passionné par les Logiciels Libres, les méthodologies (agiles…), la programmation en Python… mais aussi la politique, l'histoire, la philosophie…
Le site stephane-klein.info est visible sur
tout type de navigateur. Il est possible d'accéder parfaitement à toutes les
informations du site (sauf les commentaires) même avec un navigateur du type
Lynx ou
Links.
Il est conseillé d'utiliser un navigateur récent et conforme aux standards pour
consulter le site avec la totalité de son design (voir un screenshot du site…).
Cela fait quelques jours que je me pose la question suivante : « Est-ce que Node.js ne va
pas devenir une technologie incontournable / majeur dans les 2 ans qui viennent ? »
Le contexte
Je suis un développeur Python depuis de nombreuses années. J'aime ses librairies, j'aime ses outils,
j'aime sa communauté.
J'aime tellement sa syntaxe que quand je vois la syntaxe d'autres langages, j'ai une réaction
quelque peu épidermique à la lecture du code.
Avec le temps, l'habitude de la syntaxe Python minimaliste proche d'un pseudo code rend difficile
la possibilité d'apprécier un autre langage. Je ne sais pas si c'est positif ou négatif,
je me pose simplement la question. Enfin ceci est un autre sujet.
Cependant, mon regard se tourne de plus en plus vers Node.js... je n'ai pas
franchi le pas, je n'ai rien développé en Node.js… mais je me demande si je ne passe pas à
coté de quelque chose d'important.
Les forces de Node.js
Bien que Node.js date seulement de 2009 :
il a déjà un bon système de package : Node Package Manager que la grande
majorité de la communauté semble utiliser
il a déjà une très forte communauté, de très nombreuses librairies,
exemple : plein de librairie classées,
déjà plus de 9000 packages sur npm
tous les développeurs web (front-end) connaissent le langage, il est très populaire.
Par conséquent, pour passer à Node.js il n'y a pas le frein d'apprendre un nouveau langage comme ça
serait le cas avec l'utilisation d'un framework web basé sur Ruby ou Python. Je pense que dans
les mois qui viennent, de nombreux développeurs PHP vont passer à Node.js… surtout ceux qui
regardaient ailleurs mais qui ne souhaitent pas apprendre un nouveau langage.
la possibilité de partager du code (librairies communes…) entre la partie client et serveur peut
être intéressant. La question se pose de plus en plus étant donnée qu'on est de plus en plus amené
à effectuer beaucoup de traitement coté client (exemple avec Backbone.js).
Dernièrement, dans tous mes projets de développement web, j'ai utilisé un moteur de template
coté client en plus du moteur de template coté serveur.
Je dois gérer de plus en plus souvent une couche modèle coté client. Des vues coté client…
Cela fait donc plein d'éléments en doubles, utilisés
une fois sur le serveur, une fois sur le client. Donc deux technologies à maîtriser.
Ces derniers jours, la visualisation du screencast du framework javascript Meteor
m'a mis la puce à l'oreille.
Autre exemple, il est possible d'utiliser la même API Canvas coté client et
coté serveur (avec node-canvas).
Node.js semble être très rapide, ça tient très bien la monté en charge.
La vitesse de l'interpréteur Javascript est en constante progression V8 (JavaScript engine)
Faiblesses de Node.js
Je ne sais pas si mes remarques sont exactes, je n'ai aucune expérience en Node.js.
Exemple dans la partie Bad Use Cases
du guide Felix's Node.js Convincing the boss guide il
est indiqué que les framework
Node.js sont moins matures que ce que l'on peut trouver en Ruby, Python et Php (bon pour ce dernier
j'ai des doutes, je pense que la communauté Node.js est déjà plus mature, plus structurée que
la communauté Php… enfin bon…).
Je n'ai pas trouvé d'outil comme Whoosh en Javascript
(c'est un moteur de recherche léger). J'ai tout de même trouvé Node-xapian
Je ne sais pas si il est encore tôt pour passer à Node.js mais si la communauté continue à être
aussi dynamique que ces 2 dernières années… alors les pièces manquantes seront bientôt créées.
Quand je vois cette liste, je me pose sérieusement la question : est-ce que Javascript est le langage incontournable
de ces 10 prochaines années ? Certes il est déjà incontournable dans le navigateur, mais pour le reste ?
Édition 5 mai 2012 :
j'ai publié ce billet sur LinuxFR, j'ai reçu 90 commentaires…
j'ai publié ce billet sur la mailing list de l'Afpy, j'ai reçu 25 commentaires… malheureusement les archives de cette liste n'est pas publique
Pour ne pas fausser le nombre de visites de mes sites - c'est à dire des sites sur lesquels
je suis en train de travailler, développer, rédiger du contenu - je cherchais une astuce pour
que Google Analytics ne prenne pas en
compte mes propres visites.
J'ai trouvé par exemple une solution qui constite à mettre en place un filtre sur les adresses IP
que j'utilise. Cependant, cette solution ne me convient pas tout à fait. Je peux consulter
mon site depuis divers accès… je n'ai pas envie d'ajouter toutes les adresses IP.
J'ai trouvé une autre solution qui me convient mieux :
je modifie le user-agent de mon navigateur, j'y ajoute un identifiant
dans les pages de mes sites, j'active le code Javacript de Google Analytics uniquement si le "User-Agent" ne contient pas l'identifiant que j'ai ajouté
Pour modifier la valeur de mon "User-Agent", j'utilise l'extension Firefox User Agent Switcher.
J'ai ajouté "stephane-klein" comme identifiant, ce qui me donne le résultat suivant :
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2;stephane-klein) Gecko/20100101
Firefox/10.0.2
Ensuite, au niveau de l'activation de Google Analytics dans mes pages webs, j'ai quelque chose comme ça :
if (navigator.userAgent.indexOf("stephane-klein") == -1) {
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-29999662-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script');
ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' :
'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
})();
}
Certes, mon identifiant "stephane-klein" sera visible pour toutes mes visites sur tous les sites (bien que je peux
switcher rapidement la valeur de mon "User-Agent") mais bon, je trouve cela pas bien grave. Il est aussi possible
d'utiliser un identifiant qui n'a pas de sens, un UUID par exemple.
Personnellement, cet article me fait penser à une réflexion qui m'est déjà venu de nombreuses fois :
là où l'auteur de l'article voit deux systèmes, deux types d'applications distinctes, je vois en fait deux couches…
Bon en fait, l'auteur semble le dire aussi à la fin de son article quand il parle de CPS + PMS.
Je reprends ci-dessous à peu près la description qu'il fait d'un CPS et d'un PMS :
CPS - c'est le système qui gère la couche données, la logique métier du CMS, comme :
l'enregistrement des ressources (Pages, Images, Dossiers…)
un moteur de recherche plain texte (avec filtre…)
un workflow
un système de versionning
import / export de données
…
PMS - c'est le système qui pour résumer "affiche" les pages :
la navigation
système de template
layouts
skins / thèmes
back office d'édition
…
« Content Repository »
À mes yeux… je ne fais pas bien la distinction entre un Content Repository et
un CPS.
Si j'essaie de les différencier, je dirais qu'un Content Repository est une librairie ou un serveur alors qu'un CPS est une
application, avec des Interfaces Utilisateur…
Dans la suite de l'article, je vais partir du principe que Content Repository est la même chose qu'un CPS même
si ce n'est pas totalement exact.
Dans le monde Java, une spécification nommée JCR (Java Content Repository) décrit ce qu'est un Content Repository et comment
l'utiliser (spécification d'une API standard).
Il existe plusieurs implémentations de JCR mais la plus connue semble être Jackrabbit
de la fondation Apache. Je l'avais rencontré il y a quelque années lorsque j'ai étudié de loin Nuxeo.
J'ai été agréablement surpris de découvrir les projets PHP suivants (ce qui confirme que je ne suis pas le seul à me poser ces questions) :
The ability to evolve content models over time (what I call “schema evolution”)
Branch / merge (in the Source Code Management (SCM) sense of the term)
Snapshot based versioning
ACID transactions
Scalability to large content sets
Geographic distribution
Chacun de ces points sont détaillés dans son article et c'est fortement intéressant.
Par exemple, je trouve le point « Branch / Merge » très juste… bien que je ne sache pas tout à fait
comment l'implémenter simplement.
À partir de cette liste, voici la liste des "requirements" de mon Content Repository idéal :
Base de données où je peux stocker des objects JSON ainsi
que des blobs (exemples : base de données NoSQL comme MongoDB,
CouchDB)
Base de données où je peux stocker des collections (pour des dossiers), des liens (pour des redirections), des associations (pour des catégories, des tags…)
API Rest qui permettent d'accéder plus ou moins à toutes les features du Content Repository
Système d'import / export de données (je ne sais pas si il y a un format standard pour les CMS… enfin je n'ai jamais trouvé)
Support d'une API CMIS (bien que je la trouve peu élégante… c'est bien une API faite par le monde Java)
Accès WebDAV
Gestion des utilisateurs
Pour le moment, je n'ai pas trouvé le Content Repository de mes rêves.
Le standard CMIS « Content Management Interoperability Services »
Le standard CMIS est un autre élément
intéressant à prendre en compte dans un CPS.
CMIS est une couche d'abstraction dont le but est de permettre de faire communiquer plusieurs instances de CMS
identiques ou différentes ensemble. Elle doit permettre par exemple d'importer les données d'une instance
à une autre.
J'ai prévu d'écrire d'autres billets à propos des Content Repository :
Un retour d'expérience et mes réflexions concernant un premier Content Repository que
j'ai écrit en Python, basé sur la base de données NoSQL ZODB et le moteur de
recherche Whoosh. Il comporte aussi un
connecteur WebDAV.
Un autre billet sur une proposition d'API RESTful pour un Content Repository… quelque chose
de naturel et vraiment dans l'esprit RESTful.
Exemple :
GET http://example.com/blog/my-post => est dans l'esprit RESTful
GET http://example.com/post?name="my-post" => est moins dans l'esprit RESTful
Dans l'API REST de CMIS j'ai trouvé beaucoup de requête suivant la seconde forme d'URL
et très peu ou pas sous la première forme d'URL.
Je vous invite à lire l'article Wikipedia Méthodologie open space car il correspond très bien à ce que j'ai vécu.
Voici un extrait :
Selon Harrison Owen1, le succès d'un Open Space repose sur le respect d'une loi, étayée par quatre principes. Pendant le rituel d'ouverture, ces éléments sont cités et expliqués aux participants.
Les quatre principes :
Les personnes qui se présentent, sont les bonnes ;
Ce qui arrive,est la seule chose qui pouvait arriver ;
Ça commence quand ça commence ;
Quand c’est fini, c’est fini.
La loi des deux pieds : Si vous n’êtes en train ni d’apprendre, ni de contribuer, passez à autre chose !
Dans l'open space auquel j'ai participé, deux éléments supplémentaires ont été ajouté lors du rituel d'ouverture :
« Être un bourdon, ce n'est pas sale ! » : ce n'est pas grave si l'on passe d'un groupe à l'autre… on peut partir d'une discussion (suivre la loi des deux pieds), on peut s'insérer dans une discussion sans problème
« Être un papillon, ce n'est pas sale ! » : si on n'est perdu… ce n'est pas grave… attention toutefois à ne pas tuer les papillons :)
L'hôtel Arnold était entièrement réservé pour l'Agile Open France 2012… le cadre était vraiment très pratique.
L'hôtel était vraiment très bien, très beau, les chambres spacieuses, les repas étaient très bons, les employés de l'hôtel étaient vraiment très agréables…
Des petits salons très confortables, fauteuils, canapés, open bar, équipé de tableaux, de rétroprojecteurs…
Vraiment, le cadre était parfait.
Les principaux sujets auxquels j'ai participé
De mémoire, j'ai participé aux sujets suivants (les titres ne sont sans doute pas exacts, l'ordre est arbitraire) :
Les Farfadet du génie logiciel
Le service Heroku : discussions et retours d'expériences
Le langage Erlang : discussions, retours d'expériences, initiation
Le langage Ruby discussions, comparaisons Python/Ruby, retour d'expériences
J'ai assisté rapidement à une petite session Node.js
J'ai vécu une belle expérience lors d'une session/expérience sur le « Dialogue »… : très enrichissant… et j'ai constaté que j'étais vraiment entouré de personnes très intelligentes (ou à l'écoute… en éveil… je n'arrive pas à trouver le bon mot) ou alors c'est le contexte qui fait progresser tout le monde… je ne sais pas…
Discussions à propos du déploiment d'applications web Python, j'ai découvert entre autre l'outil Fabtools (développé par Ronan Amicel) basé sur Fabric
Discussions à propos des technologies NoSQL, retours d'expériences de MongoDB, CouchDB …
Discussions à propos des Fablab, imprimantes 3D et ce que cela peut changer dans la société
Discussions à propos de « Pourquoi les sites des technos Ruby sont beaux, plus beaux que les outils Python » (je ne parle pas des réalisations faites avec ces outils, mais les sites web de ces outils, le coté marketing de Ruby qui est très bien réussi)
Discussions à propos de la réalisation d'applications mobiles : native vs html vs autre outils
J'ai assisté à une discussion au sujet de « Mon designer : un équipier agile »
Discussions à propos de Pylons, Pyramid, framework avec et sans opinions, j'y ai découvert le projet Ptah surcouche de Pyramid avec des opinions.
Discussions à propos de « Comment vendre de l'agile ? »
Discussions à propos de « Est-ce que passé une taille critique, une startup doit se structurer, comme par exemple mettre en place des entretiens individuels annuels d'évaluation ? »
Discussions à propos de « Est-ce qu'il faut encore développer ses applications vs utiliser des outils clés en main ? »
Discussions à propos de « Comment répondre à des offres, est-ce qu'il faut répondre à des offres, comment répondre à un cahier des charges… ». J'ai adoré cette discussion, avec des retours d'expériences, exploration de pistes…
Discussions à propos de « Comment travailler en équipe quand les membres ont des compétences différentes, utilisent des technologies différentes ? »
À savoir, que parallèlement à ces sujets, il y en avait toujours trois, quatre ou même cinq autres.
Mon bilan
De toutes les manifestations que j'ai fait, c'est la meilleur, c'est là où j'ai appris le plus de choses en si peu de temps… et encore je n'ai pas pu assisté à toutes les discussions, toutes les sessions…
Je ne pense pas avoir passé dans ma vie, 48h aussi riches !
Vraiment le format Open Space est vraiment très bien pour échanger des expériences… philosopher…
De plus ce format permet de rendre tout de monde accessible… pas de pudeur… il est possible de parler avec vraiment tout le monde.
J'ai plus ou moins suivi le contenu de la documentation…
Dans la vidéo j'ai fait quelques erreurs d'expression alors soyez indulgents… ce n'est pas facile de faire un
screencast valide du premier coup.
Je vous conseille de visualiser la vidéo en mode 720p afin de bien pouvoir lire le contenu de la console.
Après la réalisation du screencast je me suis rendu compte que j'aurais dû agrandir la taille des polices.
