Ravidhu Dissanayake

Commandes utiles pour Docker

Les commandes qui suivent peuvent sûrement être mieux écrites et/ou améliorées. J’ai constitué cette liste au gré de mes expériences.

Cycle de vie des containers Docker

Il est parfois très utile d’avoir une visualisation des ressources utilisées par les containers. Ainsi cette commande me permet d’avoir les statistiques d’utilisation des mémoires vives et CPU des containers actifs sur la machine courante :

Lorsque j’ai besoin d’arrêter tous les containers d’un coup, je fais la commande qui suit :

Et quand j’ai besoin de tous les supprimer :

Docker prend pas mal de place et il faut parfois faire le ménage. C’est pourquoi je lance la commande qui suit pour supprimer tous les container arrêtés :

Une autre commande que j’utilise pour faire le ménage me permet d’enlever les images taguées en « <none> » :

Enfin, je termine toujours le ménage avec les commandes officielles de docker pour supprimer les images inutiles :

Il existe aussi une commande docker qui a un impact plus large. En effet il supprime l’intégralité des images non utilisées, des containers non utilisés, mais aussi les réseaux non utilisés :

A l’intérieur des containers de Docker

Quand les choses ne fonctionnent pas correctement, je vais toujours jeter un oeil sur les logs d’un container avec la commande suivante :

Il existe des moments ou il faut rentrer dans le container pour approfondir l’investigation d’un problème. Pour cela j’utilise l’une des deux commandes en fonction du container  :

  • Si le container est très léger et que le container exécute une commande bash, docker permet de s’attacher au process bash dans le container :
  • Si le lancement d’un autre processus n’est pas gênant :

Il peut être utile de récupérer l’adresse IP locale d’un container. C’est possible grâce à la commande suivante :

Docker-compose

Si vous utilisez docker-compose, il faut parfois supprimer et reconstruire juste un container de la grappe. Ainsi, cette commande facilite cette tâche :

 

Commandes utiles pour Git

Voici une liste non exhaustive de commandes que j’utilise très souvent. Elle s’est constituée au gré de mes besoins.

La commande qui suit permet d’initialiser et configurer le dépôt git avec votre email et votre nom :

Lorsqu’on fait la migration d’un dépôt ou qu’on renomme un dépôt distant, la commande qui suit permet de définir/changer l’url du dépôt distant sur le dêpôt local :

Voici la commande que j’utilise pour faire les mises en production. Ainsi, je pousse la branche master et le tag. Cela permet de lancer le déploiement automatiquement :

La commande pour supprimer le dernier commit de la branche courante :

La commande ci-dessus est très utile pour faire du ménage dans l’historique.

Il existe une variante à cette commande qui permet de réinitialiser le dépôt à un commit précis :

Il faut parfois synchroniser votre code avec celle d’une branche distante. Pour cela, la commande suivante remet vos fichiers dans le même état que dans la branche distante :

Je continuerai à mettre à jour cette page au fur et à mesure de mon utilisation de git. Néanmoins, même si j’utilise git quotidiennement, je ne suis pas amené à faire des manipulations très compliquées.

Comment configurer Webpack

Webpack est un bundler, c’est à dire qu’il prend les différents modules NodeJS ainsi que les plugins JavaScript utilisés dans votre projet et crée un fichier ( ou plusieurs ) en sortie. Il permet ainsi d’utiliser l’ES6, la nouvelle version du langage JavaScript, mais également ReactJS et d’autres frameworks JavaScript. Il peut être utilisé comme compilateur et est même obligatoire pour certains frameworks JavaScript comme je le disais dans mon précédent article.
Par ailleurs, il existe un très bon chapitre dans le livre dédié à Webpack de la série SurviveJS et accessible gratuitement en ligne qui le compare à d’autres outils.

Cet outil s’utilise de plusieurs manières, avec sa mise en place, voici ce que le développeur pourra faire simplement :
  • Pour la mise en production :
    • Compiler une version optimisée pour le déploiement en production.
  • Pendant le développement :
    • Compiler l’ensemble des fichiers et avoir une version lui permettant de déboguer facilement.
    • Compiler l’ensemble des fichiers et avoir une version lui permettant de déboguer facilement et de recompiler à chaque modification faite sur les fichiers.
    • Lancer le serveur de développement de Webpack qui fait la même chose que le précédent point mais charge les fichiers compilés à partir de la mémoire et les distribuent à travers un serveur. Il recharge la page automatiquement également.

Installation de Webpack

Évidemment, Il faut installer au préalable NodeJS et NPM. Ensuite, il suffit de se placer dans le dossier du projet contenant le package.json. Enfin, dans un Terminal :

