La fonctionnalité "Activité" de GitLab me manque dans GitHub.

Voici trois exemples concrets de fonctionnement de cette fonctionnalité, dans trois contextes différents.

Le premier, dans le projet GNOME Shell :

Le second, dans le groupe Wayland : https://gitlab.freedesktop.org/groups/wayland/-/activity

Et le troisième, pour l'utilisateur Lucas Stach: https://gitlab.freedesktop.org/users/lynxeye/activity

Je trouve cette fonctionnalité très utile quand on travaille sur un projet. Elle permet d'avoir une vue d'ensemble de ce qui s'est passé sur un projet sur une période. Elle vient en complément de l'historique Git qui est limité aux changements effectués sur le code source.

Dans certaines situations, je sais qu'un collègue travaille sur un sujet qui me concerne et la fonctionnalité "Activité" me permet de mieux comprendre où il en est, de suivre facilement ce qu'il fait.

Cette fonctionnalité "Activité" permet de pratiquer la stigmergie.

J'utilise aussi cette fonctionnalité lors de la rédaction d'un rapport d'activité ou d'un message de Daily Scrum. Elle m'aide à retrouver précisément ce que j'ai fait dernièrement.

Je trouve la page "Contribution activity" d'un user GitHub limité, par exemple, elle ne contient pas l'historique des commentaires.

Même chose au niveau d'un projet, dans la page "Pulse", par exemple : https://github.com/sveltejs/kit/pulse.

Je viens de regarder du côté de Codeberg / Forgejo : <https://codeberg.org/forgejo/forgejo/activity. Même constat que pour GitHub, les informations sont très réduites.

Je découvre une nouvelle limitation de Hasura par rapport à PostGraphile.

Hasura permet d'exécuter des fonctions PostgreSQL seulement si leur type de retour est une table. De plus, cette table doit être tracked par Hasura.

Return type: MUST be SETOF <table-name> OR <table-name> where <table-name> is already tracked.

Return type workaround: If the required SETOF table doesn't already exist or your function needs to return a custom type i.e. row set, you can create and track an empty table with the required schema to support the function.

-- from

D'autre part, Hasura doit avoir des permissions d'accès à cette table utilisée en retour de fonction.

Par exemple, Hasura ne supporte pas ce type de configuration :

REVOKE ALL PRIVILEGES ON TABLE foobar FROM hasurauser;

CREATE FUNCTION myfunction() RETURNS SETOF foobar
LANGUAGE sql VOLATILE SECURITY DEFINER
AS $$
     SELECT * FROM foobar
$$;

Cette limitation, parmi d'autres, renforce ma préférence pour PostGraphile plutôt que Hasura dans un contexte d'utilisation avec PostgreSQL — PostGraphile supporte uniquement PostgreSQL.

Je viens de voir à nouveau un badge Website Carbon Calculator sur un site.

Ce type d'initiative me dérange, parce que je considère la méthode de calcul comme non rigoureuse.

Quelques exemples :

• Elle semble ne pas prendre en compte la consommation du device côté client (smartphone, desktop…) ;
• Elle semble ne pas prendre en compte la charge cotée serveur.

Je pense que les personnes qui intègrent ce type de badge sur leur site sont dans une démarche de Greenwashing. Je pense qu'elles ne maitrisent pas le sujet.

Le projet Lighthouse est bien plus honnête dans sa démarche. N'étant pas en mesure de donner des mesures rigoureuses, il semble avoir abandonné ce projet : 🍃 adding environment protection KPI and audits (like CO2 footprint)

Pour fournir une information plus rigoureuse, je pense qu'il serait possible d'agréger les statistiques de consommation via PowerTOP de tous les serveurs qui servent à héberger le site web, croiser cette information avec les statistiques de visites tout en prenant en compte les caractéristiques énergétiques du data center.

Mais, tout cela est très compliqué.

En attendant, je pense qu'il est bien plus honnête de simplement intégrer un badge Lighthouse qui prends en compte les paramètres suivants :

• la taille de la page et de ses dépendances ;
• la complexité de rendu de la page.

Plus la note Lighthouse est élevée, moins le site web consomme d'énergie, à conditions égales.

Exemple : https://sklein.xyz/reports/report.html

Voir aussi : co2.js.

#Jadore le projet shadcn-svelte. Je trouve l'expérience développeur (DX) excellente ❤️.

Depuis le début des années 2000, j'éprouve une certaine aversion dès que je suis confronté à une technologie basée sur Java. Pourquoi ? Parce que, à tort ou à raison, j'ai remarqué que les applications Java sont souvent très longues à démarrer et consomment une quantité excessive de RAM.

Je pense par exemple à Logstash, dont la lenteur était insupportable, que j'ai fini par remplacer d'abord par Fluentd, puis par Vector.

Je pense également à Eclipse IDE.

Et bien sûr, aux serveurs Jakarta EE.

Voici un extrait de l'article Turbo 8 is dropping TypeScript de David Heinemeier Hansson (DHH de Basecamp) :

This isn't a plea to convert anyone of anything, though. As I discussed in Programming types and mindsets, very few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.

Je trouve ce point de vue intéressant.

Voir aussi : TypeScript

La partie que je préfère de plus dans le framework SvelteKit ce sont les fonctionnalités décrient dans la section Routing et Advanced routing de la documentation de SvelteKit.

Si vous survolez ces pages de documentation, vous allez peut-être me poser la question « ok et alors, c'est quoi le truc cool ? ». Je ne vais pas vous répondre maintenant, parce que c'est intégralité de ces deux pages de documentations qui faut lire avec une très grande attention. En utilisant SvelteKit dans plusieurs projets, j'ai appris à découvrir toutes les petites subtilités du système de rooting de SvelteKit.

#JaimeraisUnJour prendre le temps de paraphraser avec mes mots cette documentation pour partager avec vous l'enthousiasme que j'ai à l'égard de SvelteKit.

Est-ce que Nuxt ou NextJS sont moins élégants que SvelteKit ? Pour le moment, je ne sais pas, je n'ai pas pris assez de temps pour pousser assez loin la comparaison. C'est l'objectif de Projet - 2 "Réaliser un petit projet basé sur NextJS pour le comparer avec SvelteKit".

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.