PHP

Journaux liées à cette note :

Pourquoi faire un refactoring de Nuxt.js vers HTMX ? 🤔 #WebDev, #htmx, #django, #Nuxt, #SvelteKit

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 :

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 :

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.

J'ai découvert Decidim et Cap Collectif, deux logiciels open-source de prise de décisions pour les collectivités #vidéo, #JaiDécouvert, #livre, #closed

Dans la #vidéo "Table ronde sur la mutualisation - Congrès ADULLACT 2024" #JaiDécouvert Decidim.

"Decidim" est un mot catalan qui signifie "Nous décidons".

Je découvre que ce projet a commencé en 2016 et qu'il est plutôt actif.

Decidim.barcelona, le premier site web propulsé par Decidim, a été lancé le 31 janvier 2016 par la ville de Barcelone peu après l'élection d'Ada Colau pour coconstruire le plan d'action municipale de la Mairie de Barcelone pour la période 2016-2019.

#JaiDécouvert un autre outil de prise de décision nommé Consul Democracy :

La première version du site s'est basée sur le logiciel libre Consul, développé par la Mairie de Madrid, dans le cadre de la collaboration intermunicipale entre les gouvernements de "Maintenant Madrid" et Barcelone en Comú constitués après les élections municipales de 2015 et des collectifs activistes liés au Mouvement 15-M. En 2017, Decidim se lance comme projet indépendant en repartant d'une base de code réécrite depuis 0 et commence à se déployer dans d'autres villes.

Le projet Decidim a publié un #livre en accès libre nommé Decidim, a Technopolitical Network for Participatory Democracy.

Je lis :

En France, l'outil Decidim est utilisé par de nombreuses municipalités telles que Lyon, Rouen, Toulouse, Brest ou Chambéry.

En 2021, l'outil a été utilisé lors d'une consultation citoyenne sur la sortie de l’Alsace du Grand Est. L'entreprise Open Source Politics, qui a géré le vote en ligne reconnait cependant un certain nombre de dysfonctionnements.

-- from

Voici les liens vers quelques instances Decidim de collectivités françaises ou de services publics :

J'ai l'impression que Rouen n'utilise pas ou plus Decidim, Wappalyzer https://jeparticipe.metropole-rouen-normandie.fr est codé en PHP.

En faisant ces recherches sur la ville de Brest, j'ai trouvé un autre gros concurrent à Decidim : Cap Collectif.

Cap Collectif est un autre logiciel de prise de décision, celui-ci est codé en PHP, voici le repository du projet : https://github.com/cap-collectif/cap-collectif. Ce projet semble avoir débuté en 2015, principalement par Aurélien David, qui semble avoir quitté le projet. Depuis, le projet semble beaucoup moins actif.

Voici quelques instances de Cap Collectif :

L'Université Paris 8 utilise un autre outil de prise de décision nommé id City qui est #closed-source .

Journal du vendredi 20 septembre 2024 à 10:25 #WorkflowManagement, #EventDriven, #cron, #scheduling, #queue, #StateMachine, #JaiDécouvert, #JeMeDemande

#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 🤔.

Une première réponse à ma question :

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 😉.

Journal du lundi 12 août 2024 à 13:25 #coding, #software-engineering, #typescript

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é.