Sliders, les mondes parallèles

Je vous écris depuis les îles saintes vierges de la prog intense, ici il fait beau et chaud toute l'année, la joie est maximale, et chaque jour apporte son lot de découvertes fantastiques.

Je ne passe aucun temps à parler de mes logiciels car je suis de l'école de Google à ses débuts, quand on disait "si je prends un café, jamais je ne rattraperai ce retard". A cette ancienne époque de l'effervescence passionnée, tout n'était que découverte et on a encore aujourd'hui du mal à stratifier tous les niveaux auxquelles appartiennent ces découvertes.

En bref, pour situer l'histoire, j'ai conçu un framework dont je suis aussi fier qu'un musicien l'est de sa musique (indépendamment de savoir s'il est bon ou mauvais), et même si lors d'un entretien d'embauche présenter ses propres travaux, bien que ça ajoute à la compétence, est considéré comme moins qu'un job d'été, le logiciel a sa propre vie et il m'impose quotidiennement son évolution.

En fait j'ai deux macro-logiciel vivants qui m'imposent leur maintenance, et ce qu'il y a de bien à cela est que le plus ancien a fortement inspiré le plus moderne, et le second en retour a apporté des solutions franches et radicales qui ont boosté le premier. Les deux se livrent à une concurrence de sorte que l'ancien veut absolument rester indépassable tandis que le moderne procède d'une vision plus globale des choses en se chargeant de tâches hétérogènes. Finalement les deux lient des liens de complicité et finissent par faire appel à leurs dispositifs réciproques en diverses occasions. C'est vraiment une histoire de dingues ; On se demande comment tout cela va finir.

Tien, rien qu'en écrivant ces lignes (ce que je fais sur tlex.fr/art) j'ai eu à rajouter une image provenant du bureau, et je viens de m'apercevoir qu'il suffisait de rajouter une ligne de code (dans mon truc) pour obtenir le plus élégant système d'upload d'image par glisser-déposer qui n'ait jamais existé, sans aucune source, et forcément parfaitement compatible universellement. Juste pour dire.

A propos de Fractal

Fractal, le système le plus récent, est un outil bureautique permettant de joindre n'importe quelle App depuis la barre d'url. Chacune de ces App pourrait donner lieu à un site dédié, en offrant un service précis, qui suit des règles standards concernant la publication des données, qui peuvent l'être à des groupes d'amis ou rester confidentielles. Mais j'ai tout mis sur socialnetwork.ovh.

Au niveau de la Dev il suffit de créer un objet du nom de l'App et elle est aussitôt joignable avec ses tables associées, ses nombreuses configurations possibles, et toute la partie créative du développeur qui est logée dans la supplantation de parcelles du dispositif-maître.

Le dispositif-maître s'appelle Appx, c'est un composant abstrait, qui est appelé en toutes circonstances à un moment où à un autre, sachant que chaque App consiste à administrer une pile de données.

Il y a aussi une série d'Apps plus simples (/com) qui ne font appel à aucune infrastructure logicielle, et permettent de faire des outils d'utilité immédiate, sans base de données.

Mais même là, sur une page blanche, il y a un environnement, qui notamment logue l'utilisateur et flatte un peu son égo, avec des messages qui apparaissent dans sa langue. L'environnement Est le logiciel, c'est lui qui consomme le plus de temps.

A l'origine de la volonté d'écrire un framework il y a eu le constat selon lequel il fallait diriger, orienter les factorisations possibles des nombreux dispositifs qui sont tous faits pour être répétés n fois. La façon de rendre génériques les fonctions courantes fait le framework. Aussi, avec la pratique qu'il engendre lui-même, on est forcés de le remodeler périodiquement. Ainsi certains dispositifs vieillissent et deviennent obsolètes après avoir été des stars (une star est une fonction très demandée). Il est logique dans une première décennie de développement que les composants fondamentaux aillent en se divisant et en se multipliant. Il appartient aussi à cette décennie de se préoccuper des protocoles invisibles, seulement logés dans la tête de l'utilisateur, qui permettent un gain providentiel de cohérence et de puissance du logiciel. Non parce que s'il faut tout expliquer partout, en permettant autant de pratiques que de fonctions, avec 1500 fonctions actives simultanément (à chaque clic) ça devient ingérable.

La structuration du logiciel est littéralement sculptée par le plaisir qu'on peut avoir à le développer, c'est le plus important car c'est un facteur d'harmonie, et finalement de performance du logiciel. L'harmonie, il faut le dire, n'est pas un terme abstrait, c'est le score rendu par un algorithme qui vérifie la cohérence des composants, et le rapport d'efficacité énergétique de l'activation de n'importe quel groupe utile de composants. En tout état de cause le logiciel ne peut exister qu'en restant à taille humaine. Et la factorisation, à chaque couche de complexité, permet d'activer des dispositifs ancestraux et extrêmement complexes en un simple et fiable branchement.

Et du plaisir, on en a quand on peut apprécier l'augmentation à la fois lente et méritée, et à la fois surprenante de ce que - ce sur quoi on travaille - devient capable de faire, et de potentiellement entrevoir.

Historiquement, quand j'étais petit, je reprenais des techniques du web et je les décomposais pour en comprendre la substance, de la rétro-conception, ensuite de quoi est née l'idée des CMS qui consistaient à modeler ces tas de capacités en un tout organique.

Il y a qu'ensuite chacune de ces compétences a continué d'évoluer selon son propre chemin, parfois en devenant des institutions, ou du moins de politiques, et enfin de nouvelles bases ou fonctions natives qui les intégraient.

C'est pourquoi le développement à long terme d'un logiciel est empli de mutations qui peuvent se dérouler à n'importe quel endroit, d'abord en niant leur utilité, puis en les imitant et enfin en se conformant à la pratique la plus usuelle, à l'occasion d'une jolie petite refonte locale. Oh, je sais, il y a plein de systèmes d'information aujourd'hui qui en sont à leur première ou deuxième refonte globale, en se fiant à des dispositifs que je juge "à la mode du moment", mais une fois que tout sera correctement installé et harmonique, dans la deuxième décennie d'un système d'information, les refontes sont plus chirurgicales. Et c'est vraiment le mot, il faut mettre un pontage, avoir des outils, et recoudre le tout à la fin. Et revenir après chercher l'outil oublié dans la plaie.

Bref ceci pour dire qu'il m'est apparu hors de portée d'envisager d'utiliser des dispositifs déjà existants et créés pour répondre à des complications qui appartiennent déjà au passé ; puis d'en dépendre à chaque nouvelle mise à jour. A la fin ça devient infernal, où est le plaisir ? C'est pourquoi au lieu de me conformer aux pratiques, ils est bien plus intelligent productif et efficace de réinventer la roue en permanence, contrairement à ce que la mode de 2014 disait. En en l'occurrence, il s'agit seulement d'adapter les innovations, dont on aura capté l'essence, à un environnement dont on connaît déjà par cœur tous les engrenages et toutes les manettes. C'est comme cela que s'obtient la maitrise.

Slide

Pour illustrer ce qui précède, j'ai voulu narrer l'histoire d'un dispositif d'un composant d'une classe nommée Slide.

Dans l'environnement, on a plein d'Apps de bureau - il est conçu selon la mode Apple MacIntosh, avec une barre de menus sensible à l'application en cours d'utilisation, et un bureau d'icônes où on gère ses fichiers - et l'une d'entre elles est en train de devenir une star, avec Art (les articles à la mode Medium), Tabler (on a toujours besoin de tableaux), et dB (Decibels) le gestionnaire de bases de données utilisateur, qu'on devrait tous avoir en standard dans Windows s'ils se souciaient un peu des gens :).

J'ai eu besoin de faire des slides à maintes occasions, pour montrer des fonctionnements, et pour cela j'utilisais des trucs google. Ils ont parfaitement compris l'utilité de proposer des utilitaires de bureau ; le seul truc c'est que je n'aime pas trop avoir à utiliser cette marque, qui est devenue la devanture de la dictature. Au moins ici c'est fluide, efficace, et on ne reçoit pas une pub après.

Et comme c'était trop simple j'ai voulu faire que le slider soit capable de présenter des données arborescentes. A partir de là, mon imagination s'est enflammée. D'abord, c'est un compagnon parfait pour une future application de ce logiciel, qui permettra d'écrire des histoires "dont vous êtes le héros". C'est ce qu'on appelle aujourd'hui des scénarios, dont la maîtrise est indispensable en intelligence artificielle. Sur ce thème j'avais préalablement développé une mécanique faite de portes logiques permettant de naviguer dans une arborescence dont les nœuds pouvaient être explorés de manière potentielle. Mais je n'avais pas assez de matière pour continuer ce travail qui est de la science fondamentale.

Le fait de faire défiler des diapos pouvait maintenant permettre d'explorer des sous-catégories, des détails dans lesquels on peut avoir besoin d'entrer au moment de sa présentation, ou alors continuer son bonhomme de chemin à la surface du sommet des considérations compliquées. C'est très pratique si on veut raccourcir son exposé, ce qui est presque toujours le cas.

Ensuite j'ai eu moi-même à étudier un cas qui se présentait sous forme de scénario, avec des fins possibles et des liens d'influence entre chacun des nœuds. Déjà rien qu'en voyant cela on peut entrevoir l'ombre d'une lointaine future infrastructure de prédiction d'événements.

Mais bon pour l'instant il s'agit juste de présenter des faits avec un principe de tiroirs à ouvrir au cours de l'exploration. Ainsi on pourrait concevoir des histoires dont il serait possible d'interroger des motifs qui soutiennent n'importe quelle affirmation, et de là on peut même imaginer une application de Sherlock Holmes, où il faut enquêter au bon endroit et relier les faits entre eux pour obtenir une cohérence (une harmonie) et en déduire une logique. Oui, bonne idée, truc à faire.

Et ce qui m'a amené ici c'est ce cas particulier et à la fois parfaitement classique du développement, au moment où on croit avoir finit son super slider avec des pages liées entre elles de façon verticale et horizontales, un gestionnaire de couleur de fond, de dégradés enregistrés et d'images, une possibilité de faire de chaque slide directement une page web à part entière, qu'on peut faire défiler et dans laquelle on peut placer des médias. Quand j'ai réalisé cela, j'ai fais du Slider mon principal élément de travail, plus important que les articles, puisqu'on peut être directif, succinct, laisser l'utilisateur libre de choisir sa navigation dans la présentation des éléments, et surtout parce que de concevoir un tel objet nécessite au préalable un travail de synthèse, une documentation, des brouillons en papier, ce qui fait toute la valeur des présentations (sa substance). Le logiciel permet de pousser son travail de synthèse au point de le structurer, et ça c'est génial. On peut vraiment présenter des déroulements faits de cas de figure, et en avoir une vue d'ensemble. Alors du coup il a fallut aussi permettre d'exporter et d'importer des contenus structurés, en utilisant comme dans OpenOffice les balises H pour la structure des chapitres.

Et c'est là quand on croit que tout marche bien qu'arrive l’écueil, le moment où on se dit qu'il faut une numérotation séquentielle des diapositives qui fasse le tour complet, pour pouvoir utiliser le logiciel dans sa version "simple", où il suffit de faire tourner la molette de la souris pour avancer. Parce durant l'édition (dans la pratique) si on déplace un objet numéroté, toutes les références à ce numéro de slide doivent être impactées. En réalité quand on demande cela, on demande à faire que la forme de l'arborescence reste identique, hormis la modification qu'on a faite.

Et là, le drame c'est de suivre la logique de développement pas à pas en se demandant où cela va nous conduire. Alors, il faut changer les références à la slide renumérotée, mais il faut aussi renuméroter les autres. Ah oui, et puis quand on renumérote une slide, on doit au préalable vérifier que ce nouveau numéro n'est pas déjà utilisé en référence à une autre slide. Mais il faut refaire cela itérativement, en se demandant ce qui a déjà été modifié ou pas. On se dit qu'il y a sûrement une fin à cette triple infinité de possibilités.

Si on devait écrire l'algorithme qui fait ce que je viens de dire, et qui est exactement et rien d'autre que ce qu'il faut faire, on se plante. Il est visiblement hideux de consacrer 50% du code de l'App pour une fonctionnalité subalterne dont personne ne doute de l'existence, en croyant d'instinct que c'est logique, que ça se fait tout seul, ou simplement en ne s'en étant jamais rendus compte. Pourtant cela doit exister depuis la nuit des temps (de l'informatique, c'est 1970). Alors comment fait-on ?

C'est amusant parce que mine de rien, savoir faire, et comprendre comment marche les simples petites choses de la vie de l'informatique, à la fois, nous les précurseurs de ce nouveau monde, on les expérimente chaque jour, et à la fois c'est ce qui devrait être enseigné dans les écoles, c'est à dire, à réfléchir par soi-même. Non pas pour savoir comment on fait, cela on finit toujours par le savoir, mais pour savoir comment on l'a découvert, et en l'occurrence, à quelle somme de problèmes il a fallu répondre, au moyen d'une méthode qui finalement est parfaitement simple et bête.

Franchement, je me disais que je n'avais jamais rencontré de problème de logique plus complexe que celui-là, parce que vraiment, c'est quasiment impossible de traiter des matrices dynamiques de données qui s'influencent toutes les unes les autres à n'importe quel moment. C'est quand même ça, le problème. Mais la solution, elle, tient en quatre lignes de code. Il faut juste sortir de son habitude de vouloir enregistrer les données, de traiter les slides une à une, et de son habitude de vouloir penser chaque événement de manière séquentielle, en se disant "alors toi, tu fais ça, mais toi avant, tu lui as dit qu'il était devenu comme ça...". Et de son habitude de vouloir économiser du processus, là où un grand coup de balai règle tout d'une traite, et de façon bien plus rapide, radicale et indubitablement fiable.

Sur cette photo d'écran, on peut voir l'état de la structure, avant et après, une modification entraînant des conséquences en chaîne, sur une arborescence-test minimale.