Développement de wotmap

Je cherche à automatiser le déploiement de la wotmap avec un fichier .gitlab-ci.yml inspiré de celui qu’avait fait @1000i100 :

.gitlab-ci.yml
stages:
  - build
  - publish

update-data:
  stage: build
  image: python:3.6.8-alpine3.9
  script:
    - wget http://g1.1000i100.fr/duniter.db
    - mkdir -p /var/lib/duniter/.config/duniter/duniter_default/
    - mv duniter.db /var/lib/duniter/.config/duniter/duniter_default/

    - mkdir -p /var/www/wotmap/
    - cp -r ./ /var/www/wotmap/

    - python3 /var/www/wotmap/script/wot_json.py -d

    - mv /var/www/wotmap ./release
  artifacts:
    untracked: true
    paths:
      - release/
  only:
    - master

pages:
  stage: publish
  image: python:3.6.8-alpine3.9
  script:
    - mv release public
  artifacts:
    untracked: true
    paths:
      - public
  only:
    - master

La méthode utilisée par @1000i100 ne permet pas d’avoir les données à jour puisque le script ne se lance que lors du git push. De plus, vu que la BDD de Duniter a changé de format, je ne vois pas trop comment faire pour importer les données dans le conteneur Docker. L’idée la plus pertinente qui me vient à l’esprit est de monter directement le dossier de la machine hôte (/var/lib/duniter/.config/duniter/duniter_default/data/leveldb/) dans le conteneur mais cette discussion sur Stackoverflow dit que ce n’est pas possible

Est-ce que quelqu’un aurait une idée ?

EDIT :serait-ce une piste ?

Si, puisque le script se lance au git push ET peut être lancé sous forme de CI récurente, comme un cron, quotidiennement par exemple.

En revanche, effectivement, pour reprendre le principe que j’utiliser avec la nouvelle BDD, il faudrait exposer cette nouvelle BDD qui n’est plus en un seul fichier, en télécharger les éléments puis en extraire les info souhaitées.

Autre possibilité, maintenant que le sync est rapide : créer un noeud et faire une sync dans la CI.

1 J'aime

@Pierre_Jean_CHANCELL ce serait amusant de pouvoir jouer une animation avec l’évolution de la toile du premier bloc jusqu’à son état actuel, un peu dans ce genre là.

Par ailleurs, je me demandais pourquoi ton programme n’enregistrait pas la position des nœuds directement côté serveur pour éviter de calculer le layout à chaque chargement de la page.

2 J'aimes

En fait le programme côté serveur qui génère la liste des nœuds calcule déjà les positions, mais il n’est pas assez efficace. Du coup on recommence côté client avec une bibliothèque plus efficace. Le prépositionnement côté serveur permet tout de même de raccourcir la durée de calcul côté client.

2 J'aimes

Oui j’y ai pensé :wink: D’autant que le premier outil de visualisation web de la WOT montrait l’évolution de la toile au cours du temps. C’était écrit en PERL si je ne me trompe pas.

EDIT : Bah tiens, je viens de retrouver le code source.

Je pourrais ptet me pencher un peu plus sur la question mais est-ce vraiment d’une grande utilité ?

1 J'aime

La vue en 3D (espace-temps) est forcément utile, mais reste encore a voir ce qu’on veut montrer :slight_smile:

j’y vois surtout le côté artistique. ça peut montrer l’évolution de la toile, son accélération, son ralentissement… Après je vois pas trop

2 J'aimes

C’est donc une question d’outils ? Ça doit être possible de faire tourner les outils clients côté serveur pour récupérer les positions une fois pour toutes, du moment qu’elles sont calculées à un endroit. Mais c’est vrai que je suis le premier à vouloir éviter de faire tourner du javascript côté serveur.

Utile, non, amusant, si ! Ta wotmap aide beaucoup à la compréhension de la wot pendant les présentations, une version animée aiderait à raconter son histoire.

1 J'aime

@Pierre_Jean_CHANCELL Si tu veux l’intégrer dans la wotmap, ça m’intéresserait d’adapter le script Python pour faire ça. Par contre il faudrait pouvoir lire la blockchain afin de construire l’index pour un bloc donné.

