Python

En cherchant un outil d'Infrastructure as code pour Grafana, #JaiDécouvert Grizzly.

Un projet qui a débuté en mars 2020, développé en Go par l'équipe de Grafana.

A utility for managing Jsonnet dashboards against the Grafana API

J'ai parcouru l'intégralité de la documentation et je suis ravi, ce projet correspond parfaitement à ce que je cherchais depuis des années !

Avant de découvrir cet outil, j'écrivais des scripts Python ou Bash d'exportation et d'importation de dashboards via l'API de Grafana.

Je souhaite l'utiliser dans le Projet 14 - Script de base d'installation d'un serveur Ubuntu LTS. Dans le repository basic_ubuntu_server_install_playground.

En étudiant l'annonce Développeur(se) back-end en CDI de Brief.me j'ai été intrigué par :

Migrer notre front-end existant de Nuxt.js vers HTMX.

Je me suis demandé quelle est la motivation de passer d'un framework de type Nuxt.js, NextJS ou SvelteKit à htmx 🤔.

J'utilise SvelteKit depuis deux ans, qui est comparable Nuxt.js, principalement en mode SSR avec Hydration, et je suis totalement satisfait. Ma Developer eXperience est excellente. Je trouve ce framework minimaliste, conforme au principe Keep it simple, stupid! (KISS), et performant.

Après réflexion, j'ai réalisé que mon expérience de développeur (DX) serait moindre si j'héritais d'un backend codé dans un langage autre que Javascript : Python, PHP, Ruby, Golang…

Et Brief.me semble être dans ce cas de figure :

• Back-end : Django, PostgreSQL, RabbitMQ, Celery
• Front-end : HTMX
• Tests : pytest
• Infra : Platform.sh

Je me suis connecté à mon compte Brief.me et en regardant ce que me retourne Wappalyzer, je constate que le site est effectivement propulsé par Nuxt.js, VueJS.

En regardant ce qu'il se passe dans l'onglet Réseau de mon navigateur, je constate que https://app.brief.me est un site web de type SPA. Le contenu des articles est chargé via l'api https://www.brief.me/api/ qui est propulsée par Django REST framework.

Si je résume, la stack est la suivante : PostgreSQL => Django => Django REST framework <=> Nuxt.js => Rendu HTML via VueJS.

Je suppose que ce qui motive la migration de Nuxt.js vers HTMX est la suppression de couches.
Plus précisément, je suppose que l'équipe tech de Brief.me souhaite supprimer les couches suivantes :

• Django REST framework
• Nuxt.js
• VueJS

Et utiliser simplement le système de template de Django en SSR pour afficher le contenu des articles et implémenter les quelques éléments dynamiques côté browser avec HTMX.
De mon point de vue, ceci a pour avantage de largement simplifier la stack, de simplifier le déploiement et d'accélérer le chargement des pages.

Ma conclusion : la librairie HTMX semble être un choix très pertinent quand elle est utilisée dans une stack non NodeJS.

#JaiDécouvert Btree un équivalent à APScheduler en Python.

Bree is a Node.js and JavaScript job task scheduler with worker threads, cron, Date, and human syntax.

Je crois avoir commencé à utiliser APScheduler aux alentours de 2010. Cependant, depuis que j'ai pris la décision de me consacrer pleinement à Javascript, je prévois de le remplacer par Btree.

#JaiDécouvert dans cette issue une application web (GUI) pour Btree : https://github.com/mihai-vlc/bree-dashboard.

Pour l'exécution de scripts shell simples, j'utilise Supercronic, un outil développé en Golang que j'intègre dans mes images Docker.

En revanche, si mes besoins en orchestration deviennent trop complexes pour Btree, je pense que Temporal pourrait être une solution intéressante pour gérer des workflows avancés.

#JaiDécouvert et un peu étudié Temporal (workflow management).

D'après ce que j'ai compris, Temporal a été initialement développé par les auteurs (Maxim Fateev et Samar Abbas) de Cadence.

