En lisant ce journal, je me suis dit que j'ai bien de la chance.
Il y a pas mal d'année de cela, j'ai codé, en C++, un parser que j'utilise encore intensivement. Bon, c'est un parserXML, pas JSON, mais la problématique est la même.
J'ai d'abord mis en place un système de callbacks. Le parsage était assuré par une fonction à laquelle je passais en paramètre, en plus du flux contenant les données à parser, une classe abstraite, dont une des méthodes virtuelles était appelée par le parser à chaque fois qu'il rencontrait un token, la méthode appelée dépendant de la nature du token rencontré.
Ce parser me servait essentiellement à désérialiser des structures de données, et, à l'usage, le système de callbacks ne s’avérait guère pratique. Il fallait en effet systématiquement mettre en place un automate pour garder trace du contexte pour pouvoir traiter correctement chaque token rencontré.
J'ai alors modifié le parser de manière à ce qu'il me rende la main à chaque token rencontré, et je le relançais autant de fois que nécessaire jusqu'à ce que l'ensemble des données soient traitées. Du coup, plus besoin de callbacks. Son utilisation consistait, à chaque balise rencontrée, à lancer un fonction dédiée au traitement du contenu de cette balise, et qui retournait à la fonction appelante une fois ce contenu traité. Donc, plus besoin d'automate ; la fonction en cours d'exécution lors du traitement d'un token me renseignait sur le contexte.
Quand j'ai lu ce journal, je me suis dit : "je dois avoir le même problème avec mon parserXML". Mais, après examen du code de mon parser et de la manière dont je l'utilisais, il s'est avéré que non. Pourtant, j'ai écrit ce parser de manière vraiment naïve, sans souci d'optimisation d'aucune sorte. Et je m'en sers notamment, en plus de la désérialisation, pour remplir ce que j'appelle une registry, grosso-modo un arbre auquel on peut affecter des attributs à chaque nœud, arbre qui, entre autres, me sert à stocker les paramètres de configuration de mes logiciels.
Du coup, je ne vois pas trop comment les parserJSON puissent soit-disant être aussi mauvais, compte tenu que, d’après l'expérience que j'ai des parser, la manière dont le parsage est réalisé dépend de la structure des données représentées par le fichier JSON (ou XML) parsé !
Ou alors, comme dit, j'ai simplement de la chance…
Pour nous émanciper des géants du numérique : Zelbinium !
Comme indiqué plus haut, je factorise mon code à outrance, ce qui fait qu'une grosse partie est commune à toutes les applications que je développe. Lors du développement de ce code, dont le cœur l'a été il y a plus de dix ans, j'avais à l'esprit les problématiques de sécurité, et j'ai fait mon maximum pour éviter les failles. Ce qui, je le concède volontiers, ne garantit en rien qu'il n'y en ai pas. Toujours est-il que ce code est déployé chez de nombreux clients, dans certains cas dans le cadre d'applications client/serveur accessibles au grand public et avec une fréquentation élevée.
Jusqu'à présent, aucun client ne m'a remonté de problèmes de sécurité. Cela peut arriver demain, auquel cas, après correction de la faille, je développerais une batterie de tests pour tester la correction, et pour tenter de détecter d'autres failles similaires. Mais, à ce jour, je ne vais perdre de temps à développer des tests pour tenter de déceler des failles dont on n'a jamais détecté la moindre trace…
Quand au code que je mets à disposition sous licence Libre, comme celui faisant l'objet de ce journal, j'attire l'attention sur la section 15 et la section 16 du fichier LICENCE fournit avec les sources. Partant de là, libre à l'utilisateur de, au choix,
auditer mon code (tâche ardue, mais pas impossible ; c'est de l'Open Source après tout),
le soumettre à une batterie de tests,
me demander de développer une batterie de tests.
Pour la dernière option, cela sera bien entendu réalisé contre rémunération, sauf s'il parvient à me fournir un test case mettant en évidence une faille qui justifie le développement de cette batterie de tests.
Encore une fois, même si moi-même je ne le fais pas, je conseille fortement tout un chacun de soumettre son code à un maximum de tests. Mais, concernant mon code, avec l'historique qu'il a, le gain que m'apporterait ces tests par rapport au temps que je passerais à les développer n'est pas rentable, à aucun point de vue, en particulier, mais pas seulement, du point de vue financier. D'autant plus que, et ton commentaire va également dans ce sens, aucune batterie de test ne peut garantir l'absence de failles.
Pour résumer, compte tenu de l'historique de mon code, de la manière dont il se comporte chez moi (j'utilise quotidiennement plusieurs logiciels que j'ai développés et qui contiennent donc ce code) et chez mes clients, je considère qu'il n'est pas plus vulnérable que la majorité des codes réalisés avec un minimum de sérieux et, de ce fait, probablement soumis à une batterie de tests. Mais je suis tout à fait disposé à réviser mon jugement, pour peu que l'on me soumette un test case prouvant mon erreur, et non pas seulement des considérations théoriques.
Quoi qu'il en soit, je te remercie pour tes remarques qui m'ont données l'occasion de m'expliquer davantage sur le sujet.
Pour nous émanciper des géants du numérique : Zelbinium !
Je suis tombe sur ce code dans ton fichier src/parser.cpp :
(...)
Est ce que tu peux expliquer ce que sont qRH, qRB, qRR, qRT, qRE et d'ou ils viennent ?
(Je suis au boulot et je peux pas charger ca dans un IDE pour tester :D )
Ce sont des macros qui datent de l'époque où je codais en C, lorsque j'avais implémenté un équivalent des exceptions, qui n'existaient pas alors, à l'aide de la bibliothèque setjmp.
Grosso modo, qRB correspond à try, qRR à catch, et qRT à l'accolade fermant du bloc du catch. Les autres macros servent à gérer les variables utilisées pour la gestion des erreurs.
Elles sont définis ici et les version d'origines, basées sur setjmp.h, sont visibles là.
D'un point de vue algorithmique, comme elles sont uniquement dédiées à la gestion des erreurs, elles peuvent être ignorées.
Pour nous émanciper des géants du numérique : Zelbinium !
D'abord, merci de contribuer du code, c'est sympa.
Merci de t'y intéresser :-).
Pour le feedback :
1) Il y a genre aucun commentaires dans le code, dur pour qui que ce soit de t'aider si ils ne peuvent pas comprendre ce que le code fait
En fait, je ne cherche pas de contributeurs, car cela poserait des problèmes de licence. Le code est, par défaut, disponible sous AGPL, mais c'est sous une autre licence, moins contraignante, qu'il est disponible pour mes clients. Je peux publier ce code sous n'importe quelle licence, car j'en suis l'unique auteur. Mais s'il contient des contributions de tiers, cela sera beaucoup plus compliqué…
En fait, bien plus que des contributeurs, c'est des utilisateurs que je recherche, qui puisse me remonter les éventuels problèmes. C'est d'ailleurs pour pour cela que j'ai migré mon code sur github, qui est l'une, voire la plus populaire des forges logiciels, pour que les utilisateurs disposent d'outils qui leurs sont familiers.
Ceci dit, je pense que ce qui manque à mon code, c'est bien plus une documentation expliquant les principes généraux que des commentaires. Mais, comme c'est moi qui ai écrit le code et que je l'utilise tous les jours, je ne suis probablement pas objectif…
2) Les noms de variables/methodes/etc… sont imbitables pour le commun des mortels (aucune idée de ce que lcl, qCDTOR, etc… sont)
En effet, d'où ce que j'écrivais ci-dessus, de la nécessité d'avoir une documentation explicative. J'envisage de publier une série d'utilitaires mettant chacun en avant une fonctionnalité bien précise de mes bibliothèques, et d'en écrire la documentation correspondante à ce moment-là. Mais, compte tenu du travail que cela représente, il faudrait qu'il y ai une réelle demande à ce niveau-là, ce dont je ne suis pas convaincu, pour me lancer.
3) Exposer un parser écrit en C++ à des documents venant de sources inconnues ( = internet) est super dangereux, est-ce que tu as fais des passes de fuzzing sur ce parser au minimum ?
Bon, je vais me faire huer, mais la vérité est que j'écris très peu de tests en tant que tels. Ce n'est pas que j'y sois opposé, et je conseille fortement d'en écrire, mais le fait est, et ça fait un paquet d'années que je développe, que j'ai très bien pu m'en passer jusqu'à présent. Ceci dit, je factorise mon code très en amont du développement, ce qui explique peut-être cela. Le préprocesseur, et le parser que lequel il s'appuie, qui font l'objet de ce journal, sont récents en tant que addonNode.js, mais le code C++ qu'il y a derrière existe depuis probablement presque dix ans, et est mis en œuvre dans tous les développements que j'ai réalisés depuis. C'est donc du code qui est utilisé très intensivement. Certes, ça ne garantit rien en soi, mais, plus un code a d'utilisateurs, plus rapidement les problèmes sont détectés (et, à priori, corrigés), et c'est pour cela que je cherche à accroître le nombre de ses utilisateurs…
Pour nous émanciper des géants du numérique : Zelbinium !
(Pour ceux qui connaissent RunKit, pourquoi process.stdout.write(...) ne fonctionne-t-il pas, et y a-t-il moyen d'avoir quelques chose d'équivalent, mis à part console ?)
Pour nous émanciper des géants du numérique : Zelbinium !
En tant que freelance, je me présente parfois comme développeur fullstack (pas exactement sous cet intitulé, mais il y a fullstack dedans). Ce que personnellement j'entends par là, c'est la capacité de pouvoir développer une application de A à Z, de l'interface utilisateur au moteur de base de données (si requis), et cela sans préjuger des technos utilisées. Cette définition n'est sans doute pas universelle, mais le fait d'utiliser ce terme, et c'est la raison pour laquelle je l'emploi, c'est que ça éveille la curiosité de mes interlocuteurs, la plupart ne connaissant pas ou peu ce terme.
Pour nous émanciper des géants du numérique : Zelbinium !
Si je me souviens bien, il fût un temps où, lors de l'édition de liens d'un programme C, seuls les 6 premiers caractères d'un symbole étaient pris en compte, et la casse était ignorée. D'où, sans doute, la concision des identifiants de la bibliothèque standard…
Pour nous émanciper des géants du numérique : Zelbinium !
Pour les pièces faites avec l'Amiga, j'utilisais un tracker, probablement Protracker. Pour les sons, je piochais dans ceux qui étaient fournis avec.
Pour le MIDI, les sons sont ceux d'origine de la Sound Blaster AWE32 que j'utilisais à l'époque. Elle m'avait coûtée une petite fortune, mais c'était l'une des meilleurs carte son de l'époque.
J'ai ajouté un PDF de la partition de la pièce 'OMS0964'. Comme la pièce n'est pas achevée, il manque certaines choses comme les nuances, ou encore les articulations…
Pour nous émanciper des géants du numérique : Zelbinium !
En fait, ce sont plutôt des exercices de style, beaucoup étant inachevés.
Les premières sont de ma période Amiga, aux timbres aisément reconnaissables, et limitées à 4 canaux, mais je m'étais quand bien amusé.
Les dernières sont du pur MIDI.
'rosscset' n'a évidemment pas été composée par moi ; c'est une transcription (ce n'est pas vraiment le terme adéquat) que j'ai réalisée pour explorer les possibilités du MIDI.
Pour la composition proprement dite, j'utilise un séquenceur MIDI + un clavier MIDI. Vu que le style de musique que je compose contient de nombreuses variations de tempo, je n'utilise que très rarement le métronome du séquenceur. Je joue en premier une voie significative, soit celle qui a la mélodie, soit une des voies d'accompagnement, et je rajoute les autres voies en me servant de cette voie comme base rythmique.
Le processus décrit dans mon précédent message sert juste à créer la partition correspondante.
Étant donné que, comme indiqué ci-dessus, je ne me sers que très rarement du métronome (je laisse le tempo par défaut, et je me contente de couper le son du métronome), il n'y a aucune correspondance entre la pulsation du métronome et ce que je joue. Or, comme le séquenceur s'appuie sur la pulsation du métronome pour en déduire la figure des notes d'après leur durée, la partition que ce dernier me génère est absolument injouable, sans compter qu'elle n'a de loin pas le rendu obtenu avec 'Lilypond'.
Pour nous émanciper des géants du numérique : Zelbinium !
je serai curieux d'avoir des retours de personnes qui composent avec les différentes solutions
Pour mes compositions et mes transcriptions, je les saisis voie par voie, fragment mélodique par fragment mélodique, à l'aide d'un petit utilitaire que j'ai écrit, et qui fonctionne de la manière suivante.
Dans un premier temps, il est en mode saisie de notes, dans lequel je joue la mélodie au clavier MIDI sans tenir compte des durées. Je lui fais rejouer la mélodie note par note, un appui sur une touche du clavier non MIDI le faisant passer d'une note à l'autre, un appui sur une note du clavier MIDI remplaçant la note en cours par la nouvelle note, ce qui me permet de corriger les erreurs.
Une fois toutes les notes de la mélodie correctement saisies, je bascule en mode saisie de durées.
Là aussi, le logiciel me joue la mélodie précédemment saisie note par note, et, pour chaque note, j'appuie sur une touche du pavé numérique, ce qui lui affecte une durée et le fait passer à la note suivante. '0' pour une ronde, '1' pour une blanche, '2' pour une noire, '3' pour une croche et ainsi de suite, en utilisant '.' si la note est pointée.
Je lui fais jouer toute la mélodie en tenant compte des durées, pour vérifier si elle est correcte, et corrige si nécessaire.
Une fois que le fragment mélodique est correct, je lui fais générer un fichier 'XML' qui décrit la mélodie, à l'aide de balises de mon cru. J'applique ensuite une transformation 'XSL' sur ce fichier 'XML', en utilisant un fichier 'XSL' spécialement écrit dans ce but, ce qui me génère le fragment mélodique au format 'Lilypond'. J'insère ce fragment dans le fichier 'Lilypond' global de l'œuvre, puis j'utilise 'Frescobaldi' pour ajouter les nuances, les articulations…
Et j'obtiens au final une superbe partition dont la présentation n'a rien à envier à ceux produits par les logiciels commerciaux, et ce sans avoir à saisir notes et durées dans le format 'Lilypond'.
Pour nous émanciper des géants du numérique : Zelbinium !
On peut mettre les options après SRC et DEST sans problèmes. C'est surtout que l'argument de --exclude est relatif par rapport à SRC, donc il ne faut pas mettre $(dossierSource) dans le PATTERN, et ce qui est indiqué ci-dessus devrait fonctionner…
Pour nous émanciper des géants du numérique : Zelbinium !
Je possède une tablette Android (ARM) sous CyanogenMod qui me permet d'aller sur le web sans avoir à allumer mon ordinateur de bureau, me sert de liseuse, et sur laquelle je peux compiler et lancer les logiciels que je développe. D'ailleurs, le logiciel que j'utilise le plus sur cette tablette est celui que je présente dans ce journal.
Comme il s'agit d'un logiciel natif en ligne de commande, j'ai installé Lil'Debi pour disposer de l'environnement de compilation adéquat, et également pour disposer d'un environnement GNU/Linux, auquel je peux me connecter à distance via SSH. La finalité de mon logiciel est de produire un fichier HTML, et j'affiche celui-ci dans un navigateur web sous Android, ce dernier ayant accès au système de fichiers de Lil'Debi.
À l'origine, je faisais tourner mon logiciel sur un NokiaN900, et c'était beaucoup plus simple parce que le N900 dispose d'un véritable environnement GNU/Linux. Malheureusement, l'écran du N900 est trop petit pour déchiffrer une partition. D'où l'utilisation d'une tablette, avec installation de Lil'Debi, pour me retrouver à peu prés avec le même environnent que celui du N900. Le problème, c'est que Lil'Debi rend la tablette poussive.
Du coup, j'ai repéré une tablette Intel hybride Android/Windows, ce qui m'offre les possibilité suivantes :
- Soit de remplacer Windows par une distribution GNU/Linux,
- soit d'installer Cygwin pour y retrouver un environnement à la GNU,
- soit de l'utiliser avec Android comme ma tablette actuelle, sachant qu'elle devrait pouvoir encaisser plus facilement Lil'Debi étant donné qu'elle a beaucoup plus de RAM, Windows oblige.
Au final, je cherche l'équivalent de mon N900 en tablette 10" ou plus, et le modèle que je décris ci-dessus s'en approche le plus, sachant que j'aimerais, en plus, en lui adjoignant un trackball et un clavier, pouvoir m'en servir de machine de développement secondaire, lorsque je suis en déplacement, et qu'il faut donc qu'elle soit assez costaude…
Pour nous émanciper des géants du numérique : Zelbinium !
De ce que j'ai pu constater, on a, d'une part, les webmails, auxquels on peut accéder d'à peu prés n'importe quel dispositif connecté à Internet, mais qui ne sont, en gros, que des frontendsIMAP, d'où le fait que l'on ne peut gérer qu'un seul compte mail à la fois, et, d'autre part, les clients natifs, qui peuvent proposer des fonctionnalités plus évoluées que celles disponibles avec IMAP, comme la gestion simultanée de plusieurs comptes en même temps, mais qui ne sont accessibles que d'une seule machine.
Ce que je cherche à obtenir, c'est le meilleur des deux mondes, c'est-à-dire pouvoir accéder à mon MUA d'un maximum de dispositifs connectés, et pouvoir cependant toujours disposer de toute les fonctionnalités de mon MUA, qui iront au-delà de celles disponibles IMAP.
C'est pour cela que mon MUA, contrairement aux MUA classiques qui accèdent directement aux serveurs POP3/IMAP, se connecte à un daemon, et c'est ce daemon se connectera aux différents comptes POP3/IMAP. Et comme c'est également ce daemon qui implémentera toutes les fonctionnalités de mon MUA, ces fonctionnalités seront disponibles quels que soient les clients utilisés (desktop, web ou mobile).
Pour nous émanciper des géants du numérique : Zelbinium !
Personnellement, le compte d'origine d'un mail m'importe peu, d'autant qu'il n'est pas rare que je change le compte d'affectation de mes alias. Faire passer ce lien entre courrier et compte au second plan est même l'un des objectifs de mon application. Mais la plupart des MUA sont, en quelque sorte, orientés comptes, donc, quelque part, je pense qu'il est préférable qu'un utilisateur qui utilisait ce genre de MUA puisse retrouver ce lien auquel il est habitué, bien que ce lien ne soit qu'accessoire au niveau de l'application.
Pour nous émanciper des géants du numérique : Zelbinium !
Je viens d'installer Claws-Mail et, effectivement, contrairement à ce que je supputais dans le journal (et que j'entendais par « …indépendamment les uns des autres »), au moins avec ce logiciel, il est possible de déplacer un courrier d'un compte mail à un autre. Ceci dit, je ne pense pas que ce soit propre à ce logiciel ; cela doit être lié au protocole IMAP…
Néanmoins, dans Claws-Mail (à moins que j'ai loupé quelque chose dans ses options de configuration), chaque compte mail a sa propre arborescence, même si elles ne sont pas aussi imperméables que je le pensais. Or, je préfèrerais avoir une arborescence unique et commune à tous les comptes mail, même s'il doit rester possible de différencier les courriers en fonction du compte dont ils sont issus.
Pour ce qui est de l'écriture d'un nouveau courrier, je ne me suis pas encore penché sur la question, me concentrant pour l'instant sur la lecture de courriers (protocole IMAP et connexions chiffrées), mais je prend bonne note de la fonctionnalité décrite.
Pour nous émanciper des géants du numérique : Zelbinium !
Après 4 LogitechM570 (dont deux suite à un remplacement sous garantie, à chaque fois accepté sans difficulté et rondement mené par Logitech), lassé par un problème récurrent de bouton gauche devenant inutilisable au bout d'à peu prés un an, j'ai actuellement un APTICO de SPEEDLINK. C'est un trackball sans fil à commande par pouce (à l'instar de Logitech, ils ne font pas (plus) de modèle filaire).
Cela fait moins d'un an que je le possède, donc je ne sais pas s'il tiendra plus longtemps que le M570, mais, malgré le fait qu'un des pieds en caoutchouc s'est barré (ce qui, personnellement, ne me dérange pas), et que le pointeur se bloque (bah oui, ça n'arrive pas qu'aux claviers) de temps en temps (il suffit alors d'actionner le bouton gauche et ça repart), il me convient.
Sinon, en filaire, mais je ne l'ai pas essayé, il existe le SANWA MA-TB39.
Pour nous émanciper des géants du numérique : Zelbinium !
Je ne suis qu'un dilettante en la matière, donc je vais peut-être sortir une grosse connerie, mais je suis un jour tombé par hasard sur ça. Ça n'irait pas dans le sens de ce que tu décris ?
Pour nous émanciper des géants du numérique : Zelbinium !
Ce n'est pas parce que c'est atypique que c'est imbitable
Imbitable n'était pas le bon mot, disons qu'elle n'est pas pour l'instant réutilisable par quelqu'un d'autre que toi : quel que soit le besoin, il sera moins coûteux de créer une nouvelle appli basée sur des technologies connues que d'investir dans la tienne.
interface web fonctionne avec tous les navigateurs web graphiques modernes
Je ne sais pas quels sont tes clients, mais pour les miens « moderne » signifie plutôt « moins de 3 ans » que « moins de 3 semaines ». Et une incompatibilité avec firefox et internet explorer pour windows < 10 est invendable.
Je n'ai jamais développé d'application web pour mes clients, et je n'ai pas l'intention d'en développer. L'interface de l’application présentée ici montre clairement que je n'ai pas les compétences en HTML, CSS et consorts pour cela (c'est pour cela que la facilité de modification de l'interface est un point clef de la technologie que j'emploie). D'ailleurs, si un prospect me contacte pour me demander de développer une application web, je lui dit sans équivoque qu'il lui sera facile de trouver développeur bien plus compétent et concurrentiel que moi pour cela.
Le fait est que les interfaces desktop que je développe s'appuient sur des technos web, pour les raisons expliquées dans ce journal. Du fait de l'utilisation de ces technos web, il me semblait juste logique que le même code puisse servir pour développer une version web de l'interface. Et c'est cette hypothèse qui fait l'objet d'une des POC présentés ici. L'interface web, c'est juste un bonus ; cela ne fait pas officiellement partie de mes prestations…
Tu as visiblement la chance d'avoir des clients qui ne s'intéressent pas à la technique et qui deviennent captifs puisque tu es le seul à pouvoir maintenir ton code, mais c'est de moins en moins la réalité du marché.
Au contraire, c'est parce que mes clients s'intéressent à la technique qu'ils me contactent. Ils sont bien conscients que c'est parce que les développeurs classiques n'ont pas la maîtrise des technologies qu'ils utilisent qu'ils ne sont pas capables de leur fournir une application qui réponde à leurs besoins. Avec mon framework, parce que j'en ai la totale maîtrise, je ne suis pas soumis au bon vouloir d'un éditeur pour en dépasser les limites.
Il vaut mieux une application développée dans une technologie soi-disant captive (mon framework, c'est quand même que du C++), mais qui réponde parfaitement aux besoins du client, qu'une application certes basée sur des technologies répandues, mais inutilisable à cause des limitations de ces technologies. Des clients dont les exigences sont telles que les technologies classiques ne peuvent y répondre sont peu nombreux, mais, d'un autre coté, comme on est peu de développeurs sur ce marché…
Du coup je ne comprends pas l'objectif de ton POC, parce que je n'ai aucun doute que ça va fonctionner et que tu vas pouvoir l'utiliser pour tes clients, mais pourquoi le rends-tu public ?
- tu as déjà expliqué dans les commentaires des journaux précédents que tu ne visais pas un usage pour les projets communautaires
- maintenant tu sembles indiquer que même pour des projets de commande tu t'adresses à un marché très restreint
Je n'ai pas trop compris ce que tu entends par viser un usage pour les projets communautaires.
Concernant mon framework, du fait qu'il soit atypique et que la documentation est inexistante, il y a peu de chances que quelqu'un s'y intéresse ; je ne communique donc pas directement dessus. Par contre, une application telle que celle présentée ici, naturellement pas en l'état, est plus à même de susciter l'intérêt, voire de fédérer une communauté. Certes, il reste bien du travail pour que cette application soit utilisable, et c'est pour cela que j'insiste plus sur l'aspect POC que sur ses fonctionnalités. Mais, à terme, peut-être deviendra-t-elle un projet communautaire ? En tout cas, je n'y aurais rien à y redire…
Je pense que tu as raison de continuer, visiblement ça peut te permettre d'avoir un avantage concurrentiel dans ton marché, mais je ne comprends pas quel est ton but en communiquant à ce sujet dans des journaux sur linuxfr.org.
Suite à ces journaux, j'observe quand même quelques téléchargements de mes logiciels. Sans préjuger de l'intention des téléchargeurs, on peut quand même supposer que mes logiciels, et donc leur évolution, les intéressent, d'où ces journaux pour communiquer à leur sujet…
Pour nous émanciper des géants du numérique : Zelbinium !
Avant je ne comprenais pas tes technologies, mais au moins tu affichais un objectif clair : avant tout répondre aux besoins de tes clients, même si c'est au prix d'une solution imbitable.
Ce n'est pas parce que c'est atypique que c'est imbitable. Et si tu m'indiquais précisément ce qui te semble imbitable, je me ferais un plaisir de te fournir les explications pour te le rendre bitable. Et ça me donnerais de précieuses indications sur ce que je dois mettre dans la documentation que je suis en train de rédiger.
Aujourd'hui on apprend que ça ne permet de générer que des interfaces web incompatibles avec la plupart des navigateurs, ce qui serait rédhibitoire pour n'importe quel client. Maintenant je ne comprends ni tes technologies, ni tes objectifs…
Je me suis peut-être mal exprimé, mais, au contraire, depuis la mise à jour de Microsoft Edge, l'interface web fonctionne avec tous les navigateurs web graphiques modernes que j'ai pu essayer. Avec la démonstration en ligne, il y a moyen de s'en rendre compte par soi-même. Il y a juste Firefox qui pose problème dans certains cas, comme je l'ai expliqué…
Pour nous émanciper des géants du numérique : Zelbinium !
Oui, le code est imbittable, parce que ça n'est pas vraiment du C++, c'est plein de macros qui définissent un nouveau dialecte, et quand on mit le code, ça ne respecte pas la grammaire du langage.
Quelles macros ? Les seules que je tape régulièrement, ce sont qRH, qRB, qRR…, et leurs consœurs qRFwk(), qRGnr()…; qui sont dédiées à la gestion d'erreurs ; algorithmiquement, elles ne sont pas significatives, et elles ne sont pas nécessaires à la compréhension du code, sauf quand celui-ci s'occupe de la gestion des erreurs, évidemment. Quant aux autres macros, elles existent juste pour m'éviter d'avoir à taper du code dont j'ai fréquemment besoin, mais elles ne constituent certainement pas un nouveau dialecte.
Si l'on m'indique quelles macros posent problème, je détaillerais volontiers leurs usages…
Ceci dit, non, ça n'est pas non plus un pur troll, puisque l'auteur du journal semble comprendre sa technologie et même arriver à en vivre. D'ailleurs, dans le journal précédent, certaines discussions techniques semblaient confirmer que plusieurs personnes comprenaient le principe.
Pour moi, c'est de l'informatique abstraite: tu as des trucs qui font des surcouches à une autre techno qui modifie du code dans un autre langage qui va te générer du HTML qu'il va falloir lire avec un navigateur, tu as besoin d'un quadricœur avec 4Go de RAM rien que pour un "Hello Word", mais soi-disant ça accélère le développement. Je ne comprend pas l'utilité d'une telle complexité, mais je dois être dépassé…
Ce n'est de loin pas de l'informatique abstraite : la preuve, il y a une démonstration accessible en ligne qui montre que c'est au contraire tout à fait concret. Quand à cette histoire de surcouche avec HTML, je n'ai pas trop compris. Cela concerne peut-être ce que j'ai décris dans ce journal.
Pour ce qui est d'avoir besoin d'un quadricœur avec 4GO de RAM, il y a un package disponible avec les binaires Windows destinés à du XP SP3 et supérieur, et un autre pour du GNU/Linux compatible IA-32 ou AMD64natif. Ces packages sont relativement simple à déployer (mais je concède que c'est améliorable), et je suis preneur de tout retour sur leur mise en œuvre.
Soit dit en passant, comme je l'ai signalé, la CGI et le backend tournent sans problèmes sur une brique internet, à savoir une architecture ARM 32 bits dual-core à 1 GHz avec 512 Mo de RAM. Pour ceux qui disposent d'un matériel similaire tournant sous GNU/Linux, ils peuvent le vérifier ; je décris la procédure dans le journal. Et enfin, il y a la démonstration en ligne ; là aussi, je suis preneur de tout retour sur les ressources nécessaires et les éventuels problèmes rencontrés en fonction du navigateur utilisé.
Pour nous émanciper des géants du numérique : Zelbinium !
# O Fortuna !
Posté par Claude SIMON (site web personnel) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 5.
En lisant ce journal, je me suis dit que j'ai bien de la chance.
Il y a pas mal d'année de cela, j'ai codé, en C++, un parser que j'utilise encore intensivement. Bon, c'est un parser XML, pas JSON, mais la problématique est la même.
J'ai d'abord mis en place un système de callbacks. Le parsage était assuré par une fonction à laquelle je passais en paramètre, en plus du flux contenant les données à parser, une classe abstraite, dont une des méthodes virtuelles était appelée par le parser à chaque fois qu'il rencontrait un token, la méthode appelée dépendant de la nature du token rencontré.
Ce parser me servait essentiellement à désérialiser des structures de données, et, à l'usage, le système de callbacks ne s’avérait guère pratique. Il fallait en effet systématiquement mettre en place un automate pour garder trace du contexte pour pouvoir traiter correctement chaque token rencontré.
J'ai alors modifié le parser de manière à ce qu'il me rende la main à chaque token rencontré, et je le relançais autant de fois que nécessaire jusqu'à ce que l'ensemble des données soient traitées. Du coup, plus besoin de callbacks. Son utilisation consistait, à chaque balise rencontrée, à lancer un fonction dédiée au traitement du contenu de cette balise, et qui retournait à la fonction appelante une fois ce contenu traité. Donc, plus besoin d'automate ; la fonction en cours d'exécution lors du traitement d'un token me renseignait sur le contexte.
Quand j'ai lu ce journal, je me suis dit : "je dois avoir le même problème avec mon parser XML". Mais, après examen du code de mon parser et de la manière dont je l'utilisais, il s'est avéré que non. Pourtant, j'ai écrit ce parser de manière vraiment naïve, sans souci d'optimisation d'aucune sorte. Et je m'en sers notamment, en plus de la désérialisation, pour remplir ce que j'appelle une registry, grosso-modo un arbre auquel on peut affecter des attributs à chaque nœud, arbre qui, entre autres, me sert à stocker les paramètres de configuration de mes logiciels.
Du coup, je ne vois pas trop comment les parser JSON puissent soit-disant être aussi mauvais, compte tenu que, d’après l'expérience que j'ai des parser, la manière dont le parsage est réalisé dépend de la structure des données représentées par le fichier JSON (ou XML) parsé !
Ou alors, comme dit, j'ai simplement de la chance…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Singulier, pluriel, faut savoir !
Posté par Claude SIMON (site web personnel) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 2.
Ne serait-ce pas plutôt «the latter» (avec deux
t) ?Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Mais je t'en prie...
Posté par Claude SIMON (site web personnel) . En réponse au journal Code natif et Node.js - parser et préprocesseur XML. Évalué à 3.
Comme indiqué plus haut, je factorise mon code à outrance, ce qui fait qu'une grosse partie est commune à toutes les applications que je développe. Lors du développement de ce code, dont le cœur l'a été il y a plus de dix ans, j'avais à l'esprit les problématiques de sécurité, et j'ai fait mon maximum pour éviter les failles. Ce qui, je le concède volontiers, ne garantit en rien qu'il n'y en ai pas. Toujours est-il que ce code est déployé chez de nombreux clients, dans certains cas dans le cadre d'applications client/serveur accessibles au grand public et avec une fréquentation élevée.
Jusqu'à présent, aucun client ne m'a remonté de problèmes de sécurité. Cela peut arriver demain, auquel cas, après correction de la faille, je développerais une batterie de tests pour tester la correction, et pour tenter de détecter d'autres failles similaires. Mais, à ce jour, je ne vais perdre de temps à développer des tests pour tenter de déceler des failles dont on n'a jamais détecté la moindre trace…
Quand au code que je mets à disposition sous licence Libre, comme celui faisant l'objet de ce journal, j'attire l'attention sur la section 15 et la section 16 du fichier LICENCE fournit avec les sources. Partant de là, libre à l'utilisateur de, au choix,
Pour la dernière option, cela sera bien entendu réalisé contre rémunération, sauf s'il parvient à me fournir un test case mettant en évidence une faille qui justifie le développement de cette batterie de tests.
Encore une fois, même si moi-même je ne le fais pas, je conseille fortement tout un chacun de soumettre son code à un maximum de tests. Mais, concernant mon code, avec l'historique qu'il a, le gain que m'apporterait ces tests par rapport au temps que je passerais à les développer n'est pas rentable, à aucun point de vue, en particulier, mais pas seulement, du point de vue financier. D'autant plus que, et ton commentaire va également dans ce sens, aucune batterie de test ne peut garantir l'absence de failles.
Pour résumer, compte tenu de l'historique de mon code, de la manière dont il se comporte chez moi (j'utilise quotidiennement plusieurs logiciels que j'ai développés et qui contiennent donc ce code) et chez mes clients, je considère qu'il n'est pas plus vulnérable que la majorité des codes réalisés avec un minimum de sérieux et, de ce fait, probablement soumis à une batterie de tests. Mais je suis tout à fait disposé à réviser mon jugement, pour peu que l'on me soumette un test case prouvant mon erreur, et non pas seulement des considérations théoriques.
Quoi qu'il en soit, je te remercie pour tes remarques qui m'ont données l'occasion de m'expliquer davantage sur le sujet.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Syntaxe bizarre
Posté par Claude SIMON (site web personnel) . En réponse au journal Code natif et Node.js - parser et préprocesseur XML. Évalué à 1.
Ce sont des macros qui datent de l'époque où je codais en C, lorsque j'avais implémenté un équivalent des exceptions, qui n'existaient pas alors, à l'aide de la bibliothèque
setjmp.Grosso modo,
qRBcorrespond àtry,qRRàcatch, etqRTà l'accolade fermant du bloc ducatch. Les autres macros servent à gérer les variables utilisées pour la gestion des erreurs.Elles sont définis ici et les version d'origines, basées sur
setjmp.h, sont visibles là.D'un point de vue algorithmique, comme elles sont uniquement dédiées à la gestion des erreurs, elles peuvent être ignorées.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Mais je t'en prie...
Posté par Claude SIMON (site web personnel) . En réponse au journal Code natif et Node.js - parser et préprocesseur XML. Évalué à 1.
Merci de t'y intéresser :-).
En fait, je ne cherche pas de contributeurs, car cela poserait des problèmes de licence. Le code est, par défaut, disponible sous AGPL, mais c'est sous une autre licence, moins contraignante, qu'il est disponible pour mes clients. Je peux publier ce code sous n'importe quelle licence, car j'en suis l'unique auteur. Mais s'il contient des contributions de tiers, cela sera beaucoup plus compliqué…
En fait, bien plus que des contributeurs, c'est des utilisateurs que je recherche, qui puisse me remonter les éventuels problèmes. C'est d'ailleurs pour pour cela que j'ai migré mon code sur github, qui est l'une, voire la plus populaire des forges logiciels, pour que les utilisateurs disposent d'outils qui leurs sont familiers.
Ceci dit, je pense que ce qui manque à mon code, c'est bien plus une documentation expliquant les principes généraux que des commentaires. Mais, comme c'est moi qui ai écrit le code et que je l'utilise tous les jours, je ne suis probablement pas objectif…
En effet, d'où ce que j'écrivais ci-dessus, de la nécessité d'avoir une documentation explicative. J'envisage de publier une série d'utilitaires mettant chacun en avant une fonctionnalité bien précise de mes bibliothèques, et d'en écrire la documentation correspondante à ce moment-là. Mais, compte tenu du travail que cela représente, il faudrait qu'il y ai une réelle demande à ce niveau-là, ce dont je ne suis pas convaincu, pour me lancer.
Bon, je vais me faire huer, mais la vérité est que j'écris très peu de tests en tant que tels. Ce n'est pas que j'y sois opposé, et je conseille fortement d'en écrire, mais le fait est, et ça fait un paquet d'années que je développe, que j'ai très bien pu m'en passer jusqu'à présent. Ceci dit, je factorise mon code très en amont du développement, ce qui explique peut-être cela. Le préprocesseur, et le parser que lequel il s'appuie, qui font l'objet de ce journal, sont récents en tant que addon Node.js, mais le code C++ qu'il y a derrière existe depuis probablement presque dix ans, et est mis en œuvre dans tous les développements que j'ai réalisés depuis. C'est donc du code qui est utilisé très intensivement. Certes, ça ne garantit rien en soi, mais, plus un code a d'utilisateurs, plus rapidement les problèmes sont détectés (et, à priori, corrigés), et c'est pour cela que je cherche à accroître le nombre de ses utilisateurs…
Pour nous émanciper des géants du numérique : Zelbinium !
# Essai en ligne.
Posté par Claude SIMON (site web personnel) . En réponse au journal Code natif et Node.js - parser et préprocesseur XML. Évalué à 1.
Pour ceux qui ne connaissent pas (c'était mon cas il n'y pas encore bien longtemps), il est possible d'essayer le paquet en ligne, grâce à RunKit.
À titre d'exemple, copiez le code ci-dessous dans le champ de saisi, puis cliquez sur le bouton vert (
run) situé en-bas à droite de ce même champ :(Pour ceux qui connaissent RunKit, pourquoi
process.stdout.write(...)ne fonctionne-t-il pas, et y a-t-il moyen d'avoir quelques chose d'équivalent, mis à partconsole?)Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: fullstack : bullshit
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Formation « Développeur d’applications Fullstack » à l’Institut National Polytechnique de Toulouse. Évalué à 3. Dernière modification le 06 avril 2017 à 14:40.
En tant que freelance, je me présente parfois comme développeur fullstack (pas exactement sous cet intitulé, mais il y a fullstack dedans). Ce que personnellement j'entends par là, c'est la capacité de pouvoir développer une application de A à Z, de l'interface utilisateur au moteur de base de données (si requis), et cela sans préjuger des technos utilisées. Cette définition n'est sans doute pas universelle, mais le fait d'utiliser ce terme, et c'est la raison pour laquelle je l'emploi, c'est que ça éveille la curiosité de mes interlocuteurs, la plupart ne connaissant pas ou peu ce terme.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Comme les dieux l'ont voulu
Posté par Claude SIMON (site web personnel) . En réponse au journal CamelCase ou lowercase_with_underscore. Évalué à 4.
Si je me souviens bien, il fût un temps où, lors de l'édition de liens d'un programme C, seuls les 6 premiers caractères d'un symbole étaient pris en compte, et la casse était ignorée. D'où, sans doute, la concision des identifiants de la bibliothèque standard…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: OSV + Renault + ARM
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche La voiture en open source. Évalué à -2.
Euh non ; je pensais naïvement qu'elles étaient immuables, et que c'étaient nos connaissances les concernant qui évoluaient…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Un petit utilitaire à moi -> XML + XSL -> 'Lilypond' + 'Frescobaldi'.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche L’expression musicale sous GNU/Linux. Évalué à 2.
Merci ! Content que ça plaise !
Pour les pièces faites avec l'Amiga, j'utilisais un tracker, probablement Protracker. Pour les sons, je piochais dans ceux qui étaient fournis avec.
Pour le MIDI, les sons sont ceux d'origine de la Sound Blaster AWE32 que j'utilisais à l'époque. Elle m'avait coûtée une petite fortune, mais c'était l'une des meilleurs carte son de l'époque.
J'ai ajouté un PDF de la partition de la pièce 'OMS0964'. Comme la pièce n'est pas achevée, il manque certaines choses comme les nuances, ou encore les articulations…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Un petit utilitaire à moi -> XML + XSL -> 'Lilypond' + 'Frescobaldi'.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche L’expression musicale sous GNU/Linux. Évalué à 3.
En fait, ce sont plutôt des exercices de style, beaucoup étant inachevés.
Les premières sont de ma période Amiga, aux timbres aisément reconnaissables, et limitées à 4 canaux, mais je m'étais quand bien amusé.
Les dernières sont du pur MIDI.
'rosscset' n'a évidemment pas été composée par moi ; c'est une transcription (ce n'est pas vraiment le terme adéquat) que j'ai réalisée pour explorer les possibilités du MIDI.
Les voici : http://q37.info/download/music/
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Un petit utilitaire à moi -> XML + XSL -> 'Lilypond' + 'Frescobaldi'.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche L’expression musicale sous GNU/Linux. Évalué à 3.
Pour la composition proprement dite, j'utilise un séquenceur MIDI + un clavier MIDI. Vu que le style de musique que je compose contient de nombreuses variations de tempo, je n'utilise que très rarement le métronome du séquenceur. Je joue en premier une voie significative, soit celle qui a la mélodie, soit une des voies d'accompagnement, et je rajoute les autres voies en me servant de cette voie comme base rythmique.
Le processus décrit dans mon précédent message sert juste à créer la partition correspondante.
Étant donné que, comme indiqué ci-dessus, je ne me sers que très rarement du métronome (je laisse le tempo par défaut, et je me contente de couper le son du métronome), il n'y a aucune correspondance entre la pulsation du métronome et ce que je joue. Or, comme le séquenceur s'appuie sur la pulsation du métronome pour en déduire la figure des notes d'après leur durée, la partition que ce dernier me génère est absolument injouable, sans compter qu'elle n'a de loin pas le rendu obtenu avec 'Lilypond'.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Un petit utilitaire à moi -> XML + XSL -> 'Lilypond' + 'Frescobaldi'.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche L’expression musicale sous GNU/Linux. Évalué à 5.
Pour mes compositions et mes transcriptions, je les saisis voie par voie, fragment mélodique par fragment mélodique, à l'aide d'un petit utilitaire que j'ai écrit, et qui fonctionne de la manière suivante.
Dans un premier temps, il est en mode saisie de notes, dans lequel je joue la mélodie au clavier MIDI sans tenir compte des durées. Je lui fais rejouer la mélodie note par note, un appui sur une touche du clavier non MIDI le faisant passer d'une note à l'autre, un appui sur une note du clavier MIDI remplaçant la note en cours par la nouvelle note, ce qui me permet de corriger les erreurs.
Une fois toutes les notes de la mélodie correctement saisies, je bascule en mode saisie de durées.
Là aussi, le logiciel me joue la mélodie précédemment saisie note par note, et, pour chaque note, j'appuie sur une touche du pavé numérique, ce qui lui affecte une durée et le fait passer à la note suivante. '0' pour une ronde, '1' pour une blanche, '2' pour une noire, '3' pour une croche et ainsi de suite, en utilisant '.' si la note est pointée.
Je lui fais jouer toute la mélodie en tenant compte des durées, pour vérifier si elle est correcte, et corrige si nécessaire.
Une fois que le fragment mélodique est correct, je lui fais générer un fichier 'XML' qui décrit la mélodie, à l'aide de balises de mon cru. J'applique ensuite une transformation 'XSL' sur ce fichier 'XML', en utilisant un fichier 'XSL' spécialement écrit dans ce but, ce qui me génère le fragment mélodique au format 'Lilypond'. J'insère ce fragment dans le fichier 'Lilypond' global de l'œuvre, puis j'utilise 'Frescobaldi' pour ajouter les nuances, les articulations…
Et j'obtiens au final une superbe partition dont la présentation n'a rien à envier à ceux produits par les logiciels commerciaux, et ce sans avoir à saisir notes et durées dans le format 'Lilypond'.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Syntaxe
Posté par Claude SIMON (site web personnel) . En réponse au message [RÉSOLU] rsync exclusion de fichier et dossier. Évalué à 2. Dernière modification le 23 janvier 2017 à 19:14.
On peut mettre les options après SRC et DEST sans problèmes. C'est surtout que l'argument de
--excludeest relatif par rapport à SRC, donc il ne faut pas mettre$(dossierSource)dans le PATTERN, et ce qui est indiqué ci-dessus devrait fonctionner…Pour nous émanciper des géants du numérique : Zelbinium !
# CyanogenMod (LineageOS) + Lil'Debi
Posté par Claude SIMON (site web personnel) . En réponse au journal Tablette 2017. Évalué à 5. Dernière modification le 14 janvier 2017 à 17:14.
Je possède une tablette Android (ARM) sous CyanogenMod qui me permet d'aller sur le web sans avoir à allumer mon ordinateur de bureau, me sert de liseuse, et sur laquelle je peux compiler et lancer les logiciels que je développe. D'ailleurs, le logiciel que j'utilise le plus sur cette tablette est celui que je présente dans ce journal.
Comme il s'agit d'un logiciel natif en ligne de commande, j'ai installé Lil'Debi pour disposer de l'environnement de compilation adéquat, et également pour disposer d'un environnement GNU/Linux, auquel je peux me connecter à distance via SSH. La finalité de mon logiciel est de produire un fichier HTML, et j'affiche celui-ci dans un navigateur web sous Android, ce dernier ayant accès au système de fichiers de Lil'Debi.
À l'origine, je faisais tourner mon logiciel sur un Nokia N900, et c'était beaucoup plus simple parce que le N900 dispose d'un véritable environnement GNU/Linux. Malheureusement, l'écran du N900 est trop petit pour déchiffrer une partition. D'où l'utilisation d'une tablette, avec installation de Lil'Debi, pour me retrouver à peu prés avec le même environnent que celui du N900. Le problème, c'est que Lil'Debi rend la tablette poussive.
Du coup, j'ai repéré une tablette Intel hybride Android/Windows, ce qui m'offre les possibilité suivantes :
- Soit de remplacer Windows par une distribution GNU/Linux,
- soit d'installer Cygwin pour y retrouver un environnement à la GNU,
- soit de l'utiliser avec Android comme ma tablette actuelle, sachant qu'elle devrait pouvoir encaisser plus facilement Lil'Debi étant donné qu'elle a beaucoup plus de RAM, Windows oblige.
Au final, je cherche l'équivalent de mon N900 en tablette 10" ou plus, et le modèle que je décris ci-dessus s'en approche le plus, sachant que j'aimerais, en plus, en lui adjoignant un trackball et un clavier, pouvoir m'en servir de machine de développement secondaire, lorsque je suis en déplacement, et qu'il faut donc qu'elle soit assez costaude…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Trojita
Posté par Claude SIMON (site web personnel) . En réponse au journal Epeios Meta Mail User Agent : première publication.. Évalué à 1.
De ce que j'ai pu constater, on a, d'une part, les webmails, auxquels on peut accéder d'à peu prés n'importe quel dispositif connecté à Internet, mais qui ne sont, en gros, que des frontends IMAP, d'où le fait que l'on ne peut gérer qu'un seul compte mail à la fois, et, d'autre part, les clients natifs, qui peuvent proposer des fonctionnalités plus évoluées que celles disponibles avec IMAP, comme la gestion simultanée de plusieurs comptes en même temps, mais qui ne sont accessibles que d'une seule machine.
Ce que je cherche à obtenir, c'est le meilleur des deux mondes, c'est-à-dire pouvoir accéder à mon MUA d'un maximum de dispositifs connectés, et pouvoir cependant toujours disposer de toute les fonctionnalités de mon MUA, qui iront au-delà de celles disponibles IMAP.
C'est pour cela que mon MUA, contrairement aux MUA classiques qui accèdent directement aux serveurs POP3/IMAP, se connecte à un daemon, et c'est ce daemon se connectera aux différents comptes POP3/IMAP. Et comme c'est également ce daemon qui implémentera toutes les fonctionnalités de mon MUA, ces fonctionnalités seront disponibles quels que soient les clients utilisés (desktop, web ou mobile).
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Si, ça existe.
Posté par Claude SIMON (site web personnel) . En réponse au journal Epeios Meta Mail User Agent : première publication.. Évalué à 1.
Personnellement, le compte d'origine d'un mail m'importe peu, d'autant qu'il n'est pas rare que je change le compte d'affectation de mes alias. Faire passer ce lien entre courrier et compte au second plan est même l'un des objectifs de mon application. Mais la plupart des MUA sont, en quelque sorte, orientés comptes, donc, quelque part, je pense qu'il est préférable qu'un utilisateur qui utilisait ce genre de MUA puisse retrouver ce lien auquel il est habitué, bien que ce lien ne soit qu'accessoire au niveau de l'application.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Si, ça existe.
Posté par Claude SIMON (site web personnel) . En réponse au journal Epeios Meta Mail User Agent : première publication.. Évalué à 2.
Je viens d'installer Claws-Mail et, effectivement, contrairement à ce que je supputais dans le journal (et que j'entendais par « …indépendamment les uns des autres »), au moins avec ce logiciel, il est possible de déplacer un courrier d'un compte mail à un autre. Ceci dit, je ne pense pas que ce soit propre à ce logiciel ; cela doit être lié au protocole IMAP…
Néanmoins, dans Claws-Mail (à moins que j'ai loupé quelque chose dans ses options de configuration), chaque compte mail a sa propre arborescence, même si elles ne sont pas aussi imperméables que je le pensais. Or, je préfèrerais avoir une arborescence unique et commune à tous les comptes mail, même s'il doit rester possible de différencier les courriers en fonction du compte dont ils sont issus.
Pour ce qui est de l'écriture d'un nouveau courrier, je ne me suis pas encore penché sur la question, me concentrant pour l'instant sur la lecture de courriers (protocole IMAP et connexions chiffrées), mais je prend bonne note de la fonctionnalité décrite.
Pour nous émanciper des géants du numérique : Zelbinium !
# Alternative sans et avec fil
Posté par Claude SIMON (site web personnel) . En réponse au journal Quel Périphérique de pointage ?. Évalué à 1.
Après 4 Logitech M570 (dont deux suite à un remplacement sous garantie, à chaque fois accepté sans difficulté et rondement mené par Logitech), lassé par un problème récurrent de bouton gauche devenant inutilisable au bout d'à peu prés un an, j'ai actuellement un APTICO de SPEEDLINK. C'est un trackball sans fil à commande par pouce (à l'instar de Logitech, ils ne font pas (plus) de modèle filaire).
Cela fait moins d'un an que je le possède, donc je ne sais pas s'il tiendra plus longtemps que le M570, mais, malgré le fait qu'un des pieds en caoutchouc s'est barré (ce qui, personnellement, ne me dérange pas), et que le pointeur se bloque (bah oui, ça n'arrive pas qu'aux claviers) de temps en temps (il suffit alors d'actionner le bouton gauche et ça repart), il me convient.
Sinon, en filaire, mais je ne l'ai pas essayé, il existe le SANWA MA-TB39.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: HP !
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Création d'un multiroom audio à base de raspberry / hifiberry / max2play. Évalué à 1.
Je ne suis qu'un dilettante en la matière, donc je vais peut-être sortir une grosse connerie, mais je suis un jour tombé par hasard sur ça. Ça n'irait pas dans le sens de ce que tu décris ?
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: chromium, but not only
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 3.
Je n'ai jamais développé d'application web pour mes clients, et je n'ai pas l'intention d'en développer. L'interface de l’application présentée ici montre clairement que je n'ai pas les compétences en HTML, CSS et consorts pour cela (c'est pour cela que la facilité de modification de l'interface est un point clef de la technologie que j'emploie). D'ailleurs, si un prospect me contacte pour me demander de développer une application web, je lui dit sans équivoque qu'il lui sera facile de trouver développeur bien plus compétent et concurrentiel que moi pour cela.
Le fait est que les interfaces desktop que je développe s'appuient sur des technos web, pour les raisons expliquées dans ce journal. Du fait de l'utilisation de ces technos web, il me semblait juste logique que le même code puisse servir pour développer une version web de l'interface. Et c'est cette hypothèse qui fait l'objet d'une des POC présentés ici. L'interface web, c'est juste un bonus ; cela ne fait pas officiellement partie de mes prestations…
Au contraire, c'est parce que mes clients s'intéressent à la technique qu'ils me contactent. Ils sont bien conscients que c'est parce que les développeurs classiques n'ont pas la maîtrise des technologies qu'ils utilisent qu'ils ne sont pas capables de leur fournir une application qui réponde à leurs besoins. Avec mon framework, parce que j'en ai la totale maîtrise, je ne suis pas soumis au bon vouloir d'un éditeur pour en dépasser les limites.
Il vaut mieux une application développée dans une technologie soi-disant captive (mon framework, c'est quand même que du C++), mais qui réponde parfaitement aux besoins du client, qu'une application certes basée sur des technologies répandues, mais inutilisable à cause des limitations de ces technologies. Des clients dont les exigences sont telles que les technologies classiques ne peuvent y répondre sont peu nombreux, mais, d'un autre coté, comme on est peu de développeurs sur ce marché…
Je n'ai pas trop compris ce que tu entends par viser un usage pour les projets communautaires.
Concernant mon framework, du fait qu'il soit atypique et que la documentation est inexistante, il y a peu de chances que quelqu'un s'y intéresse ; je ne communique donc pas directement dessus. Par contre, une application telle que celle présentée ici, naturellement pas en l'état, est plus à même de susciter l'intérêt, voire de fédérer une communauté. Certes, il reste bien du travail pour que cette application soit utilisable, et c'est pour cela que j'insiste plus sur l'aspect POC que sur ses fonctionnalités. Mais, à terme, peut-être deviendra-t-elle un projet communautaire ? En tout cas, je n'y aurais rien à y redire…
Suite à ces journaux, j'observe quand même quelques téléchargements de mes logiciels. Sans préjuger de l'intention des téléchargeurs, on peut quand même supposer que mes logiciels, et donc leur évolution, les intéressent, d'où ces journaux pour communiquer à leur sujet…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # chromium, but not only
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 3. Dernière modification le 06 août 2016 à 09:08.
Ce n'est pas parce que c'est atypique que c'est imbitable. Et si tu m'indiquais précisément ce qui te semble imbitable, je me ferais un plaisir de te fournir les explications pour te le rendre bitable. Et ça me donnerais de précieuses indications sur ce que je dois mettre dans la documentation que je suis en train de rédiger.
Je me suis peut-être mal exprimé, mais, au contraire, depuis la mise à jour de Microsoft Edge, l'interface web fonctionne avec tous les navigateurs web graphiques modernes que j'ai pu essayer. Avec la démonstration en ligne, il y a moyen de s'en rendre compte par soi-même. Il y a juste Firefox qui pose problème dans certains cas, comme je l'ai expliqué…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Erreur lien 'technologie XDHTML'.
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 1.
C'est plutôt à moi de dire (enfin d'écrire) merci :-) !
Pour nous émanciper des géants du numérique : Zelbinium !
# Erreur lien 'technologie XDHTML'.
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 4.
Malgré mes multiples relectures, j'ai laissé passé une erreur sur le pénultième lien, celui sur la technologie XDHTML. Voici le lien correct.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: xdhbrwq/xdhbrwq XDHTML/orgnzqxdh
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 4. Dernière modification le 26 juillet 2016 à 10:17.
Quelles macros ? Les seules que je tape régulièrement, ce sont
qRH, qRB, qRR…, et leurs consœursqRFwk(), qRGnr()…; qui sont dédiées à la gestion d'erreurs ; algorithmiquement, elles ne sont pas significatives, et elles ne sont pas nécessaires à la compréhension du code, sauf quand celui-ci s'occupe de la gestion des erreurs, évidemment. Quant aux autres macros, elles existent juste pour m'éviter d'avoir à taper du code dont j'ai fréquemment besoin, mais elles ne constituent certainement pas un nouveau dialecte.Si l'on m'indique quelles macros posent problème, je détaillerais volontiers leurs usages…
Ce n'est de loin pas de l'informatique abstraite : la preuve, il y a une démonstration accessible en ligne qui montre que c'est au contraire tout à fait concret. Quand à cette histoire de surcouche avec HTML, je n'ai pas trop compris. Cela concerne peut-être ce que j'ai décris dans ce journal.
Pour ce qui est d'avoir besoin d'un quadricœur avec 4GO de RAM, il y a un package disponible avec les binaires Windows destinés à du XP SP3 et supérieur, et un autre pour du GNU/Linux compatible IA-32 ou AMD64 natif. Ces packages sont relativement simple à déployer (mais je concède que c'est améliorable), et je suis preneur de tout retour sur leur mise en œuvre.
Soit dit en passant, comme je l'ai signalé, la CGI et le backend tournent sans problèmes sur une brique internet, à savoir une architecture ARM 32 bits dual-core à 1 GHz avec 512 Mo de RAM. Pour ceux qui disposent d'un matériel similaire tournant sous GNU/Linux, ils peuvent le vérifier ; je décris la procédure dans le journal. Et enfin, il y a la démonstration en ligne ; là aussi, je suis preneur de tout retour sur les ressources nécessaires et les éventuels problèmes rencontrés en fonction du navigateur utilisé.
Pour nous émanciper des géants du numérique : Zelbinium !