FeWeb – Conférence debugging frontend

Outils et bonnes pratiques pour développeurs et designers Jeudi 16 mars 2017

ⓒ Feweb

Chrome Devtools

Maurizio Pedriale
Copie des slides : https://github.com/mamoo/feweb-talk-mar2017/blob/master/slides/index.html

Maurizio recommande Chrome Devtools car il fournit rapidement un nombre intéressant (pas trop) d’informations et permet donc d’assez rapidement trouver les problèmes.

Lui, comme d’autres orateurs, mentionnent utiliser Chrome Canary qui est un navigateur conçu pour les développeurs et “early-adopters”.

Raccourcis

Onglet Network

L’onglet Network donne le waterfall de la page et la liste de toutes les ressources chargées.

En cliquant sur la barre de couleur, Devtools donne des indications comme le TTFB (temps entre l’envoi de la requête et du premier byte retourné par le serveur). On reçoit aussi le temps nécessaire par SSL, ... On peut donc mieux comprendre ce qui bloque.

La partie en gris, à gauche de chaque ressource, donne le temps nécessaire par le serveur pour traiter la requête => lorsqu’un serveur reçoit plusieurs requêtes en simultanés, il ne peut en traiter que xxx (cinq) et donc les requêtes additionnelles sont mises en attente. Souci de la séquentialité.

D’où, pour cela, l’intérêt d’un CDN qui visera à soulager le serveur et à répartir la charge sur plusieurs serveurs.

L’onglet Network permet de simuler un type de réseau : 3G / 4G / offline / ... afin de pouvoir simuler une mauvaise qualité de réseau et voir comment se comporte la page.

Onglet Performance

Parfois l’onglet Network ne semble pas indiquer la source de la lenteur : les données sont téléchargées en deux secondes mais la barre de statut indique que la page a mis cinq secondes à charger.

Performance permet alors de lancer un recorder qui permettra alors de voir le temps requis, sur l’ordinateur, d’afficher la page. Comme p.ex. le temps CPU.

Dans l’exemple, les données étaient téléchargées en deux secondes mais la page s’affichait en cinq secondes : le CPU a pris près de 3 secondes pour traiter le script javascript. En l’occurrence, il y avait un script js non optimisé et Performance a permis de mettre cela en évidence.

Dans l’exemple proposé, il est alors recommandé de déplacer ce type de script non optimisé au bas de la page afin que le DOM s’affiche.

Performance permet aussi de montrer l’occupation de mémoire : si le script js consomme trop de mémoire, ajoute des éléments au DOM encore et encore, le browser va devenir de plus en plus court en mémoire et le garbage collector aura de plus en plus de mal à traiter ces demandes => ralentissement de la page.

Source

L’onglet source permet de définir des watchs et breakpoints comme p.ex. sur un mouse-click (l’opération est activée lorsqu’on clique dans un champs), double-click, onexit, ... On définit donc le trigger qui va lancer le breakpoint.

Devtools montre alors le code source et on peut y aller step by step pour déboguer la page.

Voir “Get Started with Debugging Javascript in Chrome DetTools

Devtools peut aussi s’arrêter lorsqu’il rencontre une exception (try catch).

Debugging operations asynchrones

Voir “Asynchronous Stack Traces

XHR Breakpoints

On peut mettre des breakpoints sur chaque appel ajax sur la page.

L’onglet source permet aussi d’intervenir dans le code source .js et par exemple d’ajouter des conditions (si la variable i == 3 alors interruption).

Objet console

L’objet console dispose d’une API. Il y a p.ex. timeStamp qui permet de mesurer le temps entre deux blocs.

console.timeStamp();
console.table();
console.assert();

Snippets

Il y a aussi la fonction snippets qui permet de copier/coller un code js pour récupérer le contenu d’une variable js et la sérialiser pour enregistrer les données au format JSON.

L’intégralité des slides de Maurizio : https://github.com/mamoo/feweb-talk-mar2017/blob/master/slides/index.html


Debug your design #likeaboss

David Leuliette
Copie des slides : http://courses.davidl.fr/presentations/devtools

(info : les slides sont en reveal.js avec le texte écrit en markdown, faire un CTRL + U pour voir le source)

Take your decisions in the Browser (càd immédiatement dessiner l’écran dans un éditeur plutôt de Photoshop p.ex.)

Chrome Devtools

On peut intervenir directement dans le DOM, ajouter des classes, ID, ...

A droite dans la liste des onglets, il y a un bouton avec trois points verticalement. Il y a alors la possibilité p.ex. d’ajouter des animations.

Il existe plusieurs trucs au niveau de la console, à droite, comme par exemple la possibilité de cliquer sur un code couleur en maintenant la touche SHIFT enfoncée pour passer de code hexa en rgb ou hsl.

On peut aussi cliquer avec le bouton de droite de la souris sur un élément (à gauche donc) pour ajouter un :hover p.ex., nul besoin de le taper soi-même.

Firefox Developer Editions & Safari DevTools

Pour le debugging d’une page en responsive, David préfère Firefox Developer Editions qui “est meilleur” à son goût tandis qu’il va utiliser Safari DevTools pour débogger une application iPhone.

Démo : https://www.youtube.com/embed/2NHtfp7Owxo?ecver=2

Vorlon.js

vorlon.js permet de déboguer plusieurs devices en même temps. vorlon.js permet donc d’industraliser ses tests.

... puis more puis settings, donne accès à plus de fonctionnalités.

Encore plus loin

On peut ajouter d’autres fonctionnalités à son developper tool : chrome://extensions.

Exemples :

L’intégralité des slides de David : http://courses.davidl.fr/presentations/devtools


Bescherelle ton code

Thierry Michel
Copie des slides : http://slides.com/thierrymichel/bescherelle-ton-code#/

Du code valide mais aussi respectueux de standards, sans efforts, c’est possible !

PEBKAC – Program Exists Between Keyboard And Chair
PICNIC – Problem In Chair, Not In Computer
ID-10T error

Linter

De l’anglais lint : “touffe hirsute” (ou peluche, bouloche)

Un linter est un analyser syntaxique qui va vérifier la qualité du code avant même de devoir l’exécuter comme des erreurs de syntaxe, des erreurs de conception, du code non optimisé, des erreurs de style (mise en forme du code)

Le linter va reformater le code selon certaines normes comme PSR-2. Certains auteurs Open Source exigent des contributeurs qu’ils respectent la même norme que lui.

Le linter permet aussi de davantage maîtriser le langage en comprenant mieux pourquoi telle ou telle façon de programmer.

Installation possible de différentes manières dont

Il existe des linter pour plusieurs languages donc PHPLint, Markdown lint, ESLint, PHP_CodeSniffer, ...

Quand ?

Dès qu’on code; dans l’éditeur. Privilégier le lint en temps réel.

Et avant de déployer le code via le workflow comme p.ex. grâce à gulp ou des scripts npm scripts.

L’intégralité des slides de Thierry : http://slides.com/thierrymichel/bescherelle-ton-code#/