C'est similaire de mon côté: un lecteur de flux RSS, un shaarli, et un tag "aConsulterPlusTard" et pas de reste en revanche. Sebsauvage va plus loin avec son propre wiki et la liseuse pour de longues lectures.

#futurBilletDeBlog

Réalisé par l'Arcep, il regroupe des critères formulés en questions sur des thématiques. Le critère est accompagné d'un niveau d'impact et d'une fiche pratique est associé afin de mettre en oeuvre et de tester ledit critère.

les auteurs soutiennent qu’on ne peut pas espèrer qu’une numérisation-as-usual va, par défaut, dans le sens des enjeux de transition, à l’opposé de ce que suggèrent d’autres rapports européens, comme les twin transitions du Joint Research Center de la Commission Européenne.

Les auteurs notent, sans surprise, que le contexte actuel promeut plutôt une perspective technosolutionniste basée principalement sur les gains d’efficacité.

La partie intitulé
travailler davantage sur les conséquences environnementales que sur l'attribition est exactement mon point du vue actuel entre les trois logiques : consesuentielle attributionelle, conséquentielle à court-terme et consequentielle à moyen-terme.

Si on cherche à envoyer le bon signal pour permettre le changement de comportement, l’approche attributionnelle et conséquentielle à long-terme sont les plus pertinentes.

Un exemple de modélisation de la logique conséquentielle: https://gauthierroussilhe.com/media/pages/articles/nouvelles-perspectives-de-recherche/d459add866-1681122601/e-commerce-fr.svg

Un tableau récapitule les deux méthodes attributionnelles et consequentielles long-terme, selon l'action, le temps, la portée, le type de modelisation et l'impact avec les politiques publiques.

D'autres méthodes de modélisations existent bien: Différencier le scénario de base et le scénario avec le service déployé permet de définir s’il y a eu des émissions évitées ou rajoutées à cause du service en question. Concernant le scénario de base, les politiques de transition écologique auraient plutôt tendance à faire réduire la baseline.

As UI evolves, I think we will come one day with a UI library that can be customized entirely (hello white label design system).

Being able to test features on it should also be possible. It don't understand how all accessibility criteria can be tested though.

A workflow or framework with methods for each step

1. Punch line
2. Current status
3. Next steps
4. Explanation

"Dad, I'm OK; the bull is dead."
"The car is damaged but operable."
"He then explained about the location of the accident and informed me that a person nearby had called the police and that he (Raj) had taken a few pictures of the accident scene. You don't need to rush. I'll explain when I see you."

In journalism, this is known as the inverted pyramid style

1. Having an "inbox" notes to capture ideas in form of napkin, receipt, voice recorder
2. Literature notes: When you consume content, take notes of what you don’t want to forget or what you want to use in your own writing. It is recommended to make them atomic. Make sure to include the bibliographic details, author & source at the very least, so you know where you got the idea from.
3. Permanent notes: every day, you should go through the inbox and seek to refine the fleeting & literature notes. Making connections and turning them into permanent notes.

One idea = One note
One note = One idea

4. Navigation: an index allows you to navigate in the zettelkasten; keyword notes can also be used as link.

Le TDD est avant tout une méthode de développement permettant de faire émerger son design et donc son code grâce aux tests

“Baby-step”, c’est la clé pour s’amuser, pas au sens d’enfantillage, mais pour prendre plaisir à développer et comprendre que notre métier est vraiment beau quand on supprime toute forme de “hasard”.

Un cycle TDD "Red, Green, Refactor" correspond une une bribe de spécification écrit sous forme de test et sa réponse. On écrit le code minimaliste pour que ce test "Red" fonctionne et passe au "Green".

Pour cela, il est recommandé d'abuser de son IDE. Par sa construction itérative guidée par les tests, TDD apporte par “effet de bord” un taux de couverture de code par les tests à 100%. Ce n’est pas ce que l’on recherche de prime abord, mais ce code coverage est là, et surtout il est pertinent. C’est ce dernier mot qui est important : cette pertinence permet réellement de se plonger dans la troisième phase de TDD.

Ensuite on refactorise pour donner plus de sens: spécifier les erreurs, de passer d'un constructuer à un builder, ... Nous pouvons nous le permettre car les tests nous soutiennent. Ils seront aussi à évoluer, par exemple pour vérifier que le builder pattern fonctionne correctement.

1. Conclusion
2. Key arguments
3. Detailed information

Une introduction à la méthode PARA

S pour Situation, c’est-à-dire la description du contexte qui permet de donner une vision globale à votre interlocuteur
T pour Tâche, qui désigne la mission et l’objectif à atteindre
A pour Action, qui correspond à l’ensemble des actions que vous avez initiées pour réussir à réaliser la tâche
R pour Résultat, qui permet de souligner le bilan et les effets de vos actions, notamment par la mention de données chiffrées.

c’est une méthode qui force à utiliser tes vraies situations passées, les décortiquer et prouver tes compétences à travers elles.

A methodology to build software-as-a-service apps

A great introduction to the lotus blossom.
I use it to get some ideas for the User-centered design methods class

Simple