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 ?
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é
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
Voilà qui fait plaisir à voir ! Superbe contribution
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.
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.
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+ ?
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
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 !
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
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
@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 ^^
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
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.
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
Super, ça c’est une bonne nouvelle.
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 !
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
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).
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)
!
