Ca fait un moment que ça me titille. Et j'en ai même fait une présentation pour quelques collègues.

Et vu que certains y avaient trouvé de l'intérêt, je vais lancer quelque chose de simple histoire de voir où ça pourrait me mener (avant une initiative bien plus ambitieuse à base de GitHub et de pull requests, voire même de Catala). Bref, allons-y pour quelques règles simples. Et je vais noter les règles avec mes différents commentaires à la fin

1. ZeNomic est une partie de nomic se jouant sur Workplace
2. Le texte d'une règle ou d'une proposition ne doit pas dépasser 50 mots.
3. Une proposition peut être un ajout, une modification, ou une suppression de règle.
4. Chaque proposition de règle doit être faite dans via un sondage dans lequel les réponses valides sont "oui" ou "non".
5. Un sondage en vue de valider une proposition doit être ouvert au moins 12 heures, et au plus 27 jours.
6. Une proposition est acceptée si plus de la moitié des réponses au sondage (les commentaires ne comptent pas) sont "oui" au moment de la clôture du sondage.
7. Lorsqu'une proposition est acceptée, le joueur l'ayant proposée doit envoyer un message contenant toutes les règles en cours de validité.
8. Chaque personne proposant une règle ou votant lors d'une proposition est un joueur pour le reste de la partie.
9. A tout instant, il ne peut pas y avoir plus d'une proposition de règle en cours de vote. Les propositions supplémentaires sont ignorées.

Et maintenant, quelques commentaires

1. Comme l'objectif est de jouer avec mes collègues, et que le réseau social d'entreprise est Workplace (même si ça ne me plaît pas du tout), autant essayer d'en faire quelque chose d'intéressant ...
2. Je suis depuis Conanomic accro aux limites de taille de règles. Et si la limite à une phrase avait du sens pour Conanomic, la limite la plus simple est celle du nombre de mots.
3. J'ai failli oublier cet élément essentiel !
4. Dès que j'ai posé les yeux sur Workplace, je me suis dit que je devais m'en servir pour un nomic. En particulier les sondages, qui sont vraiment faits pour voter.
5. Je n'avais initialement pas écrit cette règle. Et puis je me suis rendu compte que sans ça, on pouvait bloquer la partie avec un sondage sans limite de validité, ou avancer librement en ouvrant des sondages très courts et en y répondant.
6. Je compte sur la subtilité des joueurs pour changer ces conditions fort simples assez rapidement.
7. Oui, bon, ça, c'est fastidieux, mais je pense qu'on doit pouvoir exploiter le média d'une façon rigolote.
8. Et oui, il faut bien définir les joueurs !
9. Et on termine par la limitation classique pour limiter l'activité, sans ça, ça diverge rapidement.

Et onv a maintenant tester tout ça !

Est-il utile de rappeler que 2020 a été une année .. particulière ?

Elle avait pourtant bien commencé, avec un super snowcamp et cette présentation (pour laquelle je suis toujours stupéfait de constater qu'il y a eu une bonne centaine de personnes intéressées).

Je constate d'ailleurs avec un dégoût à peine voilé que Jacques Séguéla a fait une conférence au titre assez proche ... J'ai donc le même goût du calembour boiteux que cet inénarrable pubard ?

A titre personnelle, je peux dire sans rougir que 2020 aura été pour moi l'année du chômage partiel. Une découverte ... dont j'aurais pu me passer. Cela dit, ça m'a permis de réfléchir à quelques sujets, comme l'architecture logicielle avec C4 (dont j'adorerais parler en conférence, j'ai même déja un support raisonnablement prêt). 2020, c'est aussi une année qui s'est terminée ... dans la douleur. Et quelque part, sans doute parce que j'y serai cette année encore plus sensible, le fameux voeu de "et surtout la santé" me rend vraiment hargneux. Ca veut dire quoi "la santé" ? Et la santé sans le reste a-t-elle un sens ? Souhaiter la bonne santé, c'est avant tout souhaiter aux français marqués par cette stupidité de dichotomie corps-esprit que l'animal en eux ne s'impose pas, non ? Bon, je digresse.

L'aspect le plus navrant, c'est que la plupart de mes idées marrantes n'ont pas avancé d'un poil : la webradio est toujours en pièces, je n'ai pas fait beaucoup de Rust (pas autant que j'aurais aimé), bref, l'épidémie a pas mal pesé sur moi.

