Claude SIMON a écrit 539 commentaires

Peut-être PySimpleGUI ?

Pour nous émanciper des géants du numérique : Zelbinium !

À noter que les futurs professeurs d'informatique dans les lycées seront titulaires d'un CAPES d'informatique (qui va être crée en 2020), et non plus titulaires d'un CAPES de mathématique, ou de je ne sais quoi, option informatique…

Comme quoi, il y du progrès ; il semblerait qu'il y aurait même une agrégation d'informatique en projet.

Pour nous émanciper des géants du numérique : Zelbinium !

[…]

Merci pour toutes ces informations.

Pour ce que j'en sais, les cours de programmation s'inscrivent effectivement dans une discipline plus large, mais seront obligatoires, ainsi que l'utilisation de Python, donc exit Scratch et consorts. En outre, la place accordée à la programmation sera assez importante, mais c'est peut-être un choix des enseignants, sachant qu'ils n'ont pas de directives précises à ce sujet. Maintenant, cela diffère peut-être en fonction des lycées…

Pour revenir sur le fond de l'article, et donc la question de l'interface utilisateur dans l'enseignement de la programmation avec Python, l'éducation nationale a déjà fait un choix fort à ce niveau, avec une vision proche de la programmation fonctionnelle.
L'idée est de passer par un éditeur de texte intégrant une console python (repl.it est un bon exemple) ou par des jupyter notebooks, et de passer systématiquement par l'usage de fonction. Pour schématiser l'élève écrit ses fonctions côtés éditeurs, et il les appelle côté console.

Là aussi, de ce qu'on m'en a dit, chaque élève se verra doté d'un ordinateur portable qui lui sera propre, avec un environnement de développement Python, donc les services comme Repl.it ne seront pas utilisés, même s'il n'y a rien qui s'y oppose. Pour le reste, comme les consignes qu'ils ont reçus sont assez vagues, c'est eux qui décident…

Le but est de séparer au maximum et dès le départ la partie logique, de la partie interface.
La partie interface n'est d'ailleurs pas du tout abordée en maths, elle le sera uniquement en NSI. Mais comme NSI propose du web, les élèves devraient pouvoir créer (en étant pas mal guidé), leur propre interface lors des projets.

De plus, un des but de cet enseignement est de bien séparer HTML et Javascript, front-end et back-end. Introduire Python avec une interface web risque d'amener des confusion à ce niveau.

Pour ce qui est de l'interface web, ce sera totalement transparent. Au lieu d'utiliser print(…), ils utiliseront une autre commande qui, au lieu d'afficher un contenu dans une console texte, l'affichera dans l'interface web de l'exercice à l'endroit prévu pour cela. De la même manière, au lieu d'utiliser des input(…) pour récupérer des données utilisateurs, ils les récupèreront via les paramètres d'un callback. Ils n'auront pas affaire à HTML, JavaScript, DOM, CSS…. Dans un second temps, il sera tout à fait possible de proposer des exercices pour aborder ces technologies.

Pour nous émanciper des géants du numérique : Zelbinium !

Du coup, je me demande si vraiment, c'est un problème d'esthétique que d'intéresser les jeunes au code.

Ben quand même, une console texte, ce n'est pas très folichon. Avec une interface web, à l'aide de quelques règles CSS, on peut arriver à faire quelque chose de visuellement fun. Bon, les exercices présentés dans ce journal ne sont pas un bon exemple de ce point de vue, vu mon niveau en CSS… D'ailleurs, s'il y a des volontaires maitrisant CSS pour enjoliver les exercices…

De plus, le fait d'utiliser des technos web, c'est pour leur montrer que, non, leur smartphone, ce n'est pas seulement pour avoir accès Facebook, Instagram, Twitter ou que sais-je encore. On peut aussi l'utiliser pour avoir accès à des applications que l'on a soi-même crées.

Pour nous émanciper des géants du numérique : Zelbinium !

Marrant, quand j'étais au lycée il y a fort fort longtemps, on avait appris le BASIC sur TO7/70. Ça m'avait royalement gonflé de dessiner des carrés de couleur à l'écran, alors du Python, il va vraiment falloir être pédagogue.