Vous pouvez rajouter « -g » pour l’installer de manière globale mais je préfère avoir une bonne séparation des modules NodeJS pour chaque projet.
Ensuite, Il faut créer le fichier webpack.dev.config.js et le fichier webpack.prod.config.js  qui vont contenir les configurations pour chaque environnement.
Remarque : Par défaut Webpack va chercher un fichier « webpack.config.js » mais nous allons mettre en place un fichier pour l’environnement de développement et un autre pour créer les fichiers de production.
Pour le moment on va remplir uniquement webpack.dev.config.js :

Comme Webpack n’est pas installé de manière globale, il faut le lancer à partir du dossier node_modules :

Néanmoins, pour faciliter le lancement des commandes on va renseigner le fichier package.json pour pouvoir lancer les commandes avec « npm run« . En somme, voici les commandes pour chaque situation :

Les fichiers d’entrées et de sorties

Commençons d’abord par définir les fichiers d’entrées et de sorties. Considérons cet exemple :

Ainsi , l’objet « entry » contient les chunks qui vont être analysés et traités. Dans l’exemple ci-dessus, Webpack va lire le fichier main.js, transformer tous les appels utilisant la syntaxe ES6 dans un format ES5 et construire un fichier concaténé contenant l’ensemble des éléments requis.
De plus, la valeur « [name].js » de « output.filename » indique que la clé de l’objet « entry » va être utilisée pour le nom du fichier généré. Ainsi, le fichier concatené va s’appeler superApp.js.
Vous pouvez forcer un nom fixe évidemment, mais je trouve que cette configuration est plus flexible.
Si vous voulez servir les fichiers à partir d’un CDN, il faut rajouter publicPath à l’objet « output » :

En effet, cette valeur va être utilisée pour savoir où sont stockés les fichiers compilés. Par ailleurs, il est également utilisé par les loaders (comme file-loader ou url-loader) afin de remplacer le début des URL. C’est pourquoi, dans l’exemple ci-dessus, « https://my.super.cdn.com/ » va être rajouté au début de tous les attributs src et href , mais aussi dans les appels url() dans les CSS.

Les plugins et les modules

La section module contient principalement la clé « loaders » avec une liste d’objets. Ces objets contiennent :

  • Le test qui permet de filtrer les fichiers.
  • Les fichiers et dossiers exclus.
  • Le loader qui va transformer le fichier.

Les loaders doivent être ajoutés avec NPM, ainsi pour babel :

Le loader BabelJS va transpiler le code ES6 vers du code ES5. Considérons donc un fichier contenant le code suivant :

Il va être importé dans le fichier main.js de la manière suivante :

On ajoute la configuration de BabelJS dans notre fichier de configuration de Webpack :

La clé « query » contient des paramètres pour BabelJS. Les « presets » permettent de donner des indications sur la syntaxe du fichier source afin de configurer BabelJS pour la transformation du code ES6 vers ES5. Le plugin pour BabelJS, « transform-runtime« , permet d’accélérer la compilation en optimisant les appels des modules.

Les plugins que je conseils

CommonChunkPlugin

Ce plugin peut être utilisé de deux façons :

  • En indiquant le chunck contenant les modules communs.
  • En indiquant le nom du fichier qui va contenir l’ensemble des modules communs à tous les chunks de votre application.

On va donc avoir des fichiers de chunk plus légers et permettre de mettre en cache chez l’utilisateur, le fichier JavaScript contenant les modules communs à toute l’application.
Pour que ces modules communs soient mis automatiquement dans un fichier à part, vous n’avez qu’a rajouter le plugin dans la liste des plugins de la manière suivante :

ou en choisissant explicitement les chunks ayant les modules communs:

Il faut bien faire attention à charger le fichier généré par le plugin avant les chunks. Pour de plus amples informations concernant la configuration de ce plugin très puissant, c’est par ici.

ExtractTextPlugin

Il requiert une installation :

Il permet de mettre dans un fichier css l’ensemble des styles écrits en SCSS ou SASS ou avec n’importe quelle autre langue de stylisation compilée.
D’abord, il faut l’ajouter dans la liste des plugins :

puis dans les modules, il faut le spécifier en tant que loader :

Vous remarquerez que j’utilise plusieurs loader. Il faut évidement les installer avant de pouvoir les utiliser. Ainsi, resolve-url, par exemple, est très utile pour réécrire les chemins d’accès des fichiers appelé avec url() dans les styles écrits en SASS .

ProvidePlugin

Il permet de spécifier un module pour une variable. En effet, lors de la compilation, la variable en clé va être détectée et le compilateur va rajouter le module spécifié en valeur. Il faut rajouter l’instantiation dans la liste des plugins. Exemple :

