Table des matières

Présentation d'un gros projet

Présentation d'un gros projet

Ce document vise à vous faire une présentation d'un gros projet web que j'ai réalisé il y a quelques années.

Le but n'est pas de comprendre les détails de son fonctionnement mais de vous donner un retour d'expérience de quelques problèmes qui se posent dans ce genre de projet, et des très nombreuses technologies utilisées.

Le projet

Il s'agit d'un site internet qui propose des exercices de mathématiques générés aléatoirement et répétables à l'infini. L'un des intérêt est que l'élève peut répondre aux questions sous forme mathématique et que les différentes formes de la réponse seront comprises : Si la réponse est $\frac{1}{4}$, les réponses $0,25$, $\frac{8}{32}$ ou même $\sqrt{\frac{1}{16}}$ seront toutes valables et acceptées.

Vous pouvez voir le site en fonctionnement et comme vous n'avez pas de compte, vous pouvez voir des exercices sur cette page. Vous pouvez vous connecter avec l'identifiant test@test.com et le mot de passe test (soyez gentils de ne pas le modifier…)

Les technologies liées à l'utilisation

Il y en a beaucoup, vous allez voir.

D'abord nous devons distinguer les technologies permettant de concevoir le site et les technologies permettant de l'utiliser. Nous allons commencer par la partie utilisation.

Comme pour tout site web, nous sommes dans une situation client-serveur.

Côté serveur

On parle de backend. Si par exemple une banque propose un poste de développeur backend, il s'agit de programmer côté serveur.

hébergeur

Le serveur est fourni par un hébergeur. J'utilise ex2.

L'hébergeur fournit tous les outils nécessaires permettant de se connecter au site, de charger les fichiers dans un sens ou dans l'autre, de créer une base de données, des adresses mail, des noms de sous-domaine, le cryptage pour avoir un site en https au lieu de http…

Pour information, le coût pour l'hébergement et la réservation du nom de domaine s'élève à environ 60 € / an.

nom de domaine

Il faut aussi réserver un nom de domaine. J'ai réservé le nom goupill.fr. On est libre de créer en suite tous les sous-domaines que l'on veut. Par exemple exercices.goupill.fr ou wiki.goupill.fr.

serveur LAMP

Le serveur est un classique LAMP : Linux, Apache Mysql PHP

Linux est le système d'exploitation de la plupart des serveurs web
Apache est le logiciel qui permet au serveur d'être à l'écoute de toute requête web d'un client et d'y répondre
Mysql est le gestionnaire de base de données
PHP est le langage de script exécuté sur le serveur.

Pour le programmeur (moi), il faut surtout :

Mettre en place la base de données
Écrire tous les scripts PHP
Faire quelques réglages Apache

Côté client

On parle de frontend. Si une banque propose un travail de développeur frontend, il s'agit du site web côté client.

L'utilisateur utilise un navigateur. On ne maîtrise pas le navigateur que choisira d'utiliser le client. Il faut donc, autant que possible, faire en sorte d'être compatible avec les leaders du marché : Chrome, Firefox, Opera, Machinchouette Windows.

Les pages web sont bien sûr des pages html qui seront stylées avec du css et pour rendre le tout plus réactif, on utilise javascript qui est compris par tous les navigateurs.

Comment ça se présente du point de vue de l'utilisateur ?

L'utilisateur démarre son navigateur et charge la page https://exercices.goupill.fr

Si vous visualisez le code source de la page d'accueil – avant connexion – clic-droit sur la page, vous devriez trouver une commande pour voir le code de la page – vous verrez qu'il n'y a pas grand chose.

Tout se passe au niveau des documents chargés dans la partie <head>. On y trouve des fichier .js (javascript) et .css (feuilles de styles). Ce ne sont que des bibliothèques toutes faites comme jquery ou bootstrap (je reviendrai sur tout cela plus loin)

Le code javascript produit par mes soins est tout compressé dans un seul fichier main.2.2.394.min.js qui se charge en fin de document à l'aide de requirejs.

Donc, du point de vue de l'utilisateur, la page charge, en plus du html, quelques fichiers, notamment des fichiers javascript. Le fichier main.2.2.394.min.js (chargé en bas) qui contient tout le programme et pèse environ 1 Mo. Il est chargé une première fois. Il n'y aura presque plus de chargements ensuite. Toute l'apparence du site, toutes les règles de mise en page, les actions à exécuter quand on appuie ici ou là, tout est contenu dans ce fichier main.

Ensuite, quand vous cliquez des liens du site et que vous avez l'impression de changer de page, ce n'est qu'une illusion. main se charge de rafraîchir la page, de modifier la barre d'adresse du navigateur et de maintenir l'historique de navigation pour vous permettre de revenir en arrière.

