En ce qui me concerne, mes compétences s’arrêtent à la relecture mais je suis dispo.
Je peux aussi donner un coup de main, que ce soit pour la rédaction ou la relecture.
Idem pour moi.
Mercin @Inso, en ce qui me concerne je n’ai pas envie de m’impliquer dans la rédaction mais je peut vérifier la cohérence du fond et apporter les éléments de connaissance qu’il manquerais
Pour ma part je ne me sent pas du tout de faire de la rédaction pure, par contre je veux bien me pencher sur de la traduction anglaise…
Et puis sur des infographies aussi, ça fait toujours bien! Ca peut être dans un 2e temps par contre, déjà rédiger les sujets, ensuite lorsque toutes les infos sont là, voir à les présenter sous forme graphiques jolies du genre celles-ci:
image
image
image
image
image
ou encore des éléments inertes (inutiles juste jolis) du genre les cubes dans:
pdf
image
dans site
Excellente l’idée des infographies ! C’est très bien en terme de pédagogie.
Je compte citer en fin d’article tout ceux qui auront participé avec un lien vers les clés publiques pour suggérer des remerciements en ğ1. Ça vous irait ?
Oui ho, m’en fou des Ḡ1 j’en ai plein!!!
La gloire par contre ça me va! hihi
L’objectif est surtout de permettre aux autres utilisateurs de la Ḡ1 de commencer à échanger et donner
Voilà un premier jet sur le plan de la série. Je pars sur 12 épisodes. Potentiellement, 1 épisode par mois.
https://mensuel.framapad.org/p/intro_article_duniter
Hésitez pas à commenter directement sur le pad !
Je viens de me rendre compte qu’il n’y a que 11 articles de prévus !
Si vous avez une idée de 12ème article, je suis preneur
J’ai ajouté un article sur la notion d’API pour les clients et de logiciels parallèles.
Même si le sujet est en gestation et doit être discuté un peu avant de taper du code…
C’est mon dada les APIs et ça manque depuis l’abandon de BMA.
- Il faudrait donc une API pour les clients.
- Utilisant un standard (GraphQL, json-rpc, etc).
- API via une librairie unique par langage.
- API vers Duniter seulement pour des infos déjà en BDD et rapides.
- API supplémentaires vers des logiciels parallèles dédiés (ex: Neo4j pour la WoT, ElasticSearch pour la blockchain).
Il faudrait que les développeurs de client listent les besoins d’informations rapides à recevoir pour établir un cahier des charges de L’API. Mais c’est un autre sujet…
Superbe boulot ! Ce post est précieux.
Merci pour le lien, je vais y mettre mon grain de sel
Idée à ce sujet : référencer tout post technique comme source explicative de chacun des sujets exposés dans le wiki / enrichir le wiki de nouvelles entrées et liens pour chaque nouveau post technique.
À noter que n’importe quel module, et donc notamment une nouvelle API, peut produire ses propres tables intermédiaires stockées dans la base de données de Duniter. Donc a priori, vous pouvez vous lâcher !
J’ai publié l’article sous forme d’une pull request sur github : https://github.com/duniter/website_fr/pull/37
C’est ouvert aux commentaires avant d’être mergé !