Alors ? Que faire de 2021 ? En fait, je suis assez indécis. Je commence réellement à penser qu'il est temps de changer quelques orientations ... Et je vais me permettre une métaphore. Dans les milieux de la science-fiction littéraire, il y a une question qui hante : la science-fiction a-t-elle gagné ou perdu ? Autrement dit, le genre science-fictif a-t-il gagné ses lettres de noblesse ou reste-il un décor pour des oeuvres sans grand sens ? Cette question, je pense qu'on peut se la poser au sujet de l'informatique : aujourd'hui, plus aucune entreprise n'existe en-dehors de son informatique (oui, posé comme ça, c'est prétentieux, mais dans la mesure où l'informatique est le cerveau et le système nerveux des entreprises, sans cette informatique, la plupart des entreprises disparaissent immédiatement). Par ailleurs, les plus fortes valorisations sont aujourd'hui des entreprises du domaine informatique. Est-ce que ça traduit réellement un engouement pour ces technologies ? Non. Ca traduit uniquement le fait que l'espionnage commercial, renommé en intelligence économique et en connaissance client, est littéralement devenu le pétrole du XXIème siècle, c'est-à-dire un élément moteur de l'économie. Tout cela va sans doute faire émerger un business générant de la pollution de notre sphère informationnelle personnelle, et c'est déja le cas grâce à des "leaders" comme Google, bien sûr, mais aussi la fameuse licorne française Criteo ... Et c'est là où je voulais en venir avec ma métaphore : l'informatique a effectivement conquis les entreprises comme un outil corruptif : chaque dirigeant est tenté d'informatiser plus son entreprise, de rajouter de "l'intelligence artificielle", des "algorithmes" dans une quête d'une rentabilité améliorée ... Or je pense que cette rentabilité améliorée ne justifie la plupart du temps pas les dépenses qui sont engagées dans sa poursuite. Mais comment le montrer ? Et surtout, comment le montrer dans un monde économique qui continue à croire au mythe de la croissance éternelle ?

Parce que le corollaire de cette question, c'est évidement la question du but : pourquoi faire tous ces efforts ? Pourquoi continuer à chercher à produire plus dans un monde que les catastrophistes nous décrivent comme à l'agonie ? Personnellement, sans croire uniquement au solutionnisme technologique, je pense qu'on peut sauver la planète ... pour peu qu'on réoriente toute cette intelligence actuellement occupée à "produire de la richesse" vers une intelligence plus verte, qui essaierait de préserver le monde qui nous entoure.

Et figurez-vous que c'est peut-être la meilleure justification pour reprendre mes efforts vers plus de Rust : produire des solutions logicielles plus efficaces énergétiquement. Et j'aimerais bien un jour creuser l'intérêt des méthodes DevOps vis-à-vis de l'intérêt écologique ... Parce que ces histoires de recompilation de l'univers à chaque commit me paraissent de plus en plus difficiles à vivre ..

Mais tout ça, c'est le futur, qui n'attend que nous ! Alors allons-y !

Ce titre d'un goût douteux vient d'une présentation du design pattern visiteur que j'ai fait il y a peu, et dont je me suis dit qu'il serait chouette d'en faire un article "propre". Et comme la plupart des articles qui en parlent le font en UML, je vais vous le montrer avec du code ... Java (parce que c'est ce que je pratique).

Supposons donc que je souhaite afficher le dessin d'un arbre (oui, c'est un peu abstrait, mais c'est la version la plus concrète que j'ai trouvé, grâce à mon collègue Delphin). Pour ça, vous disposez de quelques classes : Feuille, Fleur. Et comme ce code est du code déja existant, les méthodes d'affichage portent des noms différents ... ce qui peut donner lieu par exemple à ce code (beaucoup trop simpliste, mais c'est pour donner l'idée).

import java.util.Arrays;
import java.util.List;

class Feuille {
	public String montrerFeuille() { return "🍃"; }
}
class Fleur {
	public String afficherFleur() { return "🌺"; }
}
public class Main {
	public static void main(String[] args) {
		List<Object> visitables = Arrays.asList(new Feuille(), new Fleur());
		for (Object v : visitables) {
			if (v instanceof Feuille) {
				Feuille f = (Feuille) v;
				System.out.println(f.montrerFeuille());
			} else if (v instanceof Fleur) {
				Fleur f = (Fleur) v;
				System.out.println(f.afficherFleur());
			}
		}
	}
}

