Nœud spécialisé : tninfo.elois.ifee.fr

Bonjour cher duniterriens :slight_smile:

Suite aux rml8 je me suis amuser à faire un petit nœud spécialisé qui liste les membres ayant expirés ainsi que les membres qui doivent renouveler leur demande d’adhésion avant ‘d’ jours.

Après quelques péripéties j’ai réussi à héberger ce nœud spécialiser sur ma VM, il est accessible à l’adresse suivante : http://tninfo.elois.ifee.fr/expire

J’ai profiter de l’occasion pour héberger aussi mon nœud membre sur ma VM (je le tournais seulement sur mon PC perso jusque là). Je tourne donc 2 nœuds sur la même machine, ça ne semble pas poser de problème particulier ^^

Une question reste en suspend pour les mises à jours. Mon nœud spécialisé est une compilation du dépot rml8-noeud-specialise, hors ce dépôt ne sera pas mis à jours ?
En ce cas, comment transposer le code spécialisé dans une install classique ?

5 « J'aime »

Très bon. Remarque : le paramètre “nombre de jours” ne change pas…

1 « J'aime »

Merci comme ça fonctionnais en local chez moi je ne me suis pas rendu compte que j’avais oublier un $ dans le proxy nginx pour transmettre les paramètres…
c’est corrigé :wink:

1 « J'aime »

Vous noterez qu’il y a encore 48h, 9 membres avaient perdu leur statut de membre, deux d’entre eux ont renouveler entre temps, il s’agit de vit et Thatoo :slight_smile:

1 « J'aime »

Voilà qui fait plaisir à voir ! Superbe contribution :slight_smile:

Par contre je pense que le mois affiché est faux, il y a un décalage de 1 mois avec les vraies dates. C’est certainement dû à ce que le mois 0 vaut pour janvier.

Moi ça me va très bien, ça nous fait de la montée en charge réseau ce qui un test très important !

La meilleure chose à faire est de forker le dépôt rml8-noeud-specialise et de maintenir toi-même la version de Duniter qui se trouve dans package.json.

En cas de mise à jour de Duniter, tu n’as qu’à changer ce n° pour le nouveau (0.50.3 par exemple) :

"duniter": "0.50.3",

Puis un petit coup de yarn et relancer le nœud. Servir chaud.

edit : ou encore plus simple :

"duniter": "*",

Ce qui a pour effet de prendre la toute dernière version disponible quoi qu’il arrive. Il faut quand même lancer yarn et relancer le nœud pour que la mise à jour soit effective.

2 « J'aime »

Merci pour ton engouement,
c’est ma 1ère contrib et j’espère pas la dernière, ce petit exercice était un bon bac a sable pour rentrer dans le code.
j’ai toujours coder seul dans mon coin et tout appris en auto-didacte alors je ne connais pas github et toutes les conventions à respecter entre développeurs donc je m’excuse par avance mais je vais certainement faire toutes les erreurs à ne pas faire !

Je viens de forker le dépot rml8-noeud specialise comme tu me l’a conseiller et j’'ai modifier le fichier package.json avec “*” pour la version du duniter comme ça plus besoin de le modifier à l’avenir.

Le code source du script qui tourne ce nœud spécialisé se trouve dans le fichier : expire_members_specialized_node.js

4 « J'aime »

Merci pour ce nouveau nœud. Il me reste 97 jours :thumbsup: !

1 « J'aime »

petite remarque : si vous tapez 180 jours vous obtenez la liste complète des 206 membres de testnet :wink:

1 « J'aime »

Attention changement d’adresse, il faut enlever le /1 à la fin !
Nouvelle adresse : http://tninfo.elois.ifee.fr/expire/

Je viens de rajouter le tri des membres par ordre croissant ou decroissant de date de dernier renouvellement :slight_smile:

j’ai mis à jours le script source expire_members_specialized_node.js

On peut maintenant facilement voir que 9 membership vont expirer d’un coup vendredi prochain !
Est ce que les clients actuels affichent une notification de rappel quand l’échéance approche ?

Un service que je trouverai utile serait d’être notifier par message lorsque l’échéance approche,
c’est déjà prévue dans cesium+ ?

Non, Césium et Sakia sont buggés et n’affichent plus que le statut de membre va expirer.

Extra cette contribution ! :wink:

il vaut mieux que tu me détaille ton idée. On arrivera peut-etre pas à la même fonctionnalité.
=>

Je viens de remarquer que le 1er tableau “membres dont le statut a déjà expiré” ne correspond pas à la réalité que l’on peut constater ici : http://cgeek.fr:9330/wot/members

Il y a un décalage probable d’au moins 2 jours.

Source : 36 Membres vont expirer d'ici le 17 Décembre!

1 « J'aime »