UglifyJsPlugin

Il sera utilisé en production principalement. En effet, il va permettre de minifier et d’obfusquer les chunks, exemple :

DefinePlugin

Il permet de définir des constantes qui seront utilisées pendant la compilation. Exemple :

NoErrorsPlugins

Il permet d’arrêter la compilation lorsqu’il y a une erreur.

La configuration pour le développement

Commençons par installer le serveur de développement :

Il faut penser à rajouter la clé « devtool » pour avoir les source-maps des fichiers compilés et un publicPath pointant sur une IP local. Donc, si on prend le fichier de configuration ci-dessus, il faut rajouter les indications suivantes pour avoir le serveur correctement configuré:

Pour commencer, la clé contentBase de l’objet devServer correspond au dossier où se trouve vos fichiers statiques (comme les images). Ensuite, en ce qui concerne les fichiers compilés, ils sont chargés en mémoire et servies par le chemin indiqué par « output.publicPath ». Ainsi, à chaque modification de fichier, les fichiers en mémoire sont remplacés et le navigateur est rechargé.
Enfin, J’ai rajouté quelques configurations :

  • Quelque plugins à titre d’exemple ( si vous utilisez CommonsChunkPlugin, il faut faire attention à charger le fichier commons.js avant les autres chunks ).
  • La clé headers pour éviter l’erreur CORS lors de l’appel au serveur.
  • La clé watchOption doit être mis en place lorsque vous utilisez Webpack dans une VM.

Remarque:
La configuration du serveur de développement doit avoir le host et le port identique au output.publicPath. En effet cela permet au fichier static de correctement charger.

Exemple d’une configuration pour l’environnement de production

La configuration de production ressemble évidemment à celle pour le développement. Il faut néanmoins rajouter quelque plugins et enlever les clés concernant les outils de développement :

 
Vous pouvez encore rajouter d’autre plugins comme OccurenceOrderPlugin ou DedupePlugin. Mais comme indiqué dans le titre, la configuration ci-dessus n’est qu’un exemple, il n’est pas prévu pour un véritable environnement de production. Mais je pense qu’il vous donne déjà une bonne direction. De plus, je vous invite à tester les différents plugins disponible sur la documentation officielle pour trouver la configuration qui convient le mieux à votre application.

Dans quel projet utiliser Webpack ?

Cet outil devrait s’intégrer dans n’importe quel type de projet qui utilise du JavaScript et du CSS. Il a un écosystème de plugin et de loader tellement large que vous allez forcément trouver chaussure à votre pied. En plus il va vous permettre d’utiliser les dernières innovations tant au niveau du langage JavaScript avec l’ECMAScript 6 aka ES6 ou le TypeScript qu’au niveau du langage CSS avec SASS ou LESS.
Il s’intègre naturellement dans des projets NodeJS mais sa flexibilité est telle qu’il est aussi l’aise dans des projets PHP avec Zend ou Symfony. En effet, pour se dernier, vous pouvez le mettre en place pour l’utiliser avec ou en remplacement d’Assetic.
En somme, Webpack vous permet d’utiliser les dernières technologies disponibles en JavaScript et en CSS, tout en vous permettant d’industrialiser vos déploiements avec facilité et flexibilité.

Vers quelle Technologie aller pour réussir votre projet web (3ème partie)

Comme je vous l’indiquais dans mon précédent article, dans le cadre d’une requête venant d’un navigateur, les Frameworks peuvent être utilisés pour deux scénarios :

  • Soit le Framework fait le traitement de la requête et renvoie une page HTML complète, le rendu est donc fait côté serveur et le navigateur ne fait qu’afficher la page.
  • Soit le Framework lit la requête dans le navigateur, fait une requête à une ou plusieurs urls ( API REST ) si besoin pour récupérer des données. Les données sont affichées directement dans le navigateur en modifiant le HTML, c’est le rendu côté client.

Les plus beaux stands du Bazar *: Le rendu fait côté client

