Archives de catégorie : Non classé

Novembre et décembre : les liens

Une sélection des liens qui me sont passés sous le nez en novembre et décembre, rassemblés pour cause de vacances.

  • Bonne nouvelle, google est officiellement alimenté uniquement alimenté par de l’électricité solaire et éolienne. Cela fonctionne surtout via des subventions pour les projets de renouvelable, google utilisant bien sur le réseau de distribution local.
  • Il est maintenant, relativement facilement, possible de mettre le visage de qui on veut sur une vidéo. Par exemple Gal Gadot dans un porno.
  • The Coming Software Apocalypse. Un long article, qui part du manque de fiabilité des logiciels puis parle de notre façon de travailler, qui n’a pas changé depuis des décennies, et donne plein d’exemples et de pistes pour montrer comment on peut faire différent et mieux.
  • Une histoire intéressante : des gens se sont rendu compte que sur l’emoji burger de google le fromage était mal placé (!), la firme a donc du le changer.
  • Move Slowly and Fix Things. Une tribune intéressante de Jonas Downey de basecamp, qui cite tout ce qu’on a donné au logiciel (nos données, notre vie…), et nous rappelle que nous somme la première ligne de défense des utilisateurs.
  • Pour une fois un article en français, qui parle des petites mains du big data, les raters, qui saisissent et corrigent les données. Et qui ont accès à toutes votre vie (presque), pour quelques euros de l’heure.
  • Comment pourrait-on reconstruire un web meilleur, plus conforme à la vision utopique des geeks qui l’ont créé ? L’article aborde des aspects techniques (un modèle P2P pour toutes les requêtes, pour réduire la charge réseau par exemple), mais aussi « politiques » comme l’excessive centralisation de service (eg : facebook, google, …)

 

Litterate programming 2017

J’ai récemment lu l’article de Donald Knuth sur la programmation lettrée. C’est un de ces paradigmes un peu oubliés, avec pourtant un potentiel très cool.

C’est quoi la programmation lettrée ?

L’idée original de Donald Knuth est d’écrire un programme sous la forme d’un essai en langage naturel, expliquant ce que le programme fait, avec entre les lignes des morceaux de code exécutable.

Le programme est écrit sous la forme d’un essai en langage naturel, avec du code exécutable entre les lignes.

Il est ainsi possible de générer à partir du même fichier une documentation en langue naturelle (par exemple sous la forme d’un fichier latex, html, etc…) et un programme exécutable par une machine.

Vous me direz « c’est javadoc » : Eh bien non !

Les outils de génération auxquels nous sommes habitués permettent de générer une documentation à partir de texte annoté sur la structure du programme. C’est toujours le langage machine qui donne la contrainte de où est placé le texte. On documente une classe ou une fonction.

Avec la programmation lettrée, le texte est au premier plan, et c’est lui qui impose la structure du programme, pas le langage machine.

Avec la programmation lettrée, le texte est au premier plan.

Personnellement je trouve l’idée assez cool. Pour plein de raisons.

Déjà, on ne raconte pas assez nos vies, ou plutôt la vie du projet dans nos programmes. Il est rare que les gens placent le contexte, le pourquoi fonctionnel, politique, historique de tel ou tel morceau de code. Et souvent on se pose des questions longtemps après, même si le code est clair sur ce qu’il fait, sur pourquoi ça a été fait.

Ensuite, écrire du texte en français (ou en anglais, c’est un autre débat) permet de structurer sa pensée. On peut penser à des choses que l’on aurait oublié (pour moi qui suit un intuitif et un éternel distrait c’est intéressant), mieux comprendre un concept, une fonctionnalité, et donc mieux l’implémenter, etc…

Et aussi, j’aime assez tout ce qui s’écarte de l’habituel et permet de voir la programmation autrement. Avouons que le changement est rafraîchissant.

Comme ce paradigme est un peu oublié, il y a peu d’outils à disposition pour en faire, et pas vraiment d’envie de le voir arriver dans les projets (contrairement à la programmation fonctionnelle, qui a le vent en poupe).

Je me suis demandé ce que cela donnerait si on essayait d’appliquer cette idée dans un langage mainstream actuel. Voici un exemple en Java, tiré d’un programme réel, et un peu retravaillé :

Le code complet :

/**
* Interroge le service infos pour récupérer les informations, et les stocke
* dans redis.
* On ne garde que les infos en cours de validité.
*/

public F.Promise<List<GLZoneInfo>> poll() {
   // En avril 2016, la direction des renards a demandé à intégrer les
   // informations aviaires à l'application, afin de [...].
   // On commence par récupérer la liste des contenus auprès du service infos.
   return infosClient.getContentList().flatMap((contentList) -> {
       // On a alors une liste d'objets qui contiennent les ids et date
       // de validité des contenus existants.
       List<F.Promise<GLZoneInfo>> promises = contentList.stream()
               // On ne conserve que les publications en cours de validité.
               .filter(InfosService::mustBeDisplayedNow)
               // pour chacun des contenus non filtrés, on va chercher le
               // détail (avec le titre, le texte, etc...) en appelant
               // le service infos avec l'identifiant donné dans la liste,
               // et on traduit le résultat dans notre modèle.
               .map((content) -> infosClient
                   .getContent(content.getContentId())
                   .map(InfosService::convert))
               .collect(Collectors.toList());

       // Note : on va chercher les détails en parrallèle, pour plus d'efficacité.
       return F.Promise.sequence(promises).map((informations) -> {
           // Une fois les contenus récupérés, on les stocke dans redis
           storeInCache(informations);
           // Par commodité, on renvoie les contenus stockés, ce qui permet
           // pour un poll fait à la main de voir ce qui a été stocké.
           return informations;
       });
   });
}

