Woah, merci @elois pour ta réponse !
On devrait éditer le 1er post pour lister les questions/réponses comme ça…
3, 4, 10 coups même ! En tant que dev qui a envie de bien faire, ce n’est pas super motivant d’avoir à bricoler de l’existant pour arriver à ses fins alors que l’on sait que l’on pourrait faire mieux et plus simple en repartant d’une bonne base. Et en plus ça va profiter à toute la communauté, c’est enthousiasment !
Oui, Hasura construit une api graphql sur une ou plusieurs bases de données postgresql mais aussi des bdd sql. Moi je ne vais pas regretter du tout ElasticSearch. C’est un moteur de recherche est je n’ai jamais compris l’intérêt de l’utiliser comme base de données. En termes de perf, Hasura peut tenir un million de connexions websocket. On a de quoi voir venir. J’ai des fonctions postgresql pour faire de la recherche en langage naturel, et de la recherche par géolocalisation. Hasura transforme n’importe quelle vue et fonction postgresql en api graphql… Avec les remote schemas, c’est un outil vraiment génial pour construire une architecture en microservices. Si vous voulez tester en 2 min, il y a https://cloud.hasura.io/ ou sur heroku.
Ce n’est pas qu’un moteur de recherche. Il permet de faire du schemaless : stocker du JSON directement, en indexant chaque attribut et donc de permettre de faire des recherches ET des calculs (AVG, SUM, COUNT, etc).
Le gain de temps est énorme, surtout quand le format des documents changent beaucoup (ex: les blocs, les profiles, etc.). Mais tout cela est sans doute moins utile, maintenant qu’on a un framework bien cadré comme Substrate. Je vais regarder du côté de Hasura. J’avoue que ca m’arrange de ne pas à avoir à migrer les pod Cesium+
Très bonne initiative @llaq . Cependant je pense que @elois gère sa CI lui même au mieux, car il est expert git ^^
Mais il te dira si il a besoin d’aide je pense
Tikka va être publié rapidement sur notre gitlab.
C’est un client de bureau qui se veut le plus complet possible.
La partie api n’a pas été encore faite. C’est le moment idéal pour coder en python ce qui est nécessaire pour piloter substrate.
Ya plus ka.
S’il existe des bibliothèques python pour substrate, je ne sais pas si une bibliothèque commune est encore utile . sûrement, à réfléchir car ça ralentit les développements (pour ne pas impacter tous les clients encas d’erreur ).
En fait je vais pas faire de tag pour l’instant c’est trop tôt, mon besoin le plus urgent c’est d’avoir une CI qui controle les MR, vérifier que fa compile bien, que les tests passent, et vérifier fmt et clippy aussi
Tout d’abord, ravi de voir qu’une nouvelle dynamique d’évolution règne autour du projet G1. Je suis un adepte depuis plusieurs années, j’ai beaucoup œuvré pour faire connaitre la G1 notamment au sein du groupe monnaie libre touraine depuis au moins 3 ans.
Je constate aujourd’hui une sorte de plafond de verre (ou résistance) autour des 3000 utilisateurs. A vous lire, on peut imaginer que cela est dû à des problèmes techniques, je pense que c’est bien le cas mais je crains que ce ne soit que secondaire.
Face à cette stagnation d’intérêt de la G1, j’ai fini par m’intéresser plus largement à la technologie blockchain et donc tout l’écosystème des cryptomonnaies. Aujourd’hui j’ai fortement l’impression que la résistance des 3000 utilisateurs soit aussi du au fait que la G1 ne puisse avoir une perspective de listing sur des exchanges, ni de conversion vers d’autre monnaies.
Je m’intéresse trouver des crypto-éthique tel que la G1 mais que l’on peut convertir.
Avec ce nouveau projet y aurait-il des perspectives de conversion ?
Belle journée
Je pense aussi que la technique n’est qu’une cause secondaire de la lente croissance de la G1, mais la technique actuelle ne permettrait pas de croître beaucoup plus, de toute façon. La changer ne résoudra pas tout, mais c’est nécessaire.
Le problème de la conversion est un problème de manque d’utilisation réelle : techniquement les échanges sont possibles. C’est l’offre qui manque. Et si le manque d’offre de conversion vers d’autres monnaies est perçu comme un frein, ça peut juste signifier que l’offre dans la monnaie est trop faible.
Cependant l’utilisation d’un framework assez répandu permettra plus d’interopérabilité avec d’autres outils, donc peut-être une mise en place plus facile d’outils de conversion. (mais il faudra toujours trouver des gens prêts à faire les conversions)
Oui clairement, plusieurs blockchains substrate sont déjà listés sur des exchanges, donc techniquement ont pourrait lister la Ğ1 infiniment plus facilement.
Je suis d’avis également que c’est indispensable pour que la Ğ1 se développe, mais pas suffisant bien sur
Génial, si tu peux t’occuper de la dockerisation à ma place ce serait top, je sais très bien le faire, mais je gère trop de truc faut que le délègue, tu veux les droits sur le dépôt pour pouvoir pousser une branche ?
Utiliser PolkadotJs apps pour interagir avec ta blockchain locale comme je le montre dans mes vidéos
Juste pour info, pontem est basé sur substrate et polkadot.
Pontem est une blockchain de test pour diem (anciennement libra), la future crypto-monnaie de Facebook !
Je réponds un peu tardivement, mais j’ai voulu prendre le temps de vérifier les promesses tenues par ce framework. Car effectivement, si celles-ci sont tenues alors cette découverte serait une excellente nouvelle pour la Ğ1. Vraiment, une très très bonne nouvelle.
Néanmoins, les promesses n’engagent que ceux qui y croient. Alors j’ai voulu les vérifier je n’ai pour l’instant pas réellement trouvé de whitepaper ou quelque chose s’en approchant.
Avez-vous des liens ? Je cherche à répondre à la question : « quel est le protocole Substrate ? ».
Il n’y en a pas justement, Substrate se situe un niveau d’abstraction au-dessus, c’est ce qui le rend autant customisable. Substrate fourni un cadre permettant de se concentrer sur son cœur de métier, sans se soucier de tout un tas de truc indispensables au fonctionnement d’une blockchain (la couche réseau, la synchro des blocs, l’api, les meenpool, la base de donnée, etc).
Et pour nous aider à coder notre runtime wasm, une sous-partie de substrate (facultative), un framework dans le framework, c’est FRAME:
C’est FRAME et ses macros qui permettent de générer automatiquement une grande partie du boilerplate code à partir de la logique métier que l’on déclare, c’est ce qui permet d’aller si vite
Enfin FRAME viens avec de nombreuses palettes (sorte de «modules» ultra génériques), on peut choisir quelles palettes on veut prendre et les configurer conformément à nos besoins. Par exemple dans ma PoC toute la gestion des transferts de monnaie et des soldes est gérée par des palettes pré-existantes (balances et transaction_payment).
Hello !
Donc, j’ai un peu regardé pour la CI, je pense que pour m’épargner du travail, ce serait bien d’attendre l’image docker de @Pini, ça permettrai de pas faire du travail en double
Ben la CI et la dockerisation c’est deux trucs biens différents même s’il y a des liens, et je vais avoir besoin d’une CI rapidement alors propose déjà ce que tu as
En fait, je trouve que tout est lié
Plus sérieusement, gitlab CI utilise une image docker, donc c’est à peu prés la même chose.
Je vais pour l’instant partir de l’image Rust fournie par docker hub, j’ai fait des tests sur alpine, mais je pense que je vais passer sur debian.