Cette technique est utilisée depuis très longtemps mais elle n’a jamais été aussi structurée que depuis quelques temps. Le séquençage de la requête est le même que le rendu fait côté serveur, à la seule différence que le corps de la page est vide. En effet, c’est lors de l’initialisation du javascript que la page va se construire et que le contenu va apparaître. Ce temps d’initialisation, peut s’étendre d’une fraction de secondes à plusieurs secondes en fonction de l’ordinateur, de l’utilisateur et de la complexité de l’application.
Ainsi les données brutes ne sont pas traitées par ces Frameworks (c’est possible mais je ne vous le conseille pas), ils ne s’occupent que de l’affichage.
On peut éviter cela avec des solutions qui génèrent le contenu de la page d’arrivée de l’utilisateur, le reste de la navigation se faisant directement côté utilisateur (avec Ember Fast ou ReactJS). Grâce à cette approche on résout le problème de la page blanche pour l’utilisateur et les robots des moteurs. L’internaute voit ainsi une page avec du contenu et les robots peuvent indexer ces contenus.
Le langage Javascript, a un nombre incroyable de Frameworks. Grâce à l’avènement de NodeJS et la démocratisation de NPM, le langage Javascript devient LE langage du navigateur ( aka “côté client” ). Personnellement je pense que ce bazar est une bonne chose, mais il faut avouer que c’est difficile de s’y retrouver lorsqu’on veut choisir.
j’ai donc pris le parti d’analyser seulement EmberJS, AngularJS et ReactJS avec Flux.

  • EmberJS appartient à Tilde, entreprise qui fournit des solutions Rails.
  • AngularJS a été créé par un développeur pendant son temps libre au sein de Google. Mais aujourd’hui, google a assigné une équipe dédiée pour son développement. La version 2 d’Angular est même très soutenue par Microsoft.
  • ReactJS et Flux sont issus de Facebook et sont le résultat de plusieurs années d’optimisation de facebook.com.

 

Remarque :
Google crawle les sites web construits en Javascript et il existe quelques maigres recommandations officielles de leur part sur le sujet. Au moment ou j’écris ces lignes et à ma connaissance, il est le seul moteur de recherche qui est capable de le faire. Il faut donc pré-générer les pages en HTML pour les autres moteur de recherche.
Vous avez le choix entre deux approches : soit vous pouvez le faire à la volée lorsqu’un robot se présente, soit vous générez toutes les pages de votre site à l’avance.
Quelque soit le choix que vous aurez fait, vous pouvez passer par un tiers ou mettre en place une solution vous même. La mise en place de la solution prend du temps mais requiert aussi :

  • l’intégration de la solution dans votre processus de mise en production.
  • la mise en place d’un moyen de test des pages générées pour les chefs de projet mais aussi les développeurs.

En définitive, tout est une question de ressource, si vous en avez les capacités, cette technologie peut vraiment vous aider.
Personnellement, je pense que si le projet a une forte dépendance au référencement naturel, une technologie faisant le rendu côté serveur est plus adaptée. Aussi bien pour des raisons humaines que budgétaires 🙂
Les cas de Ember Fastboot et de ReactJS : Le premier est un serveur fait par l’équipe du Framework EmberJS pour générer la page côté serveur à la volée. Ainsi l’’internaute voit quelque chose dans son navigateur le temps que le navigateur finisse de charger le javascript contenant l’application. Il a été créé pour le Framework EmberJS mais la documentation indique qu’il peut être utilisé avec ExpressJS. ReactJS s’intègre aussi très bien avec ExpressJS pour permettre de générer des pages à la volée. Vous pouvez évidemment mettre en Cache les pages générées par les deux solutions pour économiser du temps de traitement.

Communauté

AngularJS a la plus grosse communauté entre EmberJS et ReactJS. C’est le plus vieux des trois et l’aura de Google a influencé grandement sa popularité.
Le Couple ReactJS+Flux à une communauté qui augmente également très rapidement. EmberJS à une communauté plus large que ReactJS mais elle est relativement stable depuis quelque années. Trouver une réponse lors de la phase de démarrage ne devrait pas être un problème pour les trois Frameworks.
Remarque pour les développeurs :
Je parle de couple ReactJS+Flux car ReactJS seul n’est pas un Framework à proprement parler. En effet, il ne s’occupe que des composants qui permettent l’affichage du contenu. Flux, s’occupe de rapatrier la donnée. Par ailleurs, il faut bien comprendre que Flux est avant tout un concept , même si Facebook a mis à disposition son implémentation, il en existe de nombreuses autres.

Documentation

Les documentations des trois Frameworks sont excellentes. Flux étant un concept, sa documentation dépend du projet qui en a fait l’implémentation. Certaines comme Fluxxor sont plutôt bien faites, à contrario, la libraire mise à disposition par Facebook a une documentation plutôt limité.
Les communautés de ces 3 Frameworks font un gros travail d’approfondissement dans la compréhension des concepts que ces Frameworks implémentent. Ils publient énormément de tutoriels écrits et de formations vidéos très abordables.

Infrastructure

