
Cliquez sur un ou plusieurs tags pour appliquer un filtre sur la liste des notes de type "Journaux" :
[ << Notes plus récentes (1006) ] Pas de notes plus anciennes
Jeudi 1 septembre 2022
Journal du jeudi 01 septembre 2022 à 20:26
Je trouve que Best current practice est intéressant pour éviter de tomber dans la rigidité d'un process 🤔.
Mercredi 31 août 2022
Journal du mercredi 31 août 2022 à 15:00
#JaiDécouvert le terme technique Best Current Practice (https://fr.wikipedia.org/wiki/Best_Current_Practice).
Journal du mercredi 31 août 2022 à 14:17
Voici une liste de communautés qui utilisent le concept de RFC :
Dimanche 3 avril 2022
#JaiDécouvert le concept de marqueur de modestie épistémique en mai 2019 dans cette vidéo de Lê Nguyên Hoang : « Modestie épistémique #DébattonsMieux ».
#JaiDécidé d'essayer à partir d'aujourd'hui de mettre cela en pratique autant que possible dans ma communication.
Mon intuition, c'est que cela va être très difficile à l'oral, dans le flux de la communication, mais je pense qu'il n'y a aucune raison que je n'y arrive pas à l'écrit.
Pour l'écrit, j'aurais tendance à dire que c'est une question de rigueur, équivalente à ma rigueur d'utilisation des conventional comments quand je poste des commentaires de review.
Voici quelques exemples de marqueurs de modestie épistémique que je pourrais utiliser :
- il me semble que …, ça serait …
- j'aurais tendance à dire que …
- peut-être ...
- probablement ...
- sans doute ...
- si je devais parier ...
- mon intuition dirait que ...
- je me trompe sans doute…
- il me semble extrêmement probable …
- il semble que …
- selon cette article ....
- je pense que .....
- j'ai entendu dire que ....
- il paraît ......
- selon ce consensus ....
Jeudi 24 mars 2022
Journal du jeudi 24 mars 2022 à 15:49
Une illustration des conséquences de la "Pensée magique" ou "Pensée désidérative" : L’accident de Tchernobyl expliqué par le Dr V. Legassov (Série Chernobyl (mini-série)).
Samedi 29 janvier 2022
Journal du samedi 29 janvier 2022 à 15:35
#JaiLu ce thread Hacker News : Why our team cancelled our move to microservices.
There is no reason even a significantly larger org - say 40+ people in 8-10 teams cannot work effectively in a single repository and monolith architecture. Beyond that there are certain growing pains and if you don't effectively manage those then I could see how you end up going with micro-services.
Vendredi 28 janvier 2022
Journal du vendredi 28 janvier 2022 à 20:00
J'ai acheté un Serveur NUC i3 gen 5 d'occasion pour 150 € sur LeBonCoin, avec pour objectif de l'utiliser comme serveur Homelab.
Je prévois d'y installer Proxmox pour déployer des Virtual Instances.
Mardi 5 octobre 2021
Journal du mardi 05 octobre 2021 à 14:00
Je viens de déjeuner avec un ami qui m'a fait découvrir le livre Team Topologies.
Vendredi 19 avril 2019
Journal du vendredi 19 avril 2019 à 17:33
Cela fait des mois que je me demande comment nommer le repository #Git « chapeau », « umbrella » qui est le starting point d'une boite ou d'un projet.
J'ai trouvé une réponse chez GitLab, {compagny_name}-development-kit
: https://gitlab.com/gitlab-org/gitlab-development-kit.
Ce repository est un "development kit".
Mardi 15 janvier 2019
Journal du mardi 15 janvier 2019 à 15:22
Ce mois de janvier est riche en article au sujet des Monorepo !
#JaiLu le contre pied du l'article "Monorepos: Please don’t" : Monorepo: please do! !
As a leader, I’ll pick the monorepo every time: because tools must reinforce the culture I want, and culture comes from the tiny decisions and behaviors of a team every day.
👌
Son thread Hacker News : 161 commentaires.
Mardi 8 janvier 2019
Journal du mardi 08 janvier 2019 à 17:28
#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos and the Fallacy of Scale | Hacker News".
J'ai trouvé l'article très intéressant ainsi que les commentaires.
Jeudi 3 janvier 2019
Journal du jeudi 03 janvier 2019 à 15:13
#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos: Please don’t".
Il contient de très bons commentaires biens argumentés qui expliquent les avantages des Monorepo, j'ai trouvé cela passionnant 🙂.
Jeudi 22 novembre 2018
Journal du jeudi 22 novembre 2018 à 15:09
Au début, j'avais une sorte de jouissance à créer des dépôts pour chaque service de mon projet (je précise que tout seuls, ils ne servent à rien), j'avais l'impression d'être un bon élève. Mais, que c'est pénible d'en maintenir une cohérence ! Je suis plus heureux en Monorepo.
-- Témoignage d'un ami
Jeudi 25 octobre 2018
Journal du jeudi 25 octobre 2018 à 15:09
#JaiDécouvert le nom du Monorepo de DigitalOcean : Cthulhu 😉.
Mercredi 17 octobre 2018
Journal du mercredi 17 octobre 2018 à 17:59
Confusion à ne pas faire « Monolith ≠ Monorepo :
Monolith
Monolith ≠ monorepo. Monolith is huge amount of coupled code of 1 application that is hell to maintain.
Un projet en microservice peut très bien être hébergé dans un Monorepo.
J'ajoute aussi Multirepos ≠ microservices.
Il est tout à fait possible — voire courant — d'héberger un Monolith dans plusieurs repositories, mais d'après mon expérience, cela s'avère peu pratique, je peux même dire, pénible !
Journal du mercredi 17 octobre 2018 à 16:06
#JaiDécouvert le site "Advantages of monorepos" (https://danluu.com/monorepo/).
Avantages :
- « Simplified organization » 👌
- « Simplified dependency management » 👌
- « atomic changes » 👌
- « Extensive code sharing and reuse » 👌
- « Unified versioning, one source of truth » 👌
- « Code visibility and clear tree structure providing implicit team namespacing » 👌
- « Large-scale refactoring » 👌
- « Collaboration across teams » 👌
Samedi 23 juin 2018
Journal du samedi 23 juin 2018 à 17:50
Dans la vidéo ThinkerView "Blockchain, gouvernance et énergie ? Primavera De Filippi et Remy Bourganel", j'ai entendu Primavera De Filippi parler de l'article "La tyrannie de l’absence de structure" que j'ai trouvé extrêmement intéressant.
Lundi 11 juin 2018
Pourquoi je n'utilise pas d'acronyme non documenté sur Wikipedia ?
Je viens d'ajouter le contenu du Mail de Musk en 2010 « Les acronymes sont vraiment à éviter » dans la documentation guidelines du projet professionnel sur lequel je suis en train de travailler actuellement.
Pourquoi ?
Dans un souci d'efficacité, j'aime recevoir des informations le plus explicites possible, afin d'éviter des quiproquos, de minimiser mes risques d'erreurs, d'éviter de faire perdre du temps à mes collaborateurs en posant une multitude de questions.
Comme j'essaie de suivre la règle d'or, j'essaie moi-même de communiquer de la façon la plus explicite possible — je précise que ce n'est pas simple, même avec la meilleure volonté du monde !
C'est pour cela que j'évite au maximum de créer et d'utiliser des acronymes.
Voici quelques extraits du Mail de Musk 2010 « Acronyms Seriously Suck ».
L'utilisation excessive d'acronymes inventés est un obstacle important à la communication et il est extrêmement important de maintenir une bonne communication au fur et à mesure que nous nous développons.
👍️
Personne ne peut se souvenir de tous ces acronymes et les gens ne veulent pas avoir l'air stupides lors d'une réunion, alors ils restent assis dans l'ignorance. C'est particulièrement difficile pour les nouveaux employés.
Je suis tout à fait d'accord avec cette déclaration 👍️.
J'ai appris par expérience que la majorité des humains ne posent pas de question quand ils ne connaissent pas un mot ou un sujet.
J'essaie personnellement de mettre mon égo de coté et de poser la question, mais il m'arrive aussi de ne pas le faire.
D'autre part, ma mémoire est limitée, l'apprentissage des acronymes internes d'une organisation ou d'une équipe me demande trop de charge cognitive.
Un acronyme que la plupart des ingénieurs en dehors de SpaceX connaissent déjà, tel que GUI, peut être utilisé.
Je suis tout à fait aligné avec cette pratique👍️.
Personnellement, je suis la règle suivante : j'ai le droit d'utiliser un acronyme à condition qu'il soit référencé par une page Wikipedia et que la liste de ses homonymes sur sa page "disambiguation" soit très courte dans mon contexte d'utilisation (exemple pour FTP). Si ce n'est pas le cas, je n'utilise pas l'acronyme.
Lundi 18 décembre 2017
Mardi 12 décembre 2017
Journal du mardi 12 décembre 2017 à 10:29
J'ai été perturbé par le contenu des slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos (voir 2017-12-03_1217).
J'ai continué à étudier le sujet des Monorepo et j'ai commencé à migrer un side project vers ce pattern. Pour le moment, l'expérience est très agréable. Je pense que je vais continuer dans cette direction.
Dimanche 3 décembre 2017
Lundi 12 septembre 2016
Journal du lundi 12 septembre 2016 à 20:00
Le chapitre Le boycott du bus de Montgomery - Comment naissent les mouvements de société ? du livre Le Pouvoir des Habitudes Changer un rien pour tout changer m'a profondément marqué.
#JeSouhaite creuser le sujet.
Mercredi 15 juin 2016
Journal du mercredi 15 juin 2016 à 10:02
« Bye bye Mediapart, bonjour Brief.me »
C'est décidé, je vais me désabonner de Médiapart. Ce n'est pas du tout parce que je ne les aime pas, au contraire, j'adore. Mais, je souhaite m'abonner à https://www.brief.me/ qui correspond plus à mon besoin, une info rapide à lire, qui ne mise pas sur l'émotion (à la différence de TF1, BFM…). Et comme je ne souhaite pas multiplier mes abonnements en ligne, j'arrête Médiapart.
Jeudi 10 décembre 2009
Bilan après 4 mois d'apprentissage de keyboard layout Bépo avec un TypeMatrix
55
#wpm
sur un #typematrix #bepo après 4 mois de pratique !
J'ai commencé à apprendre le Keyboard layout Bépo cet été, en août 2009, pendant que j'étais en vacances en Savoie à Bourg-Saint-Maurice.
J'utilise un clavier TypeMatrix et le logiciel d'entrainement Klavaro.
Fin de la liste des notes.