Bon, évidement, c'est un exemple pourri. Parce que ce que vous voulez faire, c'est les mettre dans une liste, et appeler leurs méthodes. Dans une vision classique, vous allez ajouter une interface, et ça donnera ce code

import java.util.Arrays;
import java.util.List;

class Feuille implements Affichable {
	public String montrerFeuille() { return "🍃"; }

	@Override public String afficher() { return montrerFeuille(); }
}
class Fleur implements Affichable {
	public String afficherFleur() { return "🌺"; }

	@Override public String afficher() { return afficherFleur(); }
}
interface Affichable {
	public String afficher();
}
public class Main {
	public static void main(String[] args) {
		List<Affichable> affichables = Arrays.asList(new Feuille(), new Fleur());
		for (Affichable affichable : affichables) {
			System.out.println(affichable.afficher());
		}
	}
}

Qui présente en fait un inconvénient important : à chaque usage, vous allez ajouter des méthodes dans votre interface, et les implémenter dans chacune de ces classes. Et le code de votre domaine se retrouvera pollué par des tonnes de bouts de trucs qui n'ont que peu de rapport. Or le principe de la programmation structurée, quelquesoit la structure, c'est de limiter la complexité, pour permettre au développeur d'attaquer des problèmes plus complexes. Et c'est à ça que sert le visiteur.

Alors comment faire ? Eh bien, grâce au visiteur, pardi ! Celui-ci repose sur deux idées. D'abord, rendre notre modèle visitable, comme un musée, c'est-à-dire créer une interface Visitable implémentée par les différents éléments du modèle. Ensuite, créer une interface Visitor et des implémentations qui vont isoler la complexité. Regardez, ça n'est pas si compliqué.

class Feuille implements Visitable {
	public String montrerFeuille() { return "🍃"; }

	@Override public void accept(Visitor v) { v.visit(this); }
}
class Fleur implements Visitable {
	public String afficherFleur() { return "🌺"; }

	@Override public void accept(Visitor v) { v.visit(this); }
}
interface Visitable {
	public void accept(Visitor v);
}
interface Visitor {

	void visit(Feuille feuille);

	void visit(Fleur fleur);

}
public class Main {
	public static void main(String[] args) {
		List<Visitable> visitables = Arrays.asList(new Feuille(), new Fleur());
		for (Visitable v : visitables) {
			v.accept(new Visitor() {
				@Override public void visit(Feuille feuille) {
					System.out.println(feuille.montrerFeuille());
				}

				@Override public void visit(Fleur fleur) {
					System.out.println(fleur.afficherFleur());
				}
			});
		}
	}
}

Toutefois, il y a encore plusieurs problèmes.

Le premier est assez simple : nos objets sont beaucoup trop basiques. Et dans un modèle réel, il faudrait avoir des objets conteneurs. Dans notre cas, ce sera ... la Branche.

class Feuille implements Visitable {
	public String montrerFeuille() { return "🍃"; }

	@Override public void accept(Visitor v) { v.visit(this); }
}
class Fleur implements Visitable {
	public String afficherFleur() { return "🌺"; }

	@Override public void accept(Visitor v) { v.visit(this); }
}
class Branche implements Visitable {
	List<Visitable> children = new ArrayList<Visitable>();
	public Branche(List<Visitable> children) { this.children.addAll(children); }
	public Branche(Visitable...children) { this(Arrays.asList(children)); }

	@Override public void accept(Visitor v) {
		v.startVisit(this);
		for(Visitable c : children) {
			c.accept(v);
		}
		v.endVisit(this);
	}
}
interface Visitable {
	public void accept(Visitor v);
}
interface Visitor {
	void visit(Feuille feuille);
	void visit(Fleur fleur);

	void startVisit(Branche branche);
	void endVisit(Branche branche);
}
public class Main {
	public static void main(String[] args) {
		List<Visitable> visitables = Arrays.asList(new Feuille(), new Fleur(),
				new Branche(new Feuille(), new Fleur()));
		for (Visitable v : visitables) {
			v.accept(new Visitor() {
				@Override public void visit(Feuille feuille) {
					System.out.println(feuille.montrerFeuille());
				}

				@Override public void visit(Fleur fleur) {
					System.out.println(fleur.afficherFleur());
				}

				@Override
				public void startVisit(Branche branche) {
					System.out.println("➡🌿");
				}

				@Override
				public void endVisit(Branche branche) {
					System.out.println("⬅🌿");
				}
			});
		}
	}
}