Ces Frameworks côté client n’ont pas besoin d’une infrastructure très complexe : Il leur faut simplement un serveur HTTP envoyant la page initiale (avec ou sans contenu pré-généré).
En effet, le gros de l’infrastructure sera pris par l’API REST côté serveur, qui va communiquer avec le Framework. Ce dernier peut être également écrit en Javascript (ExpressJS par exemple) ou grâce à une application en PHP.
Une chose est à retenir : un Framework front end va communiquer avec un autre applicatif pour traiter la donnée, il le fait généralement en REST. C’est l’application côté serveur qui va effectuer les requêtes en base de donnée et envoyer les données au Framework.

Concept à maîtriser

Les Frameworks front end requièrent la compréhension des patrons de conceptions ( Design Pattern ). Angular 1 et Ember ont tous les deux implémentés le patron de conception MVC : Model, Vue, Controlleur.
Mais Angular 2 et ReactJS on une approche différente : ils définissent les différentes parties comme des composants ( AngularJS, ReactJS ). Ce concept n’est pas nouveau en soi mais son implémentation dans le cadre de ces Frameworks a besoin d’être compris et maîtrisé.
L’optimisation côté client est un point à ne pas oublier. L’application étant exécutée entièrement côté client, le chef de projet devra avoir une vision claire des utilisateurs ciblés.
Cette information va aider le développeur à optimiser les performances de l’application.
Si par exemple les utilisateurs sont dans des zones ou la connexion internet est mauvaise et/ou qu’ils possèdent des ordinateurs peu puissant, il faudra rendre l’application la plus légère possible tout en gardant les fonctionnalités.
Un des enjeux par exemple pour une application étant utilisée dans des zones de connexion limitées, est d’être la plus légère possible tout en conservant les fonctionnalités essentielles.
Il faut absolument savoir compiler : avec la ribambelle de packages utilisés dans nos projets, il faut savoir mettre en place un moyen de compiler l’ensemble du code dans un seul fichier ( Webpack ou Browserify ). Ce fichier est alors envoyé côté client et est exécuté.
Évidemment, Il faut aussi mettre en place des tests utiles pour éviter les régressions lors du développement.

Avantage

Ces Frameworks permettent de créer des applications rapidement. Ils ont tous un système de modules. Cela permet d’avoir une séparation claire des fonctionnalités dans le code. Cela permet aussi de récupérer des modules réalisés par d’autres personnes afin de gagner du temps sur le développement. Elles permettent de mettre en place des sites très modulables et personnalisables. En effet, l’essence même de ces outils est de manipuler les éléments HTML d’une page. De ce fait, avoir des fonctionnalités qui personnalisent l’affichage est possible.

Chef de projet

Ces Frameworks permettent de mettre en place des applications qui ne rechargent plus la page entière, seule la section qui a besoin de données est rechargée.

Développeur

Leurs composants de base permettent de gérer l’affichage mais aussi de se brancher à des APIs facilement. Ils permettent aussi de réduire la charge du serveur car ce dernier n’aura plus qu’à traiter la donnée et à la renvoyer dans un format très simple ( JSON ).Il n’aura donc plus besoin de générer la page de l’utilisateur en HTML.

Inconvénient

Au même titre que les Frameworks cités dans la partie précédente, les Frameworks front end demandent un temps d’adaptation. Même s’ils sont plus légers, le temps est relatif à l’expérience du développeur. De plus, ce dernier doit faire preuve de discernement lors de la recherche d’informations pour ne pas tomber dans des pièges.

Développeur

La mise en place des compilateur est assez long. En effet, la configuration peut être assez longue car ils ont tous leur façon de gérer les différentes étapes. Si votre application est un Saas, il faut prendre des précautions à la taille des fichiers JS envoyés au client. En effet, il faut bien configurer le compilateur pour qu’il crée plusieurs fichiers de sortie correspondant au contexte de l’utilisateur.

Vers quelle Technologie aller pour réussir votre projet web (2ème partie)

Lorsque le navigateur demande un site web au serveur, il fait une requête. Lors de l’utilisation d’un Framework, la réponse à cette requête est généralement traitée de deux manières :

  • Soit le Framework fait le traitement de la requête et renvoie une page HTML complète, le rendu est donc fait côté serveur et le navigateur ne fait qu’afficher la page.
  • Soit le Framework lit la requête dans le navigateur, fait une requête à une ou plusieurs urls ( API REST )  si besoin pour récupérer des données. Les données sont affichées directement dans le navigateur en modifiant le HTML, c’est le rendu côté client.