Seules les données de la base de données peuvent occasionner de nouveau chargement. Quand par exemple vous vous connecter, il y a un échange de données pour vérifier que votre nom d'utilisateur et votre mot de passe sont valides. Cet échange de donnée est très léger.

Tous les chargements et modifications de base de données peuvent donner lieu à un échange avec le serveur mais dans ce cas encore, seules les données sont échangées. Toutes les informations permettant d'indiquer comment on affichera les choses sont contenues dans le main.

Développement et production

La version du site telle qu'elle est vue par l'utilisateur est la version de production.

Mais cette version est inutilisable pour le programmeur. Ce gros fichier main contient tout et il est compressé. Au moment de la programmation, on voit une grande quantité de petits fichiers réalisant tous une petite partie du travail. Ces fichiers sont assemblés et compressés en l'unique fichier main.

La phase de programmation est appelée la phase de développement.

Technologies liées à la programmation

Il y en a beaucoup. Je vais essayer de ne pas en oublier.

github

Github Permet de déposer une copie de tous les fichiers de programmation et de maintenir l'historique de toutes les modifications. Ainsi, on peut librement modifier le projet et remonter à une version antérieure si on s'aperçoit qu'on a fait fausse piste. Github fournit également tous un tas de services permettant de signaler des bugs, de lister des tâches à effectuer… Il s'agit de permettre le travail collaboratif.