Et comme celle-ci implémente visitable, on voit bien que le compilateur va nous aider à implémenter le bon code :

1. On ajoute l'interface Visitable, du coup le compilateur nous dit qu'il faut rajouter la bonne méthode.
2. Quand on a implémenté l'interface Visitable, on a écrit la ligne visitor.startVisit(this); et visitor.endVisit(this); qui n'existent pas dans l'interface Visitor. Il faut donc les ajouter.
3. Et par conséquent, il faut aussi les ajouter dans l'implémentation anonyme qu'on utilise dans notre classe Main.

Et ça, c'est un gros avantage du visiteur sur les interfaces "ad-hoc" : chaque usage est facilement identifié par le compilateur (ce qui est encore plus performant que de l'identifier par la recherche de code d'un IDE quelconque. Et ça, c'est un avantage d'autant plus performant que la base de code est importante.

Cela dit, si vous regardez le code dans la classe Main, ça n'est pas très joli : il y a des tas de System.out.println, et personnellement, je préfèrerai en avoir un seul ... Ca veut dire construire une chaîne de caractère dans le visiteur et la retourner. Bon, on parle de String, mais ce serait bien si on pouvait retourner n'importe quoi, non ? Heureusement, avec Java, on peut faire des types génériques. Regardez le code suivant

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

class Feuille implements Visitable {
	public String montrerFeuille() { return "🍃"; }

	@Override public <Type> Type accept(Visitor<Type> v) { return v.visit(this); }
}
class Fleur implements Visitable {
	public String afficherFleur() { return "🌺"; }

	@Override public <Type> Type accept(Visitor<Type> v) { return v.visit(this); }
}
class Branche implements Visitable {
	List<Visitable> children = new ArrayList<Visitable>();
	public Branche(List<Visitable> children) { this.children.addAll(children); }
	public Branche(Visitable...children) { this(Arrays.asList(children)); }

	@Override public <Type> Type accept(Visitor<Type> v) {
		v.startVisit(this);
		for(Visitable c : children) {
			c.accept(v);
		}
		return v.endVisit(this);
	}
}
interface Visitable {
	public <Type> Type accept(Visitor<Type> v);
}
interface Visitor<Type> {
	Type visit(Feuille feuille);
	Type visit(Fleur fleur);

	void startVisit(Branche branche);
	Type endVisit(Branche branche);
}
public class Main {
	public static void main(String[] args) {
		List<Visitable> visitables = Arrays.asList(new Feuille(), new Fleur(),
				new Branche(new Feuille(), new Fleur()));
		for (Visitable v : visitables) {
			System.out.println(v.accept(new Visitor<String>() {
				@Override public String visit(Feuille feuille) {
					return feuille.montrerFeuille();
				}

				@Override public String visit(Fleur fleur) {
					return fleur.afficherFleur();
				}

				@Override public void startVisit(Branche branche) {
				}

				@Override public String endVisit(Branche branche) {
					return "⬅🌿";
				}
			}));
		}
	}
}

