Pourquoi et comment utiliser WakaTime pour monitorer ses habitudes de programmation¶
Concept ?¶
Un sportif peut chercher à surveiller précisément quel entraînement il pratique quotidiennement, quel muscle il développe etc.
Et bien, la même façon, les programmeurs et développeurs peuvent être intéressés par savoir sur quels projets ils passent le plus de temps, sur quels fichiers ou dossiers ils travaillent etc.
Pourquoi ?¶
Hum… en fait, la vraie raison semble purement liée à l’égo : les programmeurs sont fiers de voir tout le temps qu’il passe sur leurs projets.
Avertissement
Si vous êtes préoccupé-e par votre vie privée, vous devez plutôt utiliser un outil local unique tel que le grand ActivityWatch, qui offre un plugin « surveillant » votre activité, pour quelques éditeurs, y compris VSCode que j’utilise et conseille d’utiliser ! Les données restent locales et aucun espionnage n’est possible avec ActivityWatch.
À faire
Essayer les deux tout le mois d’avril, puis supprimer WakaTime si je suis content de ActivityWatch ?
Cette introduction étant faite, laissez-moi vous présenter un outil intéressant que j’utilise depuis quelque temps.
Comment ?¶
Le but de WakaTime est de proposer aux développeurs une façon simple, « sécurisée » et centralisée de surveiller le temps passé à programmer.
Et ils font ça bien, puisque WakaTime se présente sous trois formes :
une interface web, fort bien conçue, qui permet notamment de visualiser son activité,
une très grande collection de plugin, ces petits logiciels (aussi appelés greffons) que vous pouvez facilement ajouter à votre éditeur de texte favori,
et un moyen très facile d’intégrer certains graphiques sur un site web, un blog Twitter, Facebook etc.
Le concept est simple : votre éditeur de texte vous espionne, envois les données en ligne sur les serveurs de WakaTime, et ensuite vous (et les responsables du service, ainsi que la NSA bien-sûr) pouvez librement consulter ces données. Effrayant, non ?
Dans mon cas¶
Installation et utilisation de WakaTime¶
J’utilisais Sublime Text 3 de façon quasi exclusive durant 4 ans. Sans surprise, WakaTime propose un greffon pour Sublime Text 3, mon éditeur favori.
Il s’installe en deux clics, et s’intègre à la perfection (discret, charge système minimum, et il peut même accumuler les données et les envoit plus tard si l’ordinateur est déconnecté du réseau).
J’utilise désormais Visual Studio Code, et il y a bien sûr aussi une extension pour Wakatime qui s’installe rapidement aussi.
Aperçus des statistiques ?¶
Durant les 8 premiers jours (après avoir installé le greffon, en janvier 2015), j’étais en « mode » « développement intensif » pour conclure certains projets (StrapDown.js, MEC Students Face-Book demo etc), mais j’étais tout de même un peu effrayé de voir 29h d’activité en 8 jours !
Il est aussi possible de voir :
sur quels projets vous passez le plus de temps,
quels types de fichiers vous travaillez, jour par jour,
et même quels fichiers (cela peut être désactivé).
Par exemple, la première semaine, cela se répartissait selon : 30% HTML, 29% Python, 15% reStructuredText, 6% Bash, 12% Markdown.
Partager ces statistiques ?¶
Temps passé à programmer durant les 30 derniers jours¶
Ce premier graphique montre combien de temps je code chaque jour (environ) :
Langages utilisés durant les 30 derniers jours¶
Vous pouvez voir que j’utilise principalement Python et Bash, LaTeX et reStructuredText, et Markdown (ou HTML, si c’est une page utilisant StrapDown.js) :
Et depuis le début de mon utilisation de WakaTime :
Éditeurs de textes utilisés¶
WakaTime détecte que j’ai utilisé l’extraordinaire Visual Studio Code depuis 2018 et Sublime Text avant 2018, pour environ ~90% de mon temps d’écriture et de programmation quotidien, et Bash et PyCharm IDE pour les ~10% restant :
Note
WakaTime ne compte pas l’utilisation de GNU Nano, GNU Octave GUI, ou Spyder pour Python 2/3. Par contre, désormais ils proposent des greffons WakaTime pour Bash, Zsh et iTerm (terminaux) !
Partager les stats d’un projet en particulier¶
Il est aussi possible de partager les statistiques d’un projet en particulier, grâce à un lien spécifique, comme https://wakatime.com/@lbesson/projects/qdkkfmhcoi par exemple (correspondant à ce project).
Inclure un graphique via une iframe ?¶
Ci dessus est intégrée la page https://wakatime.com/@lbesson :
Note
En attendant de faire mieux…
J’aimerai trouver un moyen pour n’inclure que le graphique en camembert, et pas toute la page. Correction : Le 19 décembre (2015), j’ai reçu un courriel personnel de Alan Hamlet PDG et créateur de WakaTime, pour m’informer de la nouvelle fonctionnalité de partage de graphiques WakaTime. Les graphiques inclus ci-dessus sont de bons exemples de ce qu’apporte cette toute nouvelle fonctionnalité (que je trouve très cool !).
Aperçu complet de 2015¶
Environ 600 heures en tout en 2015, alors que la moyenne des utilisateurs de WakaTime était de 269h, la médiane à 193h (mais le max à 2342h !).
Une moyenne quotidienne de 2 heures 27 minutes en 2015, alors que la moyenne des utilisateurs de WakaTime était de 44 min, et la médiane à 31 min (mais le max à 6 h 25 min !).
Et pour le choix de langages, j’ai surtout utilisé Markdown (177 h), LaTeX (160 h), Python (151 h) et reStructuredText (85 h, et j’étais souvent 1er utilisateur de reStructuredText dans le tableau des utilisateurs les plus actifs sur WakaTime !); et les tous les autres langages sont à moins de 5h/an (Bash, OCaml, Octave/Matlab, HTML / CSS etc).
Aperçu complet de 2017¶
Comme en 2015, environ 600 heures en tout en 2017 (611h), alors que la moyenne des utilisateurs de WakaTime était de 249h (mais le max à 3468h !).
Une moyenne quotidienne de 2 heures 17 minutes en 2017, alors que la moyenne des utilisateurs de WakaTime était de 41 min (mais le max à 9 h 30 min, ce codeur doit être un grand passionné !).
J’ai codé à 100% sous GNU/Linux (fan de XUbuntu comme toujours), et 303h avec Sublime Text, 282h avec Visual Studio Code et 45h avec PyCharm. GNU Nano, Firefox et Jupyter ne sont pas comptés (mais uLogMe me dit que je n’y passe pas beaucoup de temps de toute façon).
Projets par projets, j’ai codé 266h pour ce projet pour ma thèse (SMPyBandits), 48h pour cet article, 41h pour ma thèse en général, 38h pour mes slides, 20h pour ce site web, 17h pour mes scripts et configuration Bash, 10h pour mon blog de cuisine, 9h pour mes notebooks (mais ça ne compte pas le temps passé dans Jupyter), et moins de 8h pour tous les autres projets.
Et pour le choix de langages, j’ai surtout utilisé Python (277 h), Markdown (107 h), LaTeX (135 h), et reStructuredText (28 h); et les tous les autres langages sont à moins de 5h/an (Bash, OCaml, Octave/Matlab, HTML / CSS etc).
Aperçu complet de 2018¶
Un peu moins qu’en 2017 j’ai codé environ 600 heures en tout en 2018 (587h), alors que la moyenne des utilisateurs de WakaTime était de 320h (ça a augmenté depuis les premières années !).
Une moyenne quotidienne très stable, à 2 heures 18 minutes en 2018, alors que la moyenne des utilisateurs de WakaTime était de 52 minutes (aussi augmenté !).
Mon jour le plus intense a été le 10 octobre 2018, avec 10 heures 50. Je pense que c’était pour terminer ces deux articles là, HAL-02049824 et HAL-02006825 !
J’ai codé à 100% sous GNU/Linux (fan de XUbuntu comme toujours), et 100% avec Visual Studio Code. GNU Nano, Firefox et Jupyter ne sont pas comptés (mais uLogMe me dit que j’y passe moins de temps de toute façon, quoique j’ai utilisé Jupyter beaucoup plus en 2018, avec ces deux projets ParcourSup.py et notebooks).
Projets par projets, j’ai codé 171h pour ce projet pour ma thèse (SMPyBandits), 76h pour le code LaTeX de ce long article, 21h pour mes slides, 10h pour ce site web, 15h pour mes scripts et configuration Bash, 10h pour mon blog de cuisine.
Quelques projets m’ont aussi beaucoup occupé : fontify avec 21h en mars 2018, ParcourSup.py avec 28h en juin et juillet 2018 (sans compter le temps dans Jupyter), la chasse aux trésors pour mes 25 ans avec 6h en février 2018, etc
Je note aussi environ 16h pour mon blogue « zéro déchet » et 17h pour mon blogue de cuisine, environ 16h pour mon CV (mis à jour et traduit en novembre 2018) et moins de 15h pour tous les autres projets.
Et pour le choix de langages, j’ai surtout utilisé Python (217 h), Markdown (115 h), LaTeX (175 h), et reStructuredText (13 h), Bash (11h), CSS (8h); et les tous les autres langages sont à moins de 5h/an (Bash, OCaml, Octave/Matlab, HTML / CSS etc).
Aperçu complet de 2019¶
Un peu moins qu’en 2018 j’ai codé environ 500 heures en tout en 2019 (508h), alors que la moyenne des utilisateurs de WakaTime était de 289h.
Une moyenne quotidienne très stable, à 2 heures 15 minutes en 2019, alors que la moyenne des utilisateurs de WakaTime était de 47 minutes.
Mon jour le plus intense a été le 28 janvier 2019, avec 8h 58 minutes. Je pense que c’était pour terminer cet article, HAL-02006471!
J’ai codé à 100% sous GNU/Linux (fan de XUbuntu comme toujours), et 100% avec Visual Studio Code. GNU Nano, Firefox et Jupyter ne sont pas comptés (mais uLogMe me dit que j’y passe moins de temps de toute façon, quoique j’ai utilisé Jupyter beaucoup plus en 2019, avec ces deux projets ALGO1-Info1-2019 et notebooks).
Projets par projets, j’ai codé 226h pour ma thèse de doctorat, 63h pour ce projet pour ma thèse (SMPyBandits), 58h pour mes slides.
Et pour le choix de langages, j’ai surtout utilisé LaTeX (363 h), Python (77 h), Markdown (29 h); et les tous les autres langages sont à moins de 5h/an (Bash, OCaml, Octave/Matlab, HTML / CSS etc).
Aperçu complet de 2020¶
Beaucoup moins qu’en 2018, j’ai codé environ 128 heures en tout en 2020, alors que la moyenne des utilisateurs de WakaTime était de 313h (en hausse). J’explique cette grosse baisse par le fait que a) je n’ai quasiment plus écrit d’articles et je n’avais pas ma thèse à rédiger ! b) je ne suis plus en développement actif d’un gros projet (comme je l’étais les années précédentes avec notamment SMPyBandits, c) je n’ai quasiment pas eu besoin de rédiger ni slides, ni notebooks, d) la plupart de mon matériel d’enseignement était déjà prêt ou quasiment prêt, e) je code quand même, mais assez souvent pour des petites modifications j’utilise GNU Nano dans un terminal, ou Python dans un notebook Jupyter (et donc ça n’est pas compté par WakaTime), f) pour un cours (INF1 en L1 à l’Université Rennes 1), il m’a fallu utiliser Eclipse et je n’avais pas pensé à installer le plug-in WakaTime.
Une moyenne quotidienne très diminuée, à 1 heures 2 minutes en 2020, alors que la moyenne des utilisateurs de WakaTime était de 51 minutes (donc je code quand même plus que la moyenne ? intéressant !).
Mon jour le plus intense a été le 4 novembre 2020, avec 5h 30 minutes (en grosse baisse des jours intenses des années précédentes). Je ne sais plus pour quoi c’était, mais sûrement un peu un mélange des projets suivants : Discord-bot-to-add-spoiler-to-any-code-snippet, Generateur-attestation-de-sortie-automatique-COVID-19-confinement-en-France.
Comme toujours, j’ai codé à 100% sous GNU/Linux (fan de XUbuntu comme toujours), et 100% avec Visual Studio Code… du moins c’est ce que croit WakaTime ! WakaTime ne détecte pas l’utilisation de GNU Nano, Firefox et Jupyter.
Projets par projets, j’ai codé 26h de LaTeX et de Java pour ce cours INF1 en L1 à l’Université Rennes 1, pour rédiger et mettre à jour des sujets de TD/TP/projets/exam et corrections. J’ai aussi travaillé environ 20h pour cette carte (surtout pour expérimenter des trucs), et moins de 10h dans tous les autres projets.
Et pour le choix de langages, cette année j’ai surtout utilisé Markdown (53 h), LaTeX (30 h) et Java et Python à égalité avec 13h chacun (sur VSCode, en comptant Eclipse et Jupyter notebooks, je dois avoir trois fois plus au moins) ; et les tous les autres langages sont à moins de 5h/an (Bash, OCaml, JavaScript, HTML / CSS etc). Mais c’est assez injuste envers ces langages, comme j’écris beaucoup de scripts Bash en une ligne dans un terminal, que j’utilise souvent GNU Nano pour éditer des scripts Bash, et des notebooks Jupyter pour Python et aussi OCaml, etc.
Bref aperçu de mon temps de programmation depuis 2015¶
Apparemment, en octobre 2018, j’avais accumulé plus de 2529 heures de statistiques de programmation depuis 3 ans et demi (janvier 2015). C’est beaucoup ! En plus de 10+3*12=46 mois, j’ai vécu environ 33 120 heures, et dormi environ 10 000 heures. Ainsi, 2500 heures de programmation représentent environ 7% de ma vie et environ 11% de ma vie éveillée. J’ai passé 11% de ma vie à coder. C’est beaucoup, je pense (ça ne compte pas seulement les heures de bureau, mais TOUTE MA VIE depuis 3 ans). Ohlala…
Petit interlude (de XKCD.com)¶
Un bonus : accéder aux statistiques en ligne de commande¶
Il est facile d’installer l’outil WakaTimeCLI,
avec la commande npm install wakatimecli
.
Cet outil en ligne de commande se base sur cette API, et devrait être facile à utiliser. La première commande est wakatime -help qui montre les différentes options acceptées par cet outil :
Please pass an option:
-? or -help
-u or -user
-t or -today
-y or -yesterday
-w or -week
L’aide (wakatime -help
) n’est pas très bien écrite, mais on peut deviner son utilisation ici directement dans son code source.
Note
Cet outil produit une sortie en couleur, cool !
C’est moins cool lorsqu’on s’aperçoit que les couleurs sont ne sont pas supprimée si la sortie est redirigée vers un terminal qui n’accepte pas les codes ANSI, ou un fichier (c’est pas la faute au script mais au module cli-color qui aurait du implémenter une meilleure méthode de détection, comme je l’avais fait pour ANSIColors il y a quelques années)).
Comme l’explique cette remarque sur stackoverflow, ce n’est pas une bonne pratique. (J’ai demandé via le dépôt GitHub pour WakaTimeCLI de régler ce problème)
Merci à cette astuce à coup de sed (` | sed -r « s:\x1B\[[0-9;]\*[mK]::g »`).
Ensuite, il faut ajouter votre clé API Key (disponible dans les réglages sur WakaTime.com) :
wakatime -api yourApiKeyHere
Par exemple, la commande wakatime -w donne le temps total passé sur son (ses) éditeur(s) de code durant les 7 derniers jours.
Avertissement
Cet outil semble cassé, cf ce bug (25/01/2021).
Un autre outil pour lire ses statistiques WakaTime en ligne de commande : client wakatime Python officiel¶
En utilisant pip install wakatime, on installe le client CLI officiel, qui est ce projet sur Pypi.
Il ne permet aucune autre visualisation que cette option –today, c’est assez décevant.