Mot-clef « Debug »

Quelques trucs sur Jekyll #2

Lisibilité des erreurs

Par défaut, le serveur de développement de Jekyll remonte des erreurs assez sommaires en ne précisant que le template concerné. C’est inutilisable quand on débugue un template (même si un numéro de ligne ne serait pas du luxe) mais quand l’erreur vient d’un plugin c’est plutôt limité.

Pour un affichage un peu plus détaillé avec une trace d’exécution permettant de déterminer quelle ligne de quel plugin est en cause, il faut utiliser l’option --trace ou -t.

bundle exec jekyll serve --drafts -t

Fichiers sitemap.xml et robots.txt

Il existe un plugin pour générer le fichier sitemap.xml, par contre je n’ai rien trouvé pour gérer son intégration au fichier robots.txt. On peut certes faire un fichier robots.txt à la main mais le lien est censé être absolu, donc ce n’est pas super propre de le mettre en dur.

Finalement je m’en suis sorti en ajoutant un fichier robots.html avec le contenu suivant :

---
layout: null
permalink: robots.txt
---

Sitemap: {{ site.url }}/sitemap.xml

La directive permalink: robots.txt permet de forcer le bon nom de fichier, layout: null dit que le contenu ne doit pas du tout être habillé et comme on est dans une page normale on a accès aux variables globales, notamment site.url.

Éviter la profusion d’espaces dans les pages

Le moteur de template de Jekyll fonctionne en ajoutant des pseudo-balises dans le code HTML notamment pour indiquer les structures de contrôles, boucles, affectations de variables, etc.

Pour que le code reste lisible on fait des retours à la ligne entre ces différentes balises et on indente. Ceci aboutit à de très nombreuses lignes uniquement peuplées d’espaces (ceux de l’indentation).

Exemple :

<h2>Catégories</h2>
{% assign groupedCategories = site.categories | group_categories %}
{% for group in groupedCategories %}
  <h3>{{ group[0] }}</h3>
  <ul>
    {% assign categories = group[1] | sort_by_keys %}
    {% for category in categories %}
      <li><a href="/categories/{{ category[0]|slugify:'latin' }}/">{{ category[0] }}</a> ({{ category[1].size }})</li>
    {% endfor %}
  </ul>
{% endfor %}

Il est possible d’y remédier en utilisant un caractère - dans les balises. Chaque - suivant une ouverture de balise ({% devient {%-) indique que les espaces précédents doivent être ignorés et sur les fermetures ( (%} devient -%})) que les espaces suivants doivent être ignorés.

L’exemple précédent devient alors :

<h2>Catégories</h2>
{%- assign groupedCategories = site.categories | group_categories -%}
{% for group in groupedCategories %}
  <h3>{{ group[0] }}</h3>
  <ul>
    {%- assign categories = group[1] | sort_by_keys -%}
    {% for category in categories %}
      <li><a href="/categories/{{ category[0]|slugify:'latin' }}/">{{ category[0] }}</a> ({{ category[1].size }})</li>
    {%- endfor %}
  </ul>
{% endfor %}

C’est la même syntaxe que l’on retrouve dans d’autres moteurs de templates comme Twig pour PHP (la plupart des syntaxes sont assez proches en fait entre ces deux moteurs).

Remarque : cette syntaxe semble ne pas bien fonctionner avec le tag endraw, en effet j’ai des erreurs dès que je place un tiret un en début de ce tag (alors qu’à la fin et sur le tag raw ça marche)…


JavaScript Debugger

Cet article est marqué comme contenant des informations dépassées depuis le 21/10/2018.
Cette extension n'existent plus, remplacée par les outils de développement natifs de Firefox.

Quand on a travaillé un peu sur des sites ou applications utilisant des JavaScript volumineux, on se rend compte assez vite que c'est laborieux. Les erreurs sont mal remontées, on n'a pas de stack trace, etc. Firefox est déjà largement au dessus d'Internet Explorer à ce niveau en fournissant une console d'erreur nettement plus lisible et fonctionnelle mais ça reste insuffisant sur des scripts complexes et fortement découpés en de nombreuses fonctions élémentaires.

Une solution au problème : JavaScript Debugger, une extension pour Firefox qui, comme son nom l'indique, implémente un débuggeur JavaScript.

JavaScript Debugger - fenêtre principale

Comme sur les débuggeurs disponibles pour les autres langages, on peut donc placer des point d'arrêt (breakpoint) permettant une exécution pas à pas du script, avec à chaque étape la possibilité d'inspecter toutes les variables définies et leurs valeurs. Ça ne résout pas tout mais ça aide grandement à comprendre ce qui arrive !

Malheureusement, cette extension est encore loin d'être parfaite : elle est assez lourde et ne se ferme pas toujours vraiment lorsqu'on ferme la fenêtre et même en fermant toutes les fenêtre Firefox, il arrive qu'il reste toujours une instance de Firefox qui traine dans les processus en cours et qu'il faut tuer à la main (sous Windows du moins, je ne l'ai pas testé sur un autre système).

Donc ce n'est pas parfait mais ça a le mérite de combler un gros manque, donc ça mérite le coup d'œil :)

Sinon, l'extension Firebug est censée fournir une partie de ces fonctionnalités également mais, jusqu'à présent, à chaque fois que j'ai tenté de l'installer elle m'a causé plus de problèmes qu'autre chose (instabilité du navigateur) donc je n'ai pas approfondi...