Et au passage, une petite astuce : quand le code commence à utiliser plusieurs classes (et c'est le cas ici), commencez par lire le code utilisateur. En l’occurrence, le code qui est dans la méthode main(...). Dans celui-ci, on voit bien que le visiteur est conçu pour ne retourner que des String, parce que j'utilise les types génériques.

Il y a toutefois un défaut. Dans ce cas, on n'a pas retourné le contenu de notre branche. Pour changer ça (et c'est précisément l'intérêt du visiteur), il suffit de modifier le visiteur défini dans la classe Main pour y ajouter un StringBuilder qu'on retourne ... comme ça

      new Visitor<String>() {
				StringBuilder returned = new StringBuilder();
				@Override public String visit(Feuille feuille) {
					return returned.append(feuille.montrerFeuille()).append('\n').toString();
				}

				@Override public String visit(Fleur fleur) {
					return returned.append(fleur.afficherFleur()).append('\n').toString();
				}

				@Override public void startVisit(Branche branche) {
					returned.append("➡🌿").append('\n').toString();
				}

				@Override public String endVisit(Branche branche) {
					return returned.append("⬅🌿").append('\n').toString();
				}
			}

D'une manière générale, vous allez vite apprendre à aimer les Stack (quelquesoit leur forme) avec les visteurs 😅.

Il nous manque une dernière chose : quand je visite un musée, je ne visite pas forcément toutes les pièces. Alors, comment faire un visiteur qui ne passe pas dans tous les objets ? Simplement en modifiant notre méthode startVisit(...) (je ne mets que les morceaux intéressants) :

class Branche implements Visitable {
  // [....]
	@Override public <Type> Type accept(Visitor<Type> v) {
		if(v.startVisit(this)) {
			for(Visitable c : children) {
				c.accept(v);
			}
		}
		return v.endVisit(this);
	}
}
interface Visitor<Type> {
  // [....]
	boolean startVisit(Branche branche);
  // [....]
}
public class Main {
  // [....]
				@Override public boolean startVisit(Branche branche) {
					returned.append("➡🌿").append('\n').toString();
					return true;
				}
  // [....]
}

Et là, vous avez l'implémentation "canonique" d'un visiteur en Java.

Ce design pattern est en fait très utilisé : dès que vous transformez un modèle en un autre, il est très pratique. Et ces transformations, vous en faites .... tout le temps : compter les objets, c'est une transformation, tout comme afficher un text, ou calculer une somme. Pour la petite histoire, le collègue qui me l'a fait découvrir il y a dix ans en mettait partout ... et à juste titre. Par ailleurs, je l'ai implémenté ici en java, mais j'ai déjà eu des résultats satisfaisants dans d'autres langages : du Rust, du Python, du Groovy (évidement). A mon sens, tous les langages présentant des structures de données arborescentes peuvent y trouver de l'utilité.

Je voudrais rapidement d'une vidéo qui a un peu circulé dernièrement, dans laquelle Etienne Klein nous parle des medias de masse et des ingénieurs. Si vous ne l'avez pas encore vue, regardez ...

Cette vidéo me fait en fait plutôt sourire (alors que franchement elle devrait me faire pleurer).

Parce qu'Etienne Klein, qui fait cette vidéo à destination des jeunes centraliens, semble s'émouvoir de l'absence des techniciens et ingénieurs que compte la France par milliers ? millions plutôt ? Et ce qui me fait sourire dans son intervention, c'est qu'il semble croire que ce monde de l'avancée scientifique, ce monde du progrès est inaudible dans le débat politique. Bon, regardez autour de vous ...

Même si la 5G est critiquée, elle est quand même installée.

Et même si tout le monde critique les usages inéthiques de l'informatique et du capitalisme de surveillance, ces usages sont quand même de plus en plus présents.

Je pourrais aller plus loin et parler d'autres choix technologiques alimentés par le marketing, mais je pense que vous voyez l'idée. Si ça n'est pas le cas, je vais la clarifier.

Les ingénieurs et techniciens n'ont pas besoin de s'exprimer, parce que le déploiement de leurs produits parle pour eux. Quand vous voyez une Zoe (par exemple, hein) passer, ce que vous voyez, c'est une chaîne technologique qui va de l'extraction de terres rares jusqu'au design de rétroviseur, bref le travail de centaines de techniciens et ingénieurs qui vous passe sous les yeux.

Est-ce que c'est arrogant ? Oui, phénoménalement. Mais c'est aussi une façon commode de tourner le dos aux débats inutiles agitant le bocal parisien de médias laissant parler en boucle des gens dont la seule culture est littéraire. Et si je n'ai rien contre la culture littéraire, bien au contraire, je pense néanmoins que laisser notre pays être dirigé et étudié par des gens qui n'ont aucune idée des processus technologiques leur permettant leur existence médiatique est précisément une erreur liée à l'arrogance des ingénieurs.

Ca me rappelle furieusement ces histoires de savants fous au service de dictateurs cintrés qui abondent dans l'imaginaire ... Et quelque part, c'est ça qui me fait pleurer : reconnaître que ce silence met factuellement ces capacités de construction au service des mécaniques de pouvoir. Je l'ai illustré avec les exemples de la 5G ou du capitalisme de surveillance : actuellement, les ingénieur innovent, mais la plupart dans des directions des plus discutables. Et ça ne semble poser de problèmes à personne ... pas même à moi, en un sens.

Parce qu'il ne faut pas se leurrer : les projets auxquels je participe, qui sont des éléments du fonctionnement de grands groupes de la distribution, sont des instruments permettant leur continuation. C'est assez criticable, en soi.