Archives de l’auteur : Raphaël Lemaire

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, …)

 

Octobre : les liens du mois

En souvenir de la revue de presse du meetup backbone.js, en complément des excellentes revue d’Arolla et de Xébia, et surtout pour ma pomme, parce que ça me fait une archive de bonne qualité, j’ouvre une catégorie d’articles sur ce blog : les liens du mois.

Voici donc quelqu’uns des articles qui sont passés sous mes yeux en octobre, et que je trouve assez intéressants pour être partagés.

Une explication détaillée et enrichie d’histoire et d’anecdotes du load average de linux : linux load averages.

Un designer pointe les problèmes avec le design de l’iPhone X : apple is really bad at design.

Un rappel que la validation de formulaire c’est compliqué (par exemple les noms / prénoms) : la région Bretagne demande l’autorisation du tilde dans les prénoms 

 

Un guide plutôt bien fait sur « comment bien répondre aux questions » , et sur le même blog, « comment expliquer avec des dessins ».

Et enfin,  moment esprit critique, qui prend les exemples du tabac et dérèglement climatique pour rappeler comment semer le doute dans les esprits, malgré des vérités objectives bien étayées :  l’ignorance : des recettes pour la produire, l’entretenir, la diffuser.

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.