Dans cette seconde partie, nous allons aborder le rendu côté serveur pour les Frameworks PHP et Javascript.
Le langage PHP a énormément de Frameworks mais je ne parlerai que de Symfony 2/3 et Zend 2. Il sont pour moi les deux solutions les plus pérennes et les plus viables. En effet, elles sont soutenues et maintenues par des entreprises en coopération avec la communauté.
Pour Javascript, j’ai choisi ExpressJS avec un moteur de template; vous pouvez choisir celui que vous voulez car il font tous le même job : faire le rendu de la page en HTML dans le serveur. Fait par un seul homme à ses débuts, il est aujourd’hui maintenu par une grosse communauté et cet effort est soutenu par StrongLoop qui est une entreprise appartenant à IBM.

La Cathédrale* : le rendu fait côté serveur

C’est la technique “historique” de génération de page web, en voici la séquence simplifiée :

  1. Le navigateur envoie une requête au serveur.
  2. Le serveur renvoie du html avec les fichiers de styles et le javascript.
  3. Le navigateur affiche le html, utilise le css contenu dans les fichiers de style pour disposer et styliser les différents tags html.
  4. Le javascript s’exécute et met en place les interactions de l’interface du site ( popin lors du clic sur un mot ou un bouton, lecteur média, …etc ) et si besoin récupère des données supplémentaires à afficher.

Remarque :
Les CMS présentés dans la précédente partie utilisent en général cette technique pour afficher les sites web. Mais il existe des plugins qui permettent de faire des rendus côté client, nous détaillerons cette technique dans la prochaine partie.
jesus love frameworks

Communauté

Zend Framework et Symfony ont des communautés très larges. Zend Framework est considéré comme le framework historique de PHP mais il connaît un déclin fasse à Symfony depuis quelque années.
Les communautés de Zend Framwork et de Symfony sont respectivement animés par Zend Technologie et SensioLabs . Ces entreprises soutiennent l’effort de développement fait par la communauté mais sont très largement les moteurs des différentes sorties de versions. Beaucoup d’entreprises proposent aujourd’hui des prestations dans ces deux technologies mais Symfony 2 est le plus choisi ces dernières années.
ExpressJS est l’un des premiers framework NodeJS. ExpressJS est un peu l’équivalent de Zend pour NodeJS. De nombreux tutoriels existent, il est donc simple de trouver une réponse en cas de blocage.

Documentation

Zend Framework a eu une documentation passable à la sortie de la version 2. Mais ils se sont améliorés au fil des sorties des versions mineurs (2.x). La version 3, qui est sortie récemment, à mis en place une excellente documentation pour ses packages de base. Des tutoriels sont mis en ligne depuis peu concernant l’utilisation des différents modules à l’image de Symfony.
Symfony 2 a quant à lui une très bonne documentation. La documentation de référence est complétée par le CookBook qui permet d’avoir des cas pratiques d’utilisations des différentes parties du framework appelé bundles. Cela facilite grandement la compréhension des différents bundles de base et permet ainsi de réduire le temps d’apprentissage du framework.
ExpressJS étant très simple, sa documentation est moins lourde à parcourir que les deux gros frameworks PHP. Il n’y a que la documentation de référence sur le site officiel mais trouver un tutoriel sur un cas d’utilisation est très simple.

Infrastructure

Les frameworks PHP nécessitent une une infrastructure classique LAMP ou LeMP ( Linux, Apache/eNginX, Mysql/MariaDB, PHP ), mais requiert une configuration du serveur HTTP (Apache ou eNginX) plus poussée. Il s’installe difficilement chez les hébergeurs mutualisés, mais ce n’est pas non plus  impossible. Je vous conseille vivement d’utiliser eNginX couplé à PHP-FPM ou à HHVM pour augmenter le temps de traitement PHP.
ExpressJS fonctionne avec le serveur HTTP intégré à NodeJS. Sur les grosses applications NodeJS, on peut voir un serveur eNginX en face du serveur NodeJS. c’est à dire que la requête du navigateur va d’abord passer par eNginX avant d’aller sur un serveur NodeJS. Cela permet d’avoir eNginX qui partage la charge entre plusieurs serveurs NodeJS dans la même machine.
Je vous conseille également de mettre en place un/des serveur(s) de Cache afin d’accélérer la navigation de l’utilisateur.

Concepts à maîtriser

Les frameworks PHP et Javascript requièrent  la compréhension des patrons de conceptions (Design Pattern ). Le patron de conception ( c’est vraiment moche la traduction 😀 ) le plus important à maîtriser est le MVC : Modele, Vue, Controller.
Symfony 2 et 3, Zend 1 et 2 et ExpressJS 4 utilisent d’autres Design Pattern comme le Singleton, la Factory, l’Observer, la Façade… etc. Il faut bien comprendre leur fonctionnement global pour bien les utiliser. C’est le seul moyen d’architecturer correctement les différentes fonctionnalités en utilisant toute la puissance offerte par ces frameworks.
Il faut savoir correctement organiser les données dans la base de donnée. Avec une base de donnée relationnelle, l’organisation des données entre les tables est cruciale dans la performance de le traitement des requêtes. Les bases de données NoSQL sont plus permissives dans leur organisation et demandent donc une plus grande rigueur dans l’organisation des schémas.
Enfin, il faut savoir mettre en place des tests utiles afin d’éviter des régressions lors du développement. En plus de tous cela, je vous conseille de mettre en place un déploiement continu de l’application.