merci en fait j’avais remarquer, c’est parce que mon script considère un membership comme expiré au delà de 180 jours. Ce qui reviens a estimer que tout les mois font exactement 30 jours, c’est évidemment faut.
Entre le 1 juin et le 1er decembre, il y a eu 183 jours, d’ou le décalage de 2/ 3 jours !

EDIT : C’est mis à jours, le noeud prend désormais en compte les mois à 31 jours ^^
En revanche la précision se limite toujours au jours près, pas à l’heure !

1 « J'aime »

C’est acceptable à mon avis :slight_smile:

Refonte totale des requêtes SQL pour s’adapter au nouveau format index de la base SQLite.

l’adresse du nœud spécialisé est toujours la même >> http://tninfo.elois.ifee.fr/expire

J’en ai profiter pour renommer le dépôt github par un nom plus explicite :
https://github.com/librelois/duniter-expire-members-specialize-node

Tout ce passe dans le script expire_members_specialized_node.js.

Attention, étant donné qu’un nœud ne peut fonctionner que sur une seule monnaie, lors du passage à la monnaie gtest, j’hébergerai un nouveau noeud expire-members pour gtest qui remplacera le noeud actuel !

J’ai ajouter une colonne précisant la date d’expiration, ça évitera à l’utilisateur de la calculer de tête :wink:
Pour l’instant les fonctionnalités de ce nœud spécialisé sont très basiques, mais si vous avez des suggestions d’améliorations vous pouvez les exprimer ici :slight_smile:

@cgeek, le format de la base SQLite va t’il encore sensiblement changer d’ici la version 1.0 ?

Pour info, lorsqu’un process standard de modularisation sera en place, je compilerai mon script en un simple module qui vous pourrez ajouter à votre nœud comme bon vous semble ^^

3 « J'aime »

Hé bien, on ne peut pas dire que tu traines !

J’ai regardé le code, j’ai simplement 2 remarques :

  • quand tu convertis un bloc en temps, tu utilises le champ time. Est-ce volontaire d’utiliser ce champ qui donne ce temps local au nœud émetteur du bloc ? Le temps commun étant plutôt dans le champ medianTime.
  • as-tu vu que la date d’expiration d’une adhésion se trouvait directement dans m_index.expires_on ? Je crois que tu le calcules actuellement, mais tu pourrais prendre directement cette valeur qui est celle utilisée par le nœud lui-même.

En tout cas, je dois dire que ça fait réellement plaisir de voir des développeurs s’approprier le sujet sans même me demander. Ça me conforte dans l’idée qu’il est temps de vous donner les clés pour poursuivre les développements, et que les choses peuvent aller très vite :slight_smile:

Non, il sera identique.

J’en suis arrivé à un point où le cœur lui-même ne devrait plus changer sensiblement, et ce que je souhaite est développer l’API de modules afin de limiter mes interventions, et que ce soit bien vous, développeurs actuels de modules, qui preniez le relais en étendant les fonctionnalités du cœur. Il me semble que c’est la voie royale, le cœur n’ayant pas ou peu vocation à changer (sauf changement de protocole).

Je vais commencer à développer tout cela cette semaine.

2 « J'aime »

C’est parce que je n’ai modifier quasiment que les requêtes. J’ai garder la même structure de code.

Merci pour cette subtilité que je n’avais pas saisie. Je vais donc utiliser medianTime à la place de time.

Oui j’ai vu mais si j’utile expired_on c’est la cata… je doit revoir toute la structure de mon code !
Ma priorité était de faire une maj qui fonctionne. A terme j’utiliserai expired_on :wink:

Super, ça c’est une bonne nouvelle. :slight_smile:
En passant, je te félicite pour la très rapide avancée de Duniter en si peu de temps. Il y a trois mois encore c’était la 0.3 !

2 « J'aime »

GTest est en approche … !

2 « J'aime »

Ce serait chouette d’avoir des fonds de couleur de bleu à rouge selon qu’il reste peu ou bcp de temps avant sortie de la WoT

1 « J'aime »

Nouvelle mise à jours de mon nœud spécialisé, avec 4 commits :

1/ utilisation du champ medianTime au lieu de time
2/ utilisation de m_index.expires_on pour obtenir directement la date d’expiration du membership courant
3/ Autonomisation du code vis à vis de la monnaie, je vais chercher la valeur de msValidity dans le bloc#0 au lieu de la définir manuellement. Ainsi, le même code devrait fonctionner pour gtest :wink:
4/ Mise en place d’un dégradé du vert au rouge pour les membres en fonction de la proximité de la date d’expiration (couleur définie relativement à la durée msValidity, pour rester indépendant de la monnaie).

le script source >> expire_members_specialized_node.js

L’adresse du noeud est toujours la même >> http://tninfo.elois.ifee.fr/expire

EDIT : pour “voir” le dégradé de couleurs correctement, il vous faut afficher un grand nombre de membres. par exemple tout les membres. (il suffit d’indiquer un nombre de jours supérieur ou égal à msValidity, 183 jours pour test_net)

4 « J'aime »