Le projet qui nous intéresse ici est présent en deux dépôt. La version qui est terminé et fonctionne, et une autre version que je n'ai pas eu le temps d'achever (j'évoquerai plus loin ce problème)

Quand on regarde les fichiers du projets, on est vite perdu, on ne trouve pas où cela commence. C'est normal, dans tout cela, le site n'est nulle part…

Je vais prendre l'exemple de la 2e version qui, bien qu'inachevée, est mieux organisée.

Le dépôt contient :

Le site dans sa version de développement avec toutes les consignes pour mettre en place cet environnement de développement et aussi pour obtenir la version de production.
Le dossier dev, comme développement, contient toutes les briques de la version publique du site, c'est à dire tout ce qui permettra de produire les pages visibles par le client. le dossier php contient les scripts PHP qui seront exécutés du côté du serveur.
Des fichiers de configuration à la racine qui indique les outils nécessaires.

Les outils tiers

Un point sur ces outils nécessaires. Prenons l'exemple de jquery : C'est un module javascript extrêmement utile, quasiment une extension obligatoire qu'utilise tous les sites web. Ce module contient quantité de fonctions permettant de manipuler la page html – ce qui est justement ce que l'on a besoin de faire sur ce genre de site : qu'un panneau apparaisse quand on appuie ici, que tel élément change de couleur, etc.

jquery est géré par une communauté de programmeur qui le maintiennent à niveau, corrigent les bugs, le font évoluer, le mettent à disposition pour tous gratuitement…

Vais-je faire une copie des fichiers jquery dans mon dépôt ?

NON !

Une façon de faire est d'utiliser un outil comme npm et Node.js. Le fichier packages.json présent à la racine du dépôt – vous pouvez le visualiser – indique quels sont les modules nécessaires et en particulier vous y trouvez jquery. Il est indiqué latest ce qui signifie que l'on veut la version la plus à jour.

Comme il peut arriver que des mises à jour ajoutent des modifications problématiques, il est possible d'indiquer que l'on veut une version précise.

Donc en résumé :

vous installez npm,
vous téléchargez les fichiers du dépôt,
npm, en exploitant packages.json, télécharge automatiquement tous les modules utiles comme jquery.

npm node.js

Node.js permet d'exécuter du javascript sur la machine. C'est l'interpréteur un peut comme python.exe pour Python. npm, déjà mentionné, est le gestionnaire de paquets : il se charge de télécharger les modules utiles. npm est exécuté par node.js.

Node.js est aussi de plus en plus utilisé sur le serveur, à la place de PHP. Il permet de développer côté serveur en javascript ce qui est pratique car c'est déjà du javascript côté client.

coffeescript

Personnellement je ne suis pas très fan de javascript. J'ai préféré utilisé coffeescript.

Il s'agit d'un langage qui ressemble beaucoup à Python et qui donne accès à des tas de raccourcis de syntaxe. L'idée de coffeescript est de fournir un code plus agréable que javascript, et de transformer ensuite ce code en javascript.

Cela signifie que les fichier .coffee que l'on trouvera dans le projet ne peuvent pas être utilisé tels quels. Il faut les transformer en .js.

Pourquoi ne pas programmer en Python ? Il se trouve que les navigateurs internets ne savent pas exécuter Python et cela n'est pas près de changer : De l'aveu même su créateur de Python, Guido Von Rossum, Python est beaucoup trop lourd pour cela. On doit donc utiliser javascript. Mais javascript est moins régulier que Python, les différents navigateurs ne l'interprètent pas toujours de la même façon…

Les langages comme coffeescript permettent de programmer de façon agréable, sans trop s'embarrasser de détails techniques trop touffus de javascript tout en permettant à la fin la traduction vers le javascript qui sera compris par les navigateurs.

Grunt

Grunt est un outil qui a été très utilisé mais est passé de mode. Il sert à automatiser certaines tâches du programmateur.

Un exemple : J'ai dit que je programmais en coffeescript et qu'il fallait transformer le coffeescript en javascript. On peut programmer Grunt pour que, automatiquement, chaque fois que l'on fait une modification dans le fichier coffeescript, il recalcule automatiquement le fichier javascript correspondant et recharge la page web – on appelle cela live reload – sur laquelle on consultait le site en cours de développement.

Autre exemple : On peut programmer Grunt pour qu'il assemble automatiquement tous les bouts de fichiers répartis ici et là pour produire le gros fichier main de la version de production.

Donc Grunt est un outil servant à automatiser les tâches du programmeur. Encore une fois l'idée générale est que le programmeur utilise des morceaux épars – des modules comme jquery, des feuilles de styles toutes faites comme celles de bootstrap, etc. – qu'il préfère utiliser d'autres langages que javascript – coffeescript dans mon cas – qu'il souhaite organiser son programme en de multiples fichiers alors que pour l'exécution il sera plus pratique d'en avoir un seul gros.

Grunt se charge de faire le lien.

webpack

Comme je l'ai dit, grunt est passé de mode, de même qu'un autre outil que j'utilisai, requirejs. Je suis donc passé à webpack – comme ça commence à faire quelques années, allez savoir, il est peut-être passé de mode aussi…

C'est une difficulté de ce travail. On développe en utilisant certains outils. Mais ces outils sont dépendants d'une communauté de programmeur et si un outil est abandonné, l'outil devient inutilisable et il faut reprendre de larges pans de ce que l'on a déjà fait pour les mettre à jour.

J'ai commencé à reprendre le site pour le mettre à jour avec de nouveaux outils comme webpack mais je n'ai pas eu le temps d'aller au bout d'autant que certaines solutions que j'avais trouvées dans la première version ne fonctionnaient plus dans la nouvelle…

Exemple : J'utilisai un outil pour afficher comme il faut les formules mathématiques. Il était impensable que je fasse un tel outil moi-même. Cet outil fonctionnait bien avec la version antérieure mais n'était pas pris en charge par webpack d'où une impasse…

webpack gère automatiquement le passage de la version de développement à la version de production. Pendant le développement, on travaille en utilisant le site web morcelé en de nombreux fichiers (même pas en javascript !) Une simple ligne de commande permet d'exécuter toutes les traductions nécessaires, l'assemblage des morceaux, la compression, pour obtenir le site tel qu'il doit être vu par les utilisateurs finaux.

PHP

Je ne détaille pas trop. PHP est le langage côté serveur. Évidemment, au moment du développement, le pc du programmeur est à la fois client et serveur et il doit pouvoir exécuter du PHP.

Essentiellement, PHP aura pour travail de gérer les requêtes du client, de vérifier son identité (gère une session) de faire les tests nécessaires pour savoir ce qu'il est autorisé à faire ou non, et à dialoguer avec le SGBD.

Pour dialoguer avec le SGBD, PHP possède toutes les commandes nécessaires mais elles peuvent être pénibles à utiliser. J'utilise un module (encore une couche !) qui simplifie les choses.

Comme je l'ai dit plus haut, certains hébergeurs proposent maintenant de programmer côté serveur en javascript.

PHPMyAdmin

PHPMyAdmin est l'outil de référence pour créer et gérer une base de données. Il est disponible chez tous les hébergeurs.

Les modules pour la page web

Un coup d'œil au packages.json vous montre qu'il y en a pas mal. Il s'agit de modules réalisant les fonctions utiles pour ne pas avoir à réinventer la roue.

Dans le site web, on veut par exemple disposer d'un beau combo qui se déplie harmonieusement avec des pictogrammes dedans… Ceci n'existe ni en html, ni en css ni en javascript. Il faut le programmer. Mais cela a déjà été fait des tas de fois par des spécialistes. Vu le travail que représente la conception du site, vous n'avez pas envie de refaire le travail que d'autres on déjà fait mieux que vous ne le pourrez. Donc vous téléchargez des modules (exemples) :

jquery : extension quasiment indispensable à javascript,
font-awesome : bibliothèque de pictogrammes très variée,
mathquill : création de champ de saisie permettant d'écrire comme en maths, avec des fractions…
katex : écriture de formules mathématiques dans la page web avec un beau rendu,
backbone : gestion des données sur le client (les données de la base de données) et des échanges de données avec le serveur,
marionette : C'est le cœur du site. Prend en charge les requête internes au site, gère le changement de l'affichage pour faire comme si on avait changé de page, le lien avec backbone pour récupérer et mettre à jour les données.
underscore : bibliothèque de diverses fonctions utiles. Contient aussi un système de templates. Les pages du site sont comme des formulaires avec des cases à remplir par les données. Ainsi, une page utilisateur a toujours le même aspect, seules les informations de l'utilisateur changent. *underscore* fournit les outils pour transformer le template en html.
bootstrap : vous avez peut-être constaté que beaucoup de sites internet se ressemblent. C'est normal ! Moi par exemple, je ne suis pas graphiste. Je ne vais pas m'embêter à créer un style personnel de site. J'utilise un style tout fait. twitter bootstrap (c'est bien le même twitter que celui que vous connaissez) fournit un ensemble de style qui permettent de faire rapidement du très beau.