Et puis on ne peut pas stocker les positions de tous les nœuds pour chaque bloc, donc il faudra choisir la fréquence. Pour éviter de recalculer plusieurs fois les graphes passés on peut les archiver.

SigmaJS permet de rajouter des noeuds dynamiquement au graphe. En remettant le layout dynamique tel que je l’avais fait au début, on verrait la toile évoluer mais le CPU va prendre cher :stuck_out_tongue: Pour faire ça, il faudrait tout l’historique des dates d’entrée et de sortie des membres.

Voilà. Mais le seul historique qu’on a est la blockchain, et on ne peut pas demander ces calculs au client, donc mon idée est de calculer le graphe côté serveur pour tous les instants voulus.

Actuellement le JSON fait 3 Mo, donc même avec seulement 1 graphe archivé par mois, on arrive à 72 Mo pour 2 ans, ce qui fait trop…

Tout ça m’amène à la réflexion que la toile, comme tout système distribué dont chaque nœud agit indépendamment, n’est pas nécessairement représentable entièrement. Par exemple, l’univers, pris à une grande échelle, forme des filaments de superamas de galaxies. Mais on ne peut jamais représenter en réduit l’univers entier, parce que premièrement ça reviendrait à réduire les actions indépendantes de 10^beaucoup objets à l’action d’un seul (un processeur informatique) ; deuxièmement parce que nous ne voyons pas l’intégralité de l’univers, pourtant nous sommes quasi-sûrs qu’il s’étend au-delà de notre champ de vision. (ce dernier point d’approche du concept d’Holochain)

1 J'aime

Il reste toujours la possibilité de rendre certains nœuds mobiles sélectivement. Par exemple, lors de l’ajout d’un nouveau nœud on rend celui-ci mobile ainsi que ses voisins, et on les fixe à nouveau une fois la position d’équilibre atteinte. Ou alors on rend mobile seulement le nœud en focus et ses voisins. Comme ça, on évite les calculs gourmands impliquant tous les nœuds.

Une source d’inspiration pour la wotmap : https://galaxy.opensyllabus.org/

Merci @HugoTrentesaux. Il y a en effet qqes idées à prendre :wink: Quelles sont les fonctionnalités qui t’intéressent sur ce site ?

1 J'aime
  • le temps de chargement est très rapide
  • le graphe est extrêmement lisible
  • le jeu de couleur est agréable à l’œil

mais il manque plein de fonctionnalités par rapport à la wotmap actuelle (représentation des liens, changement de point de vue…)

Là pour le coup, c’est parce qu’on ne peut pas calculer la position des nœuds côté serveur. La bibliothèque python-igraph n’implémente l’algorithme de position des noeuds qui m’intéresse. C’est pour ça que le navigateur (via SigmaJS) est obligé de le faire…

Oui je suis d’accord. Sûrement du à l’algorithme de positionnement des nœuds qui doit être différent de celui que j’utilise (force-atlas). J’avais modifier un paramètre de la wotmap pour améliorer ce côté-là déjà mais y’a ptet encore des choses à faire.

Pour le moment les couleurs sont générées à la volée en fonction du nombre de communautés dans le script Python de @tuxmain . Il est sûrement améliorable mais je ne suis pas très calé pour ça. Voici le bout de code si qqun veut s’y coller :

for i in range(nb_nodes):
	outdata_wot["nodes"][i]["my_community"] = membership[i]
	(r, g, b) = colorsys.hsv_to_rgb(float(membership[i]) / nb_communities, 1, 1)
	R, G, B = int(255 * r), int(255 * g), int(255 * b)
	outdata_wot["nodes"][i]["color"] = "rgba(" + str(R) + "," + str(G) + "," + str(B) + ",1)"

On peut essayer de faire tourner le code SigmaJS côté serveur. Je n’aime pas faire tourner du JS côté serveur, mais il y a plein de gens que ça ne dérange pas :smiley: par contre, je ne saurais pas faire.

Je parlais surtout du choix des couleurs : des couleurs pastel transparentes sans bordure sur fond blanc. Ça permet de voir les régions où plusieurs disques se superposent, et ça sature moins l’œil !

2 J'aimes