Avantages

Ces frameworks permettent d’accélérer le développement. Ils ont tous un système de modules. Cela permet d’avoir une séparation claire des fonctionnalités dans le code. Cela permet aussi de récupérer des modules réaliser par d’autre personne afin de gagner du temps sur le développement. Ils incorporent des modules de base qui leur donnent une grande flexibilité et leur permet d’être le socle d’une large variété d’applications.

Chef de projet

Grande liberté dans les fonctionnalités. Une gestion du SEO peut s’adapter aisément. Les templates étant fabriqués par les développeur, les designs peuvent être personnalisés pour les fonctionnalités. Accélère le développement des fonctionnalités.

Développeur

Les Frameworks cités plus haut ont des outils pour vous guider dans l’implémentation des fonctionnalités. Ils permettent de limiter les problèmes techniques et incite aux bonnes pratiques d’écriture du code. Enfin, Beaucoup de cas pratiques différents sont disponibles sur le web pour vous aider.

Inconvénients

Étant un ensemble complexe, un framework demande un temps d’adaptation. Ce temps est relatif à l’expérience du développeur. Ce dernier doit donc faire preuve de discernement lors de la recherche d’informations pour ne pas tomber dans des pièges.

Vers quelle Technologie aller pour réussir votre projet web (1ère partie)

Dans le merveilleux monde du web, lors du démarrage d’un projet, le choix des technologies est crucial. Lors d’une refonte totale, le choix est moins difficile… mais ne veut pas dire simple 🙂
Dans le cadre d’une refonte, on peut s’appuyer sur l’expérience acquise auparavant pour repenser l’application. On peut aussi mettre en place une nouvelle expérience plus saine pour le développeur (Developper eXperience) afin de fluidifier la réécriture des fonctionnalités existantes et d’améliorer la production de nouvelles fonctionnalités.
En effet, le fait d’avoir des fonctionnalités déjà en place en environnement de production permet une analyse simplifiée du code et de l’UX.
De plus, contrairement à un nouveau projet, le besoins est clair dans une solution déjà en place. D’autant que le projet a parfois connu de nombreuses modifications de la part des demandeurs.
Si lors d’une refonte le besoin n’est pas clair pour les développeurs et le Chef de projet, c’est qu’il y a un autre problème 😉
Il faut donc correctement comprendre le besoin pour faire les bons choix. Dans le cadre d’un nouveau projet, le besoin n’est pas évident à cerner, aussi bien pour le demandeur (qui a souvent une idée floue de la solution), que pour le chef de projet ou PO qui va devoir s’approprier ce besoin et piloter le projet. Cette solution va être ensuite créée par un ou plusieurs développeurs.
En tant que développeur, on a le choix entre le confort d’un langage et/ou framework qu’on connaît, et l’aventure avec un nouveau langage et/ou framework.
Je suis partisan de l’adage qui pour un projet dit, , “la bonne technologie est la technologie que l’équipe connaît la mieux”. Mais parfois on est amené à faire un choix en fonction des contraintes. Ainsi, pour aider les développeurs, aventureux et moins aventureux, mais aussi les Chef de projets curieux, je vous propose un petit guide pour orienter votre recherche. Ce guide n’a pas vocation à vous donner une réponse toute faite mais à vous donner des pistes de réflexion autour des différents outils (tout cela n’est évidemment mon humble avis).
Nous allons donc commencer par les trois CMS PHP les plus en vue : WordPress, Drupal, Joomla. Dans les parties qui vont suivre, nous aborderons les frameworks. Ainsi, nous verrons leur utilisation dans le cadre d’un rendu fait côté serveur puis nous terminerons par le rendu fait côté client.
Cette comparaison prendra en compte les points suivants :

  • Communauté : Plus le nombre d’utilisateurs est important, plus les solutions aux problèmes rencontrées sont nombreuses.
  • Documentation : un bonne documentation peut faire gagner beaucoup de temps.
  • Infrastructure : Beaucoup de points sont communs à PHP et JS …et pour toutes les applications web en général. Ainsi le système d’exploitation des ordinateurs servant a héberger l’application sont généralement tous sous Linux. L’application web a besoin d’un serveur HTTP pour envoyer et recevoir des requêtes, en général Apache, ou eNginX. Pour sauvegarder les données, il lui faut une base de donnée, là encore, en général on retrouve des systèmes base de données relationnelles comme MySQL, mais l’utilisation de bases de donnée NoSQL augmente d’année en année. Le point de divergence vient des moyens nécessaires au traitement de la requête : avec PHP on passera par un binaire, avec Javascript, on utilisera NodeJS.
  • Concepts : Certain outils demandent la maîtrise de concepts assez avancés par les développeurs.
  • Avantages et Inconvénients d’un point de vue développeur et Chef de projet.

