Bio et autre info => https://github.com/putaindecode/website/blob/master/src/_members/MoOx.json Avatar à taille correcte => https://gravatar.com/avatar/2f6c2dcd4ba8fc44f1e7f0b2ed3d587d?s=512 (tu te débrouilles avec la taille hein =)
Jadis, par des temps lointains datant de l'époque où l'on comptait encore les MHz des processeurs, il existait des gens qui concevaient, développaient, et alimentaient des sites Internet. Tout seul ! Ces personnes possédaient toutes les connaissances nécessaires (et même des fois le matériel sur toute la boucle) pour mettre en place un site web. Équipés des meilleurs outils (frontpage et filezilla), ces êtres avaient le pouvoir rare en ces temps nouveaux: on les appelait les Maîtres du Web ! Bon en fait on les appelait pas vraiment comme ça, c'était webmaster mais je vous ai offert une super traduction, en tout cas moins ringarde que celle de l'académie française qu'on croirait sortir du film Les Visiteurs !
Enfin tout ça, c'était avant. Avant le Web : 0. 2.0 pardon. Oui vous savez cette époque où on a commencé à utiliser la méthode appelé AJAX (rien à voir avec le fameux produit pour laver le sol), pour faire du DHTML. Cette même époque où on a commencé à exploiter la puissance du réseau afin de faciliter les échanges sociaux. Ces temps où du coup, on a commencé à avoir des sites qui se rapprochaient plus des applications de par leur complexité et où tous les webmasters avaient un compte sur codes-sources.com.
Petit à petit, avec le temps, la pratique, l'évolution d'Internet, les webmasters, surchargés par la masse de travail à réaliser pour s'occuper d'un site, se sont scindés en différents groupes.
Certains sont restés sur la conception. D'autres sur la réalisation de contenus. D'autres encore se sont focalisés sur le développement du site en lui même. Toutes ces branches aujourd'hui ont chaque jour de nouvelles ramifications avec les nouveaux usages que nous faisons du web.
De part ma position dans ce milieu, je vais vous parler du poste de développeur, et plus précisément du développeur d'interface. Celui qu'on appelle encore par fois intégrateur (personnellement je trouve ce nom réducteur) ou encore -développeur front-end.
Le webmaster c'est un peu comme l'agriculteur qui s'occupe d'aller au marché vendre ses produits. Il maitrise s'occupe de toute la ligne.
Continuant dans une analogie similaire, le poste de développeur front-end peut être assimilés à une glue entre le back-end et l'interface utilisateur: il s'occupe de mettre en place la vitrine du magasin, avec les produits fait en arrière boutique (qui utilise des matières premières) et les croquis de l'architecte.
J'aime bien cette analogie.
Après j'en aime bien une autre, celle du gardien de foot. Celui qui prend tout dans les dents à la fin si ça déconne tout du long.
Mais je m'égare, parlons automatisation.
Alors que niveau back-end, les choses sont plutôt au point (que ce soit niveau système avec les gestionnaires de paquets, ou niveau logiciel avec les diverses possibilités qu'on les développeur pour faire du code propre, maintenable, testable au point de tourner en intégration continu... ), au niveau du front-end, on s'y met à peine.
C'est sur que là comme ça, quand on résume notre façon de faire, on voit mal comment automatiser tout ça. Prenons un exemple de mise en place d'un projet web, du point de vu du développeur d'interface utilisateur.
On démarre notre projet, il va donc nous falloir une base.
Si vous ne souhaitez pas utilisez de base, rendez-vous au point 1.
Si vous souhaitez partir sur de l'existant, rendez-vous au point 2.
- Bon courage. Bisous !
- C'est parti, on va faire notre petit train train habituel
On est au top, on fait de la veille, donc on sait déjà sur quoi basé notre HTML: HTMLBoilerplate. On a là un squelette HTML accompagné de pleins de bonnes pratiques. Hop hop on le télécharge. Selon les besoins on répète l'opération pour les différents boilerplates qu'on a habitude d'utiliser. Oui quoi, on est au top, on télécharge toujours les dernières versions hein ;) Bon ensuite, on va se prendre quelques petites librairies (toujours selon nos besoins). Un petit coup de jQuery juste pour le petit slider de la futur home page du site e-commerce, hop hop (non je plaisante, dans la vrai vie, ne faites pas ça). On oublie pas de télécharger notre carousel, et le lightbox pour les photos ! Ah mince, celui qu'on prends d'habitue ne marche pas avec la mise à jour de jQuery. Aïe, ouille. On en cherche un autre où on rétrograde de version ? Bref. Une fois qu'on a bien commencé tout ça, on code. Des jours, des semaines durant. On commence le style du site (on est des fous, on utilise un pré-processeur CSS). Ça compile. On test et on fait testé (les fameuses recettes, non pour le coup pas celle de grand-mère). On debugge, on optimise. On commit. On versionne... Et ça recommence. On code. Ça compile. On test. On debugge. Et ainsi ce suite. A certain moment, on déploie, et avant ça, on optimise (minimification, optmisation des images, des polices, etc).
Et à chaque nouveau projet, on repart du point 2.
Ne pourrait-on pas automatiser une partie de toutes ces taches répétitives ? Ce ne serait pas être fainéant ? Surement un peu mais il faut un minimum de fainéantise à tout bon programmeur, justement pour programmer le plus possible afin de ne pas refaire encore et encore les mêmes choses qui peuvent être automatisé. En fait, ce serait reculer pour mieux sauter. Être plus efficace, afin de pouvoir se concentrer sur le code et sa qualité. Tout simplement.
Mais alors comment on s'y prendrait un développeur front-end aujourd'hui ?
Il existe depuis quelques temps maintenant, pratique pour les projets de petite envergure, un petit paquet d'applications tel que Codekit (OS X), Hammer (OS X), Prepros (OS X/Windows), Koala (Windows/OS X/Linux), Mixture (Windows/OS X), ou encore Scout (OS X/Windows).
Déjà lorsqu'on utilise ces applications, on passe à un cap supérieur. Y'a du mieux. Mais cela se limite souvent à quelque chose similaire à de la compilation pour JavaScript et feuilles de styles. Il manque encore plein de choses à intégrer, comme par exemple la gestion des dépendances entre les librairies ou encore l'intégration des tests ou autres optimisations avant déploiement.
Il aujourd'hui plusieurs packagers front-end qui peuvent répondre à ce besoin. Voici les principaux:
- Bower (Pas de contraintes - JavaScript, CSS, Sass, Coffee, Images...)
- Volo (Idem, pas de contraintes)
- Jam (JavaScript)
- Component (ce dernier est bien plus qu'un simple gestionnaire de paquets)
Concernant la partie dépendance on va dire que c'est du pareil au même. J'ai une petite préférence pour Bower de par sa communauté et les rockstars du web qui la soutiennent. Vous avez un petit comparatif sur GitHub (en).
Comme on l'a vu dans l'exemple précédent, sans gestionnaire de paquets/dépendances, ça peut vite être pénible et prendre un peu de temps pour s'occuper de télécharger ses librairies favorites.
Avec un packager comme Bower, ça devient un jeu d'enfant. Plutôt que de parler voici ce que je viens de faire dans ma console, en moins de 25 secondes.
~
❯ bower search lightbox
Search results:
bootstrap-lightbox git://github.com/jbutz/bootstrap-lightbox.git
armory-blrrtstrap-lightbox git://github.com/psirenny/armory-blrrtstrap-lightbox.git
olightbox git://github.com/olyckne/Olightbox.git
rg-lightbox git://github.com/RGkevin/rg-lightbox.git
~
❯ bower install bootstrap-lightbox
bower bootstrap-lightbox#* not-cached git://github.com/jbutz/bootstrap-lightbox.git#*
bower bootstrap-lightbox#* resolve git://github.com/jbutz/bootstrap-lightbox.git#*
bower bootstrap-lightbox#* download https://github.com/jbutz/bootstrap-lightbox/archive/v0.6.1.tar.gz
bower bootstrap-lightbox#* extract archive.tar.gz
bower bootstrap-lightbox#* deprecated Package bootstrap-lightbox is using the deprecated component.json
bower bootstrap-lightbox#* mismatch Version declared in the json (1.0.0) is different than the resolved one (0.6.1)
bower bootstrap-lightbox#* resolved git://github.com/jbutz/bootstrap-lightbox.git#0.6.1
bower jquery#>=1.7.1 cached git://github.com/components/jquery.git#2.0.3
bower jquery#>=1.7.1 validate 2.0.3 against git://github.com/components/jquery.git#>=1.7.1
bower bootstrap#>=2.0.4 <3.0 not-cached git://github.com/twbs/bootstrap.git#>=2.0.4 <3.0
bower bootstrap#>=2.0.4 <3.0 resolve git://github.com/twbs/bootstrap.git#>=2.0.4 <3.0
bower bootstrap#>=2.0.4 <3.0 download https://github.com/twbs/bootstrap/archive/v2.3.2.tar.gz
bower bootstrap#>=2.0.4 <3.0 progress received 2.2MB of 3.0MB downloaded, 74%
bower bootstrap#>=2.0.4 <3.0 progress received 2.5MB of 3.0MB downloaded, 84%
bower bootstrap#>=2.0.4 <3.0 progress received 2.8MB of 3.0MB downloaded, 94%
bower bootstrap#>=2.0.4 <3.0 extract archive.tar.gz
bower bootstrap#>=2.0.4 <3.0 resolved git://github.com/twbs/bootstrap.git#2.3.2
bower jquery#>=1.8.0 <2.1.0 cached git://github.com/components/jquery.git#2.0.3
bower jquery#>=1.8.0 <2.1.0 validate 2.0.3 against git://github.com/components/jquery.git#>=1.8.0 <2.1.0
bower bootstrap-lightbox#~0.6.1 install bootstrap-lightbox#0.6.1
bower jquery#>=1.7.1 install jquery#2.0.3
bower bootstrap#>=2.0.4 <3.0 install bootstrap#2.3.2
bootstrap-lightbox#0.6.1 bower_components/bootstrap-lightbox
├── bootstrap#2.3.2
└── jquery#2.0.3
jquery#2.0.3 bower_components/jquery
bootstrap#2.3.2 bower_components/bootstrap
└── jquery#2.0.3
~ 24s
En quelques instants, j'ai cherché un paquet, et l'ai récupéré avec ses dépendances. C'est pas le pied ça ?
Le terme scaffolding est un peu un abus de langage lorsque l'on connait ses origines et ce que fait réellement Yeoman mais passons. Je n'ai pas encore vraiment exploité cette outil, bien que j'ai totalement conscience de ce qu'il permet. Je vais donc vous en toucher un mot.
Comment nous l'avons vu tout à l'heure avec notre exemple, après avoir télécharger nos librairies et autres boilerplates, il faut bien coller toutes ses pièces entre elles. C'est ce à quoi sert Yeoman. Il possède tout plein de générateurs qui peuvent (entre autres) exploiter Bower. Il y a même un générateur de générateur. Je vous laisse jeter un coup d'oeil sur les générateurs dont les noms vous diront quelques choses afin de bien comprendre ce que fera cette outil.
Le niveau suivant, après avoir créer sa base de projet avec des outils comme Bower et Yeoman, c'est d'automatiser les commandes du quotidien: pré-processing, tests automatisés, optimisation, déploiement... Nous avons depuis un bon bout de temps des clés en main pour résoudre cette problématique:
Make est une solution datant de 1977 ! C'est une commande qui permet tout simplement d'en exécuter d'autres, avec du code similaire à du shell script.
Dans notre cas, on pourra se créer des commandes tel que make compile, make tests, make deploy...
Voici un exemple plus parlant:
all: install build test
install:
bower install
watch:
sass watch [...]
build:
sass compile [...]
uglify [...]
test:
casper [...]
Je n'ai volontairement pas rempli les sous commandes, mais vous devinez le principe: on déclare des tâches qui en exécutent d'autres.
Ça évite de se taper les lignes à chaques fois.
On peut même faire un tâche qui execute d'autres tâches. Dans notre exemple la commande make all.
Avec ce genre de petit fichiers en plus de Bower et Yeoman, on se simplifie carrément la vie. Et lorsque l'on travail en équipe, plus besoin d'expliquer la commande à lancer au nouveau développeur ou au sysadmin pour le déploiement.
Make étant assez limité, d'autres émules sont apparus adaptés à différents langages tel que Rake (Ruby), Cake (Clojure), Jake (JavaScript)... Il existe aussi Ant basé sur XML, ce qui rend les fichiers très verbeux. Puis bon, celui là est fait en Java. Je ne me suis fais à aucun de ces outils mais j'ai beaucoup accroché au petit dernier: Grunt.
Ouais bon ok, Grunt c'est pas vraiment un porc, plutôt un sanglier, et encore qu'il y aurait des origines en rapport avec Warcraft :)
Donc avec cette outil, on passe au summum de l'automatisation.
Pourquoi plus qu'avec les autres ? De part son écosystème.
Grunt possède énormément de tâches déjà disponibles dont voici quelques exemples (je vous passe les grunt-compass, grunt-less, grunt-uglify & co):
- grunt-contrib-watch: Surveiller ses fichiers et lancer des tâches lors des modifications. Embarque le rechargement automatique dans votre navigateur (livereload).
- grunt-contrib-jshint: Valider ses fichiers avec JSHint
- grunt-contrib-imagemin: Minifier ses fichiers JPEG et PNG
- assemble: Base pour faire un génerateur de site statiques
- grunt-casperjs: Rien de mieux pour lancer ses tests fonctionnels avec CasperJS
- grunt-webfont: Convertir des svg en web fonts avec feuilles de styles prêt à l'emploi
- grunt-angular-*: Tout pleins de plugins angular si c'est votre dada
- grunt-autoprefixer: Ajouter les préfixes CSS automatiquement en se basant sur CanIuse.com et des versions de navigateurs spécifiés
- grunt-notify: Afficher des notifications de rapport des tâches intégré à votre OS
- grunt-responsive-images: Générer des images à différentes tailles
Bon je m'arrête là car on a plus de 1700 tâches disponibles, il a donc de tout et n'importe quoi. Mais sachez que si vous pensez à une tâche Grunt, il est possible qu'elle existe déjà. Puis si ce n'est pas le cas, il est très facile d'écrire ses propres tâches Grunt, sans forcément le publier où que ce soit.
Pour découvrir Grunt pas à pas, je vous invite à lire l'article Premiers pas avec Grunt sur Putain de Code.fr. Si vous souhaitez aller plus loin où que vous voulez directement mettre vos yeux dans de la source, je vous invite aussi à regarder le code source du projet HappyPlan, un générateur de site statique basé sur Grunt. Vous y verrez comment exploser votre Gruntfile en petit fichier, beaucoup plus pratique pour la maintenance ;)
Il existe aujourd'hui deux alternatives sérieuses à Grunt.
La première est Brunch.io. Le projet se veut plus simple et plus rapide d'utilisation au détriment de la flexibilité qu'apporte Grunt. Je vous invite à regarder le tableau comparatif afin de vous faire votre propre opinon. Notez que pour les points concernants l'intégration de Bower et de Source Maps, cela peut se faire via des plugins Grunt. Il reste donc bien la vitesse comme argument majeur.
La deuxième alternative tout fraiche est Gulp. Le point fort de ce petit dernier est son approche par flux plutôt que par fichiers. Cela afin d'avoir de meilleurs performances en évitant multiples lectures/écritures durant votre workflow. Ne parlons pas de la flexibilité car ici point de configuration, juste du simple code à coupler avec de simples composants (cf la page du projet où vous trouverez des exemples). Je vous invite à lire ces slides: Gulp, The streaming build system qui montrent avec des schémas les différences entre ce projet et l'approche de Grunt. Vous trouverez les composants Gulp disponible via cette simple recherche sur npm
Personnelement j'utilise actuellement Grunt pour son écosysteme, mais je pense essayer Gulp sur mon prochain projet. En effet quand on commence à avoir un workflow très poussé, on peut commencer à sentir de petites lenteurs avec Grunt.
J'espère vous avoir donné envie d'automatiser votre quotidien de développeur front-end. Je sais pas vous, mais moi, je ne pourrais plus faire machine arrière, surtout depuis que j'ai gouté au livereload !
Note: Derrière le mot livereload ne se cache pas uniquement l'application Livereload. Il existe maintenant tout un tas de composants à brancher sur votre workflow actuel.