Le panneau de debug de Loomiz

Publié le 17 avr 07 à 07:04 | Catégorie : Développement Web | 19 commentaires

La semaine dernière, j’ai eu l’occasion de retravailler sur le panneau de Loomiz qui contient des informations très utiles pour son développement. Même si vous avez déjà eu l’occasion de l’apercevoir, je voulais revenir un peu plus en détail dessus, sachant que cela intéresserait sûrement quelques lecteurs qui comme moi sont en train de concevoir une application web.

Ce panneau de débogage (comme on dit en français) est situé en bas de chaque page du site. Il s’active à la demande et n’est disponible que lorsque l’application est exécutée sur un serveur local. Cette contrainte existe pour des raisons évidentes de sécurité, ce panneau prodiguant de nombreuses informations à propos du site qui pourraient être utilisées contre lui-même.

Grâce à ce panneau, je dispose par exemple des valeurs des paramètres de la requête HTTP qui vient d’être effectuée (en fonction de la méthode utilisée) :

Php variables

Ce panneau me donne également accès au contenu de la session courante, aux cookies et aux en-têtes retournés avec la réponse.

Un autre aspect important concerne les requêtes effectuées auprès de la base de données. Heureusement, le framework sur lequel est basé Loomiz dispose de l’infrastructure nécessaire pour récupérer facilement ces requêtes. Il ne reste plus ensuite qu’à mettre en forme ces résultats :

Requêtes à la base de données

Les différentes erreurs Php sont redirigées dans un fichier qui ne dépend pas du serveur, mais de l’application elle-même. De cette manière, il est possible d’exploiter et d’afficher son contenu, en mettant en valeur les erreurs les plus importantes :

Messages d'erreur de Php

En cliquant sur le nom du fichier qui a généré une erreur, j’accède alors à son code source dans une nouvelle fenêtre et à la ligne qui pose problème :

Affichage du contenu d'un fichier Php

Les messages d’erreur ou de notification de l’application sont disponibles dans une section à part :

Messages applicatifs

La pile d’appels des fonctions, ainsi que les variables d’environnement et du serveur sont accessibles à travers ce panneau. Il sert également de réceptacle lorsque je veux obtenir le contenu d’une variable bien précise au sein du code de Loomiz (dump en anglais).

Ce panneau évolue petit à petit en fonction de mes besoins et me permet de minimiser au mieux le temps passé à investiguer et à corriger les erreurs (et il y en a toujours). L’idée est de centraliser en un point unique et surtout accessible toutes les informations qui pourraient m’aider à élucider un problème et à comprendre comment réagit l’application. Il fait très clairement partie des bonnes pratiques de développement qu’il vaut mieux adopter le plus tôt possible. Mais peut-être en avez-vous d’autres ?

A lire également

Les visiteurs qui ont vu cette page ont consulté ensuite :

A savoir

La rédaction de cet article a nécessité 1 heure et 7 minutes. Si vous le souhaitez, vous pouvez être prévenu de la parution de nouveaux articles en vous abonnant par RSS ou par email.


