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…
Une dépêche ? Je veux bien tenter l'expérience. Mais il faudra m'indiquer précisément quel devra en être le contenu attendu, pour que je puisse en rédiger un premier jet qui soit plus parlant au lectorat de ce site que le contenu de ce journal. Premier jet que je modifierais en fonction des différentes suggestions jusqu'à aboutir à un contenu qui fasse consensus (je suppose que c'est le principe de fonctionnement de l'espace collaboratif).
Dans le même temps, le sous système linux a des gros inconvénients :
[…]
- on est root d'office dans le sous système linux, […]
Négatif ! Il faut faire un sudo pour pouvoir faire un aptitude update, par exemple.
le terminal est un cmd, donc pas très configurable
Pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer dans conEmu, par exemple,
il faut penser à lancer la commande bash à chaque fois qu'on veut un terminal (c'est là aussi qu'on perd du temps entre le démarrage du cmd et de bash ensuite)
Là aussi, pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer à partir d'une icône.
Quand je me suis intéressé au développement d'interfaces natives, j'ai consulté la doc. et les tutos, pas de manière très approfondie, il est vrai, de toolkits comme Qt, wxWidgets, qui devait encore s'appeler wxWindows à l'époque, et d'autres dont je ne me souviens plus du nom. Or, je ne me souviens pas qu'il y soit jamais fait référence à MVC. Peut-être que je n'ai pas poussé ma lecture assez loin.
Lorsque je me suis intéressé au développement d'interfaces web, j'ai également consulté la doc. et les tutos de différents framework, et là, il y est rapidement fait référence à MVC. Et pourtant, je n'ai pas l'impression d'avoir pousser ma lecture plus loin qu'avec les docs et tutos ci-dessus, d'où ma méprise.
PS: L'échappement des inputs web c'est pas quelque chose qui se gère en trois lignes, les règles changent en fonction du contexte.
C'est vraiment juste un truc que j'ai codé en mode quick and dirty, pour gérer les cas les plus évidents (&, <, "…).
Le plus gros soucis avec l'utilisation de C++ pour la gestion d'interface Web a mon sens n'a rien a voir avec le language, mais tout a voir avec le fait que comme très peu de personnes l'utilisent dans ce but, tout l'ecosystème de la sécurité web va être à refaire …
Oui, c'est possible. D'un autre coté, vu le nombre d'outils qui existent pour faire du développement web dans d'autres langages, il y en a probablement pas mal qui ont une licence suffisamment permissive pour pouvoir s'en inspirer, voire carrément copier le code concerné, puisque pas mal de ces langages sont codés en interne en C ou en C++…
Non tu affirme que c'est peu utilisé en natif (tu as même tenté de dire que ce n'était pas très populaire, ce qui est drôle quand on est seul utilisateur d'une techno). Je te pointe des documents qui montent que c'est une notion centrale de bibliothèques très utilisées
Possible que je me sois gouré sur sur son degré d'utilisation mais j'aimerais quand même un lien sur une appli avec interface native qui utilise MVC et dont je peux voir les sources, et, vu ce que tu dis des documents dont tu m'as donné la référence, ça ne devrait pas être très difficile à produire…
Et je ne vois pas en quoi croire (même si, à priori, à tort) qu'une techno. n'est pas très utilisée, c'est la critiquer.
Tu fais sincèrement ce que tu veux. Je m'en fou. C'est juste que tu remplace un pattern d'archi utilisé par aucun. Dans le monde argument. C'est juste dommage parce que tu nous dis à côté ne pas être capable de rester ton code. MVC est entre autre là pour que tu puisse le faire.
J'ai mon propre pattern d'archi, et je n'ai jamais dit que je n'étais pas capable de tester mon code, juste qu'écrire le code correspondant n'est, actuellement, pour moi, pas économiquement viable. Et, à l'instar de MVC, mon propre pattern d'archi est tout à fait adapté à l'écriture de tests, mais écrire le code de ces tests… (etc.).
Parce que ton code est bugué? Fais ce que tu veux mais ton code est bugué si tu ne te débrouilles pas pour que ça fonctionne avant de te lancer dans des trucs fous comme une structure commerciale tu va dans le mur. Il n'y a pas de "mais ça fonctionnait", il faut mettre en place quelque chose pour s'assurer que ce que tu sors fonctionne. Tu veux pas faire de test unitaire très bien, il y a avoir un cahier de test, hier sur un environnement propre (docker ou une vm par exemple), etc. Pour le moment tu ne semble pas prendre conscience du problème. Avec ou sans communication ton truc ne fonctionne pas. Je l'ai ressayé, ça a "marchait" quelques fois (avoir des erreurs et servir lancer le programme au debuger pour trouver l'url qui va bien, c'est fonctionner ?). Puis plus du tout, comme si ton serveur ne répondait de token à mon client… J'ai pas de doute que ça se corrige mais il faut que tu attrape ce genre de problème plus tôt si tu veux rester crédible. Si les gens doivent payer les pots casser à chaque nouvelle version, ils ne peuvent qu'aller voir ailleurs, tu ne leur donne pas le choix.
faire des tests sur un code ne garantit pas qu'il est exempt de bugs,
concernant le bug que tu as rencontré, tests ou pas tests, ça ne change rien, parce que je n'arrive pas à reproduire le problème (ceci dit, je suis en train de travailler sur une nouvelle version de Atlas.jar qui corrige ce bug, mais ça sera évidemment une correction à l'aveugle),
faire des tests sur un code ne garantit pas qu'il est exempt de bugs (oui, c'est la même chose que le 1., mais ça s'applique également au second bug que tu as rencontré).
Bref, rien ne prouve que tu n'aurais pas rencontré les mêmes problèmes avec mon appli. si je l'avais soumise à une batterie de tests que j'aurais codés. Je ne nie pas que ce soit possible, mais, de mon expérience, j'en estime la probabilité très faible, trop faible pour que j'investisse du temps (et donc de l'argent) pour pallier à cet hypothétique problème en codant des tests.
Je ne te convaincrais pas, tu ne me convaincras pas, donc je propose d'en rester là sur le sujet. Et cette proposition vaut aussi pour les autres qui seraient tenté d'intervenir sur ce même sujet.
M'ignorer ? Si l'alternative c'est d'avoir à répondre à des commentaires hors sujet et/ou contenant des arguments d'une part erronés et qui, d'autre part, ne font pas avancer le débat, oui, je préfère.
[^] # É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 :
Zelbinium, la programmation ludique
[^] # 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…
Zelbinium, la programmation ludique
[^] # 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.
Zelbinium, la programmation ludique
# 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…
Zelbinium, la programmation ludique
[^] # 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.
Zelbinium, la programmation ludique
# 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…
Zelbinium, la programmation ludique
# 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.
Zelbinium, la programmation ludique
# 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 :-).
Zelbinium, la programmation ludique
[^] # 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.
Zelbinium, la programmation ludique
# 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.
Zelbinium, la programmation ludique
[^] # 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
Zelbinium, la programmation ludique
[^] # 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…
Zelbinium, la programmation ludique
[^] # 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.
Zelbinium, la programmation ludique
[^] # 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.
Zelbinium, la programmation ludique
[^] # 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…
Zelbinium, la programmation ludique
[^] # 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.
Zelbinium, la programmation ludique
[^] # 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…
Zelbinium, la programmation ludique
[^] # 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 :
Zelbinium, la programmation ludique
[^] # 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…
Zelbinium, la programmation ludique
[^] # Re: Montre ton code
Posté par Claude SIMON (site web personnel) . En réponse au journal Prototypage d'applications web. Évalué à 2.
Une dépêche ? Je veux bien tenter l'expérience. Mais il faudra m'indiquer précisément quel devra en être le contenu attendu, pour que je puisse en rédiger un premier jet qui soit plus parlant au lectorat de ce site que le contenu de ce journal. Premier jet que je modifierais en fonction des différentes suggestions jusqu'à aboutir à un contenu qui fasse consensus (je suppose que c'est le principe de fonctionnement de l'espace collaboratif).
Zelbinium, la programmation ludique
[^] # Re: Eeeuuuhhhh
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Dark Moon : une distribution GNU/Cygwin portable pour Windows. Évalué à 1.
Négatif ! Il faut faire un
sudopour pouvoir faire unaptitude update, par exemple.Pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer dans conEmu, par exemple,
Là aussi, pas sûr que ça s'oppose à ton affirmation, mais on peut le lancer à partir d'une icône.
Zelbinium, la programmation ludique
[^] # Re: Mais il n'y a vraiment pas de quoi...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -2.
Quand je me suis intéressé au développement d'interfaces natives, j'ai consulté la doc. et les tutos, pas de manière très approfondie, il est vrai, de toolkits comme Qt, wxWidgets, qui devait encore s'appeler wxWindows à l'époque, et d'autres dont je ne me souviens plus du nom. Or, je ne me souviens pas qu'il y soit jamais fait référence à MVC. Peut-être que je n'ai pas poussé ma lecture assez loin.
Lorsque je me suis intéressé au développement d'interfaces web, j'ai également consulté la doc. et les tutos de différents framework, et là, il y est rapidement fait référence à MVC. Et pourtant, je n'ai pas l'impression d'avoir pousser ma lecture plus loin qu'avec les docs et tutos ci-dessus, d'où ma méprise.
Zelbinium, la programmation ludique
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1. Dernière modification le 05 août 2018 à 14:00.
Merci !
C'est vraiment juste un truc que j'ai codé en mode quick and dirty, pour gérer les cas les plus évidents (
&,<,"…).Oui, c'est possible. D'un autre coté, vu le nombre d'outils qui existent pour faire du développement web dans d'autres langages, il y en a probablement pas mal qui ont une licence suffisamment permissive pour pouvoir s'en inspirer, voire carrément copier le code concerné, puisque pas mal de ces langages sont codés en interne en C ou en C++…
Zelbinium, la programmation ludique
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1.
Il y a moyen de voir les sources d'une de tes appli. avec interface native qui utilise MVC ?
Zelbinium, la programmation ludique
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -5. Dernière modification le 05 août 2018 à 10:42.
Possible que je me sois gouré sur sur son degré d'utilisation mais j'aimerais quand même un lien sur une appli avec interface native qui utilise MVC et dont je peux voir les sources, et, vu ce que tu dis des documents dont tu m'as donné la référence, ça ne devrait pas être très difficile à produire…
Et je ne vois pas en quoi croire (même si, à priori, à tort) qu'une techno. n'est pas très utilisée, c'est la critiquer.
J'ai mon propre pattern d'archi, et je n'ai jamais dit que je n'étais pas capable de tester mon code, juste qu'écrire le code correspondant n'est, actuellement, pour moi, pas économiquement viable. Et, à l'instar de MVC, mon propre pattern d'archi est tout à fait adapté à l'écriture de tests, mais écrire le code de ces tests… (etc.).
Bref, rien ne prouve que tu n'aurais pas rencontré les mêmes problèmes avec mon appli. si je l'avais soumise à une batterie de tests que j'aurais codés. Je ne nie pas que ce soit possible, mais, de mon expérience, j'en estime la probabilité très faible, trop faible pour que j'investisse du temps (et donc de l'argent) pour pallier à cet hypothétique problème en codant des tests.
Je ne te convaincrais pas, tu ne me convaincras pas, donc je propose d'en rester là sur le sujet. Et cette proposition vaut aussi pour les autres qui seraient tenté d'intervenir sur ce même sujet.
M'ignorer ? Si l'alternative c'est d'avoir à répondre à des commentaires hors sujet et/ou contenant des arguments d'une part erronés et qui, d'autre part, ne font pas avancer le débat, oui, je préfère.
Zelbinium, la programmation ludique