Je me souviens d'avoir étudié Cadence vers 2019. J'ai l'impression que ce projet est encore très actif. #JeMeDemande quelles sont les réelles différences entre Temporal et Cadence 🤔.

• Cadence Use cases
• Temporal features

Une première réponse à ma question :

• Temporal supporte les langages Go, Java, PHP, Python, TypeScript, dotNET alors que Cadence est limitée aux langages Go et Java.
• Cadence propose une UI nommée cadence-web qui semble plus minimaliste que temporalio/ui.

D'après ce que j'ai lu, Temporal est totalement open-source, sous licence MIT. L'entreprise Temporal propose une version hébergée (managée) nommée Temporal Cloud.

#JaiDécouvert un exemple de projet d'Order Management System codé en Go et basé sur Temporal : https://github.com/temporalio/reference-app-orders-go.
Je n'ai pas étudié le code source, mais c'est un sujet qui m'intéresse, étant donné que j'ai travaillé par le passé sur le développement d'un Order Management System 😉.

Je cherche depuis plusieurs années une solution pour surveiller la date d'expiration des noms de domaine en analysant le contenu de Whois.

#JaiDécouvert cet exporter Prometheus qui correspond exactement à mon besoin : https://github.com/shift/domain_exporter

En examinant l'historique du projet, je constate qu'il a été lancé en 2017. Il me semble pourtant avoir recherché ce type d'exporter en 2019 sans le trouver. Peut-être n'était-il pas encore assez mature à ce moment-là 🤔.

J'ai identifié aussi les projets suivants :

• https://github.com/casnerano/domain-exporter qui semble confidentiel et moins complet, peut-être un simple POC ;
• https://github.com/sorrowless/whois-exporter écrit en Python avec un seul commit... Peut-être que son auteur n'avait pas connaissance de https://github.com/shift/domain_exporter 🤔.

Pour le moment, je n'ai pas encore trouvé de dashboards Grafana pour cet exporter.

Alexandre m'a fait découvrir la fonctionnalité Compose Watch ajoutée en septembre 2023 dans la version 2.22.0 de docker compose.

Compose supports sharing a host directory inside service containers. Watch mode does not replace this functionality but exists as a companion specifically suited to developing in containers.

More importantly, watch allows for greater granularity than is practical with a bind mount. Watch rules let you ignore specific files or entire directories within the watched tree.

For example, in a JavaScript project, ignoring the node_modules/ directory has two benefits:

• Performance. File trees with many small files can cause high I/O load in some configurations

• Multi-platform. Compiled artifacts cannot be shared if the host OS or architecture is different to the container

  -- from

Je suis très heureux de l'introduction de cette fonctionnalité, même si je n'ai pas encore eu l'occasion de la tester. Bien que je trouve qu'elle arrive un peu tardivement 😉.

Je suis surpris d'observer que cette fonction a généré très peu de réaction sur Hacker News 🤔.

Je n'ai rien trouvé non plus sur Reddit, ni sur Lobster 🤔.

Sans doute pour cela que je n'ai pas vu la sortie de cette fonctionnalité.

Je pense avoir retrouvé la première Pull Request de la fonctionnalité compose watch : [ENV-44] introduce experimental watch command (skeletton) #10163.
Je constate que compose watch est basé sur fsnotify.
Je constate ici qu'un système de "debounce" est implémenté.
Je pense que c'est cette fonction qui effectue la copie des fichiers, mais je n'en suis pas certain et je ai mal compris son fonctionnement.

Entre 2015 et 2019, j'ai rencontré de nombreux problèmes de performance liés aux volumes de type "bind" sous MacOS (et probablement aussi sous MS Windows) :

volumes:
  - ./src/:/src/

Les performances étaient désastreuses pour les projets Javascript avec leurs node_modules volumineux. Exécuter des commandes telles que npm install ou npm run build prenait parfois 10 à 50 fois plus de temps que sur un système natif ! Je précise que ce problème de performance était inexistant sous GNU Linux.