On voit qu’il y a beaucoup de commentaires, qui peuvent parfois paraître un peu redondant avec le code en dessous, mais pas non plus complètement inutiles.

Si on enlève les commentaires qui ne sont pas de la documentation de méthode ça donne :

/**
* Interroge le service infos pour récupérer les informations, et les stocke
* dans redis.
* On ne garde que les infos en cours de validité.
*/

public F.Promise<List<GLZoneInfo>> poll() {
   return infosClient.getContentList().flatMap((contentList) -> {
       List<F.Promise<GLZoneInfo>> promises = contentList.stream()
               .filter(InfosService::mustBeDisplayedNow)
               .map((content) -> infosClient
                   .getContent(content.getContentId())
                   .map(InfosService::convert))
               .collect(Collectors.toList());
       return F.Promise.sequence(promises).map((informations) -> {
           storeInCache(informations);
           return informations;
       });
   });
}

C’est le genre de chose qu’on est habitué à voir tous les jours. C’est assez lisible, si on est familier avec la syntaxe du langage et les API du framework play!.

Si on garde seulement les commentaires d’explication inséré au milieu du code ça donne :

En avril 2016, la direction des renards a demandé à intégrer les informations aviaires à l’application, afin de […].
On commence par récupérer la liste des contenus auprès du service infos.
On a alors une liste d’objets qui contiennent les ids et date de validité des contenus existants. On ne conserve que les publications en cours de validité.
Pour chacun des contenus non filtrés, on va chercher le détail (avec le titre, le texte, etc…) en appelant le service infos avec l’identifiant donné dans la liste, et on traduit le résultat dans notre modèle.
Note : on va chercher les détails en parrallèle, pour plus d’efficacité.
Une fois les contenus récupérés, on les stocke dans redis.
Par commodité, on renvoie les contenus stockés, ce qui permet pour un poll fait à la main de voir ce qui a été stocké.

On le voit ce petit texte ne ressemble pas du tout à une description de méthode, et il explique très bien ce que fait le petit bout de programme et pourquoi.

On a donc un essai qui décrit le programme.

Les avantages de cette démarche :

  • Le programme produit est plein d’explications, et donc plus documenté et plus clair.
  • Ecrire le texte permet de penser plus longtemps le programme et aussi un peu différemment, on pense donc à plus de choses, et cela permet d’éviter des oublis, des cas particuliers, etc…
  • Les commentaires ajoutés permettent de donner du contexte, d’expliciter des choses et de justifier des choix techniques, même micros.

Les inconvénients :

  • C’est assez verbeux et un peu redondant.

Une opinion tranchée sur les formats de rétro.

Voici une opinion bien tranchée sur les rétrospectives, que je donne après en avoir suivi et animé des dizaines dans différents contextes, et après avoir échangé des collègues qui sont du même avis.

Garder le même format à chaque sprint

Garder le même format à chaque sprint permet aux participants de se concentrer sur le fond (les points d’amélioration) et non sur la forme. Les membres de l’équipes ont leurs repères, visualisent comment amener les points qu’ils ont repérés pendant le sprint, voire même revoient la rétrospective précédente et ses actions.

Changer de format à chaque sprint crée une habitude de l’imprévisibilité, chaque rétro est une découverte, sans repères pour les participants. On perd du temps en discussion sur la forme, les participants ne savent où et comment remonter leurs idées, etc…

Briser la routine de temps à autre avec un format différent est intéressant, mais cela doit être exceptionnel, par exemple tous les quatre ou cinq sprints. L’effet positif de la nouveauté ne peut être ressenti que s’il y a une routine à briser.

Rester sur les classiques

Je préfère les formats simples et classiques (type KALM, ou 4L, qui d’ailleurs se ressemblent beaucoup). Ils sont faciles à comprendre, permettent aux participants de remonter toute sorte de choses (problèmes, suggestions, améliorations, blagues…) et peuvent être adaptés en direct en ajoutant des votes, des étapes, ou en timeboxant si besoin.

D’ailleurs, un autre inconvénient du changement de format régulier est que l’on tombe parfois sur des formats qui ne permettent pas tous les types de retours, ou pas facilement, ou qui peuvent paraitre infantilisants (voir par exemple la montgolfière ou les petits cochons) (mais peut-être que c’est moi qui suis ennuyeux ?).

Historisation

Toutes les rétrospectives devraient être sauvegardées (dans le wiki de l’équipe ou outil équivalent), et on devrait commencer chaque séance en projetant la rétrospective précédente pour vérifier que les actions ont bien été menées, que l’équipe a progressé.

Le rappel permet également de renforcer le sentiment de continuité : on progresse de semaine en semaine, on se souvient d’où on en était avant, et en quoi c’était moins bien.

En résumé, un animateur de cérémonies doit mettre en place une routine de l’amélioration continue, ce qui passe par de la stabilité, de la simplicité et du suivi. Il peut amener de l’air en changeant parfois les choses, mais cela ne peut être intéressant que s’il y a une routine à briser.