Les kits prêts à l’emploi : les CMS

Un CMS est une solution clé en mains pour créer un site, nécessitant simplement du contenu dynamique structuré. Autrement dit, c’est une pâte à gâteau prête à être mise au four 😉
Quand on compare les parts de marché des CMS dans le trafic web, on s’aperçoit vite qu’un CMS dépasse tous les autres : WordPress. La part exacte de WordPress n’est pas vraiment déterminée mais il se situe entre un tiers et deux tiers ( 1 , 2 , 3 ). WordPress est un CMS très ( trop ? ) généraliste au même titre que les deux autres CMS qui le suivent ( difficilement ) Joomla et Drupal.

Communauté

WordPress dispose d’une très large communauté car orienté très grand public contrairement au deux autres. Drupal et Joomla ont des communautés moins larges mais ont un public beaucoup plus technique car leur prise en main est plus compliquée.

Documentation

Très bonne documentation. Les concepts avancés sont bien expliqués mais parfois un peu abstrait. Néanmoins, vous pouvez aisément trouver des articles sur des utilisations avancées appliqués à des cas plus réels.

Infrastructure

Une infrastructure classique LAMP ou LeMP ( Linux, Apache/eNginX, Mysql/MariaDB, PHP ) suffit amplement pour faire fonctionner ces CMS. Beaucoup d’hébergeurs comme OVH ou 1&1 proposent des offres sur des serveurs mutualisés. Ces derniers ont l’avantage d’être pré-configurés, ce qui permet un déploiement rapidet. Mais si vous décidez de passer par un serveur dédié, les configurations nécessaires ne sont pas très difficiles. Sur des sites à fort trafic, il est vivement conseillé de mettre en place des serveurs de cache pour accélérer la navigation de l’utilisateur.

Concepts à maîtriser

WordPress ne requiert pas de concepts avancés à maîtriser et la prise en main est très rapide. Drupal et Joomla, dans leur dernière version, ont des organisations plus complexes que WordPress. Mais leur utilisation au jour le jour est plutôt simple après une petite période d’adaptation.

Avantage

La solution de prendre un CMS est idéale lorsque le besoin est simple ( vous avez un exemple devant vos yeux 🙂 ).

Chef de projet

Le SEO est facile à mettre en place grâce aux plugins. Il y a énormément de templates disponibles.

Développeur

Peut de choses à maîtriser. Facile de faire une template soi-même. Facile de faire un plugin soi-même.

Inconvénient

Étant très répandus, les CMS sont très exposés aux attaques : lorsqu’une faille est trouvée sur un site ayant l’un des CMS , il peut être exploité sur tous les autres sites ayant le même CMS. Les performances du site peuvent aussi s’effondrer si un plugin et/ou un serveur pour faire du Cache n’est pas installé.

Chef de projet

Il faut mettre en place un certain nombre de plugins pour pouvoir bénéficier d’un SEO efficace. La gestion du contenu personnalisé peut vite devenir contraignant si le plugin n’est pas assez bien adapté.
Implémenter des fonctionnalités non prévues par le CMS peut être long. Les templates téléchargeables ne seront pas rapidement adaptables (voir pas du tout parfois) pour certains besoins particuliers. En effet, les CMS on chacun leur façon de surcharger les modules fournis dans les templates.

Développeur

Difficiles à maintenir lorsqu’ils sont utilisés pour autre chose que du contenu simple (Application SAAS ou Ecommerce ). Les templates téléchargeables deviennent parfois… non en fait très souvent :), un cauchemar à modifier et maintenir. Et parfois, avec le même CMS, vous aurez des manières très différentes de surcharger les templates. En effet, même s’il existe des bonnes pratiques, il ne s’applique qu’à des templates simples; les templates plus complexes s’organisent de manière très différente en fonction des personnes qui les réalisent.
Les plugins peuvent être longs et contraignants à créer ou à adapter.
Les cas pratiques disponibles sur le web ne sont pas très diversifiés et obligent à utiliser des plugins peu ou pas maintenus.