Je vais en détailler quelques uns.

underscore

Je ne m'intéresse ici qu'à l'aspect templates. Par exemple le template permettant de visualiser les informations liées à un utilisateur. Vous pouvez voir que c'est principalement du html mais qu'il y a des zones délimitées par des <% %> qui permettent d'ajouter du code javascript ou encore des zones <%- %> qui permettent de remplir des trous avec des données.

underscore va transformer ce fichier template en un code javascript qui, quand il sera exécuté, fabriquera le bout de html avec les informations nécessaires. Ce bout de code javascript sera intégré au gros fichier main final.

backbone

Le fichier users.coffee, en coffeescript, détaille la gestion des données liées aux utilisateurs.

On crée une classe Item = Backbone.Model contenant tout ce qu'il y a savoir sur le contenu d'un item utilisateur et comment le gérer. backbone ajoute des fonctionnalités permettant de simplifier les requête vers le serveur : On a besoin de données sur un utilisateur que l'on a pas encore chargé ? Backbone génère une requête ajax vers le serveur pour obtenir précisément ces données. L'échange est très léger, on ne charge que ce qu'il faut.

Pour donner deux petits exemples, la méthode parse définie dans la classe consiste à prendre la réponse du serveur, qui est un bout de texte, et à l'analyser pour en extraire les données voulues. La méthode toJSON fait l'inverse, elle prend l'objet utilisateur et le transforme en une version qui pourra être expédiée vers le serveur.

Marionette

Prenons d'abord le fichier show_user_controller.coffee. Il détaille tout ce qui peut se produire autour de la partie du site consistant à montrer un utilisateur.

Déjà il faut savoir quoi faire quand on demande à afficher cette page. Le contrôleur se charge de récupérer les données concernant l'utilisateur. Puis il charge ce qui concerne l'affichage (fichier d'après). Puis il ajoute sur la fenêtre créée toutes les actions pouvant être effectuées sur cette page. Par exemple il y a un bouton pour modifier l'utilisateur (Edit). Que faire si on clique sur ce bouton ? Le contrôleur s'en charge.

Le fichier show_user_view.coffee définie la vue c'est à dire le bout de fenêtre dans lequel on affichera l'utilisateur. Ce fichier est très léger. Il se contente de dire qu'il utilise un certain template et qu'il contient deux événements susceptibles d'être déclenchés (bouton pour éditer l'utilisateur, bouton pour éditer le mot de passe)

Le principe de Marionette est de découper l'ensemble du site en vues. La page permettant de voir un utilisateur est une vue. La page permettant de modifier l'utilisateur en est une vue. Des contrôleurs permettent de détailler pour chaque vue comment elle fonctionne.

Dans le cas précédent, tout ce que fait le contrôleur quand on demande à éditer l'utilisateur, c'est de passer la main au contrôleur qui gère l'édition d'un utilisateur…

L'avantage de ce fonctionnement est que l'on peut voir chaque partie du site indépendamment des autres et que l'on a aucune peine à ajouter des fonctionnalités. Par exemple, la barre de navigation est gérée à part. C'est une vue à part entière. Si on souhaite modifier la façon dont s'affiche la barre de navigation, on n'aura pas à aller voir dans chaque page du site. Il suffira de modifier les fichiers concernant la barre de navigation, notamment son template.

Par contre on se retrouve avec une quantité de fichiers qui ne contiennent pas grand chose et il faut lier tous ces fichiers sans se tromper : le script contrôleur pointe sur un script vue qui lui même pointe sur un template…