stephane-klein.info

Le contexte

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
  • de plus en plus de sociétés semblent l'utiliser

• 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 ne pense pas que Sequelize soit aussi mature que SQLAlchemy
• 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.

Est-ce que l'on va retrouver Javascript partout ?

Voici une petite liste :

• Javascript dans les navigateurs web
• Javascript coté serveur (Node.js)
• Javascript dans Qt Introduction QML + Qt Quick qui semble vraiment super puissant
• Les possibilités d'utiliser Gtk + JS : gjs and Gtk+
• Gnome Shell est en grande partie développé en Javascript. Ses extensions sont entièrement développé en JS
• Sur mobile WebOS et Boot to Gecko

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

merci beaucoup pour vos retours d'expériences !

Séparation des Web CMS en deux couches

J'ai trouvé un article qui fait la distinction entre deux types de CMS, enfin il parle de WCMS (Web CMS) :

• « Content Production Systems (CPS) »
• « Presentation Management Systems (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) :

• PHPCR - Content Repository for PHP (voir slides)
• simPCoRe - PHP Content Repository

J'ai appris l'existence d'un projet de Content Repository pour Node.js :

• nocr

J'ai aussi trouvé Lily qui est un Content Repository basé sur Hadoop, HBase et SOLR dans un écosystème Java + API Rest.

Spécificités techniques d'un CPS

J'ai trouvé un autre article qui traite des spécificités techniques d'un CPS. Voici ci-dessous sa liste de "requirements" :

• Richly structured content types
• Unstructured binary objects
• Relationships / references / associations
• 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
• Moteur de recherche (basé par exemple sur : Xapian, elasticsearch)
• Un système de workflow
• Versionning (peut-être basé sur Git ou Mercurial)
• 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.

Il existe de nombreux clients CMIS pour différent langage…

La suite…

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.

Introduction

Je viens de commencer à utiliser Selenium pour tester des formulaires, divers pages de listes de données… dans une application métier.

Mes objectifs :

