Certes, et, personnellement, je ne m'en prive pas, mais Python est fortement mis en avant.
Le Pi de Raspberry Pi, c'est pour Python (https://www.techspot.com/article/531-eben-upton-interview/), bien que ça soit de moins en moins mis en avant. En outre, les bibliothèques logicielles pour piloter les ports GPIO sont, à la base, en C ou C++, mais ce sont les bindings en Python qui sont le plus utilisés. Et ça vaut aussi pour les bibliothèques dédiées au pilotage de certains robots (Poppy Ergo Jr et consorts).
Les exemples de programmes des tutoriels sur le pilotage de kits ou de robots avec un RPI sont systématiquement en Python, accompagnés parfois de leur version en C ou C++. Il existe des exemples de programmes en Java, mais c'est vraiment exceptionnel.
Merci pour votre réponse, je comprends mieux la démarche du framework Atlas.
Merci de m'avoir donner l'occasion d'éclaircir mes propos !
Quand je parlais de "code serveur" je voulais dire "back-end".
En fait, back-end et front-end sont gérés par le même code source. Plus besoin de front-end en tant que tel.
En tout cas, je trouve l'approche SPA bien plus attractive que les CGI en effet et c'est comme ça que j'anime mes cours de javascript.
Quand je présente le toolkitAtlas, la plupart des gens pensent de prime abord que c'est pour faire des CGI. Il faut vraiment que j'insiste, parfois lourdement, pour leur faire comprendre que c'est pour faire des SPA… En outre, la gestion des SPA est plus proche de la gestion des applications bureau, et repose moins sur HTML.
Je suis d'accord avec vous, c'est un langage difficile d'accès pour les débutants et beaucoup sont perdu avec les différentes syntaxes, les callbacks etc.
Passé cette difficulté, j'ai l'impression d'arriver à faire des choses sympa (un paint, des petits jeux vidéo, un forum websockets etc.) en peu de lignes et cela quasi sans librairie tiers (en js vanilla donc).
S'il y a besoin d'un serveur, je fournis quelque chose de minimaliste afin de leur permettre de se concentrer sur l'interaction utilisateur.
Mon but, avec le toolkitAtlas, c'est de pouvoir ajouter une GUI à un programme aussi simplement que possible, justement pour que le développeur puisse se concentrer sur le cœur du programme.
Je ne saurais dire si JavaScript est adapté pour l'apprentissage. En outre, avec la version Node.js du toolkitAtlas, l'approche est différente de celle du JavaScriptfront-end, mais il reste cependant le système des callbacks.
Je me concentre actuellement sur Python parce que c'est le langage qui est le plus souvent cité lorsque l'on parle d'initiation à la programmation, et, d'autre part, c'est également le langage le plus utilisé lorsqu'il s'agit de piloter des montages électroniques ou des robots connectés à un Raspberry Pi. Et piloter des robots, comme indiqué dans la dépêche, avec un smartphone, ça fait son petit effet auprès des adolescents :-)…
C'est dans cette optique que je questionnais l'intérêt d'Atlas, mais vous avez très bien défendu ce projet et il m'apparaît pertinent dans le cadre d'un apprentissage de la programmation.
Je suis en train de monter un atelier d'initiation à la programmation basé sur le toolkitAtlas, et j'espère le mettre à l'épreuve prochainement. J'espère que les faits vous donneront raison :-)…
Je le vois, ce qui perturbe les apprenants c'est la masse de petites choses différentes à retenir, comprendre etc. et plus l'environnement est hétérogène (c'est le cas pour le web) et plus c'est difficile d'accès.
C'est pour cela que le toolkitAtlas se veut une alternative à tous ces frameworks habituellement utilisés, car l'apprentissage de ces derniers est bien trop ardu pour des débutants. Le toolkitAtlas est, certes, bien moins puissant, mais c'est largement suffisant pour débuter. Libre à eux d'utiliser un framework lorsqu'ils auront acquis les connaissances nécessaires pour le maîtriser.
C'est pour cela aussi que quand je démarre sur Php, je leur fais faire des programme en ligne de commande avant de voir la génération du Html et l’interaction avec une base données SQL. Ce que beaucoup de tuto sur internet font en même temps. Résultat : les apprenants ne font pas la différence entre client et serveur et ont un mal fou à comprendre que le programme Php ne fait que générer du html (ou du json dans le cadre d'API web).
La version PHP du toolkitAtlas est justement prévue pour fonctionner en mode CLI. Pour un langage qui a popularisé les CGI, faire des SPA, en mode CLI qui plus est, ça en perturbe plus d'un :-)…
Bref, l'apprentissage de la programmation reste aujourd'hui quelque chose d'assez rude je trouve et j'en vois beaucoup qui décrochent. Sans doute que l’écart entre leur rapport quotidien avec l'informatique (les smartphones, des applis codées par des milliers de dev pendant plusieurs mois) et ce qu'ils arrivent péniblement à faire en cours. Si le toolkit Atlas peut faire la différence alors c'est top !
Au début, je pensais que le fait de pouvoir facilement accéder aux applications, réalisées avec le toolkitAtlas, avec un smartphone était assez anecdotique. L'idée originale, derrière cela, c'est que les adolescents puissent facilement montrer leurs réalisations à leur entourage ; à leur âge, ils ont besoin de reconnaissance, d'encouragements. Maintenant, je pense de plus en plus que c'est un point essentiel, car cela démystifie le smartphone. Je pense que la plupart perçoive leur smartphone comme un portail vers cette chose mystérieuse qu'est le cloud, dont seules les grosses boîtes, comme les GAFAMs, ont la maitrise. Avec le toolkitAtlas, ils ont un aperçu de ce que c'est, techniquement, le cloud, et j'espère que cela donnera à certains l'envie d'approfondir le sujet, et de se l'approprier.
PS : Je me rappelle avoir codé en quelques heures maxi un jeu vidéo inspiré d'Angribirds en js avec mon fils qui faisait les dessins. Grace aux pages Github et autres services de mise en ligne, on avait quelque chose qu'on pouvait montrer facilement (pas testé sur smartphone mais ça devrait peut tourner) : http://dedesite.github.io/angry_birds_filo/
C'est sympathique. J'aime bien la cinématique, ça fait vraiment penser au jeu original :-) !
Ca m'est marrant, quand on exécute le main, on vois une petite fenêtre dans le navigateur comme si on exécutait le programme python localement.
Bon travail!
Merci, mais je n'ai aucun mérite. C'est parce que le programme tourne dans Repl.it, une application web qui permet de disposer, sans rien avoir à installer, d'un environnement de développement pour pas mal de langages, juste en utilisant un navigateur web. Les logs proviennent de cette appli.
Mais ça fait quoi exactement?
Comme indiqué dans le commentaire plus haut, noyé dans les logs, il y a une URL (elle change à chaque fois) qui, lorsqu'on l'ouvre, propose une interface permettant de faire varier la valeur des différents paramètres de la fonction gaussienne et de voir leur influence sur le graphique.
Avec le programme d'origine, on est obligé de modifier ces valeurs directement dans le programme, ce qui n'est pas très pratique. On peut également modifier le programme pour passer les valeurs de ces paramètres via des arguments de la ligne de commande, ou encore en permettant leur saisie à coup de input(). Seule cette dernière option est présentée dans le guide faisant l'objet de ce journal mais, hormis sa présentation et un exemple de mise en œuvre, elle n'est pas exploitée par ailleurs.
Une autre solution serait de doter le programme d'une GUI. Malgré les indéniables avantages d'une telle interface, une telle option n'est même pas évoquée dans ce guide. Probablement, mais ce n'est qu'une supposition, parce que l'effort nécessité par la mise en œuvre et l'apprentissage d'un des nombreux frameworks existants est disproportionné par rapport aux bénéfices qu'on en retirerait dans le cadre de leur utilisation dans des programmes tels que ceux présentés dans ce guide.
Ces frameworks sont complexes parce qu'ils proposent des fonctionnalités évoluées. Le toolkitAtlas est destiné à être utilisé dans les cas on l'on n'a besoin que de fonctionnalités basiques. Et c'est aussi pour cela que l'utilisation du toolkitAtlas ne nécessite que des connaissances basiques, faciles à acquérir, en technologies web.
J'ai dernièrement fait l'acquisition d'un kit électronique d'apprentissage destiné à être utilisé avec un Raspberry Pi. Il y avait un tutoriel fournit avec ce kit proposant, à titre d'exemple, un programme Python destiné à piloter une LED RGB. Ce programme faisait afficher des couleurs aléatoires par la LED. Là aussi, aucune interactivité. Alors, à l'instar de ce que j'ai fait ici, j'ai modifié le programme pour lui ajouter une GUI, à l'aide du toolkitAtlas, programme que l'on peut voir à l'œuvre ici.
Beaucoup de tutoriels gagneraient en attractivité en proposant des exercices et des exemples de programmes avec un minimum d'interactivité, à l'heure où tout le monde est habitué à manipuler des interfaces graphiques avec leurs smartphones. Et l'un des buts du toolkitAtlas est justement de pouvoir facilement modifier un programme pour le rendre interactif par l'ajout d'une GUI.
Comme indiqué dans ce journal, je cherche des exemples de programmes Python auxquels je pourrais rajouter une GUI, et je me suis permis de modifier le programme gauss-2d.py pour en faire ça. Il faut ouvrir l'URL indiquée dans la console (il peut être nécessaire de scroller vers le haut pour la trouver) dans une nouvelle fenêtre, et mettre les deux fenêtres côte à côte.
Python ne m'est pas très familier, et encore moins matplotlib, donc c'est très largement améliorable, tout comme l'interface.
Les ayant droits avaient jusqu'au 16 avril pour réagir à ma contestation des revendications. Vérification faite, mes vidéos ne sont plus marquées comme faisant l'objet d'une revendication, sans la moindre notification, et j'ai (enfin !) pu les basculer en Creative Commons.
Au final :
publication de mes vidéos,
quelques minutes plus tard :
notification de revendication :
par mail,
au niveau de la vidéo lorsque connecté au compte Youtube,
apparition d'un encart de revendication au niveau de chaque vidéo, visible par tous,
choix de licence limité à la Youtube standard,
contestation de la revendication :
disparition de l'encart de revendication pour chacune des vidéos,
mais :
choix de la licence toujours limité à la Youtube standard,
notification au niveau de la vidéo lorsque connecté au compte Youtube toujours présente,
un mois plus tard (sans aucune notification) :
le choix des licences n'est plus limité à la Youtube standard,
plus aucune notification de revendication au niveau des vidéos.
Concernant l'initiation à la programmation, pour les plus jeunes, il y Scratch, Snap!, Blockly…, qui sont spécialement conçus pour les intéresser, et qui peuvent s'utiliser sur tablette/smartphone. Mais, pour allez plus loin, il faut bien à un moment passer à un langage comme Java, Python, Ruby…, et là, c'est un peu la douche froide.
Avant d'avoir mon premier micro-ordinateur, de tous les appareils que j'avais manipulés, ceux qui s'approchaient le plus d'un ordinateur étaient les montres LCD et les calculatrices, dont d'ailleurs une montre LCD faisant en même temps calculatrice :-). Du coup, le seul fait de pouvoir, avec mon micro-ordinateur, afficher sur un téléviseur le texte de mon choix, de l'animer, de dessiner des figures…, c'était, pour moi, avec l'expérience que j'avais des ordinateurs, suffisamment impressionnant pour me motiver à apprendre la programmation. D'ailleurs, je ne pouvais guère faire autre chose. Les seuls programmes auxquels j'avais accès étaient ceux que je recopiais à partir des sources publiés par certaines revues spécialisées (mes premiers contacts avec l'Open Source !).
De nos jours, la plupart des jeunes ont un smartphone, donc afficher "Hello, World!" dans une console texte, ce n'est pas ça qui va les impressionner, habitués qu'ils sont de manipuler, avec leur smartphone, des applications avec une interface graphique.
Le but du toolkitAtlas est de leur offrir un moyen simple d'approcher de ce à quoi ils sont habitués avec leur smartphone, en leur permettant de facilement doter leurs applications d'une interface graphique. Et, le plus simple pour cela, à mon sens, c'est d'utiliser les technos web. Alors, certes, cela implique d'avoir quelques notions de HTML (CSS est facultatif), mais HTML est simple à apprendre, et il est l'objet de nombreux tutoriels de tous niveaux et faciles à trouver. Et HTML, ça fait quand même partie de la culture générale de tout développeur, et son apprentissage peut se faire en amont et indépendamment de l'apprentissage de la programmation.
Le web vanilla, pour moi, cela désigne deux choses distinctes.
D'une part, c'est de développer en JavaScript pour le navigateur. Or, JavaScript est rarement considéré comme étant le langage idéal pour débuter, sans compter les difficultés lié à la mise en œuvre, si besoin est, d'un back-end. Le toolkitAtlas n'impose pas de langage, et permet de gérer front-end et back-end dans un seul et même programme.
D'autre part, le web vanilla, cela comprend également, pour moi, les applications de type CGI. Or, ces dernières posent problèmes en terme de réactivité. Avec le toolkitAtlas, on obtient des applications de type SPA.
Hormis cela, il y a également la facilité d'accès des programmes s'appuyant sur le toolkitAtlas, permettant au développeur en herbe d'accéder à ses applications sur son smartphone, ou de permettre à d'autres d'y accéder à partir de leur propre smartphone, sans avoir à configurer ou déployer quoi que ce soit, contrairement aux autres framworks web. S'il est suffisamment motivé, ils peut même faire tourner ses applications sur son smartphone, si ce dernier tourne sous Android et qu'il y a installé Termux, pouvant ainsi partager ses réalisations avec ses amis durant les récréations…
Le but du toolkitAtlas est uniquement d'accompagner le débutant lors de son apprentissage, de lui permettre de développer des applications suffisamment intéressantes pour lui en terme d'interaction pour le pousser à persévérer jusqu'à ce qu'il ai acquis les connaissances nécessaires pour développer (s'il le désire) des applications avec une interface graphique (desktop, web, mobile…) basés sur des frameworks traditionnels. L'utilisation du toolkitAtlas n'est pas une fin en soi, mais une passerelle entre les programmes fait avec Scratch et consorts, et des logiciels, disons, plus professionnels.
P.S. Code serveur, je ne vois pas ce que ça désigne…
Quelle alternative existe aujourd'hui pour faire des app multi-plateformes (desktop + web à minima) ?
Avant d'utiliser Electron, j'utilisais Chromium Embedded Framework, qui, comme son nom le laisse entendre, est également basé sur Chromium, et, encore avant ça, j'utilisais XULRunner, qui utilisait le moteur de rendu de Firefox, mais qui n'est plus officiellement maintenu.
Comme indiqué dans le titre, j'ai envoyé ma réponse. Je vous le signale ici, car, à l'occasion d'une précédente contribution, j'avais déjà répondu à un message similaire, en novembre 2018, sans toutefois jamais avoir reçu l'ouvrage (version papier). Donc, si jamais vous ne recevez pas cette réponse-ci non plus, c'est qu'il y a un problème…
Le cas échéant, serait-il possible que ce soit dû au fait que ma réponse soit envoyée d'une autre adresse mail que celle déclarée dans mon compte LinuxFR.org ?
P.S. : Je viens de recevoir le message de la liste prizes, et j'y ai répondu. Mais, je viens de vérifier, c'était également le cas lors du message de novembre 2018…
Par contre, utiliser git et npm pour des débutants, est-ce bien raisonnable ?
Pour npm, n'étant pas développeur web, je ne sais pas s'il est possible de bundler le strict nécessaire.
Le toolkit lui-même n'est constitué que des quelques fichiers présents dans le répertoire Atlas du dépôt. En faisant, à la place du require('atlastk'), un require pointant sur le fichier Atlas.js contenu dans ce répertoire, il n'est pas nécessaire de faire de npm install.
Ceci dit, l'utilisation de npm, c'est surtout pour pouvoir proposer des démonstrations grâce à RunKit,et, comme c'est déjà mis en place, un npm install me semble quand même plus simple que la procédure ci-dessus.
Par contre, pour git, un petit travail de CI pourrait être fait pour pousser un fichier au format zip (par exemple) vers un serveur web, non ?
GitHub offre la possibilité de télécharger l'intégralité d'un dépôt sous forme d'une archive ZIP. git n'est donc pas indispensable pour le récupérer.
Mais vous avez peut-être déjà réfléchi à ça ou testé les options :)
Je suis en pleine réflexion à ce sujet :-) !
La dépêche porte sans doute à confusion telle qu'elle est rédigée, mais le projet, en l'état, n'est pas destiné à être utilisé directement par des débutants. Il n'y a qu'à voir le site web dédié au toolkit, qui est totalement inutilisable pour un débutant. L'utilisation du toolkitAtlas n'est pas une fin en soi. Ce n'est qu'un moyen, notamment pour rendre l'apprentissage de la programmation plus "fun".
Le toolkitAtlas est, pour l'instant, pensé comme un outil destiné, par exemple, à ceux qui animent des ateliers d'initiation à la programmation. Dans ceux auxquels j'ai assisté, des ordinateurs portables (sous GNU/Linux !) étaient mis à disposition avec, déjà installé, tout un environnement de développement. Le toolkitAtlas pourrait alors également être préinstallé.
De manière générale, il ne devrait pas être difficile de modifier les tutoriels de formation à la programmation de manière à y intégrer le toolkitAtlas, pour améliorer l'interactivité des programmes qui y sont proposés à titre d'exemple ou d'exercice. L'installation du toolkit, via éventuellement une procédure maison, pourra faire partie du tutoriel, au même titre que la mise en place du reste de l'environnement de développement.
Cela vaut aussi pour les kits d'électronique ou de robotique destinés à être utilisés avec un Raspberry Pi, tel que celui utilisé dans la vidéo de démonstration présente dans la dépêche. Les tutoriels accompagnant ces kits proposent une série de programmes mettant en œuvre les différents composants inclus dans le kit. Par exemple, pour la DEL RGB, il y a un programme qui fait varier la couleur de la DEL de manière aléatoire. Donc, l'utilisateur câble sa DEL, connecte son montage au Raspberry Pi, y lance le programme proposé dans le tutoriel, admire les jolies couleurs affichées par la DEL et… c'est tout. Ça manque un brin d'interactivité, je trouve. Je pense que les constructeurs vendant ces kits auraient à y gagner de proposer, à la place de ce genre de programme, ou en complément, un programme du genre de celui présenté en seconde partie de la vidéo.
Je me suis jusqu'à présent concentré sur l'aspect technique du projet, d'abord pour en tester la faisabilité, puis pour en produire le MVP. Comme indiqué dans la dépêche, j'ai réalisé quelques démonstrations qui m'ont convaincues qu'il existe un "marché" pour ce projet. J'en suis maintenant à réfléchir comment faire évoluer le projet, mais également comment communiquer à son sujet, pour l'apporter à ceux qui en auront l'utilité, et sous la forme qui leur sera la plus utile.
Toute suggestion est bienvenue, sachant que le toolkitAtlas étant disponibles en cinq langages, et plus à l'avenir, je n'ai pas, et il me sera difficile d'acquérir, les compétences nécessaires pour sa mise en œuvre optimale dans chacun de ces langages.
J'ai publié hier une vidéo sur Youtube (et accessoirement également sur Peertube, mais ce n'est pas le sujet) avec, comme bande sonore, mon interprétation d'une œuvre musicale du domaine public. Pour justement éviter des problèmes de droits d'auteur, j'ai publié en parallèle une seconde vidéo dans laquelle on me voit interpréter cette œuvre, dans l'idée qu'elle serve de preuve que je dispose de tous les droits sur cette bande sonore, notamment celle de l'utiliser dans mes propres vidéos. J'ai mis dans la première vidéo un lien vers la seconde, pour qu'il soit facile de trouver l'origine de la bande sonore, toujours dans l'optique d'éviter les problèmes liés aux droits d'auteur.
Quelques minutes après, simultanément sur les deux vidéos, un encart a été ajouté qui indiquait que la musique de mes vidéos provenait d'une troisième dont le lien était fourni (diablement réactif, le Content ID). Effectivement, la vidéo en question contenait une interprétation de la même œuvre, et il s'avère que les ayants droit ont émis une revendication sur la bande sonore de mes vidéos (qui, je le rappelle, est mon interprétation d'une œuvre du domaine public). Je suppose que cette revendication a été émise de manière automatique par Content ID, et non pas suite à une action spécifique des ayants droit.
Du fait que les ayants droit autorisaient la réutilisation de cette œuvre, mis à part l'apparition de cet encart, la seule autre conséquence que j'ai remarqué est que la seule licence disponible pour mes vidéos est la licence Youtube standard. En fait, je ne suis pas sûr que ce soit lié à ce problème de droits d'auteur, mais seules ces deux vidéos, parmi toutes celles que j'ai publiées, ont, à la fois, cette restriction sur la licence et une revendication.
Il existe une procédure pour contester cette revendication, certes un peu alambiquée, mais qui a le mérite d'exister. J'ai mis en œuvre cette procédure, et, là encore je ne suis pas sûr que ce soit lié, mais, depuis aujourd'hui, l'encart a disparu de mes vidéos, bien qu'il y ai toujours la restriction sur la licence. En outre, ma contestation est toujours signalée comme étant en cours de traitement.
J'ai la "chance" que les ayants droit de l'œuvre à laquelle la bande sonore des mes vidéos a été associée autorise sa réutilisation, sans quoi, j'aurais probablement été contraint de supprimer mes vidéos ou, du moins, d'en remplacer la bande sonore (ce qui n'aurait pas eu de sens pour la seconde vidéo). Et que se passe-t-il si ma contestation est rejetée, malgré sa légitimité ? Je n'ai rien trouvé sur le site de Youtube qui me laisse penser que je dispose d'un recours dans ce cas de figure…
Ce qu'il y a d'étonnant, c'est que la vidéo sur laquelle pointait l'encart de revendication n'est pas visionnable en France. Elle a été postée en décembre 2018, et n'a été vue, semble-t-il, que deux fois, selon les statistiques. Du coup, en supposant que leur revendication soit légitime, mes vidéos étant visionnable en France, n'y aurait-il pas un problème ? À moins que cette vidéo n'ai été mise sur Youtube que pour servir de référence dans les encarts de revendication…
J'ai acheté un kit électronique pour Raspberry Pi (ça existe aussi pour Arduino ; c'est d'ailleurs, à peu de choses prés, les mêmes kits), et j'ai trouvé la documentation très didactique. Toute une série de montages électroniques sont proposés, chaque montage mettant en œuvre un nouveau composant plus complexe que ceux du montage précédent. Pour chaque composant, il y a une présentation détaillée de son fonctionnement, et des lois électroniques qui le gouvernent. Cependant, la documentation à laquelle j'avais affaire est en anglais. Comme je suis habitué à l'anglais, je n'ai pas cherché de version dans une autre langue.
Je précise que je suis diplômé en électronique, donc mon opinion concernant cette documentation est peut-être biaisée.
Certaines de ces documentations sont librement téléchargeables ; de quoi se faire son propre avis.
La fréquence de la note résultante est simplement égale à la valeur absolue de la différence des fréquences des deux notes. Ainsi, en jouant une note et sa tierce exacte, on perçoit cette même note, mais deux octaves plus bas :
327 Hz (mi³) - 261,6 Hz (do³) = 65,4 Hz (do¹)
À noter que cela ne fonctionne que parce que les notes émises sont des harmoniques de la note résultante, donc les notes émises ne sont plus perçues individuellement en tant que telle, mais comme constituants du timbre de la note résultante.
En théorie, ça devrait aussi fonctionner avec d'autres intervalles, mais en pratique, ça ne semble fonctionner que pour la quinte et la tierce juste.
Cela me fait penser à une astuce utilisée avec certains orgues à tuyaux.
Pour économiser le coût et la place de certains des très longs tuyaux nécessités par les notes les plus graves, on utilise à la place, pour chacun d'entre eux, deux tuyaux plus courts, donc de fréquence plus élevée.
De mémoire, en jouant simultanément une note et sa quinte juste, on entend la même note, mais une octave en-dessous.
Avant que je n'utilise cette appli., j'utilisais effectivement l'utilitaire gpio en me connectant à l'ODROID via SSH. Et là, j'ai rencontré deux problèmes.
D'une part, un problème de place. Il me fallait rester à proximité de l'ordinateur avec lequel je me connectais à l'ODROID , ou du moins de l'écran et du clavier, mais je n'avais pas la place nécessaire pour poser la platine de montage et les composants. Grâce à l'appli., j'ai carrément pu me mettre dans une autre pièce, où je disposais d'une table où j'avais largement la place pour poser la platine, les composants et la tablette avec laquelle j'accédais à l'application ainsi que son support (et non, déplacer l'ordinateur dans cette pièce n'était pas une option).
Le second problème concernait les manipulations. À chaque fois que je voulais tester un branchement, il fallait faire flèche vers le haut pour rappeler la dernière commande, puis flèche gauche jusqu'à la position du numéro de broche, effacer ce numéro, mettre le nouveau, et valider, en modifiant au passage la valeur de la broche si nécessaire. Bon, ce n'est pas vraiment un problème, mais avec l'appli., une pression sur l'écran suffit pour aboutir au même résultat, ce qui est quand même plus pratique…
(je ne vois aucun intérêt au sans fil sur ce type de périphérique) !
l'utiliser depuis son canapé :p
Je confirme :-).
J'ai le modèle qui fait bluetooth, en plus de l'unifying. Je l'utilise en unifying au bureau, et en bluetooth sur ma tablette lors de mes déplacements, l'unique port USB de la tablette étant alors occupé par le clavier.
J'ai suivi exactement la même démarche pour exactement la même raison. Je me sens moins seul du coup, parce que d'habitude j'ai du mal à faire saisir l'intérêt de cette démarche.
En ce qui me concerne, c'est sur du C++ que je suis parti, au lieu de Python. Puis je me suis «amusé» à créer des bindings pour d'autres langages, vu que le C++ s'interface avec à peu prés n'importe quel langage.
Après Java, Node.js et PHP, je viens justement de m'attaquer au bindingPython.
Ce n'est pas parce que je n'utilise pas ces frameworks que je n'ai pas regardé comment ils fonctionnent. Et la manière dont ils fonctionnent ne me convenant pas, j'ai développé ma propre solution. Le cœur du toolkitAtlas (toute la partie en C++), je l'utilise régulièrement pour développer des interfaces web aux applications que je développe pour mes clients. Donc, ce toolkit n'est effectivement pas une marotte pour moi. Mais il est déjà largement rentabilisé.
Toute la partie développée pour la version 0.1.0 du toolkit pour le rendre utilisable avec autre chose que du C++, en fait, ça utilise du code qui est également utilisé en interne pour du développement à destination de mes clients. Le code en question étant encore assez récent, ce développement de la version 0.1.0 m'a permis de l'améliorer.
Par contre, le codage pour la version 0.2.0, destinée à faciliter le prototypage, ça, c'était clairement un défi technologique que je me suis lancé. À savoir, si, avec une installation d'une simple bibliothèque codée uniquement dans le langage choisi par le développeur pour développer son application (donc, pas de C++ pour le coup, ce qui facilite l'installation de la bibliothèque en question), bibliothèque se connectant à un serveur publique qui exécute la partie codée en C++ de mon toolkit, il lui était possible de lancer son application web sur sa machine de développement de manière à ce qu'elle soit accessible de tout l'internet sans qu'il ai quoi que ce soit à déployer sur un serveur distant.
J'ai pris à peu prés deux jours par langage pour développer ces bibliothèques, en améliorant au passage la partie C++ du toolkit. Et comme le résultat obtenu me semble faciliter le prototypage d'une application web d'une manière qui, à ma connaissance, n'existe pas par ailleurs, autant la mettre à disposition de tout un chacun, d'où ce journal…
Un bon prototype c'est - entre autres - un prototype qu'on peut reprendre en grande partie pour construire l'application cible.
Pas nécessairement.
Reprenons l'exemple de mon startupeur. S'il connaît Visual Basic, par exemple, il va pouvoir réaliser le prototype avec ce langage (si le binding correspondant est un jour développé, ce qui est tout à fait envisageable). Une fois sa démo faite aux investisseurs et les fonds nécessaires obtenus, il va pouvoir embaucher une équipe de développeurs qui va lui développer son application web avec les langages traditionnellement utilisés dans ce domaine.
Ça fait longtemps que je n'ai plus fait de VB, mais je suppose qu'il y a peu de chance que ce langage soit utilisé pour réaliser une application web de quelqu'envergure, donc, dans ce cas, le code du prototype ne sera pas utilisé dans l'application finale.
Du coup, dans ton modèle, si le proto rend les utilisateurs heureux et qu'on veut aller plus loin, qu'est-ce qui est réutilisable ? Ou, est-ce que de toute façon tu penses faire évoluer ton framework pour fournir à la fois une version "développement/lab/proto", et une version "prod" ?
Il y a déjà un mode PROD. Cependant, le cœur du toolkitAtlas est codé en C++ (c'est la partie qui est déportée sur le serveur distant en mode prototypage). Or, les gestionnaires de paquets des différents environnements de développement (npm pour Node.js, p. ex.), lorsqu'ils existent, ne sont pas conçus pour déployer du code natif. Du coup, l'installation du toolkitAtlas pour une utilisation en mode PROD n'est de loin pas aussi triviale que l'installation des frameworks traditionnellement utilisés pour le développement d'applications web. Ça, plus le fait que le toolkit n'est pas assez mature pour rivaliser avec ces frameworks, fait que je préfère, pour le moment, mettre en avant le mode prototypage.
Autre question. Sur le fond, j'aime bien le principe de framework tout intégré, mais à quel point ton framework est plus intégré que l'existant ? Côté Front, comment je gère la zolie interface graphique ? Côté Back, comment je me connecte à des ressources de type bus de message et base de données ?
Le toolkitAtlas n'est pas un framework ; c'est une simple bibliothèque (alias package, extension, module, addon, librairie… selon le langage utilisé) à utiliser dans le back-end. La récupération des données saisies par l'utilisateur et celle des actions qu'il effectue, la mise en forme des données à afficher dans le navigateur… tout ça se fait directement au niveau du back-end. Donc, il n'y a pas de données qui doivent être explicitement transférées du front-end au back-end et vice-versa.
Lorsque l'utilisateur réalise une action dans l'application, cette action va être directement récupérée au niveau du back-end. Si cette action nécessite l'affichage de données, celles-ci vont pouvoir être obtenues par une requête, dans le back-end, tout ce qu'il y a de plus classique au moteur de base de données. La mise en forme et l'envoi de ces données au navigateur web vont être réalisés, toujours dans le back-end, simplement par des appels aux fonctions du toolkitAtlas. Le développeur n'a plus à s'occuper du front-end en tant que tel.
Le schéma demandé relève du détail technique dont l'utilisateur ne devrait pas avoir à se préoccuper.
Quelle est ta cible d'utilisateurs, exactement ?
Je n'ai pas développé ce toolkit en ayant un type d'utilisateur en tête. Maintenant, ce qui me vient à l'esprit, à froid, c'est le cas celui qui veut monter une startup, puisque c'est à la mode.
Beaucoup de startups s'appuient sur un service web. La première préoccupation du startupeur, c'est de convaincre des financeurs. S'il a quelques compétences en matière de développement, ou qu'il a sous la main quelqu'un qui a de telles compétences, quelque que soit le langage, il va pouvoir rapidement développer ou faire développer un prototype de son application grâce au toolkitAtlas.
Le jour où il va aller présenter son idée de startup pour obtenir des financements, il va à son RDV avec son ordinateur portable sous le bras, il passe quelque slides pour présenter son idée, et, au lieu de présenter des captures écrans de ce à quoi va ressembler sa future application, il va lancer le prototype de cette application directement sur son ordinateur portable (sous réserve qu'il soit connecté à internet), et la manipuler sous les yeux des décideurs. Et, s'il le décide, il peut afficher le code QR de l'application, et ainsi les décideurs pourront eux-mêmes manipuler l'application sur leur smartphone/tablette/ordinateur portable. Rien n'est de trop lorsqu'il s'agit de convaincre des investisseurs…
En tant que développeur de métier, le contexte dans lequel mon application est exécutée est une des premières choses que je vais regarder. L’environnement de l’application a toujours un impact, plus ou moins important, sur celle-ci.
Dans le cas d'atlas, qu'est-ce qui se passe si je tente d'accéder à des fichiers distants ? À des fichiers présente sur le réseau local de ma machine ? Est-ce qu'il est possible d'ouvrir des ports réseaux supplémentaires ? Est-ce compatible avec un support des websockets ?
L'idée de base du toolkitAtlas, c'est que les manipulations du DOM qui ne sont généralement réalisables qu'en JavaScript, et donc dans le front-end, soient disponibles dans le back-end, et ce dans le langage utilisé pour programmer ce dernier, quelque soit ce langage. Le code HTML qui est envoyé dans le navigateur peut, sans problème, contenir du code JavaScript. Le toolkitAtlas n'offre que la possibilité de manipuler le DOM à partir du back-end. Tout le reste peut se réaliser de manière classique.
le toolkitAtlas n'en est qu'à ses débuts, et je ne sais pas comment il se positionne par rapport à des solutions de développement web classiques (je n'ai jamais utilisé de telles solutions). C'est pour cela qu'en attendant qu'il soit suffisamment mature, sous réserve que les choix techniques retenus pour ce toolkit le permette, pour rivaliser avec les solutions existantes, je le présente comme une solution de prototypage, en mettant en avant une facilité de déploiement qui, me semble-t-il, n'est offerte par aucune autre solution de développement d'applications web.
Cependant, en mode prototypage, le toolkitAtlas présente certaines limitations, et les fonctionnalités avancées de certaines solutions de développement d'applications web ne sont pas disponibles avec le toolkitAtlas. Mais, d'un autre coté, on a rarement besoin de fonctionnalités avancées pour un prototype. En outre, il est bien entendu possible que certaines de ces fonctionnalités puisse être disponibles dans les futures versions du toolkit…
Il ne faut pas perdre de vue que, en l'état, le toolkit n'est prévu que pour réaliser du prototypage, donc, à priori, l'application finale n'utilisera pas ce toolkit, rendant, il me semble, ce genre de questionnement superflu.
Cependant, pour répondre rapidement à la question, en attendant l'éventuelle publication de la dépêche, je peux indiquer les différents composants constituant ce toolkit et leurs répartitions :
Alors, sur la machine du développeur, voilà ce qui tourne (il y des sources C++ dans les repositories, mais ils ne sont pas utilisés dans ce mode de fonctionnement du toolkit) :
Et, sur le serveur distant, celui qui est mis à disposition gracieusement, il y un serveur apache, qui relaie les requêtes du navigateur web de l'utilisateur vers ce logiciel : https://github.com/epeios-q37/xdhwebq-cli. Ce logiciel se connecte à cet autre logiciel : https://github.com/epeios-q37/xdhq. C'est également à ce dernier logiciel que se connecte la partie du toolkit installée sur la machine du développeur.
Bon, je vais quand même tenter un schéma :
Machine util. Serveur distant Machine développeur
------------ ----------------------------------- ----------------------
| nav. web | --> | apache --> xdhwebq-cli --> xdhq | <-- | xdhq-.../atlas-... |
------------ ----------------------------------- ----------------------
Signification de la flèche :
client --> serveur
D'une part, cela dépend du mode de fonctionnement choisi. D'autre part, le mode de fonctionnement décrit dans ce journal, qui est maintenant le mode de fonctionnement par défaut, a justement été conçu pour que l'utilisateur n'ai pas à se préoccuper de cela. Il installe le toolkit, il code son prototype, il le lance, et ça fonctionne. Il n'a pas à se demander s'il faut un serveur http, si un tel serveur est inclut dans le toolkit, s'il faut une machine qui soit accessible d'internet, et, le cas échéant, qu'est-ce qui doit être installé sur cette machine, etc.
L'idée c'est d'avoir un outil qui soit le plus simple possible à mettre en œuvre, d'où la diversité (parmi trois seulement aujourd'hui, en attendant de futurs développements) de langages utilisables, et le fait qu'il suffise d'un ordinateur connecté à internet pour que le prototype soit accessible partout depuis internet. Plus c'est simple à utiliser, plus important sera le nombre d'utilisateur.
Le schéma demandé relève du détail technique dont l'utilisateur ne devrait pas avoir à se préoccuper. Par contre, ce schéma intéressera un éventuel contributeur, mais avant d'avoir des contributeurs, il faut des utilisateurs, c'est pour ça que je pensais aborder les détails techniques dans un second temps seulement.
Ceci dit, si, comme semble le suggérer la note du commentaire, ce schéma intéresse un nombre suffisant de personnes, il pourra être inclut, avec éventuellement d'autres éléments techniques semblables, dans la dépêche qu'on me suggère de rédiger dans les précédents commentaires…
[^] # Re: C'est pas mal, mais
Posté par Claude SIMON (site web personnel) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.
Et où as-tu vu que j'ai quoi que ce soit contre Python ?
D'ailleurs, je suis tellement contre Python que j'ai même publié un paquet Python : https://pypi.org/project/atlastk/ :-) !
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: C'est pas mal, mais
Posté par Claude SIMON (site web personnel) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 1.
Certes, et, personnellement, je ne m'en prive pas, mais Python est fortement mis en avant.
Le Pi de Raspberry Pi, c'est pour Python (https://www.techspot.com/article/531-eben-upton-interview/), bien que ça soit de moins en moins mis en avant. En outre, les bibliothèques logicielles pour piloter les ports GPIO sont, à la base, en C ou C++, mais ce sont les bindings en Python qui sont le plus utilisés. Et ça vaut aussi pour les bibliothèques dédiées au pilotage de certains robots (Poppy Ergo Jr et consorts).
Les exemples de programmes des tutoriels sur le pilotage de kits ou de robots avec un RPI sont systématiquement en Python, accompagnés parfois de leur version en C ou C++. Il existe des exemples de programmes en Java, mais c'est vraiment exceptionnel.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Encore un nouveau standard?
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Zoom sur trois projets émergents portés par Mozilla : Fluent, Bugbug et BinaryAST. Évalué à 1.
PGCD ?
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Est-ce vraiment plus accessible ?
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Les jeunes et la programmation (Atlas toolkit v0.7). Évalué à 1.
Merci de m'avoir donner l'occasion d'éclaircir mes propos !
En fait, back-end et front-end sont gérés par le même code source. Plus besoin de front-end en tant que tel.
Quand je présente le toolkit Atlas, la plupart des gens pensent de prime abord que c'est pour faire des CGI. Il faut vraiment que j'insiste, parfois lourdement, pour leur faire comprendre que c'est pour faire des SPA… En outre, la gestion des SPA est plus proche de la gestion des applications bureau, et repose moins sur HTML.
Mon but, avec le toolkit Atlas, c'est de pouvoir ajouter une GUI à un programme aussi simplement que possible, justement pour que le développeur puisse se concentrer sur le cœur du programme.
Je ne saurais dire si JavaScript est adapté pour l'apprentissage. En outre, avec la version Node.js du toolkit Atlas, l'approche est différente de celle du JavaScript front-end, mais il reste cependant le système des callbacks.
Je me concentre actuellement sur Python parce que c'est le langage qui est le plus souvent cité lorsque l'on parle d'initiation à la programmation, et, d'autre part, c'est également le langage le plus utilisé lorsqu'il s'agit de piloter des montages électroniques ou des robots connectés à un Raspberry Pi. Et piloter des robots, comme indiqué dans la dépêche, avec un smartphone, ça fait son petit effet auprès des adolescents :-)…
Je suis en train de monter un atelier d'initiation à la programmation basé sur le toolkit Atlas, et j'espère le mettre à l'épreuve prochainement. J'espère que les faits vous donneront raison :-)…
C'est pour cela que le toolkit Atlas se veut une alternative à tous ces frameworks habituellement utilisés, car l'apprentissage de ces derniers est bien trop ardu pour des débutants. Le toolkit Atlas est, certes, bien moins puissant, mais c'est largement suffisant pour débuter. Libre à eux d'utiliser un framework lorsqu'ils auront acquis les connaissances nécessaires pour le maîtriser.
La version PHP du toolkit Atlas est justement prévue pour fonctionner en mode CLI. Pour un langage qui a popularisé les CGI, faire des SPA, en mode CLI qui plus est, ça en perturbe plus d'un :-)…
Au début, je pensais que le fait de pouvoir facilement accéder aux applications, réalisées avec le toolkit Atlas, avec un smartphone était assez anecdotique. L'idée originale, derrière cela, c'est que les adolescents puissent facilement montrer leurs réalisations à leur entourage ; à leur âge, ils ont besoin de reconnaissance, d'encouragements. Maintenant, je pense de plus en plus que c'est un point essentiel, car cela démystifie le smartphone. Je pense que la plupart perçoive leur smartphone comme un portail vers cette chose mystérieuse qu'est le cloud, dont seules les grosses boîtes, comme les GAFAMs, ont la maitrise. Avec le toolkit Atlas, ils ont un aperçu de ce que c'est, techniquement, le cloud, et j'espère que cela donnera à certains l'envie d'approfondir le sujet, et de se l'approprier.
C'est sympathique. J'aime bien la cinématique, ça fait vraiment penser au jeu original :-) !
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Ah ben ça tombe bien !
Posté par Claude SIMON (site web personnel) . En réponse au journal Document de cours : "Python for science". Évalué à 1.
Merci, mais je n'ai aucun mérite. C'est parce que le programme tourne dans Repl.it, une application web qui permet de disposer, sans rien avoir à installer, d'un environnement de développement pour pas mal de langages, juste en utilisant un navigateur web. Les logs proviennent de cette appli.
Comme indiqué dans le commentaire plus haut, noyé dans les logs, il y a une URL (elle change à chaque fois) qui, lorsqu'on l'ouvre, propose une interface permettant de faire varier la valeur des différents paramètres de la fonction gaussienne et de voir leur influence sur le graphique.
Avec le programme d'origine, on est obligé de modifier ces valeurs directement dans le programme, ce qui n'est pas très pratique. On peut également modifier le programme pour passer les valeurs de ces paramètres via des arguments de la ligne de commande, ou encore en permettant leur saisie à coup de
input(). Seule cette dernière option est présentée dans le guide faisant l'objet de ce journal mais, hormis sa présentation et un exemple de mise en œuvre, elle n'est pas exploitée par ailleurs.Une autre solution serait de doter le programme d'une GUI. Malgré les indéniables avantages d'une telle interface, une telle option n'est même pas évoquée dans ce guide. Probablement, mais ce n'est qu'une supposition, parce que l'effort nécessité par la mise en œuvre et l'apprentissage d'un des nombreux frameworks existants est disproportionné par rapport aux bénéfices qu'on en retirerait dans le cadre de leur utilisation dans des programmes tels que ceux présentés dans ce guide.
Ces frameworks sont complexes parce qu'ils proposent des fonctionnalités évoluées. Le toolkit Atlas est destiné à être utilisé dans les cas on l'on n'a besoin que de fonctionnalités basiques. Et c'est aussi pour cela que l'utilisation du toolkit Atlas ne nécessite que des connaissances basiques, faciles à acquérir, en technologies web.
J'ai dernièrement fait l'acquisition d'un kit électronique d'apprentissage destiné à être utilisé avec un Raspberry Pi. Il y avait un tutoriel fournit avec ce kit proposant, à titre d'exemple, un programme Python destiné à piloter une LED RGB. Ce programme faisait afficher des couleurs aléatoires par la LED. Là aussi, aucune interactivité. Alors, à l'instar de ce que j'ai fait ici, j'ai modifié le programme pour lui ajouter une GUI, à l'aide du toolkit Atlas, programme que l'on peut voir à l'œuvre ici.
Beaucoup de tutoriels gagneraient en attractivité en proposant des exercices et des exemples de programmes avec un minimum d'interactivité, à l'heure où tout le monde est habitué à manipuler des interfaces graphiques avec leurs smartphones. Et l'un des buts du toolkit Atlas est justement de pouvoir facilement modifier un programme pour le rendre interactif par l'ajout d'une GUI.
« Smart IoT Crafting » : l'IoT pour tous
# Ah ben ça tombe bien !
Posté par Claude SIMON (site web personnel) . En réponse au journal Document de cours : "Python for science". Évalué à 2.
Comme indiqué dans ce journal, je cherche des exemples de programmes Python auxquels je pourrais rajouter une GUI, et je me suis permis de modifier le programme
gauss-2d.pypour en faire ça. Il faut ouvrir l'URL indiquée dans la console (il peut être nécessaire de scroller vers le haut pour la trouver) dans une nouvelle fenêtre, et mettre les deux fenêtres côte à côte.Python ne m'est pas très familier, et encore moins matplotlib, donc c'est très largement améliorable, tout comme l'interface.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Épilogue
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Un mois pour donner de la voix : « voter pour l’article 13, c’est attaquer nos libertés ! ». Évalué à 1.
Les ayant droits avaient jusqu'au 16 avril pour réagir à ma contestation des revendications. Vérification faite, mes vidéos ne sont plus marquées comme faisant l'objet d'une revendication, sans la moindre notification, et j'ai (enfin !) pu les basculer en Creative Commons.
Au final :
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Est-ce vraiment plus accessible ?
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Les jeunes et la programmation (Atlas toolkit v0.7). Évalué à 1.
Merci pour les encouragements :-) !
Concernant l'initiation à la programmation, pour les plus jeunes, il y Scratch, Snap!, Blockly…, qui sont spécialement conçus pour les intéresser, et qui peuvent s'utiliser sur tablette/smartphone. Mais, pour allez plus loin, il faut bien à un moment passer à un langage comme Java, Python, Ruby…, et là, c'est un peu la douche froide.
Avant d'avoir mon premier micro-ordinateur, de tous les appareils que j'avais manipulés, ceux qui s'approchaient le plus d'un ordinateur étaient les montres LCD et les calculatrices, dont d'ailleurs une montre LCD faisant en même temps calculatrice :-). Du coup, le seul fait de pouvoir, avec mon micro-ordinateur, afficher sur un téléviseur le texte de mon choix, de l'animer, de dessiner des figures…, c'était, pour moi, avec l'expérience que j'avais des ordinateurs, suffisamment impressionnant pour me motiver à apprendre la programmation. D'ailleurs, je ne pouvais guère faire autre chose. Les seuls programmes auxquels j'avais accès étaient ceux que je recopiais à partir des sources publiés par certaines revues spécialisées (mes premiers contacts avec l'Open Source !).
De nos jours, la plupart des jeunes ont un smartphone, donc afficher "Hello, World!" dans une console texte, ce n'est pas ça qui va les impressionner, habitués qu'ils sont de manipuler, avec leur smartphone, des applications avec une interface graphique.
Le but du toolkit Atlas est de leur offrir un moyen simple d'approcher de ce à quoi ils sont habitués avec leur smartphone, en leur permettant de facilement doter leurs applications d'une interface graphique. Et, le plus simple pour cela, à mon sens, c'est d'utiliser les technos web. Alors, certes, cela implique d'avoir quelques notions de HTML (CSS est facultatif), mais HTML est simple à apprendre, et il est l'objet de nombreux tutoriels de tous niveaux et faciles à trouver. Et HTML, ça fait quand même partie de la culture générale de tout développeur, et son apprentissage peut se faire en amont et indépendamment de l'apprentissage de la programmation.
Le web vanilla, pour moi, cela désigne deux choses distinctes.
D'une part, c'est de développer en JavaScript pour le navigateur. Or, JavaScript est rarement considéré comme étant le langage idéal pour débuter, sans compter les difficultés lié à la mise en œuvre, si besoin est, d'un back-end. Le toolkit Atlas n'impose pas de langage, et permet de gérer front-end et back-end dans un seul et même programme.
D'autre part, le web vanilla, cela comprend également, pour moi, les applications de type CGI. Or, ces dernières posent problèmes en terme de réactivité. Avec le toolkit Atlas, on obtient des applications de type SPA.
Hormis cela, il y a également la facilité d'accès des programmes s'appuyant sur le toolkit Atlas, permettant au développeur en herbe d'accéder à ses applications sur son smartphone, ou de permettre à d'autres d'y accéder à partir de leur propre smartphone, sans avoir à configurer ou déployer quoi que ce soit, contrairement aux autres framworks web. S'il est suffisamment motivé, ils peut même faire tourner ses applications sur son smartphone, si ce dernier tourne sous Android et qu'il y a installé Termux, pouvant ainsi partager ses réalisations avec ses amis durant les récréations…
Le but du toolkit Atlas est uniquement d'accompagner le débutant lors de son apprentissage, de lui permettre de développer des applications suffisamment intéressantes pour lui en terme d'interaction pour le pousser à persévérer jusqu'à ce qu'il ai acquis les connaissances nécessaires pour développer (s'il le désire) des applications avec une interface graphique (desktop, web, mobile…) basés sur des frameworks traditionnels. L'utilisation du toolkit Atlas n'est pas une fin en soi, mais une passerelle entre les programmes fait avec Scratch et consorts, et des logiciels, disons, plus professionnels.
P.S. Code serveur, je ne vois pas ce que ça désigne…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: un libc pour webassembly en somme ?
Posté par Claude SIMON (site web personnel) . En réponse au journal hey wasm : wasi ! wazaaaaaaa. Évalué à 1.
Avant d'utiliser Electron, j'utilisais Chromium Embedded Framework, qui, comme son nom le laisse entendre, est également basé sur Chromium, et, encore avant ça, j'utilisais XULRunner, qui utilisait le moteur de rendu de Firefox, mais qui n'est plus officiellement maintenu.
« Smart IoT Crafting » : l'IoT pour tous
# Réponse envoyée.
Posté par Claude SIMON (site web personnel) . En réponse au journal [Message de service] Gagnants des meilleurs contributions de mars. Évalué à 3.
D'abord, merci pour ce cadeau.
Comme indiqué dans le titre, j'ai envoyé ma réponse. Je vous le signale ici, car, à l'occasion d'une précédente contribution, j'avais déjà répondu à un message similaire, en novembre 2018, sans toutefois jamais avoir reçu l'ouvrage (version papier). Donc, si jamais vous ne recevez pas cette réponse-ci non plus, c'est qu'il y a un problème…
Le cas échéant, serait-il possible que ce soit dû au fait que ma réponse soit envoyée d'une autre adresse mail que celle déclarée dans mon compte LinuxFR.org ?
P.S. : Je viens de recevoir le message de la liste prizes, et j'y ai répondu. Mais, je viens de vérifier, c'était également le cas lors du message de novembre 2018…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: git/npm ?
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Les jeunes et la programmation (Atlas toolkit v0.7). Évalué à 3.
Salut !
Merci !
Le toolkit lui-même n'est constitué que des quelques fichiers présents dans le répertoire
Atlasdu dépôt. En faisant, à la place durequire('atlastk'), unrequirepointant sur le fichierAtlas.jscontenu dans ce répertoire, il n'est pas nécessaire de faire denpm install.Ceci dit, l'utilisation de npm, c'est surtout pour pouvoir proposer des démonstrations grâce à RunKit,et, comme c'est déjà mis en place, un
npm installme semble quand même plus simple que la procédure ci-dessus.GitHub offre la possibilité de télécharger l'intégralité d'un dépôt sous forme d'une archive ZIP. git n'est donc pas indispensable pour le récupérer.
Je suis en pleine réflexion à ce sujet :-) !
La dépêche porte sans doute à confusion telle qu'elle est rédigée, mais le projet, en l'état, n'est pas destiné à être utilisé directement par des débutants. Il n'y a qu'à voir le site web dédié au toolkit, qui est totalement inutilisable pour un débutant. L'utilisation du toolkit Atlas n'est pas une fin en soi. Ce n'est qu'un moyen, notamment pour rendre l'apprentissage de la programmation plus "fun".
Le toolkit Atlas est, pour l'instant, pensé comme un outil destiné, par exemple, à ceux qui animent des ateliers d'initiation à la programmation. Dans ceux auxquels j'ai assisté, des ordinateurs portables (sous GNU/Linux !) étaient mis à disposition avec, déjà installé, tout un environnement de développement. Le toolkit Atlas pourrait alors également être préinstallé.
De manière générale, il ne devrait pas être difficile de modifier les tutoriels de formation à la programmation de manière à y intégrer le toolkit Atlas, pour améliorer l'interactivité des programmes qui y sont proposés à titre d'exemple ou d'exercice. L'installation du toolkit, via éventuellement une procédure maison, pourra faire partie du tutoriel, au même titre que la mise en place du reste de l'environnement de développement.
Cela vaut aussi pour les kits d'électronique ou de robotique destinés à être utilisés avec un Raspberry Pi, tel que celui utilisé dans la vidéo de démonstration présente dans la dépêche. Les tutoriels accompagnant ces kits proposent une série de programmes mettant en œuvre les différents composants inclus dans le kit. Par exemple, pour la DEL RGB, il y a un programme qui fait varier la couleur de la DEL de manière aléatoire. Donc, l'utilisateur câble sa DEL, connecte son montage au Raspberry Pi, y lance le programme proposé dans le tutoriel, admire les jolies couleurs affichées par la DEL et… c'est tout. Ça manque un brin d'interactivité, je trouve. Je pense que les constructeurs vendant ces kits auraient à y gagner de proposer, à la place de ce genre de programme, ou en complément, un programme du genre de celui présenté en seconde partie de la vidéo.
Je me suis jusqu'à présent concentré sur l'aspect technique du projet, d'abord pour en tester la faisabilité, puis pour en produire le MVP. Comme indiqué dans la dépêche, j'ai réalisé quelques démonstrations qui m'ont convaincues qu'il existe un "marché" pour ce projet. J'en suis maintenant à réfléchir comment faire évoluer le projet, mais également comment communiquer à son sujet, pour l'apporter à ceux qui en auront l'utilité, et sous la forme qui leur sera la plus utile.
Toute suggestion est bienvenue, sachant que le toolkit Atlas étant disponibles en cinq langages, et plus à l'avenir, je n'ai pas, et il me sera difficile d'acquérir, les compétences nécessaires pour sa mise en œuvre optimale dans chacun de ces langages.
« Smart IoT Crafting » : l'IoT pour tous
# Mes démêlés avec le 'Content ID' de Google
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Un mois pour donner de la voix : « voter pour l’article 13, c’est attaquer nos libertés ! ». Évalué à 6. Dernière modification le 16 mars 2019 à 20:56.
J'ai publié hier une vidéo sur Youtube (et accessoirement également sur Peertube, mais ce n'est pas le sujet) avec, comme bande sonore, mon interprétation d'une œuvre musicale du domaine public. Pour justement éviter des problèmes de droits d'auteur, j'ai publié en parallèle une seconde vidéo dans laquelle on me voit interpréter cette œuvre, dans l'idée qu'elle serve de preuve que je dispose de tous les droits sur cette bande sonore, notamment celle de l'utiliser dans mes propres vidéos. J'ai mis dans la première vidéo un lien vers la seconde, pour qu'il soit facile de trouver l'origine de la bande sonore, toujours dans l'optique d'éviter les problèmes liés aux droits d'auteur.
Quelques minutes après, simultanément sur les deux vidéos, un encart a été ajouté qui indiquait que la musique de mes vidéos provenait d'une troisième dont le lien était fourni (diablement réactif, le Content ID). Effectivement, la vidéo en question contenait une interprétation de la même œuvre, et il s'avère que les ayants droit ont émis une revendication sur la bande sonore de mes vidéos (qui, je le rappelle, est mon interprétation d'une œuvre du domaine public). Je suppose que cette revendication a été émise de manière automatique par Content ID, et non pas suite à une action spécifique des ayants droit.
Du fait que les ayants droit autorisaient la réutilisation de cette œuvre, mis à part l'apparition de cet encart, la seule autre conséquence que j'ai remarqué est que la seule licence disponible pour mes vidéos est la licence Youtube standard. En fait, je ne suis pas sûr que ce soit lié à ce problème de droits d'auteur, mais seules ces deux vidéos, parmi toutes celles que j'ai publiées, ont, à la fois, cette restriction sur la licence et une revendication.
Il existe une procédure pour contester cette revendication, certes un peu alambiquée, mais qui a le mérite d'exister. J'ai mis en œuvre cette procédure, et, là encore je ne suis pas sûr que ce soit lié, mais, depuis aujourd'hui, l'encart a disparu de mes vidéos, bien qu'il y ai toujours la restriction sur la licence. En outre, ma contestation est toujours signalée comme étant en cours de traitement.
J'ai la "chance" que les ayants droit de l'œuvre à laquelle la bande sonore des mes vidéos a été associée autorise sa réutilisation, sans quoi, j'aurais probablement été contraint de supprimer mes vidéos ou, du moins, d'en remplacer la bande sonore (ce qui n'aurait pas eu de sens pour la seconde vidéo). Et que se passe-t-il si ma contestation est rejetée, malgré sa légitimité ? Je n'ai rien trouvé sur le site de Youtube qui me laisse penser que je dispose d'un recours dans ce cas de figure…
Ce qu'il y a d'étonnant, c'est que la vidéo sur laquelle pointait l'encart de revendication n'est pas visionnable en France. Elle a été postée en décembre 2018, et n'a été vue, semble-t-il, que deux fois, selon les statistiques. Du coup, en supposant que leur revendication soit légitime, mes vidéos étant visionnable en France, n'y aurait-il pas un problème ? À moins que cette vidéo n'ai été mise sur Youtube que pour servir de référence dans les encarts de revendication…
« Smart IoT Crafting » : l'IoT pour tous
# Kits pour Raspberry Pi/Arduino
Posté par Claude SIMON (site web personnel) . En réponse au message Débuter en électronique. Évalué à 2.
J'ai acheté un kit électronique pour Raspberry Pi (ça existe aussi pour Arduino ; c'est d'ailleurs, à peu de choses prés, les mêmes kits), et j'ai trouvé la documentation très didactique. Toute une série de montages électroniques sont proposés, chaque montage mettant en œuvre un nouveau composant plus complexe que ceux du montage précédent. Pour chaque composant, il y a une présentation détaillée de son fonctionnement, et des lois électroniques qui le gouvernent. Cependant, la documentation à laquelle j'avais affaire est en anglais. Comme je suis habitué à l'anglais, je n'ai pas cherché de version dans une autre langue.
Je précise que je suis diplômé en électronique, donc mon opinion concernant cette documentation est peut-être biaisée.
Certaines de ces documentations sont librement téléchargeables ; de quoi se faire son propre avis.
« Smart IoT Crafting » : l'IoT pour tous
# Erreur dans le formulaire d'inscription.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Soirée fundthecode.org du 19 mars 2019 : appel à projets libres et à participation. Évalué à 5. Dernière modification le 21 février 2019 à 08:46.
Dernier champ du formulaire pour proposer un projet :
Ça risque de faire un peu tard pour un évènement se déroulant le mois prochain :-).
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Orgues à tuyaux
Posté par Claude SIMON (site web personnel) . En réponse au message Expérience d’interférences. Évalué à 2. Dernière modification le 14 février 2019 à 08:32.
La fréquence de la note résultante est simplement égale à la valeur absolue de la différence des fréquences des deux notes. Ainsi, en jouant une note et sa tierce exacte, on perçoit cette même note, mais deux octaves plus bas :
327 Hz (mi³) - 261,6 Hz (do³) = 65,4 Hz (do¹)
À noter que cela ne fonctionne que parce que les notes émises sont des harmoniques de la note résultante, donc les notes émises ne sont plus perçues individuellement en tant que telle, mais comme constituants du timbre de la note résultante.
En théorie, ça devrait aussi fonctionner avec d'autres intervalles, mais en pratique, ça ne semble fonctionner que pour la quinte et la tierce juste.
« Smart IoT Crafting » : l'IoT pour tous
# Orgues à tuyaux
Posté par Claude SIMON (site web personnel) . En réponse au message Expérience d’interférences. Évalué à 3.
Cela me fait penser à une astuce utilisée avec certains orgues à tuyaux.
Pour économiser le coût et la place de certains des très longs tuyaux nécessités par les notes les plus graves, on utilise à la place, pour chacun d'entre eux, deux tuyaux plus courts, donc de fréquence plus élevée.
De mémoire, en jouant simultanément une note et sa quinte juste, on entend la même note, mais une octave en-dessous.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Chrome ou Firefox
Posté par Claude SIMON (site web personnel) . En réponse au message "Unresponsive script" : limiter Firefox. Évalué à 3.
https://developer.mozilla.org/fr/docs/Chrome
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Le problème est où ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Application web de contrôle des GPIOs d'un Raspberry Pi/ODROID-C2. Évalué à 1. Dernière modification le 19 décembre 2018 à 17:51.
Avant que je n'utilise cette appli., j'utilisais effectivement l'utilitaire
gpioen me connectant à l'ODROID via SSH. Et là, j'ai rencontré deux problèmes.D'une part, un problème de place. Il me fallait rester à proximité de l'ordinateur avec lequel je me connectais à l'ODROID , ou du moins de l'écran et du clavier, mais je n'avais pas la place nécessaire pour poser la platine de montage et les composants. Grâce à l'appli., j'ai carrément pu me mettre dans une autre pièce, où je disposais d'une table où j'avais largement la place pour poser la platine, les composants et la tablette avec laquelle j'accédais à l'application ainsi que son support (et non, déplacer l'ordinateur dans cette pièce n'était pas une option).
Le second problème concernait les manipulations. À chaque fois que je voulais tester un branchement, il fallait faire flèche vers le haut pour rappeler la dernière commande, puis flèche gauche jusqu'à la position du numéro de broche, effacer ce numéro, mettre le nouveau, et valider, en modifiant au passage la valeur de la broche si nécessaire. Bon, ce n'est pas vraiment un problème, mais avec l'appli., une pression sur l'écran suffit pour aboutir au même résultat, ce qui est quand même plus pratique…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: très bien
Posté par Claude SIMON (site web personnel) . En réponse au message vendu. Évalué à 1.
Je confirme :-).
J'ai le modèle qui fait bluetooth, en plus de l'unifying. Je l'utilise en unifying au bureau, et en bluetooth sur ma tablette lors de mes déplacements, l'unique port USB de la tablette étant alors occupé par le clavier.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: compilation
Posté par Claude SIMON (site web personnel) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 3.
J'ai suivi exactement la même démarche pour exactement la même raison. Je me sens moins seul du coup, parce que d'habitude j'ai du mal à faire saisir l'intérêt de cette démarche.
En ce qui me concerne, c'est sur du C++ que je suis parti, au lieu de Python. Puis je me suis «amusé» à créer des bindings pour d'autres langages, vu que le C++ s'interface avec à peu prés n'importe quel langage.
Après Java, Node.js et PHP, je viens justement de m'attaquer au binding Python.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 0.
Ce n'est pas parce que je n'utilise pas ces frameworks que je n'ai pas regardé comment ils fonctionnent. Et la manière dont ils fonctionnent ne me convenant pas, j'ai développé ma propre solution. Le cœur du toolkit Atlas (toute la partie en C++), je l'utilise régulièrement pour développer des interfaces web aux applications que je développe pour mes clients. Donc, ce toolkit n'est effectivement pas une marotte pour moi. Mais il est déjà largement rentabilisé.
Toute la partie développée pour la version 0.1.0 du toolkit pour le rendre utilisable avec autre chose que du C++, en fait, ça utilise du code qui est également utilisé en interne pour du développement à destination de mes clients. Le code en question étant encore assez récent, ce développement de la version 0.1.0 m'a permis de l'améliorer.
Par contre, le codage pour la version 0.2.0, destinée à faciliter le prototypage, ça, c'était clairement un défi technologique que je me suis lancé. À savoir, si, avec une installation d'une simple bibliothèque codée uniquement dans le langage choisi par le développeur pour développer son application (donc, pas de C++ pour le coup, ce qui facilite l'installation de la bibliothèque en question), bibliothèque se connectant à un serveur publique qui exécute la partie codée en C++ de mon toolkit, il lui était possible de lancer son application web sur sa machine de développement de manière à ce qu'elle soit accessible de tout l'internet sans qu'il ai quoi que ce soit à déployer sur un serveur distant.
J'ai pris à peu prés deux jours par langage pour développer ces bibliothèques, en améliorant au passage la partie C++ du toolkit. Et comme le résultat obtenu me semble faciliter le prototypage d'une application web d'une manière qui, à ma connaissance, n'existe pas par ailleurs, autant la mettre à disposition de tout un chacun, d'où ce journal…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 1. Dernière modification le 07 septembre 2018 à 15:47.
Pas nécessairement.
Reprenons l'exemple de mon startupeur. S'il connaît Visual Basic, par exemple, il va pouvoir réaliser le prototype avec ce langage (si le binding correspondant est un jour développé, ce qui est tout à fait envisageable). Une fois sa démo faite aux investisseurs et les fonds nécessaires obtenus, il va pouvoir embaucher une équipe de développeurs qui va lui développer son application web avec les langages traditionnellement utilisés dans ce domaine.
Ça fait longtemps que je n'ai plus fait de VB, mais je suppose qu'il y a peu de chance que ce langage soit utilisé pour réaliser une application web de quelqu'envergure, donc, dans ce cas, le code du prototype ne sera pas utilisé dans l'application finale.
Il y a déjà un mode PROD. Cependant, le cœur du toolkit Atlas est codé en C++ (c'est la partie qui est déportée sur le serveur distant en mode prototypage). Or, les gestionnaires de paquets des différents environnements de développement (npm pour Node.js, p. ex.), lorsqu'ils existent, ne sont pas conçus pour déployer du code natif. Du coup, l'installation du toolkit Atlas pour une utilisation en mode PROD n'est de loin pas aussi triviale que l'installation des frameworks traditionnellement utilisés pour le développement d'applications web. Ça, plus le fait que le toolkit n'est pas assez mature pour rivaliser avec ces frameworks, fait que je préfère, pour le moment, mettre en avant le mode prototypage.
Le toolkit Atlas n'est pas un framework ; c'est une simple bibliothèque (alias package, extension, module, addon, librairie… selon le langage utilisé) à utiliser dans le back-end. La récupération des données saisies par l'utilisateur et celle des actions qu'il effectue, la mise en forme des données à afficher dans le navigateur… tout ça se fait directement au niveau du back-end. Donc, il n'y a pas de données qui doivent être explicitement transférées du front-end au back-end et vice-versa.
Lorsque l'utilisateur réalise une action dans l'application, cette action va être directement récupérée au niveau du back-end. Si cette action nécessite l'affichage de données, celles-ci vont pouvoir être obtenues par une requête, dans le back-end, tout ce qu'il y a de plus classique au moteur de base de données. La mise en forme et l'envoi de ces données au navigateur web vont être réalisés, toujours dans le back-end, simplement par des appels aux fonctions du toolkit Atlas. Le développeur n'a plus à s'occuper du front-end en tant que tel.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 2. Dernière modification le 07 septembre 2018 à 11:39.
Je n'ai pas développé ce toolkit en ayant un type d'utilisateur en tête. Maintenant, ce qui me vient à l'esprit, à froid, c'est le cas celui qui veut monter une startup, puisque c'est à la mode.
Beaucoup de startups s'appuient sur un service web. La première préoccupation du startupeur, c'est de convaincre des financeurs. S'il a quelques compétences en matière de développement, ou qu'il a sous la main quelqu'un qui a de telles compétences, quelque que soit le langage, il va pouvoir rapidement développer ou faire développer un prototype de son application grâce au toolkit Atlas.
Le jour où il va aller présenter son idée de startup pour obtenir des financements, il va à son RDV avec son ordinateur portable sous le bras, il passe quelque slides pour présenter son idée, et, au lieu de présenter des captures écrans de ce à quoi va ressembler sa future application, il va lancer le prototype de cette application directement sur son ordinateur portable (sous réserve qu'il soit connecté à internet), et la manipuler sous les yeux des décideurs. Et, s'il le décide, il peut afficher le code QR de l'application, et ainsi les décideurs pourront eux-mêmes manipuler l'application sur leur smartphone/tablette/ordinateur portable. Rien n'est de trop lorsqu'il s'agit de convaincre des investisseurs…
L'idée de base du toolkit Atlas, c'est que les manipulations du DOM qui ne sont généralement réalisables qu'en JavaScript, et donc dans le front-end, soient disponibles dans le back-end, et ce dans le langage utilisé pour programmer ce dernier, quelque soit ce langage. Le code HTML qui est envoyé dans le navigateur peut, sans problème, contenir du code JavaScript. Le toolkit Atlas n'offre que la possibilité de manipuler le DOM à partir du back-end. Tout le reste peut se réaliser de manière classique.
le toolkit Atlas n'en est qu'à ses débuts, et je ne sais pas comment il se positionne par rapport à des solutions de développement web classiques (je n'ai jamais utilisé de telles solutions). C'est pour cela qu'en attendant qu'il soit suffisamment mature, sous réserve que les choix techniques retenus pour ce toolkit le permette, pour rivaliser avec les solutions existantes, je le présente comme une solution de prototypage, en mettant en avant une facilité de déploiement qui, me semble-t-il, n'est offerte par aucune autre solution de développement d'applications web.
Cependant, en mode prototypage, le toolkit Atlas présente certaines limitations, et les fonctionnalités avancées de certaines solutions de développement d'applications web ne sont pas disponibles avec le toolkit Atlas. Mais, d'un autre coté, on a rarement besoin de fonctionnalités avancées pour un prototype. En outre, il est bien entendu possible que certaines de ces fonctionnalités puisse être disponibles dans les futures versions du toolkit…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 4. Dernière modification le 07 septembre 2018 à 10:15.
Il ne faut pas perdre de vue que, en l'état, le toolkit n'est prévu que pour réaliser du prototypage, donc, à priori, l'application finale n'utilisera pas ce toolkit, rendant, il me semble, ce genre de questionnement superflu.
Cependant, pour répondre rapidement à la question, en attendant l'éventuelle publication de la dépêche, je peux indiquer les différents composants constituant ce toolkit et leurs répartitions :
Alors, sur la machine du développeur, voilà ce qui tourne (il y des sources C++ dans les repositories, mais ils ne sont pas utilisés dans ce mode de fonctionnement du toolkit) :
Et, sur le serveur distant, celui qui est mis à disposition gracieusement, il y un serveur apache, qui relaie les requêtes du navigateur web de l'utilisateur vers ce logiciel : https://github.com/epeios-q37/xdhwebq-cli. Ce logiciel se connecte à cet autre logiciel : https://github.com/epeios-q37/xdhq. C'est également à ce dernier logiciel que se connecte la partie du toolkit installée sur la machine du développeur.
Bon, je vais quand même tenter un schéma :
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 2.
D'une part, cela dépend du mode de fonctionnement choisi. D'autre part, le mode de fonctionnement décrit dans ce journal, qui est maintenant le mode de fonctionnement par défaut, a justement été conçu pour que l'utilisateur n'ai pas à se préoccuper de cela. Il installe le toolkit, il code son prototype, il le lance, et ça fonctionne. Il n'a pas à se demander s'il faut un serveur http, si un tel serveur est inclut dans le toolkit, s'il faut une machine qui soit accessible d'internet, et, le cas échéant, qu'est-ce qui doit être installé sur cette machine, etc.
L'idée c'est d'avoir un outil qui soit le plus simple possible à mettre en œuvre, d'où la diversité (parmi trois seulement aujourd'hui, en attendant de futurs développements) de langages utilisables, et le fait qu'il suffise d'un ordinateur connecté à internet pour que le prototype soit accessible partout depuis internet. Plus c'est simple à utiliser, plus important sera le nombre d'utilisateur.
Le schéma demandé relève du détail technique dont l'utilisateur ne devrait pas avoir à se préoccuper. Par contre, ce schéma intéressera un éventuel contributeur, mais avant d'avoir des contributeurs, il faut des utilisateurs, c'est pour ça que je pensais aborder les détails techniques dans un second temps seulement.
Ceci dit, si, comme semble le suggérer la note du commentaire, ce schéma intéresse un nombre suffisant de personnes, il pourra être inclut, avec éventuellement d'autres éléments techniques semblables, dans la dépêche qu'on me suggère de rédiger dans les précédents commentaires…
« Smart IoT Crafting » : l'IoT pour tous