19 commentaires à propos de “Le panneau de debug de Loomiz” :

  1. Désolé… il est trop tôt le matin pour te pondre un article (à ma façon) ;-). Une chose à dire, TU M’IMPRESSIONNE de plus en plus, chaque jours !
    Vraiment super cet outil !
    Je reviens plus tard pour répondre plus clairement à ce superbe article !!!
    A++

  2. Trés beau debug panel ! J’ai juste une question : pourquoi avoir développé ton propre outil de débogage ? Les outils existants ne sont peut-être pas intégrés comme le tien, mais le jeu en vaut-il la chandelle ? Eclipse et PDT (que tu utilises je crois) offrent déjà de quoi faire et l’interface peut être testée avec Firebug. Il existe d’autres outils pour les requêtes SQL. Cela n’enlève rien à ton travail remarquable, mais c’est juste que le temps, c’est de l’argent !

    Autre point : quid des tests unitaires ? Ce qui serait intéressant, c’est d’ajouter la gestion de tes tests unitaires dans ton debug panel. Là, je comprendrais que celui-ci devienne indispensable.

    Bravo pour ce joli travail et pour ton blog en général qui est une source d’informations de qualité.

  3. Magnifique Debug panel ! Tu as du y passer pas mal de temps…
    Perso j’utilise plutôt des outils externes qui me permettent d’obtenir toutes les infos que je souhaite :
    - Firebug pour contrôler toutes les requêtes au serveur, le code html, css et javascript. Indispensable !
    - Xdebug, une extension php qui permet de garder un log de toutes les requêtes. Chaque log, facilement visualisable grâce à WinCacheGrind, contient un récapitulatif de toutes les fonctions et classes appelées (natives ou non), avec leur temps d’exécution, nombre d’appels….etc. C’est très utile pour optimiser son code. De plus cette extension offre pas mal de fonctions comme un var_dump amélioré (coloration syntaxique), des fonctions de benchmark…
    Mais je ne pense pas avoir besoin d’un Debug panel exactement adapté à mon projet, car ce serait long à développer, pour un enjeu trop petit.
    En tout cas bravo à toi ;-)

  4. Waho, alors là magnifique!! En tant qu’ apprenti Webmaster (licence Webmaster ^^), je bosse sur mon projet de fin d’année et les pertes de temps dues à des bugs sont énormes!!! Je suis impressionné par ton panneau de débug!!

    J’utilise déja firebug pour mes requètes Ajax, mais Xdebug dont parle Skreo semble vraiment pas mal, je vais me pencher dessus!!

  5. Je me joins à toute l’assemblée pour applaudir des deux mains. Ce debug panel m’a l’air fort utile et bien pratique.

    Cela dit, s’il faut donner des exemples de bonne pratiques de codage, j’ai érigé celle ci au rang de principe directeur :
    “D’erreur de codage, tu ne commettra point !”

    Pas d’erreur = pas de paneau de débugage ;)

    ok, je sors —-> []

  6. Bravo superbe boulot !
    La ou tu vois la ligne de code php ou il y a une erreur, tu peux editer ton fichier php et le modifier ?

  7. Christophe, Skreo : pour répondre à vos interrogations, j’ai développé au départ ce panneau pour avoir accès aux paramètres d’une requête et surtout au contenu des objets servant à générer la page (le modèle donc, puisque Loomiz a été conçu autour d’une architecture MVC). Et une fois ce travail effectué, il s’est vite étoffé d’informations supplémentaires comme la session, les cookies ou les variables d’environnement, car ces données sont très faciles à récupérer en Php.

    J’utilise d’ailleurs les librairies dBug et occasionnellement HLI que je recommande chaudement pour afficher le contenu des variables ou des objets (ce sont des dumps de luxe).

    Cette première phase n’a pas demandé beaucoup de temps, mais d’autres sections sont venues se greffer sur ce panneau ensuite. Je pense en premier lieu aux requêtes effectuées auprès de la base de données. En Java, on dispose d’outils comme P6Spy qui permettent d’espionner ces requêtes. Comme je n’ai pas trouvé d’équivalent en Php, j’ai opté pour le profiler disponible dans Zend Framework, l’infrastructure logicielle sur laquelle est basé Loomiz. C’est ce composant qui me liste les commandes envoyées ainsi que le temps d’exécution. Cette section est pour moi une des plus importantes de ce panneau, car je sais exactement ce qui se passe avec la base de données à tout moment.

    Les logs applicatifs sont moyennement pertinents ici, puisqu’ils sont de toute manière enregistrés dans un fichier de log. Mais je les ai rajouté car ils deviennent vraiment intéressants lorsque l’application tourne sur un serveur distant et qu’il faut alors effectuer plusieurs manipulations pour récupérer ce fichier.

    Les messages d’erreur Php suivent la même logique, à la différence près que je n’avais pas accès au fichier de log correspondant sur le serveur mutualisé que j’utilise pour les tests (mais j’ai trouvé ensuite comment en créer un propre à l’application et non au serveur).

    J’ai rajouté la pile d’appel des fonctions, car Php me permet d’y accéder très facilement et que j’avais déjà tout le code nécessaire pour afficher ces informations. Je reconnais par contre volontiers que je n’étais pas obligé de rajouter la fonction qui permet de voir le contenu des fichiers source…

    Il est évident que certaines des fonctionnalités proposées par ce panneau sont accessibles depuis des plugins Firefox (je pense notamment à UrlParams, Live HTTP Headers ou View Cookies). Mais l’idée est vraiment de disposer en un point central des informations les plus utiles au développeur, plutôt que d’avoir à basculer sur un ou plusieurs outils disparates (qu’il faut également installer et configurer). En minimisant les aller-retours, on améliore le processus de développement. Ce panneau a nécessité un certain temps pour sa réalisation, mais je ne le regrette absolument pas, car c’est un bon investissement (et encore je travaille seul, la plus value de ce panneau en équipe étant bien plus importante encore).

    Maintenant, la recommandation de Thibault est probablement la meilleure stratégie à adopter…

    J’utilise Eclipse (avec PDT) et Aptana pour l’édition. Le debugger est difficile à mettre en oeuvre et me fait regretter amèrement Eclipse version Java et le remote debugging. Firebug est indispensable pour la partie ‘présentation’. Je ne sais même pas comment je faisais avant.

    En ce qui concerne les tests unitaires, je n’en ai pas encore implémenté (mais ça ne devrait plus tarder). Par contre, si vous avez en effet des outils à me conseiller pour espionner des requêtes SQL ou pour analyser les erreurs d’un fichier de log Apache (quelque chose comme Chainsaw par exemple), je suis preneur !

    Sinon pour répondre à Falken80, non je ne peux pas éditer le fichier directement en ligne. Je crois que je préfère encore Eclipse ;).

  8. As-tu déjà essayé PHPEdit comme IDE ?
    Perso, c’est ce que j’utilise, et franchement, je ne pense pas pouvoir utiliser autre chose à l’avenir.

    Il dispose notamment d’un débugger qui s’avère de plus en plus complet comme le montre ces screenshots.
    http://www.waterproof.fr/produ.....shots8.php

    Une partie des outils que tu as développé sont déjà intégrés à cet outil. Peut être que son utilisation t’aurait fait gagner du temps (ce qui est non négligeable dans ta situation de jeune entrepreneur).

    Au delà de çà, auto complétion, jump vers un déclaration d’une méthode ou d’une fonction dans un fichier externe, code beautifier, code browser et j’en passe.
    Bref, un petit bijou qui a bien évolué et qui a gagné en stabilité.

    En plus, c’est une boîte française qui fait çà et le prix de licence est largement raisonnable . Une raison de plus de faire un peu de pub à un outil toujours plus complet.

  9. La vache, qu’elle usine ! Mais çà sera surement trés pratique quand Loomiz crévera l’écran ;)

    Sinon, pour les expériences des profils LiFE-LiNE, j’inaugure une nouvelle approche (pour moi) ; il n’y aura pas un tableau de bord “unique” pour centraliser les logs, erreurs, et notifications. Mais un debuggeur intégré sur chaques profils et accessible par l’internaute… La raison ? Il y a trop de parametres exterieurs qui perturbe le fonctionnement, et du coup beaucoup de notifications pour un seul profil. Et dans la pratique, je fais les debuggages en m’occupant d’un seul profil à la fois.

    Techniquement, çà sera une liste, cachée par un CSS, qui contiendra les notifications coté serveur et des notifications de l’interface en Javascript coté navigateur… Enfin, un lien en bas de page permettra d’afficher la liste.
    Evidemment, il peut y avoir des pb qui bloque tout le système, mais les plus nombreux pb à resoudre pour moi sont sans incidence sur l’affichage fonctionnel de la page.

  10. “Olivier D. alias ze kat” : en ce qui concerne les performances, tu ne penses pas que remonter les traces tout le temps va les pénaliser ?

    j’avais trouvé un très bon script, pour remonter les exceptions javascritps sur le serveur.
    http://usabletype.com/weblog/rslog/

    A tester, perso je trouve ça assez bon pour les périodes de lancement pour ainsi corriger les derniers bugs génants sur plateforme exotique

  11. J’avais jeté un coup d’oeil à PHPEdit Tijuan, mais lorsque je me suis lancé sur le développement de Loomiz, je voulais vraiment utiliser en priorité des outils gratuits pour minimiser mes frais. Car il existe des alternatives, bien qu’imparfaites, à ces éditeurs payants. Je n’aurais certainement pas eu cette démarche si j’avais eu suffisamment de fonds, d’autant plus que l’auto-complétion d’Eclipse PDT laisse franchement à désirer ;).

    Il est super ce script John Smith, merci pour le lien !

  12. Salut Stéphane,
    Encore une fois, ton boulot m’impressionne :)
    J’essaie de développer une interface de débug similaire à la tienne, j’ai découvert Xdebug et dBug qui sont effectivement intéressants. Mais plutôt que de réinventer la roue, je me demandais si tes sources n’étaient pas disponibles ?

  13. Hello Sylvain. Non, les sources ne sont pas disponibles et difficilement utilisables en tant que telles (car fortement imbriquées dans le framework de Loomiz). Mais j’aimerais bien les retravailler pour en faire une librairie indépendante.

  14. salut, même si ce post est relativement vieux, as tu un éclaircissement stéphane sur la manière d’accéder à la pile d’appel avec php ? (à part avec les exceptions de PHP5 je vois pas trop comment tu as fais ca …)

  15. J’ai utilisé la fonction debug_backtrace Antoine.

  16. Merci, y’en a tellement des fonctions dans PHP … que je n’étais jamais tombé sur celle ci, mais elle va bien me servir !!!

  17. salut et félicitation pour ton projet. J’essai d’utiliser Eclipse PDT, mais je n’arrive justement pas à faire fonctionner mes points d’arrêts. T’aurai pas un tuyau ?

  18. Hello Tanebisse. Non, là, comme ça, je ne vois pas trop ce qui pose problème. Ceci dit, j’ai rencontré énormément de difficultés pour mettre en place le debugging avec Php. Pour information, j’ai installé le package complet de PDT qui inclut Eclipse, car je n’ai pas réussi à faire fonctionner ce plugin en le rajoutant à la version d’Eclipse que j’utilisais avant.

  19. J’ai fait de même, j’ai installé le package complet mais rien. Par contre je viens de réussir à faire fonctionner le debugger DBG avec Eclipse 3.1

Ajouter un commentaire

Les informations obligatoires sont indiquées par une étoile rouge *.



Par contre, il y a encore des trucs qui ne marchent pas. Par exemple il a compris 'DesignS' au lieu de 'Design'.

Articles Récents

Les derniers articles publiés

A Propos

Je m’appelle Stéphane Thomas et je suis Ingénieur Senior expert dans le développement d'applications web complexes. Etant également un peu Entrepreneur, j'ai tenté l'aventure de la création d'un nouveau service Internet appelé Loomiz. Je suis maintenant le cofondateur d'Hitomi Studio, un studio de développement spécialisé dans la réalisation de sites ecommerce haut de gamme pour de jolies marques.

Lire la suite…