• tester l'ajout de nouvelles entités (1)
  • les données sont injectées dans un formulaire d'une page html
  • une page de résultat est utilisées pour vérifier que les données ont bien été enregistré (ça peut être une page d'édition)
• tester la modification d'une entités (2)
  • les données sont injectées dans un formulaire d'une page html
  • une page de résultat est utilisées pour vérifier que les données ont bien été enregistré (ça peut être une page d'édition)
• tester la validité d'une page de liste (3)
• tester la validité des résultats d'un moteur de recherche (4)

Pour le moment je me suis concentré uniquement sur les points 1 et 2.

Première méthode (à l'arrache)

J'ai commencé par réaliser des fonctions du type :

• login()
• add_customer(data)
• edit_customer(data)
• check_customer(data)
• add_customer(data)
• edit_customer(data)
• check_customer(data)
• …

Les fonctions de type "add" et "edit" prennent en paramètre des données à injecter dans des pages. Les fonctions de type "add" correspondent aux pages d'ajout d'entités, les fonctions de type "edit" correspondent aux pages de modification d'entités.

Ensuite j'ai des fonctions "check", là aussi je passe en paramètre des données qui seront utilisées comme valeur de vérification face à des pages de résultats ou pages d'éditions (une page d'édition contient déjà des données, le but ici est de vérifier leurs validitées).

Ma variable "data" est du type :

data = [
    ("reference", u"C1345"),
    ("firstname", u"Stéphane),
    ("lastname", u"Klein"),
    ...
]

Dans mes fonctions ("add", "check"…) j'ai une boucle qui parcourt la structure de données et utilise les fonctions suivantes soit pour injecter des données, soit pour tester la validité des données.

def inject_value(driver, name, value):
    element = driver.find_element_by_id(name)
    if element.tag_name == 'input':
        if element.get_attribute("type") == "checkbox":
            if element.is_enabled() != value:
                element.click()
        else:
            element.clear()
            element.send_keys(value)

    elif element.tag_name == 'select':
        option_element = element.find_element_by_xpath(".//option[@value='%s']" % value)
        option_element.click()

    elif element.tag_name == 'textarea':
        element.clear()
        element.send_keys(value)

def check_value(driver, name, value):
    element = driver.find_element_by_id(name)
    if element.tag_name == 'input':
        if element.get_attribute("type") == "checkbox":
            return element.is_enabled() == value
        else:
            return element.get_attribute("value") == value

    elif element.tag_name == 'select':
        return element.get_attribute("value") == value

    elif element.tag_name == 'textarea':
        return element.text == value

Pour le moment, cela fonctionne correctement mais je trouve mon code fastidieux pour plusieurs raisons :

• j'aimerais pouvoir définir des valeurs par défaut pour les formulaires
• j'aimerais pouvoir choisir d'autres types de "selecteur", pour le moment je fais des recherches uniquement par ID
• j'aimerais pouvoir facilement indiquer le type de champ, car pour le moment je fais de l'auto détection… mais cela ne sera pas toujours faisable

Ce que j'aimerais avoir

À noter que ce code n'est pas complet… c'est un brouillon.

from sealchemy import Form, TextField, SelectField, BooleanField

...

class AddCustomer(Form):
    __submit__ = Submit(name="_same")

    reference = TextField(default=u"C1345")
    type_user = SelectField(default=u"external")
    firstname = TextField(required=True)
    lastname = TextField(required=True)
    activated = BooleanField(default=True)
    comment = TextAreaField(default=u"")

    def go_to_page(self):
        self.driver.get("/customers/add/")

class EditCustomer(Form):
    __submit__ = Submit(name="_same")

    reference = TextField(default=u"C1345")
    type_user = SelectField(default=u"external")
    firstname = TextField(required=True)
    lastname = TextField(required=True)
    activated = BooleanField(default=True)
    comment = TextAreaField(default=u"")

    def go_to_page(self, id):
        self.driver.get("/customers/%s/" % id)

    def go_to_last_inserted(self):
        """Va sur la page du dernier client qui a été ajouté"""
        ...

Cela ressemble beaucoup à l'API de wtforms que j'utilise dans mon projet. Cela ressemble aussi à FormAlchemy que j'aime aussi.

__submit__ permet d'indiquer le champ à utiliser par la commande submit.

Note : je n'utilise pas une seule classe pour faire mes traitements "add" et "edit" car les formulaires d'ajouts et d'édition sont en pratique souvent différents.

L'interface de la classe de type Form :

class IForm(zope.interface.Interface):
    def inject():
        """Cette méthode injecte les données vers le formulaire HTML"""

    def submit():
        """Cette méthode lance le submit du formulaire"""

    def inject_and_submit():
        """Exécute inject et ensuite submit"""

    def check():
        """Cette méthode retourne True si les données correspondent aux
           données présentes dans le formulaire HTML"""

    def clear():
        """Réinitialise la valeur de tous les champs de l'instance avec
           les valeurs par défauts"""

    def populate(values):
        """Affecte des valeurs aux champs de l'objet."""

La classe Session de mon projet :

class MyProject(Session):
    def __init__(self, login, password):
        ...

    def login(self):
        ...

    add_customer = AddCustomer()
    edit_customer = EditCustomer()

Dans MyProject, j'ai ajouté les propriétés add_customer et edit_customer afin que ces objets aient accès à l'objet driver de Selenium.

Exemple d'utilisation :

session = MyProject(login="username", password="password", url="http://localhost:5000/")
session.login()

values = {
    "reference": u"C1871",
    "firstname": u"Stéphane",
    "lastname": u"Klein",
}
session.add_customer.populate(values)
session.add_customer.go_to_page()
session.add_customer.inject_and_submit()
session.edit_customer.go_to_last_inserted()
session.edit_customer.populate(values)
assert session.edit_customer.check()

Plus d'informations à propos des classes Field

Les classes de type Field comme TextField, BooleanField … ont un constructeur avec plusieurs paramètres :

• name (optionnel) : définit la méthode de recherche du champ par l'attribut "name"
• id (optionnel) : définit la méthode de recherche du champ par l'attirbut "id"
• xpath (optionnel) : définit la méthode de recherche via xpath
• required (optionnel) : définit si le champ est requis ou non
• default (optionnel) : définit la valeur par défaut du champ

Par défaut, si j'ai ceci :

class ...(Form):
    firstname = TextField()

C'est équivalent à cela :

class ...(Form):
    firstname = TextField(name="firstname")

Conclusion, questions

Je vous ai donc présenté l'API que j'imagine créer sous le nom de "sealchemy".

J'ai plusieurs questions :

• est-ce que vous pensez que cette librairie serait utile ?
• est-ce que l'API, le mode de fonctionnement est judicieux ?
• est-ce que cela vous intéresse ?
• est-ce que vous avez déjà créé quelque chose du même genre ?
• quelle est votre méthode pour faire ce genre de test ?

Merci d'avance pour vos commentaires.

1   Introduction

Au quotidien, j'essaie autant que possible d'être un développeur agile. Agile dans ma façon de "coder", agile dans ma façon de concevoir la documentation technique de mes projets.

2   Problématique

Au cours de la vie d'un projet, de nombreux événements viennent perturber les plans initiaux des développeurs : cahier des charges incomplets ou erronés, évolution du besoin initial, erreurs de conceptions ou d'analyse... il faut ajouter à cela le refactoring nécessaire à l'amélioration constante de la qualité et la consistance du code source.

Ces événements ont des conséquences directes sur le code source : modification des API, création de nouvelles classes, suppression d'autres classes, création de nouvelles librairies, changement d'algorithme... Si l'on ajoute à ces changements, le manque de temps, la mise à jour de la documentation passe à la trappe.

Le problème de mise à jour de la documentation a un autre effet pervers : une personne qui consulte la documentation n'a pas connaissance du niveau de mise à jour de celle-ci, un doute persiste concernant l'exactitude des informations qui s'y trouvent. Il se peut que suite à de nombreuses expériences négatives (documentations obsolètes), une personne puisse prendre l'habitude de lire directement le code source car c'est la seule source d'information dont l'exactitude soit certaine.

3   Solutions existantes

4   Est-ce que la documentation doit générer du code source ou alors est-ce que le code source doit générer de la documentation ?

5   Pourquoi ce billet ?

J'ai écrit ce billet car il me sert d'introduction pour un prochain billet qui traitera de mon application qui permet de générer un graphe UML à partir du code source d'un programme.

6   Outils et références

Livres :

• "Petit guide à l'usage du développeur agile" de Tarek Ziadé
• Practices of an Agile Developer ... à mes yeux ce livre est une véritable bible !
• Ship it!: A Practical Guide to Successful Software Projects

Outils Python :

• Epydoc : pour générer automatiquement la documentation d'une API, librairie...
• Sphinx : outil qui permet entre autres de générer une documentation cohérente à partir de différents fichiers reSTructuredText ainsi qu'à partir du code source d'un projet
• doctest : outil qui permet de tester un programme à partir d'un jeu de tests écrit sous la forme reSTructuredText