15 KiB
Code
1. Autheurs, validations, dates, versions, changement and historique
Cf. Git SDK COMMON
2. Table des matières
-
- 6.1. Stratégie de test
- 6.2. Plan pour les tests unitaires
- 6.3. Plan d'intégration
- 6.4. Plan de charge
3. Documents de référence
Voir _Doc_references.md.
Choix des formats de données
Strings
Les chaînes de caractères (String et &str) sont utilisées pour stocker du texte. String est une collection dynamique, modifiable, possédant une allocation sur le tas, tandis que &str est une vue immuable d'une séquence de caractères.
Cas d'usage commun :
- Manipulation de texte : Lecture et écriture de fichiers texte, interfaces utilisateur, etc.
- Traitement de données formatées comme le JSON ou le XML.
- Communication réseau où les protocoles basés sur le texte sont utilisés (HTTP, SMTP).
Hexadécimales
Les valeurs hexadécimales sont souvent utilisées pour représenter des données binaires de manière lisible, notamment dans le contexte de l'adressage mémoire, du débogage, ou de la représentation de couleurs en informatique.
Cas d'usage commun :
- Affichage et édition de données binaires dans les éditeurs hexadécimaux.
- Définition de couleurs dans les standards web (CSS).
- Représentation compacte d'adresses mémoire ou de grandes valeurs binaires.
Tableaux de bytes
Les tableaux de bytes (Vec<u8v> ou [u8] en Rust) sont utilisés pour manipuler des données binaires. Ils servent à stocker et transmettre des données dans un format qui n'est pas nécessairement du texte.
Cas d'usage commun :
- Lecture et écriture de fichiers binaires, comme les images ou les fichiers audio/vidéo.
- Communication réseau, en envoyant et recevant des données binaires sur les sockets.
- Cryptographie, où les clés, les hash, et les signatures sont souvent manipulés sous forme de bytes.
Format Base64
Le format Base64 est une méthode d'encodage qui permet de représenter des données binaires sous forme de chaînes de caractères ASCII. Il est couramment utilisé pour encoder des données binaires dans des contextes où les données textuelles sont préférées, comme dans le XML, le JSON, ou les courriels.
Cas d'usage commun :
- Encodage d'images, de fichiers audio/vidéo pour leur intégration dans des fichiers HTML ou CSS.
- Transmission de données binaires dans des protocoles de communication qui ne supportent que le texte.
- Stockage sécurisé d'informations sensibles sous une forme encodée.
Différence entre Bytes et Bits
Un byte est une unité de stockage informatique qui contient 8 bits. Un bit est la plus petite unité de données en informatique et peut prendre la valeur de 0 ou 1.
Cas d'usage commun :
- Les bits sont utilisés pour les opérations au niveau le plus basique de l'informatique, comme les calculs binaires ou le stockage de valeurs booléennes.
- Les bytes sont utilisés pour presque toutes les formes de stockage et de manipulation de données, comme le texte, les images, et les instructions de programme.
Little Endian et Big Endian
Ce sont deux manières différentes de stocker ou d'interpréter des séquences de bytes qui composent des nombres plus grands dans l'ordinateur. En Big Endian, le byte le plus significatif est stocké en premier. En Little Endian, c'est le byte le moins significatif qui est stocké en premier.
Cas d'usage commun :
- Little Endian est utilisé par la majorité des architectures de processeurs modernes, y compris x86 et x86_64.
- Big Endian est souvent utilisé dans les réseaux, comme dans le protocole IP pour l'ordre des octets des adresses.
- La conversion entre les deux est nécessaire lors de l'interopérabilité réseau entre différentes architectures ou lors du traitement de fichiers binaires d'origines diverses.
Cette vue d'ensemble donne une idée de l'importance et de la polyvalence de ces concepts en programmation Rust et plus largement en informatique. Chaque élément a des cas d'usage spécifiques où il brille particulièrement bien, aidant les développeurs à choisir la meilleure approche pour leurs besoins.
Conversions de données
Aborder les conversions entre différents formats de données est essentiel dans le développement de logiciels, notamment en Rust, où la gestion de la mémoire et des types est centrale.
Conversion entre Strings et Hexadécimales
-
Préconisation : Utilisez des bibliothèques éprouvées pour convertir les chaînes de caractères en hexadécimales et vice versa. Ces opérations peuvent sembler simples, mais gérer correctement tous les cas d'erreur potentiels peut être délicat.
-
Retour d'expérience : La conversion directe peut être tentante, mais attention aux données non représentables en hexadécimal directement (comme les caractères spéciaux ou non ASCII). La validation des entrées est cruciale pour éviter les erreurs.
Conversion entre Tableaux de Bytes et Format Base64
-
Préconisation : Lors de la conversion de données binaires (comme des tableaux de bytes) en Base64, assurez-vous de comprendre l'impact sur la taille des données. La représentation en Base64 augmente la taille des données d'environ 33%. Cela peut être important pour les performances réseau et le stockage.
-
Retour d'expérience : L'utilisation de Base64 est très pratique pour intégrer des ressources binaires dans des formats textuels (comme des images en HTML/CSS). Cependant, cette facilité d'utilisation doit être équilibrée avec la considération de l'augmentation de la taille des données.
Conversion entre Bytes et Bits
-
Préconisation : Soyez conscient de l'endianess lorsque vous travaillez avec des conversions de bits à bytes et vice versa. Des erreurs dans ces conversions peuvent entraîner des bugs subtils et difficiles à détecter, surtout lors de l'interopérabilité entre différents systèmes ou protocoles.
-
Retour d'expérience : Dans les applications bas niveau ou embarquées, ces conversions sont courantes. L'utilisation explicite de types de données et de fonctions de conversion aide à maintenir la clarté du code et à éviter les erreurs.
Gestion de Little Endian et Big Endian
-
Préconisation : Lorsque vous travaillez dans un environnement hétérogène (différentes architectures de machines ou réseaux), il est essentiel d'être explicite sur l'endianess des données lors de leur envoi, réception, ou stockage. Utilisez des fonctions de conversion dédiées pour modifier l'ordre des bytes lorsque nécessaire.
-
Retour d'expérience : Les erreurs d'endianess sont parmi les plus déroutantes à diagnostiquer. Documenter clairement l'endianess attendue pour chaque interface peut sauver des heures de débogage.
Bonnes Pratiques Générales
- Validation des données : Toujours valider les données en entrée lors des conversions pour éviter des erreurs inattendues ou des vulnérabilités de sécurité.
- Performance : Soyez conscient de l'impact sur les performances des conversions, surtout dans des boucles critiques ou pour des données volumineuses.
- Clarté du code : Préférez des fonctions ou des bibliothèques de conversion explicites plutôt que des manipulations manuelles, pour la clarté du code et sa maintenabilité.
Les conversions entre différents formats de données sont omniprésentes en programmation. Une compréhension approfondie de ces opérations et une attention particulière aux détails peuvent grandement améliorer la robustesse et l'efficacité de vos applications.
4. Gestion des erreurs
Les processus doivent continuer malgré des "sous" traitements/threads en échec et les fonctions doivent être catch si il y a une possiblité d'interuption.
Stratégie de gestion des erreurs et de reporting pour faciliter le débogage et améliorer la résilience du système.
Tous les flux sont reçus par autant de relais et de membres de même rôles. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable par chacun de façon autonome en rapport à sa propre expérience.
Les arrêts de la blockchain dans son ensemble n'entraînent pas d'interruption de service, car les horodatages sont non bloquants, l'impact est une diminution de la preuve le temps de "ré-ancrer" ce qui n'aurait pas pu l'être. L'arrêt de nœuds de la blockchain pourrait ralentir la propagation des informations dans les scénarios les plus critiques, sans impact majeur sur le fonctionnement.
Les arrêts des membres dans les ItemProcess dans leur ensemble n'entraînent pas d'interruption de service, les confirmations restent en attente, toujours relayées jusqu'au rétablissement des services. L'arrêt de membres des rôles critiques des ItemProcess pourrait empêcher le démarrage des services et pour les gestionnaires des membres, l'accès au réseau pour les utilisateurs n'ayant qu'un processus connu avec un rôle dedans. Cela n'entraîne pas une perte des données. Cette incapacité pourrait venir corrompre des signatures attendues dans un délai. Dans ce cas, le rôle "resolve" des ItemProcess est en charge de l'arbitrage pour la bonne restitution des actions.
Les parties prenantes ont tous les moyens organisationnels dans les process, pour procéder au bon redémarrage des services en cas de dégradations et de situations inattendues, avec le versionning des relais et des membres des rôles; ainsi que des conditions contractuelles avec leurs implications opérationnelles et possiblement économiques.
5. Journalisation et monitoring
Tous les utilisateurs reçoivent les mêmes flux qu'ils se relaient et se restituent au démarrage, tous les flux ont une empreinte horodatée sur une timechain et peuvent être demandés unitairement entre parties, avec le même niveau de confidentialité par rôles. Les Pcd sont les listes à jour de l'état de validation de tous les éléments échangés, et les Prd sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un ItemProcess (possible de segmenter par zones et services).
Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents sur les relais qui ne sont pas critiques unitairement, tous les flux sont fongibles, chiffrés, anonymes, et peuvent passer par des relais non révélés. Cependant, l'optimisation des listes de pairs et de contrats, pourrait passer par un système de réputation qui nécessitera un historique. À ce stade, la gestion "qualitative" et "quantitative" des relais et des contrats est gérée en mémoire, non persistée et restaurée par chaque connexion à un nouveau pair.
La timechain permet de monitorer l'activité générale sur la side chain avec un nombre de jetons échangés (le même nombre à chaque message) et des ancrages critiques sont monitorables sur le mainnet publiquement par n'importe qui (mais non exploitable fonctionnellement). Ainsi seul le bon fonctionnement est monitorable, par tous, facilement, sans métadonnées exploitables pour ce qui est des usages qui restent donc confidentiels.
6. Tests
6.1. Stratégie de test
À l'issue du développement en ScrumBan, chaque ticket fait l'objet d'une revue de code, et d'un test par un testeur.
6.2. Plan pour les tests unitaires
Les tests unitaires seront ajoutés par un testeur, ainsi toutes les fonctionnalités reçues auront un test unitaire.
6.3. Plan d'intégration
L'intégration se réalise par sprint hebdomadaire.
L'ensemble des fonctionnalités livrées dans le sprint doivent être testées dans un parcours d'intégration écrit et testé par un testeur en fin de sprint.
6.4. Plan de charge
Tous les 2 sprints, des tests aux limites sont définis et mis en œuvre par un testeur depuis la simulation des comportements des utilisateurs.
7. Outils et les librairies à utiliser
Respect des normes de syntaxe Rust.
Utilisation de Visual Studio (pour le partage de configurations).
À l'étude : revues et pilotage par la documentation depuis une IA et partage d'un chat IA pour la base de connaissance.
-
Environnement : navigateur (tous dispositifs), et relais sous Debian.
-
Développement : pour compilation Wasm.
-
Pas de base de données sauf IndexedDB présent nativement pour les navigateurs et les applications mobiles.
-
Librairies :
rust-bitcoin,rand,hex,bech32,shamir_secret_sharing,uuid,sha2,chrono,aes-gcm,base64,wasm-bindgen,serde,serde_jsondans leurs dernières versions. -
Librairies de tests : Cargo test
8. Critères d'acceptation
Critères de validation pour que le système puisse être considéré comme prêt pour la production :
- Tous les parcours utilisateurs fonctionnels.
- Tous les tests unitaires présents et parcourus.
- Tous les tests d'intégration présents et parcourus.
- Aucun bug bloquant.
- 10 bugs majeurs.
- 20 bugs mineurs.
- Contrôles manquants clairement précisés.
- Documentation manquante clairement précisée.
- Autres tests manquants clairement précisés.
9. CI/CD
GitLab CI : TBD
10. Maintenance
La liste des dépendances doit être maintenue dans le readme des projets, mise à jour à chaque fin de sprint. Les tests de fin de sprint doivent intégrer une revue des dernières versions et alertes sur les librairies en dépendance.