Pour résoudre ce problème pour les utilisateurs de MacOS, j'ai exploré plusieurs stratégies de development environment, comme l'utilisation de Vagrant avec différentes méthodes de montage, dont certaines reposaient sur une approche similaire à celle de Compose Watch, c'est-à-dire la surveillance des fichiers (fsnotify…) et leur copie.

N'ayant trouvé aucune solution pleinement satisfaisante, j'ai finalement adopté la stratégie Asdf, puis Mise, qui me convient parfaitement aujourd'hui.

Cela signifie que, dans mes environnements de développement, je n'utilise plus Docker pour les services sur lesquels je développe, qu'ils soient implémentés en JavaScript, Python ou Golang...
En revanche, j'utilise toujours Docker pour les services complémentaires tels que PostgreSQL, Redis, Elasticsearch, etc.

Est-ce que la fonctionnalité Compose Watch remettra en question ma stratégie basée sur Mise ? Pour l'instant, je ne le pense pas, car je ne rencontre aucun inconvénient majeur avec ma configuration actuelle et l'expérience développeur (DX) est excellente.

Quel est mon rapport aux langages typés ?

Pour bien comprendre mon approche des langages typés, il est utile de revenir sur mon parcours.

Enfant, j'ai commencé par du Locomotive Basic (non typé), j'ai ensuite fait beaucoup de Turbo Pascal (typé) et un peu de C, C++ (typé).

À cette époque, je préférais les langages typés pour des raisons de performances.

En 2000, j'ai vraiment aimé utiliser à nouveau des langages non typés, comme PHP et surtout Python qui a été pendant très longtemps mon langage de prédilection.

J'ai à nouveau beaucoup pratiqué un langage typé de 2013 à 2018 : Golang.

Aujourd'hui, je considère qu'il est souvent plus facile et plus rapide de programmer dans un langage non typé, notamment grâce au Duck Typing. Cependant, je reconnais que les langages typés offrent des avantages indéniables, notamment en matière de refactoring de code.

Je pense qu'il est préférable d'utiliser un langage typé sur un projet critique.

Je pense qu'il est préférable d'utiliser un langage typé pour les programmes qui manipule des données complexes et divers.
C'est, par exemple, pour cela que ne suis pas un utilisateur de MongoDB. Je préfère une base de données PostgreSQL où tout est bien typé.

Il ne me viendrait pas à l'esprit d'implémenter une base de données ou un moteur web dans un langage non typé.

Par contre, je suis moins convaincu par l'utilisation d'un langage typé pour les applications d'interface utilisateur lourde ou web.

Lorsqu'une équipe de développement travaillant sur un code commun atteint une certaine taille — je n'ai aucune idée de ce nombre — je suis convaincu qu'il devient préférable d'utiliser un langage typé.

Les deux fois où j'ai essayé d'utiliser Jupyter pour réaliser, par exemple, une calculatrice financière, j'ai fini par constater que je ne trouve pas cet outil pratique. Après quelques heures, je retourne soit à un script Python classique, soit à la création d'une page web basée sur HTML et JavaScript, qui me donne bien plus de flexibilité que Jupyter.

Il est possible que ce soit parce que je connais mal Jupyter, mais j'y ai tout de même consacré plus de deux heures hier soir, explorant notamment les Jupyter Widgets (ipywidgets).

Après 11 mois de procrastination, j'ai enfin pris le temps de faire ce script https://github.com/stephane-klein/toggl-report-helper-script

Au départ, j'hésitais entre une implémentation en Python ou en JavaScript. J'ai finalement opté pour JavaScript, car cela correspond à ma nouvelle doctrine.

Même si Python reste le langage que j'affectionne profondément, que je trouve toujours aussi élégant, j'ai pris la décision de me consacrer pleinement à JavaScript.