Je ne sais pas si ça va faire une grande différence, mais le but n'est pas d'apprendre Python, mais d'apprendre la programmation. Donc, on va, à priori, laisser toutes le subtilités de Python de coté. En outre, grâce à l'interface web, on va pouvoir faire des exercices bien plus amusants que le traçage de carrés.

Pour ce qui est de la programmation objet, comme on peut en avoir un aperçu là et là, ça peut être tout à fait abordé dans le cadre d'exercices dédiés.

Pour nous émanciper des géants du numérique : Zelbinium !

BTW, quelle version de Marp utilises-tu ?

Je n'en sais rien ; je n'ai pas trouvé l'entrée de menu qui permet d'afficher cette information. Mais je crois que c'est la 0.0.13…

Apparemment, Marp est abandonné au profit d'un nouvelle suite logicielle appelée Marp Next, mais je n'ai pas encore regardé en détail…

Pour nous émanciper des géants du numérique : Zelbinium !

Vu la définition et les cas d'usage que tu cites, un proxy ne serait-il pas implémentable avec une classe abstraite en C++ ?
Je pose cette question pas tant pour faire avancer le débat que pour voir s'il n'y a pas quelque chose qui m'échappe…

Pour nous émanciper des géants du numérique : Zelbinium !

Ça ne répond pas à ton cahier des charges, mais j'ai également opté pour Marp, et j'utilise PDF Presenter pour afficher en plein écran le PDF généré par Marp.

J'ai écris un journal sur le sujet : https://linuxfr.org/users/epeios/journaux/markdown-presentation-processor-ou-de-l-interet-des-fichiers-texte. Certains y évoquent des alternatives dans les commentaires. Peut-être que tu y trouveras ton bonheur…

Pour nous émanciper des géants du numérique : Zelbinium !

Cela fait plus de vingt ans que je développe, autant professionnellement que pour mes projets personnels, quasi exclusivement en C++. Je n'utilise qu'une partie des possibilités offertes par ce langage, et rares sont les nouveautés que j'adopte. La dernière en date sont les variadic templates, apparus avec C++11. Je ne peux donc prétendre être un expert C++, et ça n'a d'ailleurs jamais été mon ambition.

Je peux d'autant moins prétendre être un expert C++ que les seules bibliothèques C++ que j'utilise sont… les miennes.

À mes débuts, il n'y avait pas autant de langages qu'aujourd'hui, et la plupart n'étaient pas très répandus. En outre, comme je connaissais déjà le langage C, c'est tout naturellement que je me suis tourné vers le C++. Ayant, dés le début, fait le choix d'écrire des programmes portables, entre les différences de comportement d'une même bibliothèque d'une plateforme à l'autre, et les bugs de certaines bibliothèques, je me suis retrouvé à écrire mes propres bibliothèques C++, codées en interne en C.

Cela est grandement facilité par le fait qu'avec C++, j'ai directement accès aux bibliothèques C standards, ainsi que systèmes, voire à l'assembleur. J'utilise donc exactement le même environnement de développement pour, d'une part, développer mes bibliothèques C++ (en C ou en assembleur), et, d'autre part, pour développer les logiciels qui s'appuient sur ces bibliothèques. Avec la plupart des autres langages, pour avoir des performances optimales, j'aurais dû quand même développer les bibliothèques en C ou en C++, et donc avoir deux environnements de développement radicalement différents. Pour le jeune aspirant développeur que j'étais à l'époque, cela aurait été probablement rédhibitoire.

Rétrospectivement, bien que ce choix ai été dicté par les circonstances, coder dans un langage sans en utiliser les bibliothèques standards paraît tout à fait insensé, encore plus de nos jours. Pourtant, c'est un choix que je ne regrette absolument pas. L'avantage est que j'ai des bibliothèques avec une API sur mesure, vu que je peux la modifier comme bon me semble, et dont les performances ne sont limitées que par les caractéristiques de la machine sur laquelle sont exécutés mes logiciels. L'inconvénient, c'est que, aujourd'hui, je suis le seul à vouloir/pouvoir modifier mes logiciels, essentiellement parce que mes bibliothèques ne sont pas documentées.

