Le post suggère de diriger les futurs profs de NSI/Python vers une bibliothèque maintenue par une personne qui n'est même pas installée par défaut sur les distributions Python classiques comme Anaconda. Cela me semble être une erreur grave. Je m'y connais plutôt en info (ce qui me permet d'être écouté oar les administrateurs du lycée) et c'est déjà compliqué pour demander aux administrateurs d'installer le moindre truc.
Les bibliothèques sont disponibles sur PyPi ; si Anaconda a un système équivalent de gestion de paquets, je veux bien créer ceux dédiés à ces bibliothèques, si cela peut en simplifier l'usage…
Ne parlons même pas de séparation entre le coeur du code et l'interface graphique d'un programme que ce genre d'enseignement va ignorer totalement.
Les manipulations concernant l'interface graphique étant réduites au minimum, seul celui qui élaborera les exercices sera amené à gérer la séparation interface/traitement…
L'outil présenté fait une jolie présentation, pour certains élèves en collège/lycée ça peut être intéressant pour juste les intéresser à la chose (les élèves en prépa sont généralement un peu plus motivés et costauds que la moyenne). L'aspect accessible via Internet est un plus (quand c'est prêt c'est directement utilisable), et un moins (il faut quelqu'un qui sache le mettre en place et bénéficier d'un hébergement).
C'est pour que ce soit directement utilisable que je met à disposition un serveur gratuit et public, sachant que, comme on est sur du logiciel libre, on reste tout à fait libre (sans jeu de mot) de mettre en place son propre serveur…
Pour ce qui est du post est des interfaces graphiques, je suis sceptique. Je suis prof dans une des meilleures prépa de France. Et je dois batailler en début d'année pour que les élèves comprennent qu'il y a une différence entre un print(a) et un return a. Écrire une interface graphique propre est un boulot de spécialiste et nécessite beaucoup de connaissances très spécifiques à la bibliothèque utilisée. Certes, c'est ici une bibliothèque très simple, qui permet de faire des input et des print plus jolis. Mais bon, je crois qu'il est plus important de savoir ce qu'est un tableau ou une table de hachage.
Et bien justement, le but de l'outil présenté ici est de pouvoir créer des exercices qui permettent aux élèves de profiter de tous les avantages d'une interface graphique, sans pour autant qu'ils aient à la manipuler directement, et ce afin qu'ils puissent se concentrer sur l'objet de l'exercice (tableau, table de hachage…).
Je me permets une remarque superficielle sur la forme :
j'essaye personnellement de présenter de bonnes habitudes de rédaction de code python à mes élèves.
Par conséquent, je préférerais leur fournir des fonctions utilitaires dont les identifiants respectent les conventions de nommage en python et non en camelCase.
J'étais passé à coté de la PEP dédiée.
Ceci dit, pour autant que je sache, dans le cadre des cours de SNT/NSI, on ne cherche pas à initier les élèves à Python en particulier, mais à la programmation en général. Du coup, respecter les conventions de nommage Python n'est pas aussi important que ça, car si un élève décide, plus tard, d'utiliser un autre langage, il est probable qu'il aura affaire à d'autres conventions de nommage.
Maintenant, cet outil est totalement agnostique concernant les conventions de nommage ; on peut donc mettre en œuvre, dans les exercices, celle de son choix.
Je vais étudier de plus près ces outils que vous partagez généreusement.
N'hésitez pas à m'en faire part si vous rencontrez des problèmes, ou si vous avez des remarques/suggestions/questions…
Concrètement, comme je n'utilise pas la STL, je ne m'attarde pas sur les nouveautés qui s'y rapportent. Donc, concernant ces nouveautés, aussitôt lues, aussitôt oubliées.
Des experts C++ qui se qualifie 4.5 / 5 en C++ et qui sont perdus dés avec 3 minutes quand tu leur parle de VTable.
Ça fait presque vingt ans que je programme quasi-exclusivement en C++, et ça ne me viendrait absolument pas à l'idée de me qualifier d'expert C++. D'une part, parce que je ne me considère pas comme tel, et, d'autre part, parce que je ne vois pas l'intérêt pour moi d'être un expert en C++, pour l'usage que j'en ai.
Le C++ est un outil que j'utilise de la manière qui me convient le mieux, qui n'est pas, j'en conviens, la plus répandue. Je me tiens au courant des fonctionnalités ajoutées au fur et à mesure des nouvelles versions et j'en adopte une de temps en temps (la dernière, ce sont les variadic templates, dont j'use et abuse), parce qu'elle me facilite mon travail de développeur. Ce qui fait que je dois n'en utiliser, au final, qu'une faible partie. Mais à quoi cela me servirait-il d'en connaître plus si je n'en ai pas l'usage ? À impressionner d'éventuels recruteurs ? Si mon compte Github ne leur suffit pas pour savoir si mes compétences en matière de programmation répondent ou non à leurs besoins, c'est leurs propres compétences qui laissent à désirer…
Pour reprendre une analogie fort populaire dans notre milieu : je possède ma voiture depuis plus de dix ans, et je bataille plusieurs minutes deux fois par an pour mettre mon auto-radio (intégré) à l'heure (c'était d'actualité il y a peu), alors que la procédure prend moins de 10 secondes si on la connaît. Du coup, malgré les dix ans et quelques que je l'ai en ma possession, difficile de me qualifier d'expert du modèle que je possède. Et ça ne me pose aucun problème, vu ce que je connais d'elle me suffit pour m'amener d'un point A à un point B dans des conditions que j'estime satisfaisantes.
Sous KDE, du moins avec Kubuntu, il y a Muon Package Manager. C'est assez proche de Synaptic, et je l'utilise systématiquement à la place de Discover. Le seul cas où j'utilise encore Discover, c'est pour les mises à jour, quand il s'ouvre lorsque l'on clique sur la notification.
Au début, je fermais la notification, et je faisais les mises à jour avec Muon. Mais Discover fait exactement les mêmes mises à jour, y compris les paquets qui n'apparaissent pas dans Discover et que j'ai donc installé via Muon, y compris également les paquets installés à partir d'un PPA, avec Muon.
J'ai eu, à l'occasion d'un projet, à programmer en différents langages (Java, Node.js, Perl, PHP, Python et Ruby), dont aucun ne m'était familier, la même bibliothèque faisant appel à des fonctionnalités assez poussées (réseau bas niveau, multi-tâche, gestion d'accès concurrents…), et c'est avec Python que je me suis le plus… amusé. En outre, pour l'implémentation de certains algorithmes, j'ai souvent écrit du code au feeling, trop paresseux que j'étais pour consulter la documentation, et c'est en encore avec Python que le code a le plus souvent fonctionné du premier coup, ou seulement après quelques modifications mineures. Ceci dit, les différences entre les versions 2 et 3, surtout concernant les fonctions réseau bas niveau, sont assez irritantes, mais il est assez facile d'écrire une surcouche qui permette de faire du réseau sans avoir à se préoccuper de la version utilisée de Python (version 2, version 3, surcouche).
Il y a quand même une singularité, que je qualifierais de maladresse, qui a du mal à passer. Par exemple, {1,2} est un set contenant deux nombres (notez les {} comme délimiteurs) et (3,4) un tuple contenant deux nombres (notez les () comme délimiteurs). Jusqu'à là, tout va bien. Par contre, bien que {5} est bien un set contenant un nombre, (6) n'est pas un tuple contenant un nombre, mais le nombre lui-même. Pour avoir un tuple contenant un seul nombre, il faut écrire (7,). Vu l'usage qui est généralement fait des parenthèses, ça peut se comprendre, mais ça reste assez déroutant. À noter que 8,9 (sans les parenthèses) est aussi un tuple contenant deux nombres.
Bon, je passe sur l'absence de switch/case, et d'enum ; on s'y fait assez rapidement.
Concernant l'apprentissage de la programmation, c'est Python qui semble être le plus utilisé. C'est encore lui qui est le langage de prédilection lorsque qu'il s'agit de manipuler les ports GPIO d'un Raspberry Pi. C'est donc vers ce langage que je me suis tourné pour un projet d'outil pédagogique (journal dédié) destiné à être utilisé dans le cadre de cours de programmation. Le fait de facilement avoir accès aux mécanismes internes de Python facilite l'écriture d'exercices pour ce genre de cours (ou du moins l'idée que je me fais d'exercices de ce genre). Alors, ce projet n'existe qu'en Python (pour le moment), donc je ne peux le comparer avec d'autres langages de ce point de vue, mais je ne vois pas trop comment faire mieux que Python. J'ai vraiment facilement et relativement élégamment pu résoudre les problématiques liés à ce genre de projets (vais peut-être faire un journal, voire une dépêche, sur le sujet un de ces jours…). Par contre, je me garderais bien de me prononcer sur la pertinence de l'utilisation de Python pour l'apprentissage de la programmation, n'ayant pas assez de recul.
Ne prenez pas ce commentaire pour plus qu'il n'est : un ressenti, donc totalement subjectif. Sachant, en outre, que, malgré toutes les qualités de Python, et des autres langages que j'ai pu essayer, le C++ reste mon langage de prédilection…
Le premier lien est l'équivalent d'un man gpio, et le second permet de voir à quoi ressemble la sortie de la commande readall. Ainsi, on peut installer l'utilitaire en connaissance de cause, et non pas juste pour se faire une idée, sans être sûr de vouloir le conserver.
Cet utilitaire n'est pas toujours installé d'office, même avec les distributions dédiées. Il n'était pas installé sur mon ODROID, par exemple.
Il y a aussi l'utilitaire gpio, installé d'office (il me semble) sur une Raspbian, avec notamment la commande readall, qui permet d'avoir une vue d'ensemble de la configuration et de l'état de chaque port GPIO. On peut voir cette commande en action sur cette vidéo (c'est du Peertube).
Dans ce cas précis , strchr(…) serait préférable, mais les deux seraient de toute manière plutôt l'équivalent de string.find(…). C'est var in other_var, en tant que construction du langage, qui n'a pas d'équivalent en C…
Comme indiqué dans le journal, le but ce n'est pas d'apprendre Python, mais la programmation en général. Donc, après avoir trouvé la solution pythonesque, un nouvel énoncé leur sera soumis dont la solution ressemble à celle proposée dans le fichier ci-dessus, histoire de les entraîner à écrire des boucles for.
À 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 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.
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.
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.
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…
Ç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.
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.
[^] # Re: NSI
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Apprentissage de la programmation dans les lycées (SNT/NSI) — la création d’exercices. Évalué à 2.
Les bibliothèques sont disponibles sur PyPi ; si Anaconda a un système équivalent de gestion de paquets, je veux bien créer ceux dédiés à ces bibliothèques, si cela peut en simplifier l'usage…
Les manipulations concernant l'interface graphique étant réduites au minimum, seul celui qui élaborera les exercices sera amené à gérer la séparation interface/traitement…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: NSI
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Apprentissage de la programmation dans les lycées (SNT/NSI) — la création d’exercices. Évalué à 2.
C'est pour que ce soit directement utilisable que je met à disposition un serveur gratuit et public, sachant que, comme on est sur du logiciel libre, on reste tout à fait libre (sans jeu de mot) de mettre en place son propre serveur…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: NSI
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Apprentissage de la programmation dans les lycées (SNT/NSI) — la création d’exercices. Évalué à 3.
Et bien justement, le but de l'outil présenté ici est de pouvoir créer des exercices qui permettent aux élèves de profiter de tous les avantages d'une interface graphique, sans pour autant qu'ils aient à la manipuler directement, et ce afin qu'ils puissent se concentrer sur l'objet de l'exercice (tableau, table de hachage…).
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: bravo... sauf pour l'excès de camelCase
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Apprentissage de la programmation dans les lycées (SNT/NSI) — la création d’exercices. Évalué à 1.
Merci !
J'étais passé à coté de la PEP dédiée.
Ceci dit, pour autant que je sache, dans le cadre des cours de SNT/NSI, on ne cherche pas à initier les élèves à Python en particulier, mais à la programmation en général. Du coup, respecter les conventions de nommage Python n'est pas aussi important que ça, car si un élève décide, plus tard, d'utiliser un autre langage, il est probable qu'il aura affaire à d'autres conventions de nommage.
Maintenant, cet outil est totalement agnostique concernant les conventions de nommage ; on peut donc mettre en œuvre, dans les exercices, celle de son choix.
N'hésitez pas à m'en faire part si vous rencontrez des problèmes, ou si vous avez des remarques/suggestions/questions…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Retour en arrière
Posté par Claude SIMON (site web personnel) . En réponse au lien Dix fonctions cachées pour mieux maîtriser Firefox - 01net. Évalué à 2.
On peut aussi rester appuyé sur le bouton droit durant le déplacement, et le relâcher seulement une fois positionné. Ça économise un clic…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Sans Ironie.
Posté par Claude SIMON (site web personnel) . En réponse au journal S'acheter son logement avec le salaire d'un expert C++ (ou autre techno). Évalué à 2.
Concrètement, comme je n'utilise pas la STL, je ne m'attarde pas sur les nouveautés qui s'y rapportent. Donc, concernant ces nouveautés, aussitôt lues, aussitôt oubliées.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Sans Ironie.
Posté par Claude SIMON (site web personnel) . En réponse au journal S'acheter son logement avec le salaire d'un expert C++ (ou autre techno). Évalué à 3.
Ça fait presque vingt ans que je programme quasi-exclusivement en C++, et ça ne me viendrait absolument pas à l'idée de me qualifier d'expert C++. D'une part, parce que je ne me considère pas comme tel, et, d'autre part, parce que je ne vois pas l'intérêt pour moi d'être un expert en C++, pour l'usage que j'en ai.
Le C++ est un outil que j'utilise de la manière qui me convient le mieux, qui n'est pas, j'en conviens, la plus répandue. Je me tiens au courant des fonctionnalités ajoutées au fur et à mesure des nouvelles versions et j'en adopte une de temps en temps (la dernière, ce sont les variadic templates, dont j'use et abuse), parce qu'elle me facilite mon travail de développeur. Ce qui fait que je dois n'en utiliser, au final, qu'une faible partie. Mais à quoi cela me servirait-il d'en connaître plus si je n'en ai pas l'usage ? À impressionner d'éventuels recruteurs ? Si mon compte Github ne leur suffit pas pour savoir si mes compétences en matière de programmation répondent ou non à leurs besoins, c'est leurs propres compétences qui laissent à désirer…
Pour reprendre une analogie fort populaire dans notre milieu : je possède ma voiture depuis plus de dix ans, et je bataille plusieurs minutes deux fois par an pour mettre mon auto-radio (intégré) à l'heure (c'était d'actualité il y a peu), alors que la procédure prend moins de 10 secondes si on la connaît. Du coup, malgré les dix ans et quelques que je l'ai en ma possession, difficile de me qualifier d'expert du modèle que je possède. Et ça ne me pose aucun problème, vu ce que je connais d'elle me suffit pour m'amener d'un point A à un point B dans des conditions que j'estime satisfaisantes.
Commentaire que j'ai écris il y quelques années sur comment ne pas être considéré comme un spécialiste C++ malgré une pratique quasi-quotidienne de plus de 12 ans : https://linuxfr.org/users/fredx/journaux/ce-qu-on-demande-a-un-developpeur-aujourd-hui#comment-1471811.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: The Wayland Itches project
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche GNOME 3.34. Évalué à 2. Dernière modification le 25 octobre 2019 à 18:17.
Sous KDE, du moins avec Kubuntu, il y a Muon Package Manager. C'est assez proche de Synaptic, et je l'utilise systématiquement à la place de Discover. Le seul cas où j'utilise encore Discover, c'est pour les mises à jour, quand il s'ouvre lorsque l'on clique sur la notification.
Au début, je fermais la notification, et je faisais les mises à jour avec Muon. Mais Discover fait exactement les mêmes mises à jour, y compris les paquets qui n'apparaissent pas dans Discover et que j'ai donc installé via Muon, y compris également les paquets installés à partir d'un PPA, avec Muon.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Personne pour le moment
Posté par Claude SIMON (site web personnel) . En réponse au message Diner des philosophes et jeu des bâtonnets. Évalué à 1.
Petite erreur à la fin du premier paragraphe :
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Sur l'utilisabilité et le jeu
Posté par Claude SIMON (site web personnel) . En réponse au journal Balance virtuelle, application éducative javascript. Évalué à 1.
Le bouton Ranger les masses est cliquable une fois la balance à l'équilibre.
« Smart IoT Crafting » : l'IoT pour tous
# Utilisation de Python par un profane
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 10.
J'ai eu, à l'occasion d'un projet, à programmer en différents langages (Java, Node.js, Perl, PHP, Python et Ruby), dont aucun ne m'était familier, la même bibliothèque faisant appel à des fonctionnalités assez poussées (réseau bas niveau, multi-tâche, gestion d'accès concurrents…), et c'est avec Python que je me suis le plus… amusé. En outre, pour l'implémentation de certains algorithmes, j'ai souvent écrit du code au feeling, trop paresseux que j'étais pour consulter la documentation, et c'est en encore avec Python que le code a le plus souvent fonctionné du premier coup, ou seulement après quelques modifications mineures. Ceci dit, les différences entre les versions 2 et 3, surtout concernant les fonctions réseau bas niveau, sont assez irritantes, mais il est assez facile d'écrire une surcouche qui permette de faire du réseau sans avoir à se préoccuper de la version utilisée de Python (version 2, version 3, surcouche).
Il y a quand même une singularité, que je qualifierais de maladresse, qui a du mal à passer. Par exemple,
{1,2}est un set contenant deux nombres (notez les{}comme délimiteurs) et(3,4)un tuple contenant deux nombres (notez les()comme délimiteurs). Jusqu'à là, tout va bien. Par contre, bien que{5}est bien un set contenant un nombre,(6)n'est pas un tuple contenant un nombre, mais le nombre lui-même. Pour avoir un tuple contenant un seul nombre, il faut écrire(7,). Vu l'usage qui est généralement fait des parenthèses, ça peut se comprendre, mais ça reste assez déroutant. À noter que8,9(sans les parenthèses) est aussi un tuple contenant deux nombres.Bon, je passe sur l'absence de switch/case, et d'enum ; on s'y fait assez rapidement.
Concernant l'apprentissage de la programmation, c'est Python qui semble être le plus utilisé. C'est encore lui qui est le langage de prédilection lorsque qu'il s'agit de manipuler les ports GPIO d'un Raspberry Pi. C'est donc vers ce langage que je me suis tourné pour un projet d'outil pédagogique (journal dédié) destiné à être utilisé dans le cadre de cours de programmation. Le fait de facilement avoir accès aux mécanismes internes de Python facilite l'écriture d'exercices pour ce genre de cours (ou du moins l'idée que je me fais d'exercices de ce genre). Alors, ce projet n'existe qu'en Python (pour le moment), donc je ne peux le comparer avec d'autres langages de ce point de vue, mais je ne vois pas trop comment faire mieux que Python. J'ai vraiment facilement et relativement élégamment pu résoudre les problématiques liés à ce genre de projets (vais peut-être faire un journal, voire une dépêche, sur le sujet un de ces jours…). Par contre, je me garderais bien de me prononcer sur la pertinence de l'utilisation de Python pour l'apprentissage de la programmation, n'ayant pas assez de recul.
Ne prenez pas ce commentaire pour plus qu'il n'est : un ressenti, donc totalement subjectif. Sachant, en outre, que, malgré toutes les qualités de Python, et des autres langages que j'ai pu essayer, le C++ reste mon langage de prédilection…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Seulement WebKit sur IOS
Posté par Claude SIMON (site web personnel) . En réponse au journal Une exploitation massive de failles dans iOS depuis plus de 2 ans. Évalué à 8. Dernière modification le 31 août 2019 à 23:24.
Si, mais, pour les raisons précédemment citées, il s'appuie sur WebKit au lieu de Gecko…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: C sur Raspberry
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Ordinateur à carte unique : Raspberry Pi 4 et consort. Évalué à 3.
Le premier lien est l'équivalent d'un
man gpio, et le second permet de voir à quoi ressemble la sortie de la commandereadall. Ainsi, on peut installer l'utilitaire en connaissance de cause, et non pas juste pour se faire une idée, sans être sûr de vouloir le conserver.Cet utilitaire n'est pas toujours installé d'office, même avec les distributions dédiées. Il n'était pas installé sur mon ODROID, par exemple.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: C sur Raspberry
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Ordinateur à carte unique : Raspberry Pi 4 et consort. Évalué à 3. Dernière modification le 23 août 2019 à 08:45.
Il y a aussi l'utilitaire
gpio, installé d'office (il me semble) sur une Raspbian, avec notamment la commandereadall, qui permet d'avoir une vue d'ensemble de la configuration et de l'état de chaque port GPIO. On peut voir cette commande en action sur cette vidéo (c'est du Peertube).« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Code
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
Dans ce cas précis ,
strchr(…)serait préférable, mais les deux seraient de toute manière plutôt l'équivalent destring.find(…). C'estvar in other_var, en tant que construction du langage, qui n'a pas d'équivalent en C…« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Code
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
C'est bien pour ça qu'il y a ceci…
Comme indiqué dans le journal, le but ce n'est pas d'apprendre Python, mais la programmation en général. Donc, après avoir trouvé la solution pythonesque, un nouvel énoncé leur sera soumis dont la solution ressemble à celle proposée dans le fichier ci-dessus, histoire de les entraîner à écrire des boucles
for.« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: un pendant python à Ruby Shoes!
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 3.
Peut-être PySimpleGUI ?
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Précisions sur l'informatique dans le secondaire.
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 1.
À 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.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Précisions sur l'informatique dans le secondaire.
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 1.
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…
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…
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 desinput(…)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.« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Programmation objet ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
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.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Programmation objet ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
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.
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: 'Marp' + 'PDF Presenter'
Posté par Claude SIMON (site web personnel) . En réponse au message recherche une solution pour faire des slides en markdown sous Fedora 30 . Évalué à 1.
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…
« Smart IoT Crafting » : l'IoT pour tous
[^] # Re: Performance
Posté par Claude SIMON (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 1.
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…
« Smart IoT Crafting » : l'IoT pour tous
# 'Marp' + 'PDF Presenter'
Posté par Claude SIMON (site web personnel) . En réponse au message recherche une solution pour faire des slides en markdown sous Fedora 30 . Évalué à 2. Dernière modification le 06 juin 2019 à 19:54.
Ç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…
« Smart IoT Crafting » : l'IoT pour tous
# Moi, pas du tout expert C++, je ne compte pas abandonner C++
Posté par Claude SIMON (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 4.
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.
« Smart IoT Crafting » : l'IoT pour tous