Numérique

Pourquoi mon intérêt pour ce thème ?

Plusieurs facteurs concordant m’ont incité à m’inscrire à un webinaire ce samedi matin 23/04/2022.

• Les Designers éthiques, Association de recherche-action autour de la conception responsable et durable

• La CNIL

• Les SMACS

Les SMACS

J’étais passé à côté de ces 2 termes SMACS et Métavers jusqu’ici. Hors, j’ai l’opportunité de donner une formation sur le bon usage des données, technologies et outils numériques à des étudiants en mastère communication. Une occasion pour moi de rafraîchir mes connaissances et d’apprendre au contact de nouvelles personnes d’un nouveau domaine pour moi.

J’ai eu mon premier ordinateur personnel à l’entrée au collège, en 1984. Je me suis rapidement passionné par toutes les activités possibles, de l’écriture de programmes à leur usage plus ou moins ludique. Cela m’a conduit naturellement au métier de développeur. Après plus de 20 ans passés en entreprise de services numériques, j’ai connu dans mon parcours professionnel quelques mini-révolutions : la conception objet a déplacé mon attention portée un temps aux schémas de bases de données entité/relations, le Java a remplacé le Pascal, le RAD a limité l’utilisation de l’UML et du RUP, l’agilité enfin a balayé (du moins dans mon état d’esprit) la gestion de projet classique par phases au profit d’une relation plus directe, plus transparente entre les utilisateurs et l’équipe de développement.

La carte de matérialité est un outil stratégique du développement durable (DD), utilisable dans toute démarche RSE, et visant à définir la réponse optimale aux attentes des différentes parties prenantes, en considérant les impacts et enjeux économiques, environnementaux et sociaux.

La carte se présente généralement sous la forme de 2 axes

• les enjeux DD des parties prenantes sur l’axe des ordonnées d’une importance faible à forte en haut
• les enjeux DD de l’organisation / entreprise sur l’axe des absisses, d’une importance faible à forte à droite h=300px >}}

On considère les attentes des parties prenantes internes/externes, faibles à fortes et le potentiel de création de valeur ou enjeux pour l’entreprise, l’organisation.

Quand utiliser et jusqu’où pousser la métaphore de la dette technique en développement logiciel ?

C’est la question que je me propose souvent quand j’accompagne une équipe. Et en général, j’utilise ou invite à trouver d’autres métaphores pour exprimer plus précisément la situation.

Passons-donc en revue quelques stéréotypes de situation qui cachent plus ou moins bien une difficulté de l’ordre d’un endettement collectif et d’un certain déni du risque associé.

En ce début 2021, nous poursuivons les séances de mob avec Anthony et Guillaume avec le challenge de code “Rover on Mars”.

Après un premier cycle rapide directement dans le code, nous sommes gênés par la complexité croissante de certaines classes qui font beaucoup trop de choses et chaque petite modif commence à coûter. Nous nous posons la question de comment séparer tout ça avec des avis partagés. Ce qu’appelle la noirceur du fond d’écran de VSCode, c’est qu’il nous manque un tableau blanc.

Je trouve que cette devise des mousquetaires représente bien le Mob :

Un (clavier + écran) pour tous, tous (les cerveaux) pour un (problème)

J’ai beaucoup entendu parler de Mob Programming ces derniers mois. Peut-être plus longtemps que je n’ai encore pratiqué, du moins à l’heure où j’écris ces lignes, mais c’est en train de changer.

Même si mon métier n’est plus d’écrire du code quotidiennement, mais plutôt d’aider les autres à bien le faire lorsqu’il y a une demande dans ce domaine, je profite des occasions pour coder (1) et apprendre à mieux le faire à plusieurs, en intégrant des mobs.

Voilà plusieurs fois que des utilisateurs de l’application klub m’informent que leur proposition a disparu.

C’est dommage, car c’est certainement un frein à réessayer plus tard pour proposer un livre intéressant au klub, et probablement une occasion manquée de faire de nouvelles découvertes. Même si l’essentiel est ailleurs que dans l’application, ce qui est certain, c’est que l’expérience globale des klubers et en particulier des nouveaux, est dégradée.

Nous pourrions faire plusieurs hyptohèses, mettre en place des mesures, des stats sur l’accès aux différentes fonctionnalités, mais ma priorité est déjà de voir ce qui ne va pas et de corriger le bug.

Un moyen mnémotechnique pour ne pas oublier c’est de penser aux CATS = les CAs de TeSt

Ne cherchez pas de contrepetterie dans ce sous-titre !

En disant cela, vous êtes tenté bien sûr d’en trouver une. Curieusement l’attirance pour le défit ou l’interdit passe souvent avant l’exécution d’une directive ou même l’application d’un conseil.

Tout le monde se rappelle que dans le manifeste agile il est écrit “un logiciel qui fonctionne plutôt qu’une documentation exhaustive”. Cette phrase a autorisé à braver le caractère obligatoire et exhaustif de la documentation, par effet de balancier. Il revient d’ailleurs assez souvent que l’on me dise que dans les projets agiles, la documentation est trop incomplète voire complètement absente.

Si vous ne l’avez pas remarqué, ce site est construit avec Hugo, qui n’est pas humain, mais un compagnon numérique, pour générer des sites web statiques. Cela présente des avantages et des inconvénients pour mon besoin particulier, qui pourraient être différents pour vous.

Il ne s’agit pas de faire la promotion d’Hugo qui s’en fiche un peu. Juste de tracer quelques informations sur mon apprentissage de quelques trucs.

Bien que la documentation d’Hugo soit complète et que je m’y réfère directement, j’aime bien écrire quelques lignes des solutions aux points durs que j’ai rencontrés. Si je devais repartir de zéro, pour créer un autre site, je devrais être un peu plus efficace et excuser plus facilement mon cerveau de ne pas s’être souvenu de tout.