Ces derniers mois, j'ai eu l'occasion de réaliser des développements pour Java, Node.js, PHP, Python, Ruby et je suis actuellement en train d'en réaliser pour Perl. Bien que j'ai trouvé certains de ces langages intéressants par certains aspects, je préfère, et de loin, coder en C++. Mais cela est probablement dû à ma manière inhabituelle de coder en C++, c'est-à-dire en utilisant exclusivement des bibliothèques maisons.

Cette manière de coder est hautement critiquable et ne saurait être encouragée. N'empêche que c'est la mienne et qu'elle me convient parfaitement. Et il se trouve que C++ est l'un des rares langages (le seul à ma connaissance, avec le C) qui facilite autant cette manière de coder, autant par l'ouverture de son environnement de développement (accès direct au C et à l'assembleur), que par les performances qu'il permet d'obtenir (qui n'ont rien à envier à celles des bibliothèques fournies en standard).

Voilà donc un autre point de vue d'un développeur C++ ayant eu un début de parcours fort similaire au tien.

Concernant certains des points évoqués dans ton journal.

Je ne trouve pas que développer en C++ est lent, mais c'est probablement parce que j'ai une flopée de bibliothèques pour mettre facilement et rapidement en œuvre toutes les fonctionnalités dont j'ai pu avoir besoin au cours de mes différents développements. Certes, développer ces bibliothèques m'a pris du temps, mais cela s'est fait au fil de l'eau, en généralisant au maximum et en déportant chaque nouvelle fonctionnalité dans une bibliothèque dés que j'ai eu besoin de cette fonctionnalité pour un logiciel.

Pour ce qui est de la compilation, vu que je n'ai jamais de dépendances du fait que je n'utilise pas de bibliothèques tiers, je n'ai besoin que d'un Makefile pour la compilation. Ce Makefile est généré à partir d'un fichier projet avec un format maison qui se contente, en gros, d'indiquer la nature du projet (exécutable, bibliothèque dynamique…), et de lister les bibliothèques utilisées. Ce fichier projet sert d'ailleurs aussi au paquetage automatique des sources de l'application dans le but de la distribuer.

Le seul gros manque, c'est une méthode standard de paquetage, ainsi qu'éventuellement un dépôt officiel. Ce n'est pas tellement gênant pour des développement à façon, car je fournis au client généralement un .zip avec les binaires. Mais pour tout mes développements open source, à part pour Windows, je ne sais pas comment faire pour mettre à disposition mes logiciels sans les faire compiler par l'utilisateur, ce qui implique qu'il ai un compilateur C++, en plus de make.

Pour nous émanciper des géants du numérique : Zelbinium !

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/ :-) !

Pour nous émanciper des géants du numérique : Zelbinium !

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.

Pour nous émanciper des géants du numérique : Zelbinium !

Visiblement le plus petit dénominateur commun c'est le PPCM, je vois pas ce que serait le plus grand dénominateur commun, en mathématique.

PGCD ?

Pour nous émanciper des géants du numérique : Zelbinium !

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 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.

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 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 :-)…

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 toolkit Atlas, 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 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.

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 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 :-)…

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 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.

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 :-) !

Pour nous émanciper des géants du numérique : Zelbinium !

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 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.

Pour nous émanciper des géants du numérique : Zelbinium !

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.

Pour nous émanciper des géants du numérique : Zelbinium !

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.

Pour nous émanciper des géants du numérique : Zelbinium !

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…

Pour nous émanciper des géants du numérique : Zelbinium !

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.

Pour nous émanciper des géants du numérique : Zelbinium !

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…

Pour nous émanciper des géants du numérique : Zelbinium !

Salut :)

Salut !

D'abord, bravo pour tout le travail !

Merci !

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 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.

Pour nous émanciper des géants du numérique : Zelbinium !

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…

Pour nous émanciper des géants du numérique : Zelbinium !

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.

Pour nous émanciper des géants du numérique : Zelbinium !

Dernier champ du formulaire pour proposer un projet :

Merci de nous laisser une adresse où vous contacter d'ici fin décembre pour annoncer les projets retenus.

Ça risque de faire un peu tard pour un évènement se déroulant le mois prochain :-).

Pour nous émanciper des géants du numérique : Zelbinium !

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.

Pour nous émanciper des géants du numérique : Zelbinium !

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.

Pour nous émanciper des géants du numérique : Zelbinium !